Many thanks Roman! > -----Original Message----- > From: Roman Danyliw <[email protected]> > Sent: dimanche 22 mars 2020 02:00 > To: Pascal Thubert (pthubert) <[email protected]>; The IESG > <[email protected]>; Benjamin Kaduk <[email protected]> > Cc: [email protected]; Carles Gomez > <[email protected]>; Samita Chakrabarti <[email protected]>; > Shwetha Bhandari (shwethab) <[email protected]>; [email protected]; > [email protected] > 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) <[email protected]> > Sent: Tuesday, March 3, 2020 11:03 AM > To: Roman Danyliw <[email protected]>; The IESG <[email protected]>; Benjamin Kaduk > <[email protected]> > Cc: [email protected]; Carles Gomez > <[email protected]>; Samita Chakrabarti <[email protected]>; > Shwetha Bhandari (shwethab) <[email protected]>; [email protected]; > [email protected] > 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. > > " > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
