Subject: [6tisch-security] Joining node and DeviceDescriptor

From: Giuseppe Piro <[email-masked]>
Date: Tue, 2 Dec 2014 17:19:45 +0100

Rene,
many thanks for the today's discussion.

I've understood that we could use the EXTEMP flag for mixing
unprotected and protected packets within a secured network. I agree
with this point.

The problem I've remarked during the call is related to the creation
of the DeviceDescriptor associated to the joining node (that stores
the EXTEMP flag).

In particular, form the reading of the IEEE 802.15.4 specification,
I've realized that in the Incoming Frame Security Procedure we have
that:

- the presence of the DeviceDescriptor is done at the step "g". The
Device Descriptor Lookup Procedure may return a failed status in the
case the descriptor is not found.
- the check of the EXTEMP flag is done at the step "j" and it supposes
that the previous function did not return an error

In the case EXTEMP flag is set to TRUE, the neighbor node can receive
an unprotected packet. I'm fine with this.

My question was related to the creation of the related
DeviceDescriptor. In the case the joining node sends for the first
time the message, the incoming frame security procedure will fail at
the step "g".

To solve the problem, the neighbor node may generate a new
DeviceDescriptor (with the EXTEMP flag set to true, for the moment),
thus being able to receive next joining messages from the same device.

Did I capture well your point ?

In that case, does the joining procedure waste resources (in terms of
packets, delays, etc..) ?

What do you think ?

Thanks and regards,
Giuseppe

-- 
Giuseppe Piro, PhD
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: giuseppepiro.com

---

From: Rene Struik <[email-masked]>
Date: Tue, 02 Dec 2014 12:43:44 -0500

Hi Giuseppe:

Thanks for your note (and for good points on the call).

Correct. The exempt flag is simply a mechanism to ensure that the higher 
layer can act on a received MAC data frame received from the joining 
node also when the joining node does not have cryptographic keying 
material yet. With the first message, while MAC security processing 
fails, this is overridden ("pass through filter") by setting the flag 
via intervention of the higher layer; once the exempt flag is set, this 
is automatic. In either case, once the received frame is at the higher 
layer, the higher layer can act on it at that stack level. As said on 
the call, the higher layer should only set this flag if it wants to 
accept entertaining join messages and should remove the flag once the 
joining device should have the proper keys or spent its grace period.

I did not check the reference to processing steps for now, but 
essentially trust this to be correct. Will revisit MAC aspects later on.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Giuseppe Piro <[email-masked]>
Date: Tue, 2 Dec 2014 22:38:44 +0100

Rene,

I've definitively got (and agree)  this point.

>From my understanding of the standard,  in the case
the device addressing mode is set to NO_ADDRESS, the Device Descriptor
Lookup procedure may return a Device Descriptor associated the
macCoordShortAddress, which exists since from the first message sent
by the joining node.

In this way, the Incoming Frame Security Procedure does not fail (at
the step "g") and the exempt flag can be checked (at the step "j").

I'm not sure that this is a good solution... but we can spent few time
to understand if this aspect could be useful or not.

Regards,
Giuseppe

On Tue, Dec 2, 2014 at 6:43 PM, Rene Struik <[email-masked]> wrote:
> layer can act on a received MAC data frame received from the joining node
> also when the joining node does not have cryptographic keying material yet.
> With the first message, while MAC security processing fails, this is
> overridden ("pass through filter") by setting the flag via intervention of
> the higher layer; once the exempt flag is set, this is automatic. In either
> case, once the received frame is at the higher layer, the higher layer can
> act on it at that stack level. As said on the call, the higher layer should
> only set this flag if it wants to accept entertaining join messages and
> should remove the flag once the joining device should have the proper keys
> or spent its grace period.
>
> I did not check the reference to processing steps for now, but essentially
> trust this to be correct. Will revisit MAC aspects later on.
>
> Best regards, Rene
>
>
>