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)
>
> > 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.
Are we in sync?
> > 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.
"
>
> > 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.
More answering your own review 😊
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
