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

From: Rene Struik <[email-masked]>
Date: Thu, 04 Dec 2014 09:09:50 -0500

Hi Tero:

Please note that setting the security level for data frames to zero would have any MAC data frame, irrespective of originating device pass incoming processing and be pushed to the higher layer, whereas with the exempt flag mechanism this is only the case for those data frames that originate from a specifically identified device (in casu, the joining node).

Since MAC security processing (with security switched on) impacts the recipient device's state, one cannot do "after the fact" pass/stop filtering at the higher layer without risking entirely messing up security-related tables at the MAC.

Thus, your suggestion about "wrongness" may itself be wrong (well: imprudent).

Best regards, Rene

==
Actually doing any of the security level checking on the MAC level is
wrong unless the frame is something that is responded by the MAC level
too. I.e. if the frame is something that is always passed to the upper
layer for processing then there is no point of doing security level
checking in the mac. On the other hand if frame is something that is
processed on the MAC level and automatically responded from there,
then security level processing needs to be done on the MAC level.

On 12/4/2014 6:59 AM, Tero Kivinen wrote:
> Michael Richardson writes:
>> From: Giuseppe Piro <[email-masked]>
>> Sender: "6tisch-security" <[email-masked]>
>> Subject: [6tisch-security] Joining node and DeviceDescriptor
>> 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.
> I assume oyu mean Exempt flag.
>
>> 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).
> This is not true anymore in the 802.15.4-2015.
>
> In the revision the Exempt flag is moved to the
> DeviceDescriptorSecLevelZero table, which is used for security level
> zero packets only. This is because the Frame Counter that is also in
> the DeviceDescriptor table needs to be moved to be per key, not per
> device, so we needed to separate the per key and per device uses of
> the DeviceDescriptor.
>
>> 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.
> Yes, but if the security level is zero, then
> DeviceDescriptorSecLevelZero table is looked instead and if entry is
> found from there, then that is returned.
>
>> - the check of the EXTEMP flag is done at the step "j" and it supposes
>> that the previous function did not return an error
> Yes, and the actual security level checking is done in step i) where
> we match that the security level of the incoming packet is at least
> the level specfied in the SecurityLevelDescriptor table. That step can
> return "conditionally passed" status, which means that security level
> was 0, but the security policy mentioned that minimum security level
> might be overriden per device basis (i.e.
> DeviceOverrideSecurityMinimum is true). Only and only in that case is
> the exempt flag checked.
>
> Btw, I am working on to simplify the security state machines in the
> 15.4, and I have already worked on the outbound one, but still need to
> work on the inbound state machine.
>
> If you want to see what I have done for the outboud state machine
> check the following document:
>
> https://mentor.ieee.org/802.15/documents?is_dcn=704&is_group=0mag&is_year=2014
>
> I hope to update that next week to include the inboud state machine
> too. If you have any comments please send them to me, I would really
> like to have someone else to check out them too, in addition to me.
>
>> In the case EXTEMP flag is set to TRUE, the neighbor node can receive
>> an unprotected packet. I'm fine with this.
> Only if DeviceOverrideSecurityMinimum is set to true for those frames
> where security override is allowed, and the device is listed in the
> exemption table.
>
> If you really want to mix unsecured and secured frames, it is better
> to just set the AllowedSecurityLevels or the SecurityMinimum elements
> properly, i.e. say that for data frames the allowed security level is
> 0 and check the security levels in the MCPS-DATA.indication call (i.e.
> allow upper layer to do the work).
>
> Actually doing any of the security level checking on the MAC level is
> wrong unless the frame is something that is responded by the MAC level
> too. I.e. if the frame is something that is always passed to the upper
> layer for processing then there is no point of doing security level
> checking in the mac. On the other hand if frame is something that is
> processed on the MAC level and automatically responded from there,
> then security level processing needs to be done on the MAC level.
>
>> 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".
> Yes. And as the DeviceDescriptor / DeviceDescriptorSecLevelZero table
> filling is upper layers problem, it needs to take care of this. The
> 802.15.4 does not specify how this is done, and it is outside the
> scope of the spec.
>
> The specification do have MLME-COMM-STATUS.indication call which will
> be called when "on receipt of a frame that generates an error in its
> security processing, as described in 9.2.3.".
>
> I.e on the first message the upper layer will be notified that it
> received a packet which failed the security processing, and then the
> upper layer can fill in the DeviceDescriptor /
> DeviceDescriptorSecLevelZero tables as needed and the next packet will
> then be properly processed.
>
>> 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 ?
> I think it is better to configure the security so that
> macSecurityLevelTable the SecurityMinimum is set to zero for those
> frame types which we want to receive in clear also.
>
> We have exactly same problem in the 15.9, as we (joining node) are
> setting up the security with node which is already having security set
> up (coordinator). We are using either data or multipurpose frames when
> sending our packets out (with empty data, and all our data in the
> payload IE). Before 15.9 can be used the upper layer needs to
> configure the security levels of the SecurityLevelDescriptor
> accordingly, so that security level zero packets are allowed to pass
> the security level processing.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Dec 2014 13:59:03 +0200

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2014 11:58:29 +0200

Rene Struik writes:
> Please note that setting the security level for data frames to zero
> would have any MAC data frame, irrespective of originating device
> pass incoming processing and be pushed to the higher layer, whereas
> with the exempt flag mechanism this is only the case for those data
> frames that originate from a specifically identified device (in
> casu, the joining node). 

Yes, but when we discussed this in the 15.9 the comment was that upper
layer needs to verify the security level anyways. For example upper
layer do not have a way to distinguish data frames from multipurpose
frames, thus trying to set up different security level requirements
for the data and multipurpose frames does not work. Also it is
impossible to know the joining nodes address beforehand, thus entry
for exempt flag cannot be filled there beforehand, which means first
packet would always be lost.

And if you have any exempts in your table, then you still need to
verify the security levels in the upper layer.

> Since MAC security processing (with security switched on) impacts
> the recipient device's state, one cannot do "after the fact"
> pass/stop filtering at the higher layer without risking entirely
> messing up security-related tables at the MAC. 

15.9 will recommend that all security level checking will be done on
the upper layer, and no filtering are done on the MAC layer, mostly
because the exempt flag processing does not really work that well for
the first connection case.

Unsecured data or multipurpose frames received by the peer do not have
any impact on any of the state in MAC, and do not affect the security
related tables at the MAC. Those frames are simply passed to the upper
layer, which can then check the security level parameter and act
accordingly, so the policy checking can be done after the fact on the
upper layer, and in most cases it needs to be done there.

Thus there is no functional benefits for doing those checks on the MAC
layer for data and multipurpose frames (which are not acted upon on
the MAC layer).

The minimum security level processing in the MAC is only useful for
frames which are acted upon on the MAC layer.
-- 
[email-masked]