Mesh Link Establishment
draft-kelsey-intarea-mesh-link-establishment-06
Discuss
Yes
(Ted Lemon)
No Objection
(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Spencer Dawkins)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2014-06-26)
Unknown
I am sorry that I have only had time for a very brief review of this document. I should be happy if you are able to say that any of my Discuss points is rubbish based on my reading too fast. ------- Section 4 The purpose of the third, detecting neighboring devices, is to make link management more efficient by detecting unreliable links before any effort is spent configuring them. Do you not think "detecting neighbor devices" is an odd name for a feature which is intended to detect unreliable links before any effort is spent configuring them? Similarly the title of section 4.3. Isn't this link discovery? (A link not being an interface :-) For example, suppose there are two links that reach the same neighbor? But in section 8... Link configuration and advertisement messages MUST be sent with an IP Hop Limit of 255, either to a link-local unicast address or to the link-local all-nodes (FF02::1) or all-routers (FF02::2) multicast addresses. ...I believe that what you are defining is effectively a link state protocol by full flooding. This is not a discovery protocol. I am very wary of such a protocol being defined (we have been there before and it sucks!) At the very least, this document needs to be clear whether it is a discovery protocol, a link parameter negotiation/discovery protocol, or a link parameter flooding protocol. In the latter case, I would like the document to explain the scope and purpose of this wholesale flooding. On the other hand, part of the problem may be that you intend that MLE should be able to send (from a central location) configuration information that is to be used at each node (or some set of nodes) in the network. Section 11 gives this hint. Yet that is a very different use of the protocol and many features of that operation (such as how thrashing between two senders is handled) are left for the reader to ponder. --- Section 5 needs to indicate how a parser knows the length of an MLE message. How do I know when to stop parsing TLVs and start parsing the MIC (in the 0 case) or stop parsing the message (in the 255 case). --- Section 7 With the exceptions of the Source Address TLV and Parameter TLV, an MLE message MUST NOT contain two or more TLVs of the same type. You need to say how such errors are handled. However, I think you have hamstrung yourself for the future. Why not add a column to the registry that says "Multi-occurrence allowed" and then state that RFCs defining new TLVs must state whether multiple occurrences are allowed. --- Section 7.1 The Source Address TLV (TLV Type 0) has a Value containing a byte string representing a link-layer address assigned to the source of the message. Does "a byte string representation" have a specific meaning in the context of IEEE 802.15.4? To me it is not specific enough to write code. --- Section 7.6 "encoded as an N-bit unsigned integer." This is curious as the TLV length can only indicate full octet lengths. Is N allowed to be other than an integer multip of 8? --- Section 7.7 Size The size in bytes of the included neighbor link- layer addresses, minus 1. This supports addresses of lengths 1 to 16 bytes. This is ambiguous. Do you mean the total size of all addresses, or the size of a single address with the requirement that all addresses must be the same size? Yet later in the same description of the data format... Address A link-layer address of a neighbor. ... which says that only one address is present (and misnames the field compared to the figure). --- Section 7.8 Value A byte string containing the new value of the parameter. The format of this value is determined by the particular parameter And yet the formats don't appear to be described when the parameters are listed later in the section. --- 7.9. MLE Frame Counter The MLE Frame Counter TLV (TLV Type 8) has a Value containing the sender's current outgoing MLE Frame Counter, encoded as an 32-bit unsigned integer. What is an MLE frame? Is this a count of messages or L2 frames or...? How does this wrap? When is it reset? Is the 32 bit integer in line format? Section 5 gives some information about this with cross-pointers to [CCM] Section 9 tells us how to handle received frame counters. But 7.9 needs to point to these other sections, and Section 8 should explicitly state about setting the counter.
Brian Haberman Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2014-06-25)
Unknown
I have no objection to the publication of this document, but there are some points that need work... 1. In section 6, it is unclear as to how Command Type 2 differs from a combination of Command Types 0 and 1. In what instances would a sender use Command Type 2? It seems to me that this *could* be an exchange like: 1) A sends CT==0 to B, 2) B sends CT==2 to A, and 3) A sends CT==1 to B. Is that the expected usage? If so, it should be explained. I was expecting to see Section 10 do that, but that didn't materialize. 2. Some of the specified Command Types and TLVs are obviously link-local in nature. Are there Command Types and TLVs that are only network-wide? I would like to see some description of how far each of the Types and TLVs should be propagated. 3. This is related to Barry's comment about destination address selection. Section 8 should tighten up the guidance on address selection. This should be tied to the point raised in #2 above, in that the destination address needs to take the scope of the information contained in the message into account. 4. It is unclear to me what Section 9 is saying about "reserved Command Types" and "reserved TLV Types". Are those just values that are not recognized?
Kathleen Moriarty Former IESG member
(was No Objection)
Discuss
Discuss
[Treat as non-blocking comment]
(2014-06-26)
Unknown
The draft seems okay, although I'd like to understand why there isn't a stronger requirement around replay protection or see that fixed with stronger language. The Security Considerations section says: Because of this, implementers must be careful in how they use information obtained from these possibly- replayed messages. For example, information from unsecured messages should not be used to modify any stored information obtained from secured messages. and section 7.4 provides a way to do this with a challenge: The recommendations in [RFC4086] apply with regard to generation of the challenge value. The byte string MUST be at least 4 bytes in length and a new value MUST be chosen for each Challenge TLV transmitted. An important part of replay protection is determining if a newly-heard neighbor is actually present or is a set of recorded messages. This is done by sending a random challenge value to the neighbor and then receiving that same value in a Response TLV sent by the neighbor.
Stephen Farrell Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2014-06-26)
Unknown
I'm not familiar with 802.15.4 security sorry, so you may need to educate me a bit, and I had to review this in a hurry so might be wrong below (and sorry again:-) but I had the following questions to discuss: (1) I don't get why its ok that there is no key management defined, either here or somewhere else via reference. That could be fixed via some more text in section 3 perhaps, if there are other specs that do define how to do key management, e.g. to reference one (or more) that do define that and to say that other uses of this need to do similarly. Absent that, maybe we're back to looking at BCP107, but I'm not sure we want to (or hopefully, need to:-) go there. (2) The overall security model is a bit complicated, I wasn't clear whether the combinations of security being on and off (i.e. initial byte = 0 or 255) adds up to a good outcome. There are also cases (e.g. joining) where where MLE security MUST NOT be used but link layer MUST be used. Has someone done an analysis of how that all stacks up together? Can you point me at that? (Sorry for the fairly vague question.) (3) As a particular case of (2), I don't get how the device joining without any keys thing is meant to work, nor under exactly what conditions. Don't you need to specify this or at least state the requirements for it to work if specified elsewhere? (4) I'm not clear that the frame counter + key cannot repeat, esp. since we don't have the key management detail here and that there seems to be a way for one node to tell another which frame counter value to start from (is that right or is that just telling a new peer what my current frame counter is at? If the latter, why not just get that by observation?). I do see you say that they MUST NOT be repeated, but if there are shared keys over >1 device, or, if its allowed to not use the same frame counter for link and MLE but is allowed to use the same key, then that may not be implementable.
Ted Lemon Former IESG member
Yes
Yes
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-06-21)
Unknown
I have a couple of questions about the use of 2119 "MAY" below; I think it's important to resolve them, so please consider these comments. -- Section 8 -- Update messages MAY be sent as above, or MAY be sent to a site-local all- MLE-nodes multicast address (to be assigned by IANA). Or they may be sent in any other way, as those "MAY"s specify optional behaviour -- so you MAY also do neither. Is that the intent? Or is the intent that one can choose, at one's option, between those two choices, but no other? If that's what's meant, let me suggest this instead: NEW Update messages MUST either be sent as above, or be sent to a site-local all-MLE-nodes multicast address (to be assigned by IANA). END What is the line that says "MAX_RESPONSE_DELAY_TIME 1 second" meant for? Should there be some other text around it? Similarly for the table: should the previous paragraph have an additional sentence that says, "The following are recommended default values for relevant timeout and retransmission parameters."? I think this would read better with an explanation such as that. -- Section 10 -- If large numbers of Link Request messages arrive a device MAY reduce or completely suspend sending Link Accept messages, and MAY send Link Reject messages instead. This is a similar double-MAY to the previous one, and it brings up a similar question: as written, it says: 1. If large numbers of Link Request messages arrive, a device has the option of reducing or completely suspending sending Link Accept messages. 2. If it does that, it has the option of sending Link Reject messages instead. It also has the option of not sending Link Reject messages instead. It could, for example, not respond at all, or respond in some other way. Is that what's intended? Or is it intended that if it stops sending Link Accepts, it will always send Link Rejects? If so, then just removing the second "MAY" will fix it.
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown