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
*/Kinney Consulting LLC/*
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email protected]
<mailto:[email protected]>
On 19, Jun2015, at 9:47, Rene Struik <[email protected]
<mailto:[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]
<mailto:[email protected]>
On 19, Jun2015, at 6:47, José Ángel Miranda <[email protected]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--
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
