Subject: [6tisch] IE Header Termination List. Minimal.

From: José Ángel Miranda <[email-masked]>
Date: Tue, 16 Jun 2015 09:18:40 +0200

Hi,

Looking at the new minimal conf (07- 08 - 09), we have observed in the IEs
example with and without security that a termination Header IE, indicating
Payload IE coming next, is added. We would like to know where, within the
standard, this is described, or if you have taken this configuration due to
any specific reason. Actually, there is no need to add the termination
Header IE, as within the Payload IE you can easily distinguish the type in
the outer IE descriptor.
It would be nice to know if this configuration will be required for the
plugtest 17 - 18 Jul.

Another question related to the test specification document for the this
plugtest, have you already released this document ? and in that case, where
can we find it?

Cheers,
Jose.

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 16 Jun 2015 16:56:29 +0200

Jose,

I believe you need to add a header termination IE before sending a payload
IE. This was pointed out during our recent discussion; I'll let the authors
confirm.

The specs for the plugtest have been distributed on the plugtest ML, please
contact me offline if you didn't receive them.

Thomas

On Tue, Jun 16, 2015 at 9:18 AM, José Ángel Miranda <[email-masked]>
wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 16 Jun 2015 18:39:24 +0200

Hi Jose,

when writing the draft we consulted one of the authors of 15.4e about the
same issue. His answer said that the original intent when the spec was
drafted was that the termination IE was only required when a header IE was
followed by something. The problem is, if we get a frame with no header IE,
how do we know what follows is a payload IE, or it is just payload that
looks like a payload IE? In 15.4, where any frame could come at any time,
we need a header terminator to tell us how to parse the rest of the packet.

so that is the reason for having it there. Any thoughts?

regards,
Xavi

2015-06-16 16:56 GMT+02:00 Thomas Watteyne <[email-masked]>:

> The specs for the plugtest have been distributed on the plugtest ML,
> please contact me offline if you didn't receive them.
>
> Thomas
>
>> Looking at the new minimal conf (07- 08 - 09), we have observed in the
>> IEs example with and without security that a termination Header IE,
>> indicating Payload IE coming next, is added. We would like to know where,
>> within the standard, this is described, or if you have taken this
>> configuration due to any specific reason. Actually, there is no need to add
>> the termination Header IE, as within the Payload IE you can easily
>> distinguish the type in the outer IE descriptor.

---

From: Rene Struik <[email-masked]>
Date: Tue, 16 Jun 2015 14:39:48 -0400

Hi Xavier:

Since your email suggested the 802.15.4e-2012 spec is ambiguous, I 
thought to check.

According to the 15.4e spec, the value of the IE List Present field in 
the FCF signals whether or not IEs are included in the frame (see Clause 
5.2.11.5b). Header and Payload IEs can be distinguished via the Type 
field (bit 15: set to zero if Header IE; set to one otherwise)  and are 
self-contained TLV data objects (see Clauses 5.2.4.2 and 5.2.4.3).

Note that IEs should only be processed at receipt after successful 
incoming frame security processing (i.e., IEs can be assumed to be 
available in the clear for this discussion).

 From this, it follows that one can easily find the demarcation line 
between Header and Payload IEs if both are present (simply parse the 
frame). Moreover, the set of Header IEs can be uniquely determined, 
without requiring a special termination symbol. If there are no Payload 
IEs, Header IEs may have the same syntax as the leftmost segment of the 
MAC payload field (with Data frames, Beacon frames, ACK frames, and even 
for Command frames [despite of the Command Type octet preceding the 
remainder of the payload]). Hence, one needs a termination symbol 
('comma symbol') to make sure one can unambiguously parse this. 
Independent of presence of Header IEs, Payload IEs again can have the 
same syntax as leftmost segments of the MAC payload and therefore 
requiring a termination symbol ('comma' symbol).

For incoming security processing, one needs to be able to distinguish 
the frame fields that constitute the 'm' field and the 'a' field in the 
CCM mode of operation. If Header IEs are present, this does require a 
termination symbol ('comma symbol'), since the encrypted payload field 
has a chance of having the same syntax.

In summary,
- if security is enabled, Header IEs require a termination symbol (so as 
not to confuse incoming security processing). This even holds if there 
are no Header IEs (since the encrypted payload may still look like a 
Header IEs);
- Payload IEs require a termination symbol (so as not to cause leftmost 
segment of payload data to be confused with payload IEs). This holds 
even if there are no Payload IEs and holds irrespective of whether 
security is enabled.

So, if there are IEs (as indicated by the IE List Present field), one has
a) Header IEs present, Payload IEs present: need for termination symbol 
for Header IEs, if security enabled; need for termination symbol for 
Payload IEs if confusion with remainder payload possible. [2 
"terminators" if security enabled; 1 if unsecured frame with payload 
(4-octet overhead w/ security; o.w., 2-octets)]
b) Header IEs present, Payload IEs not present: need for termination 
symbol for Header IEs if security enabled; need for termination symbol 
for (empty set of) Payload IEs if confusion with remainder payload 
possible. [2 "terminators" if security enabled; 1 if unsecured frame 
with payload (4-octet overhead w/ security; o.w., 2-octets)]
c) Header IEs not present, Payload IEs present: need for termination 
symbol for Header IEs if security enabled; need for termination symbol 
for Payload IEs if confusion with remainder payload possible. [2 
"terminators" if security enabled; 1 if unsecured frame with payload 
(4-octet overhead w/ security; o.w., 2-octets)]

It is quite a pity that the IE termination symbols eat up so much 
per-frame space, since this could easily have been avoided, e.g., if it 
had been defined as follows:
- have IEs start with ID field, which would allow defining termination 
symbols as 0xff (both for Payload and Header IEs), thus saving 2-octets 
per frame in most cases;
-have IEs codify length, so as to allow unambiguously determining how 
many Payload IEs actually follow, thus saving a Payload termination 
symbol. {This would have allowed 1-byte "terminators" in total with 
security and none at all, with careful design.}

