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
