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