Perhaps, removing some of the waste can be funneled back to 802.15.4rev?

On 6/16/2015 12:39 PM, Xavier Vilajosana wrote:
> Hi Jose,
>
> when writing the draft we consulted one of the authors of 15.4e about 
> the same issue. His answer said that the original intent when the spec 
> was drafted was that the termination IE was only required when a 
> header IE was followed by something. The problem is, if we get a frame 
> with no header IE, how do we know what follows is a payload IE, or it 
> is just payload that looks like a payload IE? In 15.4, where any frame 
> could come at any time, we need a header terminator to tell us how to 
> parse the rest of the packet.
>
> 2015-06-16 16:56 GMT+02:00 Thomas Watteyne <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Jose,
>
>     I believe you need to add a header termination IE before sending a
>     payload IE. This was pointed out during our recent discussion;
>     I'll let the authors confirm.
>
>     The specs for the plugtest have been distributed on the plugtest
>     ML, please contact me offline if you didn't receive them.
>
>     Thomas
>
>     On Tue, Jun 16, 2015 at 9:18 AM, José Ángel Miranda
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         Looking at the new minimal conf (07- 08 - 09), we have
>         observed in the IEs example with and without security that a
>         termination Header IE, indicating Payload IE coming next, is
>         added. We would like to know where, within the standard, this
>         is described, or if you have taken this configuration due to
>         any specific reason. Actually, there is no need to add the
>         termination Header IE, as within the Payload IE you can easily
>         It would be nice to know if this configuration will be
>         required for the plugtest 17 - 18 Jul.
>
>         Another question related to the test specification document
>         for the this plugtest, have you already released this document
>         ? and in that case, where can we find it?
>
>         Cheers,
>         Jose.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Jun 2015 01:58:24 +0300

Rene Struik writes:
> According to the 15.4e spec, the value of the IE List Present field
> in the FCF signals whether or not IEs are included in the frame (see
> Clause 5.2.11.5b).

This is true. 

> Header and Payload IEs can be distinguished via the Type field (bit
> 15: set to zero if Header IE; set to one otherwise)  and are

This is not. Nothing in the 802.15.4e says that there cannot be long
format for header IEs, or that you cannot have short format for
payload IEs. On the other hand the section 5.2.2.6.17 says:

	5.2.2.6.17 IEs field

	The IEs field is variable in length and is present if the IEs
	Present field is set to one. The format of IEs is specified in
	5.2.4. It contains Header IEs, followed by Payload IEs. Each
	type of IE list is terminated as required per 5.2.4.22.

I.e. both IE lists are terminated as required per 5.2.4.22. The
5.2.4.22 says:

	5.2.4.22 IE List Termination IE

	The Header IE list is terminated with an IE List Termination
	IE (ID = 0x7e or 0x7f) that has a content length of zero.
	Explicit termination is required after a Header IE if there is
	one or more Payload IEs (0x7e), or MAC payload (0x7f),
	following the Header IE list. If an unformatted payload
	follows the Payload IE list, then the payload IE list is
	terminated with a list termination IE (ID = 0xf) that has a
	content length of zero. Otherwise the terminator may be
	omitted.

I.e. no header termination IE is needed if there is nothing coming
after it. The 0x7e is needed if there is Payload IEs after Header IEs,
and 0x7f is needed if there is no Payload IEs, but there is payload
after it.

> Note that IEs should only be processed at receipt after successful incoming
> frame security processing (i.e., IEs can be assumed to be available in the
> clear for this discussion).

Actually this is not specified in the 802.15.4e... Also several of
those IEs are processed by MAC, and even if the frame is accepted from
node A with data payload, that does not mean that all IEs in that
frame is something that will be accepted.

In the 802.15.4rev there is new security tables similar to the Frame
security tables for IEs, to specify whether they are accepted or
ignored by the MAC. 
-- 
[email-masked]

---

From: José Ángel Miranda <[email-masked]>
Date: Fri, 19 Jun 2015 13:47:25 +0200

Hi,

Ok, after having read your answers I would like to clarify some points:

- Following the current standard*, IEs payload are NOT encrypted.*
- Within an Enhanced Beacon, the MAC payload conforms IEs payload + Beacon
Payload.
- The inclusion of IEs within the frame is indicated via FCF( bit 9 ).

These assumptions are correct and based on the current standard ( 802.15.4e
- 2012 ), in which the minimal is based.
Therefore, when receiving a frame, specifically a beacon, there is no need
to add a termination Header IE before the Payload IEs due to the following
reasons:
- When having received the beacon, you can check whether it has Information
Elements or not by just checking the FCF.
- Header IEs and Payload IEs have different type within the first 2 byte
descriptor ( Header IEs have type 0 and Payload IEs have type 1 ).
- If Header IEs are not present and Payload IEs are present, after having
read the MAC Header the next byte to read will be Payload IEs and together
with identification of the IE type ( Payload IEs type 1 ) you already have
a way to know that what you have are Payload IEs, thus you do not have to
add a termination Header IE before.

In case of following other standard rather than the current one ( may be
the next rev. ), when having the Payload IEs encrypted (* this is NOT as
specified in the current standard* ), there would be one condition where
the termination Header IE is strictly required:
- You would have the IE list present bit set within the FCF and at time to
decrypt the frame you need to know, in order to operate properly the
incoming security procedure, what is 'c data' and 'a data', therefore you
need to add a termination Header IE in order to: avoid possible confusion
with the non-formatted encrypted payload and know where the MAC Header
ends.

Taking into account these points, the beacon showed within the minimal
draft should be modified ( omitting the termination Header IE ).

Cheers,
Jose.

2015-06-18 0:58 GMT+02:00 Tero Kivinen <[email-masked]>:

> incoming

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Jun 2015 09:22:18 -0500

