Hi Ben, I've just submitted -10 version which has Chris's changes integrated as well as all suggestions you made.
The diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-enterprise-pa-multihoming-10 Full text: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10 A few comments below: On Thu, Jul 4, 2019 at 6:12 AM Benjamin Kaduk <[email protected]> wrote: > > > > To fully benefit from the RA-based solution, first-hop routers need > > > > to implement SADR and be able to send dedicated RAs per scoped > > > > > > > > It's not just the first-hop routers, though -- won't all the first-hops > > > > need to be part of the same connected SADR domain? > > > > > > They are. By design/definition. > > Perhaps I'm still confused, but I thought other parts of this document > admitted the possibility of having multiple SADR-capable routers that are > not all in a connected domain, if only to say "don't do that". For > example, all the SERs need to be in the same domain. But if I look at, > e.g., Figure 1's topology, R3 would be a first-hop router for H41, and if I > read the quoted text literally, having R3 and the SERs support SADR but not > R5 would seem to produce a disconnected domain and thus problems. That's why we are saying: "Therefore all SADR-capable routers within the domain MUST be logically connected." Having R3 and SERs in the SADR domain with non-SADR capable R5 between them might lead to a routing loop. The changes made in -10 to clarify this: 1) Replaced: "To fully benefit from the RA-based solution, first-hop routers need to implement SADR and be able to send dedicated RAs per scoped forwarding table as discussed above," with "To fully benefit from the RA-based solution, first-hop routers need to implement SADR, belong to the SADR domain and be able to send dedicated RAs per scoped forwarding table as discussed above.." 2) Added another item to the Deployment Considerations section: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-7.1 "During the incremental SADR domain expansion from the SERs down towards first-hop routers it's important to ensure that at any moment of time all SADR-capable routers within the domain are logically connected (see Section 5)." Is it less confusing now? > That's one type of attack, yes. I think there may be another one where the > attacker has some wiretap in ISP_A but not ISP_B, and they can use the > ICMPv6 message to tell the sender to use the source address from ISP_A when > traffic would otherwise go to ISP_B or elsewhere -- the forged message > causes the traffic to be routed where the attacker can do other things to > it. > > > > I think that if such messages are required to be sent from the > > > link-local address and the GTSM is enforced, then the attack vector is > > > limited to the same L2 domain which is a bit better..I'll add the text > > > to clarify it tomorrow. After thinking about it I've realized that GTSM would not help here. Those messages could be sent from SERs (which are a few hops away). I've moved all security considerations from that section to Section 10: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-10 Please let me know if you have any comments for -10 version. Thanks! -- SY, Jen Linkova aka Furry _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
