Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
draft-ietf-6lo-rfc6775-update-21
Yes
(Suresh Krishnan)
No Objection
(Adam Roach)
(Alexey Melnikov)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 16 and is now closed.
Warren Kumari
No Objection
Comment
(2018-04-02 for -16)
Unknown
Thank you for a very readable document - this is not a simple process, but the document was clear and understandable. Also, thank you for addressing Jürgen Schönwälder's OpsDir comments (I have not personally checked that each was incorporated, but the authors said that they would, and I'm trusting them). Issues: "In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for all the addresses to which it can currently forward packets." -- I do not believe that this is correct and am not quite sure how to fix it. Can you point where in RFC4861 it says this? I'd agree that *to be efficient* a router should have enough space to hold an NCE for all locally attached subnets, but a constrained device *could* presumably age out and relearn old entries. Apart from that somewhat pathological case, if I'm a router and get a transit packet (not for a directly connected interface), I don't need to have a neighbor entry for it (otherwise "core" routers would need to build NCEs for every IP on the Internet :-P). Perhaps "for all directly connected subnets." or "for all directly connected addresses to which it can currently forward packets."? I'm somewhat uncomfortable with the uppercase MUST in: "A network administrator MUST deploy updated 6LR/6LBRs to support the number and type of devices in their network, ..." Having an uppercase MUST driving operators' design decisions stuff feels weird. I'd be perfectly fine with something like "In order to deploy this, network administrators MUST..." or "Network Administrators need to ensure that 6LR/6LBRs support the number and..." Nits: Section 4.2.1. Comparing TID values "In order to keep this document self-contained and yet compatible, the text below is an exact copy from section 7.2. "Sequence Counter Operation" of [RFC6550]."" I think that it would be helpful to delimit the copied text (perhaps by indenting it) -- it was unclear to me where the copied text started and ended, and so I had to go read RFC6550 (which kind of defeats the purpose of copying it). Section 4.3. Registration Ownership Verifier "An RFC6775-only will confuse the name-spaces," Missing a word - perhaps "device", "6LoWPAN Router" or "implementation"? Section 7.3. RFC6775-only 6LoWPAN Router "But if RFC6775-only and updated 6LRs coexist temporarily in a network, then it makes sense for an administrator to install a policy that allows so, and the capability to install such a policy should be configurable in a 6LBR though it is out of scope for this document." s/that allows so/that allows this/ -- readability (purely a nit). Section Appendix B. Requirements (Not Normative) "This section lists requirements that were discussed discussed by the 6lo WG..." I guess that they were discussed at length? :-P Section B.1. Requirements Related to Mobility " Due to the unstable nature of LLN links, even in an LLN of immobile nodes a 6LN may change" s/of immobile nodes a/of immobile nodes, a/ (add comma -- also a nitty nit).
Suresh Krishnan Former IESG member
Yes
Yes
(for -16)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -17)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -17)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-04-04 for -17)
Unknown
Thanks for the thoughtful privacy considerations in this document.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -16)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2018-04-03 for -17)
Unknown
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-04-03 for -17)
Unknown
Section 6.1 has: Registration Ownership Verifier (ROVR): Enables the correlation between multiple attempts to register a same IPv6 Address. This can be a unique ID of the Registering Node, such as the EUI-64 address of an interface. This can also be a token obtained with cryptographic methods and used as proof of ownership of the registration. [...] I understand that the actual crypto is (currently) in draft-ietf-6lo-ap-nd, but from the point of view of this document, the ROVR token (or "crypto-ID" in the terminology of 6lo-ap-nd) behaves as a bearer token. That is, I include it with my EARO and my registration request is authenticated and associated with that "identity"; there is not anything in this document that ties the crypto-ID to the EARO. From a very quick read of the other document, it sounds like the 6LR can optionally request validation that the 6LN using the crypto-ID actually has control of the associated private key, and is expected to do so on the first exchange, and so arguably the transport key+LLA are what associates the crypto-ID with the EARO. The conclusion from the above would be that this sort of ROVR is not itself proof of ownership of anything, so it might be better to have text like "this can also be a token obtained with cryptographic methods which can be used in additional protocol exchanges to associate a cryptographic identity (key) with this registration". In several places in section 7 it is indicated that implementations that support this spec should always use the new data structures even when talking to RFC6775-only peers; this generally seems fine due to the way that reserved fields are used. I was not entirely sure if the same holds for the use of new status codes in the EARO, though -- do things work out okay if (e.g.) "Moved" or "Removed" are interpreted as a generic error? In general the Security and Privacy Considerations seem well thought-out (in the model where Layer-2 security is already in place), thank you! (Key distribution remains a hard problem, of course, and sharing such keys across groups does reduce the security properties of the system, but this is not the right place to go into detail on such issues.) One final nit: what is the "port" involved in the Binding? It does not sound like it is an IP port...
Deborah Brungard Former IESG member
No Objection
No Objection
(for -17)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-04-04 for -17)
Unknown
I found this document quite challenging to read. It would be very helpful if it started with a description of the failings of 6775 and a brief overview of how it solves those. At the risk of self-citing, the techniques of RFC 4101 might be helpful here. In addition, I recognize that some of the guarantees here depend on draft-ietf-6lo-ap-nd. I have not yet thoroughly reviewed that document, but it is not yet clear to me precisely what guarantees it in fact provides. This specification introduces the Extended Address Registration Option (EARO) based on the ARO as defined [RFC6775]. A 'T' flag is Can you describe here the problem that ARO has that this solves? that this specification avoids the Duplicate Address message flow for Link-Local Addresses in a Route-Over [RFC6606] topology. This sentence is not really maximally clear. Why does it avoid it? o The address that is being registered with an NS with an EARO is now the Target Address, as opposed to the Source Address as This would read better, I think if you said "The address that is being registered is set to the target address in the NS containing the EARO,as opposed to..." denoting a ROVR size of 128, 192 and 256 bits respectively. Status: 8-bit unsigned integer. Indicates the status of a It took me a minute to realize that this is the length of the *entire* option and so it's 1 larger than the length of the ROVR. Some text might help here. registration of a particular IPv6 Address and it cannot be used to correlate registrations of different addresses. "cannot" doesn't seem quite right. I.e., if you use the same EUI-64, someone could use it for that. Perhaps you mean "must not" rightmost bit and place the result in the EDAR message to maintain compatibility. This way, the support of DAD is preserved. Is there a reason for the rightmost bits? I see that https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06 uses the leftmost bits for Crypto-ID. Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the Registered Address using a cryptographic ROVR. I'm a little unsure how to read this text. It seems like the techniques you are discussing are about whether a node behaves incorrectly, but 6775 says that the first trust model of 3756 applies, and *that* says: A model where all authenticated nodes trust each other to behave correctly at the IP layer and not to send any ND or RD messages that contain false information. This model is thought to represent a situation where the nodes are under a single administration and form a closed or semi-closed group. A corporate intranet is a good example. So in that setting why do you need ownership guarantees? Is this just belt and suspenders? address, but a stronger identification (e.g., by security credentials) is RECOMMENDED. When that maximum is reached, the router should use a Least-Recently-Used (LRU) algorithm to clean What would these security credentials be?
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -17)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -17)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-04-04 for -17)
Unknown
I believe this document would have been easier to read for me if section 6 would have been before section 4; however, I guess that's a matter of taste. On the TID in section 6.1: Should this field be zero if the T flag is not set? I guess you should at least say that the field should be ignored if the T flag is not set.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -16)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -17)
Unknown