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 On 19 June 2015 at 22:46, Jonathan Hui <[email protected]> wrote: > 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 protected]> 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. >> >> 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 >> >> On 19 June 2015 at 18:13, Jonathan Hui <[email protected]> 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. >>> >> >> <RCC>But it is not possible to distinguish between Payload IEs and >> Unformatted Payload. Therefore the List Termination IE is still needed</RCC> >> >> >>> >>> 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 protected]> >>> wrote: >>> >>>> 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 >>>> 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. >>>> >>>> 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. >>>> >>>> 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 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* >>>> IEEE 802.15 WG vice chair, TG chair >>>> ISA100.11a WG chair >>>> O: +1.847.960.3715 >>>> [email protected] >>>> >>>> >>>> On 19, Jun2015, at 6:47, José Ángel Miranda <[email protected]> >>>> wrote: >>>> >>>> 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 protected]>: >>>> >>>>> 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 >>>>> > self-contained TLV data objects (see Clauses 5.2.4.2 and 5.2.4.3). >>>>> >>>>> 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 protected] >>>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>>> >>>> -- >>>> email: [email protected] | Skype: rstruik >>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
