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 protected]> wrote: > 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 protected]>: > >> 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
