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

[Benjamin Kaduk <[e-mail]>]

Hi Pascal,

This also looks good to me; I'll just leave a few minor comments here
before returning to the other thread.

On Sun, Mar 22, 2020 at 01:00:06AM +0000, Roman Danyliw wrote:
> Hi Pascal!
> 
> The new language in -19 looks good to me and addresses my feedback.  Thanks for making these updates.
> 
> Roman
> 
> -----Original Message-----
> From: Pascal Thubert (pthubert) <[e-mail]> 
> Sent: Tuesday, March 3, 2020 11:03 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; Benjamin Kaduk <[e-mail]>
> Cc: [e-mail]; Carles Gomez <[e-mail]>; Samita Chakrabarti <[e-mail]>; Shwetha Bhandari (shwethab) <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)
> 
[...]
> > How do things degrade if a secondary 6BBR "stands back" to let a primary
> > handle a given message but the primary 6BBR has gone offline unbeknownst
> > to the secondary?
> 
> Yes, text needed too. Not just in the security section. If the registering node loses a 6BBR,  it should reregister to another (that's an obvious), and if it is registered to multiple 6BBRs, it should refresh the other registrations with a new TID (text needed). We have no design for a registered node using multiple registering node, and that's worth mentioning too.
> 
> 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."

>    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".)

>    indicate an identical Binding in another 6BBR (same Registered
>    address, same TID, same ROVR) are silently ignored but for the
>    purpose of selecting the primary 6BBR for that registration.
> 
> <...>
> 
>    If a Registering Node loses connectivity to its or one of the 6BBRs
>    to which it registered an address, it retries the registration to the
>    (one or more) available 6BBR(s).  When doing that, the Registering
>    Node MUST increment the TID in order to force the migration of the
>    state to the new 6BBR, and the reselection of the primary 6BBR if it
>    is the node that was lost.
> "
> 
> > 
> > Are there any noteworthy scaling requirements to the bridging and routing
> > proxy modes?  (I don't think so, and we just allude to "dimensioned for the
> > number of registrations that each needs to support"
> > in Appendix B, but it doesn't hurt to ask.)
> 
> Not really that I can figure, beyond the obvious that you mention.
> 
> Putting it all together there we go for the proposed section 11 update:
> 
> 
> "
> 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
[...]".

>    secure unicast to/from the Backbone Router and secure broadcast from
>    the routers in a way that prevents tampering with or replaying the ND
>    messages.
> 
>    For the IPv6 ND operation over the backbone, and unless the classical
>    ND is disabled (e.g., by configuration), the classical ND messages
>    are interpreted as emitted by the address owner and have precedence
>    over the 6BBR that is only a proxy.  It results that the security
>    threats that are detailed in section 11.1 of [RFC4861] fully apply to
>    this specification as well.  In very short:
> 
>    *  Any node that can send a packet on the backbone can take over any
>       address including addresses of LLN nodes by claiming it with an NA
>       message and the Override bit set.  This means that the real owner
>       will stop receiving its packets.
> 
>    *  Any node that can send a packet on the backbone can forge traffic
>       and pretend it is issued from a address that it does not own, even
>       if it did not claim the address using ND.
> 
>    *  Any node that can send a packet on the backbone can present itself
>       as a preferred router to intercept all traffic outgoing the
>       subnet.  It may even expose a prefix on the subnet as not-on-link
>       and intercept all the traffic within the subnet.
> 
>    *  If the rogue can receive a packet from the backbone it can also
>       snoop all the intercepted traffic, be it by stealing an address or
>       the role of a router.
> 
>    This means that any rogue access to the backbone must be prevented at
>    all times, and that nodes that are attached to the backbone must be
>    fully trusted / never compromised.
> 
>    Using address registration as the sole ND mechanism on a link and
>    coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a
>    registered address within that link.  The protection is based on a
>    proof-of-ownership encoded in the ROVR field and protects against
>    address theft and impersonation by a 6LN, because the 6LR can
>    challenge the Registered Node for a proof-of-ownership.
> 
>    The protection extends to the full LLN in the case of an LLN Link,
>    but does not extend over the backbone since the 6BBR cannot provide
>    the proof-of-ownership when it defends the address.
> 
>    A possible attack over the backbone can be done by sending an NS with
>    an EARO and expecting the NA(EARO) back to contain the TID and ROVR
>    fields of the existing state.  With that information, the attacker
>    can easily increase the TID and take over the Binding.
> 
>    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.)

-Ben

>       increased security that [I-D.ietf-6lo-ap-nd] provides on the LLN
>       will also apply to the backbone; it becomes impossible for an
>       attached node to claim an address that belongs to another node
>       using ND, and the network can filter packets that are not
>       originated by the owner of the source address (SAVI), as long as
>       that the routers are known and trusted.
> 
>    Remote ND DoS attack avoidance:  the complete list of addresses in
>       the network will be known to the 6LBR and available to the default
>       router; with that information the router does not need to send a
>       multicast NA(Lookup) in case of a Neighbor Cache miss for an
>       incoming packet, which is a source of remote DoS attack against
>       the network
> 
>    Less IPv6 ND-related multicast on the backbone:  DAD and NS(Lookup)
>       become unicast queries to the 6LBR
> 
>    Better DAD operation on wireless:  DAD has been found to fail to
>       detect duplications on large Wi-Fi infrastructures due to the
>       unreliable broadcast operation on wireless; using a 6LBR enables a
>       unicast lookup
> 
>    Less Layer-2 churn on the backbone:  Using the Routing Proxy
>       approach, the Link-Layer address of the LLN devices and their
>       mobility are not visible in the backbone; only the Link-Layer
>       addresses of the 6BBR and backbone nodes are visible at Layer 2 on
>       the backbone.  This is mandatory for LLNs that cannot be bridged
>       on the backbone, and useful in any case to scale down, stabilize
>       the forwarding tables at Layer 2 and avoid the gratuitous frames
>       that are typically broadcasted to fix the transparent bridging
>       tables when a wireless node roams from an AP to the next.
> 
>    This specification introduce 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, but not more than a default
>    router and a DHCP server, respectively, which already exist in
>    classical networks, and can be defended using the same methods.
> 
>    A possible attack over the LLN can still be done by compromising a
>    6LR.  A compromised 6LR may modify the ROVR of EDAR messages in
>    flight and transfer the ownership of the Registered Address to itself
>    or a tier.  It may also claim that a ROVR was validated when it
>    really wasn't, and reattribute an address to self or to an attached
>    6LN.  This means that 6LRs, as well as 6LBRs and 6BBRS must still be
>    fully trusted / never compromised.
> 
>    This specification mandates to check on the 6LBR on the backbone
>    before doing the classical DAD, in case the address already exists.
>    This may delay the DAD operation and should be protected by a short
>    timer, in the order of 100ms or less, which will only represent a
>    small extra delay versus the 1s wait of the DAD operation.
> 
> "
> 
> 
>