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

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear Roman and Benjamin

Many thanks for your reviews!

I took the liberty to merge your comments on section 11 in a single thread, since they have commonalities.
Also, I'll try to answer the questions with my own words as they come, and then propose a global change to section 11 at the end of the email.
The overall changes are posted as -1ç but you may use the copied text below to propose amendments / additions, I hope that all works for you.

https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-19


Please see below:

> 
> ----------------------------------------------------------------------
> DISCUSS (Roman):
> ----------------------------------------------------------------------
> 
> Section 11.  Can assumptions of the about the security properties of the links
> be clarified.
> 
> This specification applies to LLNs and a backbone in which the
>    individual links are protected against rogue access, e.g., by
>    authenticating a node that attaches to the network and encrypting at
>    the MAC layer the transmissions that may be overheard.  In
>    particular, the LLN MAC is required to provide secure unicast to/from
>    the Backbone Router and secure Broadcast from the Backbone Router in
>    a way that prevents tampering with or replaying the RA messages.
> 
> -- what are the specific assumptions about the protections that will be on the
> link.  Is the list of properties in the “e.g.” the full list?

For all I know it is the full list, let me remove the "e.g.,".  

Compiling this question with Benjamin's below I'd say that this work inherits from ND, which allows any node that can access the link to do anything, appear as a router,  source traffic and attract traffic. ND can also be used to DoS a network from a remote node by sending high volumes of packets, each to a different forged address, and each causing a temp state in the router and a broadcast on the fabric.

We interwork with that on the backbone, and the draft gives precedence to the legacy operation, meaning that a node that can attack ND can attack us in the exact same way.

I can add words to say that. RFC 4861 section 11.1 tells us to "keep the bad guys out or all bets are off", IOW, Woodstock. Section 11.2 has the hopeful thinking that SeND will be deployed, and we know it will not happen. For info, this only implementation that shipped that I'm aware of is the router side by our co-author Eric in Cisco's IOS. We are well placed to know it's doomed and very motivated to give another chance to securing ND. Which lead us to AP-ND.
And since ND does nothing for that, it means "do not let the bad guys access the network at L2" and "do not let the bad guys compromise any system on the network". I will not even try the Woodstock analogy there.

What changes:
- nodes that are attached to the LLN cannot attack that easily (if AP-ND is enforced) 
- we have nodes that are more sensitive than others (the 6BBR and 6LBR are new targets that can impact many nodes, note that the default router already was one, and anybody could impersonate it).
- when a policy enforces AP-ND to all nodes including the backbone then :
    * the increased security that we have on the LLN will also apply to the backbone (no impersonation or stealing address)
    * the complete list of addresses n the network will be known to the default router which will block the remote DoS attacks
    * DAD and Lookups will be fast and without multicast, which again will be a protection against some ND-based DoS attacks. 
    * DAD will work on Wi-Fi (arguably it does not today in a large conference like IETF)
    * L2 tables will be small and stable


> -- As the second sentence references the only the LLN MAC, using Figure 1
> and 2 as a reference (realizing they are non-normative), what’s expected
> properties of the links between the router-and-6BBR or IPv6 node-and-6BBR
> (i.e., the links connecting to the “backbone side”)?

This is typically (IOW always) a legacy ethernet link and the expectation has to be compatible with existing deployments and capabilities (Woodstock).
The registration is an attempt to migrate to a more zero-trusty behavior.

> 
> 
> ----------------------------------------------------------------------
> COMMENT: (Benjamin)
> ----------------------------------------------------------------------
>
> 
> We force a sequencing that has EDAR/EDAC occur before normal NS(DAD);
> does this provide a new DoS avenue by virtue of delaying the normal
> NS(DAD) procedure by (e.g.) dropping the EDAC messages?

I do not see a large opening since the unicast query is rapid. The node could have a short time out in the order of a few ms before it starts DADing. Which is negligible compared to the 1s (time x retries) DAD time out that plagues IPv6 over Wi-Fi in IEEE 802.11ai (Fast Link Setup, aka FILS) scenarios.
I see a DoS attack against the 6LBR, but that's common to any server like DNS or LISP MSMR, and the traditional methods apply.


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

I had trouble parsing but after a night's sleep it appears that an s/of/or/ helps a lot. Point taken, this relates to the classical ND attacks on the backbone that cannot be defeated unless the registration is the only form of ND on the backbone. It seems relevant to point out the Woodstock approach in classical ND in the intro and indicate that we're subject to it by contagion on the backbone.

"

   This specification considers a special type of MLSN with a central
   backbone that federates edge (LLN) links, each Link providing its own
   protection against rogue access and tempering or replaying packets.
   In particular, the use of classical IPv6 ND on the backbone requires
   that the all nodes are trusted and that rogue access to the backbone
   is prevented at all times (see Section 11).

"


>    This specification applies to LLNs and a backbone in which the
>    individual links are protected against rogue access, e.g., by
>    authenticating a node that attaches to the network and encrypting at
>    the MAC layer the transmissions that may be overheard.  In
>    particular, the LLN MAC is required to provide secure unicast to/from
>    the Backbone Router and secure Broadcast from the Backbone Router in
>    a way that prevents tampering with or replaying the RA messages.
> 
> It seems like it would be worth stating these requirements/applicability
> statement much earlier in the document (possibly in addition to here), e.g., in
> the Introduction.

Incorporated in the above


> 
>    provide the proof-of-ownership.  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.
> 
> 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.

We trust any node on the backbone to behave honestly, that's the Woodstock.  In the 'what changes' text I need to mention the 6BBR and the 6LBR, as points of concentration which would naturally attract an attacker, because they are bottlenecks that see all of a particular type of traffic. But as look as classical ND is operated in the network, compromising any node is probably enough to perform any ND attack.

> 
> We could also discuss how things break if the "distributed database" of
> registrations gets out of sync across 6BBRs/etc..

Yes, I'll have a paragraph on that, bottom line is that a stale state will lose in a fight and disappear ultimately when there is none.
Still, a legacy node that does not understand EARO in NA may pick the old 6BBR even if the new one also responds.

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

"