Hello again, Benjamin > > Again and again, many thanks for your arch-fantastic reviews!
> > " > > Each Backbone Router (6BBR) maintains a data structure for its > > Registered Addresses called a Binding Table. The abstract data that > > is stored in the Binding Table includes the Registered Address, > > anchor information on the Registering Node such as connecting > > interface, Link-Local Address and Link-Layer Address of the > > Registering Node on that interface, the EARO including ROVR and TID, > > a state that can be either REACHABLE, TENTATIVE, or STALE, and other > > information such as a trust level that may be configured, e.g., to > > protect a server. The combined Binding Tables of all the 6BBRs on a > > backbone form a distributed database of 6LNs that reside in the LLNs > > or on the IPv6 Backbone. > > " > > This is nice! I am still not sure about how much a deployment needs to care > about concurrency and/or consistency issues for the "distributed database"; > given that lossy radio technologies are involved I mostly assume that things > will be self-healing in the face of a bit of delayed update propagation, but > it > would be nice to have that confirmed. To do care and this is why we have the ROVR and the TID included in the exchange on the backbone. The point is to ensure that the database is maintained up to date with the right state at the right place. This db becomes a core functionality for a modern switch and router as it is the point where the hosts are observed. This is injected in many features, such as LISP MS/MR, SD-stuff, network management and security tools. > > > Section 9 > > > > > > even for a duplicate address. Consequently, and unless > > > administratively overridden, the 6BBR still needs to perform IPv6 ND > > > DAD over the backbone after an EDAC with a status code of 0 or 9. > > > > > > I'd be curious to see a pointer to the discussions that caused > > > "unless administratively overridden" to be introduced, as naively > > > that note does not seem necessary. > > > > The idea behind it is that if all nodes register to the 6LBR then the DAD > > can > be avoided. > > But the only way to know is administrative. I wanted to leave that door > open. But I guess it is implicitly. > > Removed the text. > > > > > > > > If a registration is received for an existing Binding with a non-null > > > Registration Lifetime and the registration is fresher (same ROVR, > > > fresher TID), then the Binding is updated, with the new Registration > > > Lifetime, TID, and possibly Registering Node. In Tentative state > > > (see Section 9.1), the current DAD operation continues unaltered. In > > > other states (see Section 9.2 and Section 9.3 ), the Binding is > > > placed in Reachable state for the Registration Lifetime, and the 6BBR > > > returns an NA(EARO) to the Registering Node with a status of 0 > > > (Success). > > > > > > Does this mean we don't re-do DAD for registrations already in a > > > Stale state when we receive an updated registration for them? > > > > Correct. If a sign of reuse of the address had been seen the Binding would > have been removed in 9.3. That's the point actually of keeping the address in > Stale state. > > I guess I wasn't sure if those mechanisms would be 100% reliable to avoid two > nodes thinking they have the same address, but it's been too long since I > wrote this for me to be sure what I was thinking. If you say they are 100% > reliable, that is good enough for me. Classical IPv6 ND DAD is NOT 100% reliable. It is in fact very unreliable on large wireless deployments. Anything that happens on the backbone that is based on multicast may have misses. What makes IPv6 work is that the collisions actually do not happen with pseudo-random, crypto-based or MAC-seeded IIDs. The next spec on having a 6LBR on the backbone will make it reliable, provided that the 6LBR itself is. But getting 6MAN to endorse it will be an interesting time, help appreciated. > > > > > > It might be worth a brief preface that since we're modifying the ND > > > and DAD processes, the attacks in scope are basically limited to > > > blocking discovery of taking over addresses from other nodes (which, > > > to be fair, can in some cases have substantial consequences in terms of > reading the "stolen" traffic!). > > > > Argl, I cannot parse that. Would you kindly suggest text? > > I was thinking something like: > > The procedures in this document modify the mechanisms used for IPv6 ND > and DAD and should not affect other aspects of IPv6 or > higher-level-protocol operation. As such, the main classes of attacks > that are in play are those which week to block neighbor discovery or to > forcibly claim an address that another node is attempting to use. In the > absence of cryptographic protection at higher layers, the latter class of > attacks can have significant consequences, with the attacker being able > to read all the "stolen" traffic that was directed to the target of the > attack. Cool, using it. At some point you become an author! > > > The 6BBR can also perform such an attack, right? It might be worth > > > explicitly stating that we trust it to behave honestly in order for > > > this stuff to work properly. > > > > Sure, the attacker impersonates a 6BBR. A compromised 6BBR is an ideal > attacker. > > A compromised 6BBR can do anything like accept registration but not > forward traffic, not proxy, etc... > > But that's obvious isn't it? > > It's probably obvious, yes. At this point I'm never sure where the line is > for > "too obvious to mention"; some things are obvious to me but far-from- > obvious to people who haven't had a couple years' experience as SEC AD... And I probably know my spec too well. Let's go then. What about uplifting the below: " This specification introduces a 6BBR that is a router on the path of the LLN traffic and a 6LBR that is used for the lookup. They could be interesting targets for an attacker. A compromised 6BBR can accept a registration but block the traffic, or refrain from proxying. A compromised 6LBR may accept unduly the transfer of ownership of an address, or block a new comer by faking that its address is a duplicate. But those attacks are possible in a classical network from a compromised default router and a DHCP server, respectively, and can be prevented using the same methods. " Again, many, many thanks Benjamin : ) Since these are limited changes I'll post a single update with Mirja's comments as well. Keep safe! Pascal _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
