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

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

Many thanks Roman!

> -----Original Message-----
> From: Roman Danyliw <[e-mail]>
> Sent: dimanche 22 mars 2020 02:00
> To: Pascal Thubert (pthubert) <[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)
> 
> 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)
> 
> 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.
> 
> "
> 
>