I have been reading these emails on IE Headers with great interest.  In the IEEE 802.15 maintenance standing committee we often have long discussions on how IEs should be used and as a result have started an interest group on an IEEE 802.15.4 guide.  As part of that effort I have created an IE Table guide, 15-15-0090-06 <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>, https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>.  If you wish to review it, this is a publicly available document.

But to the points raised:
- "there is no need to add a termination header IE” - this is incorrect, the IE termination header IE is required to be transmitted before the payload IEs.
- “header IEs and Payload IEs have a different type within the first 2-byte descriptor” - this is incorrect, currently there is no overlap but we will need these extra IDs in the future.
- "If Header IEs are not present and Payload IEs are present, after having read the MAC Header the next byte to read will be Payload IEs and together with identification of the IE type ( Payload IEs type 1 ) you already have a way to know that what you have are Payload IEs, thus you do not have to add a termination Header IE before”  This is incorrect

I have included an example of an Enhanced Beacon in the IE Table Guide.  Please let me know if you believe I have made a mistake and why you believe it is a mistake.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

On 19, Jun2015, at 6:47, José Ángel Miranda <[email-masked]> wrote:

Hi,

- Following the current standard, IEs payload are NOT encrypted.
- Within an Enhanced Beacon, the MAC payload conforms IEs payload + Beacon Payload.
- The inclusion of IEs within the frame is indicated via FCF( bit 9 ).

These assumptions are correct and based on the current standard ( 802.15.4e - 2012 ), in which the minimal is based.
Therefore, when receiving a frame, specifically a beacon, there is no need to add a termination Header IE before the Payload IEs due to the following reasons:
- When having received the beacon, you can check whether it has Information Elements or not by just checking the FCF.
- Header IEs and Payload IEs have different type within the first 2 byte descriptor ( Header IEs have type 0 and Payload IEs have type 1 ).
- If Header IEs are not present and Payload IEs are present, after having read the MAC Header the next byte to read will be Payload IEs and together with identification of the IE type ( Payload IEs type 1 ) you already have a way to know that what you have are Payload IEs, thus you do not have to add a termination Header IE before.

In case of following other standard rather than the current one ( may be the next rev. ), when having the Payload IEs encrypted ( this is NOT as specified in the current standard ), there would be one condition where the termination Header IE is strictly required: 
- You would have the IE list present bit set within the FCF and at time to decrypt the frame you need to know, in order to operate properly the incoming security procedure, what is 'c data' and 'a data', therefore you need to add a termination Header IE in order to: avoid possible confusion with the non-formatted encrypted payload and know where the MAC Header ends. 

Taking into account these points, the beacon showed within the minimal draft should be modified ( omitting the termination Header IE ).

Cheers,
Jose.

This is true.

        5.2.2.6.17 IEs field

