Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)

[Benjamin Kaduk <[e-mail]>]

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