On Mon, Mar 23, 2020 at 10:17:43AM +0000, Pascal Thubert (pthubert) wrote: > Hello again Benjamin: > > Just to make sure you're kept busy ; ) > > > > Proposed changes in 3.5. Primary and Secondary 6BBRs > > > > > > " > > > A Registering Node MAY register the same address to more than one > > > 6BBR, in which case the Registering Node uses the same EARO in all > > > the parallel registrations. On the other hand, there is no provision > > > in 6LoWPAN ND for a 6LN (acting as Registered Node) to select its > > > > I'm assuming that "6LoWPAN ND" here means "stuff currently published as > > RFCs, excluding this document, AP-ND, etc." > > That is correct in -20 but AP-ND does not either. > > In the terminology section (2.4) we say > > > 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy > Networks [RFC6775] and "Registration Extensions for 6LoWPAN > Neighbor Discovery" [RFC8505]. > > But then, I believe that it should include AP-ND. > Note that both this are in C310, held by the same docs > > " > 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy > Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor > Discovery" [RFC8505], and " Address Protected Neighbor Discovery > for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd]. > " > Note that AP-ND is mentioned several times later; Is that OK? (more below)
I don't mind. (But I'm not sure that I'm the best placed to comment...) > > > > > > 6LBR (acting as Registering Node), so it cannot select more than one > > > either. To allow for this, ND(DAD) and NA messages with an EARO > > > that > > > > (in particular with respect to "cannot select more than one".) > > I guess you're confused between 6LR and 6LBR. The 6LN can attached to > multiple 6LRs but it is the 6LRs that select the 6LBR, not the 6LN. Ah, I think you are right about my confusion. > Are we in sync? It looks like it. > > > > 11. Security Considerations > > > > > > This specification applies to LLNs and a backbone in which the > > > individual links are protected against rogue access, by > > > authenticating a node that attaches to the network and encrypting at > > > the MAC layer the transmissions so packets may neither be overheard > > > or nor forged. In particular, the LLN MAC is required to provide > > > > I think that the "authenticating a node that attaches [...]" is meant to > > apply to > > the LLN links, and perhaps the backbone provides the protection against > > rogue > > access by physical access protection? Maybe we need two clauses after the > > comma, e.g., "on the LLN by [...], and on the backbone by [...]". > > Yes, as discussed in the next block, the attacks on the backbone are a lot > easier if backwards compatibility has to be maintained. There's the > discussion on who should win when a legacy fights with an LLN node, the > current text has the legacy win to enable a smooth incremental deployment. > > Proposed change: > " > This specification applies to LLNs and a backbone in which the > individual links are protected against rogue access, on the LLN by > authenticating a node that attaches to the network and encrypting at > the MAC layer the transmissions, and on the backbone side using the > physical security and access control measures that are typically > applied there, so packets may neither be overheard or nor forged. > > " +1 > > > > > > If the classical ND is disabled on the backbone and the use of > > > [I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will > > > benefit from the following new advantages: > > > > > > Zero-trust security for ND flows within the whole subnet: the > > > > (I'm tempted to try to work "non-router" in here somehow, but not sure it's > > worth the effort.) > > Sorry I'm not sure I see the point. The duplication may be with a router. I can see why you were confused at this remark; it's ... pretty opaque! I was reacting to "zero-trust security" -- we still have to trust the routers to do the right thing, so my knee-jerk reaction is to not apply "zero-trust" to them. -Ben _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