In the 802.15.4rev there is new security tables similar to the Frame
security tables for IEs, to specify whether they are accepted or
ignored by the MAC.
--
[email-masked] <mailto:[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 19 Jun 2015 15:36:40 +0100

Pat - just one point below.

Robert

On 19 June 2015 at 15:22, Pat Kinney <[email-masked]>
wrote:

> I have been reading these emails on IE Headers with great interest.  In
> the IEEE 802.15 maintenance standing committee we often have long
> discussions on how IEs should be used and as a result have started an
> interest group on an IEEE 802.15.4 guide.  As part of that effort I have
> created an IE Table guide, 15-15-0090-06
> <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>,
> https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx.
> If you wish to review it, this is a publicly available document.
>
> - "there is no need to add a termination header IE” - this is incorrect,
> the IE termination header IE is required to be transmitted before the
> payload IEs.
>

<RCC>Surely if there are only header IEs, no payload IEs *and no MAC
payload*, there is no need for a termination header IE after the header
IEs?</RCC>

> - “header IEs and Payload IEs have a different type within the first
> 2-byte descriptor” - this is incorrect, currently there is no overlap but
> we will need these extra IDs in the future.
> - "If Header IEs are not present and Payload IEs are present, after having
> add a termination Header IE before”  This is incorrect
>
> I have included an example of an Enhanced Beacon in the IE Table Guide.
> Please let me know if you believe I have made a mistake and why you believe
> it is a mistake.
>
> Pat
>
>
> Pat Kinney
> *Kinney Consulting LLC*
> [email-masked]
>
>
> These assumptions are correct and based on the current standard (
> 802.15.4e - 2012 ), in which the minimal is based.
> - When having received the beacon, you can check whether it has
> Information Elements or not by just checking the FCF.

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Jun 2015 09:42:37 -0500

No, even if there are no Header IEs, the header IE termination is required if there are Payload IEs

Pat

Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 9:36, Robert Cragie <[email-masked]> wrote:

Robert

On 19 June 2015 at 15:22, Pat Kinney <[email-masked] <mailto:[email-masked]>> wrote:
I have been reading these emails on IE Headers with great interest.  In the IEEE 802.15 maintenance standing committee we often have long discussions on how IEs should be used and as a result have started an interest group on an IEEE 802.15.4 guide.  As part of that effort I have created an IE Table guide, 15-15-0090-06 <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>, https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>.  If you wish to review it, this is a publicly available document.

<RCC>Surely if there are only header IEs, no payload IEs *and no MAC payload*, there is no need for a termination header IE after the header IEs?</RCC>

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715 <tel:%2B1.847.960.3715>
[email-masked] <mailto:[email-masked]>

On 19, Jun2015, at 6:47, José Ángel Miranda <[email-masked] <mailto:[email-masked]>> wrote:

Hi,

Cheers,
Jose.

This is true.

        5.2.2.6.17 IEs field

_______________________________________________
6tisch mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

_______________________________________________
6tisch mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 19 Jun 2015 16:44:37 +0200

Pat,

I believe Robert considers the case in which the frame has only:
- header IEs
- NO payload IEs
- NO payload

In that case, we don't see a Termination IE for the header IEs, right?

Thomas

On Fri, Jun 19, 2015 at 4:42 PM, Pat Kinney <
[email-masked]> wrote:

>> <https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx>
>> , https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx.
>> - "If Header IEs are not present and Payload IEs are present, after
>> having read the MAC Header the next byte to read will be Payload IEs and
>> together with identification of the IE type ( Payload IEs type 1 ) you
>> already have a way to know that what you have are Payload IEs, thus you do
>> not have to add a termination Header IE before”  This is incorrect
>>
>> Therefore, when receiving a frame, specifically a beacon, there is no
>> need to add a termination Header IE before the Payload IEs due to the
>> following reasons:
>> - You would have the IE list present bit set within the FCF and at time
>> to decrypt the frame you need to know, in order to operate properly the

---

From: Rene Struik <[email-masked]>
Date: Fri, 19 Jun 2015 10:47:20 -0400

On 6/19/2015 10:22 AM, Pat Kinney wrote:
> I have been reading these emails on IE Headers with great interest. 
>  In the IEEE 802.15 maintenance standing committee we often have long 
> interest group on an IEEE 802.15.4 guide.  As part of that effort I 
> have created an IE Table guide, 15-15-0090-06 
> https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx.  If 
> you wish to review it, this is a publicly available document.
>
> - "there is no need to add a termination header IE” - this is 
> incorrect, the IE termination header IE is required to be transmitted 
> before the payload IEs.
RS>> This statement seems incorrect. Please see 802.15.4e-2012, Clause 
5.2.4.22: that clause does not say anything about the explicit 
termination in the scenario where there are no Header IEs. Technically, 
there is also no need (if at most authentication is required, since 
Header IEs and Payload IEs can be distinguished). {If confidentiality is 
provided, then one would have to include this, as my analysis already 
showed}.
<<RS
> 2-byte descriptor” - this is incorrect, currently there is no overlap 
> but we will need these extra IDs in the future.
RS>> This statement seems incorrect as well. Please see 802.15.4e-2012, 
Clause 5.2.4.2: Header IEs and Payload IEs differ on the Type Subfield. 
The ID space is a different subfield altogether.
<<RS
> having read the MAC Header the next byte to read will be Payload IEs 
> and together with identification of the IE type ( Payload IEs type 1 ) 
> you already have a way to know that what you have are Payload IEs, 
> thus you do not have to add a termination Header IE before”  This is 
> incorrect
RS>> I would like to understand this, since this statement seems 
incorrect as well, based on the current 802.15.4e-2011 spec.
<<RS
>
> I have included an example of an Enhanced Beacon in the IE Table 
> Guide.  Please let me know if you believe I have made a mistake and 
> why you believe it is a mistake.
>
> Pat
>
>
> Pat Kinney
> */Kinney Consulting LLC/*
> <mailto:[email-masked]>
>
>
> - Header IEs and Payload IEs have different type within the first 2 
> byte descriptor ( Header IEs have type 0 and Payload IEs have type 1 ).
> - If Header IEs are not present and Payload IEs are present, after 
> having read the MAC Header the next byte to read will be Payload IEs 
> and together with identification of the IE type ( Payload IEs type 1 ) 
> you already have a way to know that what you have are Payload IEs, 
> thus you do not have to add a termination Header IE before.
>
> In case of following other standard rather than the current one ( may 
> be the next rev. ), when having the Payload IEs encrypted (*this is 
> NOT as specified in the current standard* ), there would be one 
> condition where the termination Header IE is strictly required:
> - You would have the IE list present bit set within the FCF and at 
> time to decrypt the frame you need to know, in order to operate 
> properly the incoming security procedure, what is 'c data' and 'a 
> data', therefore you need to add a termination Header IE in order to: 
> avoid possible confusion with the non-formatted encrypted payload and 
> know where the MAC Header ends.
>

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Jun 2015 09:49:33 -0500

Sorry, I misunderstood.  In the case of a frame with Header IE(s), no Payload IE(s), and no Payload; no termination “is required” since the end of the frame can be determined by the frame length and CRC type.  

Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 9:44, Thomas Watteyne <[email-masked]> wrote:

Pat,

Thomas

On Fri, Jun 19, 2015 at 4:42 PM, Pat Kinney <[email-masked] <mailto:[email-masked]>> wrote:
No, even if there are no Header IEs, the header IE termination is required if there are Payload IEs

Pat

Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 9:36, Robert Cragie <[email-masked] <mailto:[email-masked]>> wrote:

Robert

 

Pat

Pat Kinney
Kinney Consulting LLC

Hi,

Cheers,
Jose.

This is true.

        5.2.2.6.17 IEs field

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Jun 2015 09:56:47 -0500

Rene;

The points you mention have been discussed for long periods of time and the conclusions are in the IE Table document.  You might recall that Ben Rolfe was the technical editor in charge of IEs for 802.15.4e-2012 and he was the person we tagged to write the IE Termination Explanation in the IE Table document.  If you wish to challenge the SCmaintenance’s interpretation of IEEE 802.15.4, please submit your cause, BUT read the IE Table document first!  In the case of "that clause does not say anything about the explicit termination in the scenario where there are no Header IEs”  the SC maintenance must go beyond what is not stated to make sure all cases are covered.

Pat

Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 9:47, Rene Struik <[email-masked]> wrote:

> - "there is no need to add a termination header IE” - this is incorrect, the IE termination header IE is required to be transmitted before the payload IEs.
RS>> This statement seems incorrect. Please see 802.15.4e-2012, Clause 5.2.4.22: that clause does not say anything about the explicit termination in the scenario where there are no Header IEs. Technically, there is also no need (if at most authentication is required, since Header IEs and Payload IEs can be distinguished). {If confidentiality is provided, then one would have to include this, as my analysis already showed}.
<<RS
> - “header IEs and Payload IEs have a different type within the first 2-byte descriptor” - this is incorrect, currently there is no overlap but we will need these extra IDs in the future.
RS>> This statement seems incorrect as well. Please see 802.15.4e-2012, Clause 5.2.4.2: Header IEs and Payload IEs differ on the Type Subfield. The ID space is a different subfield altogether.
<<RS
> - "If Header IEs are not present and Payload IEs are present, after having read the MAC Header the next byte to read will be Payload IEs and together with identification of the IE type ( Payload IE…
RS>> I would like to understand this, since this statement seems incorrect as well, based on the current 802.15.4e-2011 spec.
<<RS

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

---

From: Rene Struik <[email-masked]>
Date: Fri, 19 Jun 2015 11:02:06 -0400

Hi Pat:

6TiSCH should base its assessment on the 802.15.4e-2012 specification, 
not on hearsay and "personal oracles". Hence, my *technical* note.

Position-based arguing dilutes the value of technical discussion.

Rene

On 6/19/2015 10:56 AM, Pat Kinney wrote:
> Rene;
>
> The points you mention have been discussed for long periods of time 
> and the conclusions are in the IE Table document.  You might recall 
> that Ben Rolfe was the technical editor in charge of IEs for 
> 802.15.4e-2012 and he was the person we tagged to write the IE 
> Termination Explanation in the IE Table document.  If you wish to 
> challenge the SCmaintenance’s interpretation of IEEE 802.15.4, please 
> submit your cause, BUT read the IE Table document first!  In the case 
> of "that clause does not say anything about the explicit termination 
> in the scenario where there are no Header IEs”  the SC maintenance 
> must go beyond what is not stated to make sure all cases are covered.
>
> Pat
>
> Pat Kinney
> On 19, Jun2015, at 9:47, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> termination in the scenario where there are no Header IEs. 
> Technically, there is also no need (if at most authentication is 
> required, since Header IEs and Payload IEs can be distinguished). {If 
> confidentiality is provided, then one would have to include this, as 
> my analysis already showed}.
> <<RS
> RS>> This statement seems incorrect as well. Please see 
> 802.15.4e-2012, Clause 5.2.4.2: Header IEs and Payload IEs differ on 
> the Type Subfield. The ID space is a different subfield altogether.
> <<RS
>> and together with identification of the IE type ( Payload IEs type 1 
>> ) you already have a way to know that what you have are Payload IEs, 
>> and together with identification of the IE type ( Payload IEs type 1 
>> ) you already have a way to know that what you have are Payload IEs, 
>> Taking into account these points, the beacon showed within the 
>> minimal draft should be modified ( omitting the termination Header IE ).
>>
>> Cheers,
>> Jose.
>>
>>
> email:[email-masked]  | Skype: rstruik

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 19 Jun 2015 10:13:31 -0700

I agree that IEEE 802.15.4e-2012 alone is ambiguous about what to do with
the Header IE list termination.

It is clear that in the presence of encryption, the List Termination IE for
Header IEs is necessary whenever any Payload IEs or Unformatted Payload is
present.  The List Termination IE is needed to determine the end of the
authenticated header and start of the encrypted payload.

It is also clear that in the absence of encryption, it is possible to
decipher between Header IEs and Payload IEs.  For Header IEs, Figure 48n
shows that Bit 15 is always set to 0.  For Payload IEs, Figure 48o shows
that Bit 15 is always set to 1.  For that reason, including a List
Termination IE at the end of the Header IE list is redundant in the absence
of encryption.

Of course, IEEE 802.15.4e-2012 says nothing about the relationship between
Header IE List termination and encryption.  In that respect, IEEE
802.15.4e-2012 is ambiguous about whether or not to include the List
Termination IE at the end of a Header ID list.

Ben Rolfe and I have spent countless conversations trying to interpret the
IEEE 802.15.4e-2012.  I'm glad to see that the SC maintenance is looking to
address this ambiguity.

--
Jonathan Hui

On Fri, Jun 19, 2015 at 7:47 AM, Rene Struik <[email-masked]> wrote:

> there is also no need (if at most authentication is required, since Header
> IEs and Payload IEs can be distinguished). {If confidentiality is provided,
> then one would have to include this, as my analysis already showed}.
> <<RS
>
> RS>> I would like to understand this, since this statement seems incorrect
> as well, based on the current 802.15.4e-2011 spec.
> <<RS
>
>

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Jun 2015 15:39:19 -0500

Thanks Jonathan;

In addition to the many other things that need to be done, we really need to make IE use non-ambiguous.  Once again, I ask anyone interested to please read the referenced IE Table document and reply if you believe their are errors and why you believe them to be errors.

Pat
Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 12:13, Jonathan Hui <[email-masked]> wrote:

I agree that IEEE 802.15.4e-2012 alone is ambiguous about what to do with the Header IE list termination.

It is clear that in the presence of encryption, the List Termination IE for Header IEs is necessary whenever any Payload IEs or Unformatted Payload is present.  The List Termination IE is needed to determine the end of the authenticated header and start of the encrypted payload.

It is also clear that in the absence of encryption, it is possible to decipher between Header IEs and Payload IEs.  For Header IEs, Figure 48n shows that Bit 15 is always set to 0.  For Payload IEs, Figure 48o shows that Bit 15 is always set to 1.  For that reason, including a List Termination IE at the end of the Header IE list is redundant in the absence of encryption.

Of course, IEEE 802.15.4e-2012 says nothing about the relationship between Header IE List termination and encryption.  In that respect, IEEE 802.15.4e-2012 is ambiguous about whether or not to include the List Termination IE at the end of a Header ID list.

Ben Rolfe and I have spent countless conversations trying to interpret the IEEE 802.15.4e-2012.  I'm glad to see that the SC maintenance is looking to address this ambiguity.

--
Jonathan Hui

On Fri, Jun 19, 2015 at 7:47 AM, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
> - "there is no need to add a termination header IE” - this is incorrect, the IE termination header IE is required to be transmitted before the payload IEs.
RS>> This statement seems incorrect. Please see 802.15.4e-2012, Clause 5.2.4.22 <http://5.2.4.22/>: that clause does not say anything about the explicit termination in the scenario where there are no Header IEs. Technically, there is also no need (if at most authentication is required, since Header IEs and Payload IEs can be distinguished). {If confidentiality is provided, then one would have to include this, as my analysis already showed}.
<<RS
> - “header IEs and Payload IEs have a different type within the first 2-byte descriptor” - this is incorrect, currently there is no overlap but we will need these extra IDs in the future.
RS>> This statement seems incorrect as well. Please see 802.15.4e-2012, Clause 5.2.4.2 <http://5.2.4.2/>: Header IEs and Payload IEs differ on the Type Subfield. The ID space is a different subfield altogether.
<<RS

cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>

---

From: José Ángel Miranda <[email-masked]>
Date: Fri, 19 Jun 2015 22:59:08 +0200

Hi Jonathan,

I agree with you in the second point and this is what I meant when I wrote
my message about the termination Header IE.
Therefore I think the next paragraph is the most clarifying thing I have

>It is also clear that in the absence of encryption, it is possible to
decipher between Header IEs and Payload IEs.  For Header IEs, Figure >48n
shows that Bit 15 is always set to 0.  For Payload IEs, Figure 48o shows
that Bit 15 is always set to 1.  For that reason, including a >List
Termination IE at the end of the Header IE list is redundant in the absence
of encryption.

Therefore, if you take the Beacon format from the minimal and compare it
with what the current standard specifies, you conclude that in absence of
encryption, if the Header IE list termination is included, you are actually
wasting 4 bytes when you do not need to do so.

In response to some of the answers, I did not say that Header IE list
termination is not used or necessary, of course it is used but when needed

>after it

So it is used in order to determine, *when you have Header IEs*, what type
of payload follow the Header IEs.
Once more, taking the Beacon which is showed in the minimal document, there
you have a beacon which contains:
- Header IEs not present.
- Payload IEs present and not encrypted (  In the current standard the IEs
Payload within the beacon are not encrypted, please see table 53 from the
standard where it is specified that the private payload is the Beacon
payload and not the entire MAC payload ).
- Beacon payload not present.
So, what is the need to add a Header IE termination list? There is not.

And in case of having security activated for that beacon, the Header IE
termination list is required if:
- There is encrypted beacon payload ( MAC Payload = IEs Payload + Beacon
Payload ).
- There are Payload IEs and they are encrypted ( In the current standard
the IEs Payload within the beacon are not encrypted, please see table 53
from the standard where it is specified that the private payload is the
Beacon payload and not the entire MAC payload ).

It would be nice to clarify some of these points.

Jose.

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 19 Jun 2015 14:06:14 -0700

While we originally intended that the header terminator was optional, it appears that even for unencrypted payloads, without a header terminator, it is possible to mistake payload that looks like an IE for an actual payload IE.     

One can certainly specify what kinds of IEs will be sent and when in a top level standard to remove the ambiguity.  For example, we could say that enhanced beacon frames never contain a header IE or payload that is not an IE as a matter of policy, removing the need for an explicit header terminator.    It seems we get hung up a lot on assuming the MAC is vanilla 15.4e/15.4-2015  with no upper layer policies on what is valid, necessitating the need to handle every 15.4 eventuality. 

-- 
Jonathan Simon

On Jun 19, 2015, at 1:39 PM, Pat Kinney <[email-masked]> wrote:

>> I have been reading these emails on IE Headers with great interest.  In the IEEE 802.15 maintenance standing committee we often have long discussions on how IEs should be used and as a result have started an interest group on an IEEE 802.15.4 guide.  As part of that effort I have created an IE Table guide, 15-15-0090-06, https://mentor.ieee.org/802.15/dcn/15/15-15-0090-06-0mag-ie-table.docx.  If you wish to review it, this is a publicly available document.
>> 
> http://cp.mcafee.com/d/2DRPoQ938Od6Qm6m1P3z8WVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrhLUVxVZ_HYyOVsQsEIZuVtdAtvANPPX2rDbnhIyyHssPOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCrsDaBypsxlK5LE2FvdTw09JAQsInKr1vF6y0QJKjBiNcQKCy0d6zh05_R3UCy04_5mkdDaI3h05pkDNEw6VgAHF_6S3hOrum9nGYm

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 19 Jun 2015 14:24:53 -0700

Hi Pat,

I have read the referenced IE Termination Table (in particular, Section 2
IE Termination Explanation) and I don't see anything "wrong" in the sense
that it cannot be implemented.  What is specified there is certainly one
way to specify the use of the List Termination IEs and will work regardless
of the MAC Security Level in use.

However, as previously mentioned, there are cases where the inclusion of
List Termination in the Header IE List is redundant (e.g. depending on what
MAC Security Level is in use).  One could always expand the referenced IE
Termination Table to include additional columns, but that will also
increase the number of rows in the tables (i.e. Cases).

I can certainly appreciate the desire to keep it simple.  At the same time,
I can also appreciate the desire to minimize transmitted bytes.  The SC
maintenance should consider these tradeoffs carefully.

--
Jonathan Hui

On Fri, Jun 19, 2015 at 1:39 PM, Pat Kinney <
[email-masked]> wrote:

> Thanks Jonathan;
>
> In addition to the many other things that need to be done, we really need
> to make IE use non-ambiguous.  Once again, I ask anyone interested to
> please read the referenced IE Table document and reply if you believe their
> are errors and why you believe them to be errors.
>
> Pat
> Pat Kinney
> *Kinney Consulting LLC*
> It is clear that in the presence of encryption, the List Termination IE
> for Header IEs is necessary whenever any Payload IEs or Unformatted Payload
> is present.  The List Termination IE is needed to determine the end of the
>> Guide.  Please let me know if you believe I have made a mistake and why you
>> believe it is a mistake.
>>
>>  Pat
>>
>>
>>  Pat Kinney
>> *Kinney Consulting LLC*
>> be the next rev. ), when having the Payload IEs encrypted (* this is NOT
>> as specified in the current standard* ), there would be one condition
>> where the termination Header IE is strictly required:

---

From: Robert Cragie <[email-masked]>
Date: Fri, 19 Jun 2015 22:35:45 +0100

Hi Jonathan,

I don't think it makes any difference re. encryption and I think the table
at the beginning of Section 2 15-15-0090-06-0mag-ie-table.docx is correct.
I also think you have one point wrong - see inline comment below.

Below is an alternative representation of what is in the table mentioned
above, showing what you could expect in the 8 cases (monospaced font
required):

Case |<--------- Header --------->||<------- Payload ------>|
-----|----------------------------||------------------------|
1    | MHR(0) |                   ||                 ||     |
2    | MHR(1) | HIE[1-n]          ||                 ||     |
3    | MHR(1) |             HT1   || PIE[1-n] | [PT] ||     |
4    | MHR(1) | HIE[1-n] |  HT1   || PIE[1-n] | [PT] ||     |
5    | MHR(0) |                   ||                 || MPY |
6    | MHR(1) | HIE[1-n] |  HT2   ||                 || MPY |
7    | MHR(1) |             HT1   || PIE[1-n] |  PT  || MPY |
8    | MHR(1) | HIE[1-n] |  HT1   || PIE[1-n] |  PT  || MPY |

Robert

> Termination IE at the end of the Header IE list is redundant in the absence

<RCC>But it is not possible to distinguish between Payload IEs and
Unformatted Payload. Therefore the List Termination IE is still needed</RCC>

---

From: Pat Kinney <[email-masked]>
Date: Fri, 19 Jun 2015 16:38:36 -0500

Agreed, Jonathan.

Given how ambiguities cause significant issues (this case for example) and given that many believe that 802.15.4 is already too complicated, we believed that giving up the two bytes in some instances was a reasonable trade

Pat

Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 16:24, Jonathan Hui <[email-masked] <mailto:[email-masked]>> wrote:

Hi Pat,

I have read the referenced IE Termination Table (in particular, Section 2 IE Termination Explanation) and I don't see anything "wrong" in the sense that it cannot be implemented.  What is specified there is certainly one way to specify the use of the List Termination IEs and will work regardless of the MAC Security Level in use.

However, as previously mentioned, there are cases where the inclusion of List Termination in the Header IE List is redundant (e.g. depending on what MAC Security Level is in use).  One could always expand the referenced IE Termination Table to include additional columns, but that will also increase the number of rows in the tables (i.e. Cases).

I can certainly appreciate the desire to keep it simple.  At the same time, I can also appreciate the desire to minimize transmitted bytes.  The SC maintenance should consider these tradeoffs carefully.

--
Jonathan Hui

On Fri, Jun 19, 2015 at 1:39 PM, Pat Kinney <[email-masked] <mailto:[email-masked]>> wrote:
Thanks Jonathan;

Pat
Pat Kinney
Kinney Consulting LLC

On 19, Jun2015, at 12:13, Jonathan Hui <[email-masked] <mailto:[email-masked]>> wrote:

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 19 Jun 2015 14:46:24 -0700

Robert,

There are cases where the inclusion of HT1 could depend on encryption if we
wanted to.  For example, consider Case 7:

Header IE Present: No
Payload IE Present: Yes
Data Payload Present: Yes

The MAC header only indicates whether or not IEs (header or payload) are
present.  When encryption is enabled, HT1 is needed to indicate that there
are no Header IEs present.  However, when encryption is not enabled, I can
simply tell by looking at Bit 15 of the Payload IE header and HT1 is not
needed.  Of course, including HT1 in both cases is the most general and
would cover both cases.

As mentioned in my previous mail, adding conditions based on security adds
complexity and I can appreciate the desire to keep things simple.

--
Jonathan Hui

On Fri, Jun 19, 2015 at 2:35 PM, Robert Cragie <[email-masked]>
wrote:

>> Of course, IEEE 802.15.4e-2012 says nothing about the relationship
>> between Header IE List termination and encryption.  In that respect, IEEE
>> Ben Rolfe and I have spent countless conversations trying to interpret
>> the IEEE 802.15.4e-2012.  I'm glad to see that the SC maintenance is
>> looking to address this ambiguity.
>>
>> --
>> Jonathan Hui
>>
>>> not have to add a termination Header IE before.
>>>
>>> be the next rev. ), when having the Payload IEs encrypted (* this is

---

From: José Ángel Miranda <[email-masked]>
Date: Sat, 20 Jun 2015 00:04:50 +0200

Jonathan,

In this sentence:
"... When encryption is enabled, HT1 is needed to indicate that there are
no Header IEs present..."
You are considering that the Payload IEs are encrypted, which is not
specified in IEEE802.15.4e - 2012. Following what the standard specifies,
the Payload IEs are not encrypted; therefore, in case 7 when having
security, there is no need to add the HT1, as you can do the same process
as when encryption is not enabled because Payload IEs are not encrypted and
you can simply check Bit 15 of the Payload IE header.

Table 53 IEEE802.15.4-2011 specifies which fields are considered private
and which open.

Jose.

2015-06-19 23:46 GMT+02:00 Jonathan Hui <[email-masked]>:

> Robert,
>
> There are cases where the inclusion of HT1 could depend on encryption if
> we wanted to.  For example, consider Case 7:
>
> Header IE Present: No
> Payload IE Present: Yes
> On Fri, Jun 19, 2015 at 2:35 PM, Robert Cragie <
> [email-masked]> wrote:
>
>> Hi Jonathan,
>>
>> I don't think it makes any difference re. encryption and I think the
>> table at the beginning of Section 2 15-15-0090-06-0mag-ie-table.docx is
>> correct. I also think you have one point wrong - see inline comment below.
>>
>>>> ,
>>>> Clause 5.2.4.2: Header IEs and Payload IEs differ on the Type
>>>> Subfield. The ID space is a different subfield altogether.
>>>> <<RS
>>>>

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 19 Jun 2015 15:13:46 -0700

Jose,

See Section 5.2.1.7a in IEEE802.15.4-2012:

"Payload IEs, if present, follow the MHR and are considered part of the MAC
payload, i.e., they may be
encrypted."

A primary reason for having Header and Payload IEs is to separate those IEs
which may be encrypted and those that should never be encrypted.

--
Jonathan Hui

On Fri, Jun 19, 2015 at 3:04 PM, José Ángel Miranda <[email-masked]>
wrote:

>> As mentioned in my previous mail, adding conditions based on security
>> adds complexity and I can appreciate the desire to keep things simple.
>>
>> --
>> Jonathan Hui
>>
>>
>>>>>  In case of following other standard rather than the current one (
>>>>> may be the next rev. ), when having the Payload IEs encrypted (* this
>>>>> is NOT as specified in the current standard* ), there would be one
>>>>> time to decrypt the frame you need to know, in order to operate properly
>>>>> the incoming security procedure, what is 'c data' and 'a data', therefore
>>>>> you need to add a termination Header IE in order to: avoid possible
>>>>> confusion with the non-formatted encrypted payload and know where the MAC
>>>>> Header ends.
>>>>>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 19 Jun 2015 23:59:09 +0100

Jonathan,

OK - the bit I missed is that distinguishing whether the payload is Payload
IEs or Unformatted Payload can be done by looking at the IE List Present
bit. I agree with your original e-mail.

Robert

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 21 Jun 2015 19:18:02 +0300

>         IE (ID = 0x7e or 0x7f) that has a content length of zero.

The first sentence says that Header IE list is terminated. That does
not list any exceptions.

>         following the Header IE list. If an unformatted payload

This second sentence gives enforces the first rule, i.e. explicit
termination is required if there is anything after the Header IE list,
i.e. either payload IEs, or MAC payloads. 

>         content length of zero. Otherwise the terminator may be

So that otherwise only covers the case where there is nothing after
the header IE (i.e. no payload IEs, and no MAC pyload), or nothing
after payload IE (i.e. no MAC payload).

This text does not give any exception that Header IE termination could
be omitted if you do not have any header IEs, or if the payload is
unencrypted.

> Once more, taking the Beacon which is showed in the minimal
> document, there you have a beacon which contains:
> - Payload IEs present and not encrypted (  In the current standard
>   the IEs Payload within the beacon are not encrypted, please see
>   table 53 from the standard where it is specified that the private
>   payload is the Beacon payload and not the entire MAC payload ).

Table 53 was not updated in the 4e even when it should have been. This
was one of the issues we found while making the 802.15.4rev, and this
was fixed there following the instructions from implementors and
people who wrote the 4e.

Also the section 5.2.1.7a clearly states that payload IEs are part of
MAC payload, and they may be encrypted (i.e. if security level is >=
4). 

> So, what is the need to add a Header IE termination list? There is

It needs to be added as 5.2.4.22 says that Header IE list is
terminated when there is payload IEs after it.

Yes, some other protocol defining IEs, could have defined IEs in such
way that some of those termination IEs can be left out, but 802.15.4e
did not do that. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Jun 2015 12:27:40 +0300

Robert Cragie writes:
> If the command ID is encrypted, a KeyUsageDescriptor for a MAC
> command frame can no longer be used.

KeyUsageDescriptors can be checked after the frame has been decrypted.
This is how most of the other security protocols do things (for
example IPsec), i.e. you use information in the frame to pick up the
security association, you verify MIC and decrypt packet, and after
that you verify that the packet matches the security policies. 

> This should be made clear.

In the 802.15.4rev we did make this clear by moving the security level
descriptor and key usage policy checks after the unsecuring the frame. 

> This has implications for policing frames, especially MAC command
> frames.

Yes. On the other hand all implementors who we polled did say that
they do not support frames where we first have encrypted Payload IEs
and then unencrypted MAC Command ID, and then again encrypted MAC
command Content field.

Supporting such frames would be possible, but would be bit
complicated, as you would need to do following:

- Parse MHR and Header IEs to find the start of MAC Payload
- Decrypt the MAC Payload, but keep copy of the encrypted MAC Payload
- Parse the Payload IEs to find the length of them.
- Fetch the clear text Command ID from the encrypted MAC Payload part
  from the offset found out in previous step.

Even in this case you would need to decrypt the frame first before
you can run the security level descriptor and key usage policy
checks, as you do not know the length of Payload IEs before you have
decrypted the frame.

You can check what the incoming frame security procedure looks like
from the

https://mentor.ieee.org/802.15/dcn/15/15-15-0275-00-0mag-security-functional-description-from-p802-15-4-revc-df5.pdf

document (note, that there is typo in 9.2.3 step M, the 9.2.9 should
be 9.2.10).

The way how frame is splitted to encrypted and clear text parts in
802.15.4rev is to say that in general Private Payload field is set to
the MAC Payload Field, and Open Payload field is set to empty. This
means the whole MAC Payload field will be encrypted. Then there are
two exceptions to that general rule in table 147. Those exceptions
are:

+-----------------------+-----------------------+--------------------------+
| Frame type            | Private Payload field | Open Payload field       |
+-----------------------+-----------------------+--------------------------+
| Beacon                | Beacon Payload field  | All other fields in      |
| (Frame Version < 2)   |                       | the MAC Payload field    |
+-----------------------+-----------------------+--------------------------+
| MAC Command           | Content field         | Command Identifier field |
| (Frame Version < 2)   |                       |                          |
+-----------------------+-----------------------+--------------------------+
-- 
[email-masked]