Hi Benjamin, Thanks for your comments!
On Thu, Jun 27, 2019 at 8:14 AM Benjamin Kaduk via Datatracker <[email protected]> wrote: > I mostly only have editorial comments, but please note the potential > additional security considerations for ICMPv6 "use this source > address" messages, and the question about leaving a SADR domain being > equivalent to leaving the site. > > Abstract > > This document attempts to define a complete solution to this problem. > It covers the behavior of routers to forward traffic taking into > account source address, and it covers the behavior of host to select > appropriate source addresses. [...] > > nit: singular/plural mismatch routers/host Fixed. > Section 1 > > The return packet will be routed over the Internet to ISP-A, but > it will not be delivered to the multihomed site because its link with > ISP-A has failed. [...] > > nit: I think formally the subject that "it" refers to in "its link" is > the packet, not the site, so we'd want to disambiguate here. Rephrased as 'The return packet will be routed over the Internet to ISP-A, but it will not be delivered to the multihomed site because its link with it will not be delivered to the multihomed site because the site ISP-A has failed. Two-way communication would require some uplink with ISP-A has failed.' > Note that the same may be true with a provider that does not > implement BCP 38, if his upstream provider does, or has no > corresponding route. The issue is not that the immediate provider > implements ingress filtering; it is that someone upstream does, or > lacks a route. > > I'm sure this is just my lack of background, but I didn't see much > introduction of what a "corresponding route" means. I've added some clarifying text there to indicate that it's for the route for the return traffic. > That is, some routers must be capable > of some form of Source Address Dependent Routing (SADR), if only as > described in [RFC3704]. [...] > > I do not see reference to either "source address dependent routing" or > "SADR" in RFC 3704. Reference to the section 4.3 of [RFC3704] added. > Section 3.2 > > In Figure 2, we modify the topology slightly by inserting R7, so that > SERa and SERb are no longer directly connected. With this topology, > it is not enough to just enable SADR routing on SERa and SERb to > support PA multi-homing. There are two solutions to ways to enable > PA multihoming in this topology. > > nit: "solutions to ways" seems redundant Fixed. > > Section 4 > > 3. Augment each less specific source-prefix-scoped forwarding table > with all more specific source-prefix-scoped forwarding tables > entries based on the following rule. If the destination prefix > of the less specific source-prefix-scoped forwarding entry > exactly matches the destination prefix of an existing more > specific source-prefix-scoped forwarding entry (including > destination prefix length), then do not add the less specific > source-prefix-scoped forwarding entry. [...] > > I think this is just editorial, but we start by saying ~"augment > less-specific routes" and thenwe say ~"do not add the less-specific > routes", which doesn't match up -- we can't add X to the baseline when X > is the baseline, and would have to remove X and replace it with the > more-specific thing. I'm not really sure how to re-phrase it... Chris, any ideas? > The forward tables produced by this process are used in the following > way to forward packets. > > nit: "forwarding tables" Fixed. > Any traffic that needs to exit the site will eventually hit a SADR- > capable router. Once that traffic enters the SADR-capable domain, > then it will not leave that domain until it exits the site. [...] > > Er, what enforces/provides this property? (I assume it's not a new > requirement being introduced here...) I've rephrased it to: " As all SERs belong to the SADR domain any traffic that needs to exit capable router. Once that traffic enters the SADR-capable domain, the site will eventually hit a SADR-capable router. To prevent then it will not leave that domain until it exits the site. This routing loops involving SADR-capable and non-SADR-capable routers, property is required in order to guarantee that there will not be traffic that enters the SADR-capable domain does not leave the domain routing loops involving SADR-capable and non-SADR-capable routers. until it exits the site. Therefore all SADR-capable routers with the domain MUST be logically connected." [some editorial nits metioned here fixed] > We can also use this source-prefix-scoped route originated by SERa to > communicate the desired routing policy to SERb1. We can define an > EXCLUSIVE flag to be advertised together with the IGP route for > (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). [...] > > Just to check my understanding, is this "we can define" a statement of > future possibilities (viz. > https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02) > or something being undertaken in this current document? I'm not sure actually. Chris, Fred - do you recall what do we mean here? > However using ICMPv6 for signalling source address information back > to hosts introduces new challenges. [...] > > New security risks, too! They are discussed in the text and I've added another sentence: 'However this approach has some security implications such as an ability for an attacker to send spoofed ICMPv6 messages to signal invalid/unreachable source prefix causing DoS-type attack.' > > In addition, the same source prefix > SHOULD be used for other destinations in the same /64 as the original > destination address. The source prefix SHOULD have a specific > lifetime. Expiration of the lifetime SHOULD trigger the source > address selection algorithm again. > > nit: I assume this lifetime is for the cached mapping of src/dst > prefixes, and not for using the source prefix at all. You are absolutely right, fixed. > > Section 5.2.4 > > As all those options have been > standardized by IETF and are supported by various operating systems, > no changes are required on hosts. [...] > > nit: this is a comma splice. Fixed. > > The policy distribution can be automated by defining an > EXCLUSIVE flag for the source-prefix-scoped route which can be set on > the SER that originates the route. [...] > > nit: "can" is present tense and implies the capability already exists > today; my understanding from the rest of the document is that this > statement refers to potential future work. Hmmm....As a non-native speaker I'd need some advice....Would 'could' be better? > > Section 5.3.3 > > Potential issue with using ICMPv6 for > signalling source address issues back to hosts is that uplink to an > ISP-B failure immediately invalidates source addresses from > 2001:db8:0:b000::/52 for all hosts which triggers a large number of > ICMPv6 being sent back to hosts - the same scalability/rate limiting > issues discussed in Section 5.2.3 would apply. > > nit: the grammar here is not great. Also, is the invalidation "for all > hosts" just for use with external destinations? Rephrased to "Using ICMPv6 would have the same scalability/rate limiting issues discussed in Section 6.2.3. ISP-B uplink failure immidiately makes source addresses from 2001:db8:0:b000::/52 unsuitable for external communication and might trigger a large number of ICMPv6 packets being sent to hosts in that subnet." > Section 5.5.2 > > In the absence of (S=ULA_Prefix; D=::/0) first-hop routers > will send dedicated RAs from a unique link-local source LLA_ULA with > PIO from ULA address space, RIO for the ULA prefix and Router > Lifetime set to zero. [...] > > (This is still scoped to the "no external connectivity" case, right?) Hmm...Looks like I need to clarify it in the text - but no. Whatever the uplinks state is, the ULA-scoped tabe SHOULD NOT have the default route. So ULAs will be used for intra-site communication only. (well, the default address selection shall take care of it anyway). > particularly useful if all ISPs assign prefixes via DHCP-PD. In the > absence of ULAs uplinks failure hosts would lost all their GUAs upon > prefix lifetime expiration which again makes intra-site communication > impossible. > > nit: I think this is supposed to be "In the absence of ULAs, on uplink > failure hosts would lose [...]" yes, fixed. Thanks! > Section 5.6 > > [I stopped noting most grammar nits here] > > 1. no new (non-standard) functionality needs to be implemented on > hosts (except for [RFC4191] support); > > RFC 4191 is from 2005; does it really still count as "new"? ;) If you look what OSes support RIOs you might be unpleasantly surprised..'New' as 'have not been implemented yet'. > 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. > > Section 5.7.1 > > [RFC8106] defines IPv6 Router Advertisement options to allow > IPv6 routers to advertise a list of DNS recursive server addresses > and a DNS Search List to IPv6 hosts. Using RDNSS together with > 'scoped' RAs as described above would allow a first-hop router (R3 in > the Figure 3) to send DNS server addresses and search lists provided > by each ISP (or the corporate DNS servers addresses if the enterprise > is running its own DNS servers). > > I only skimmed RFC 8106, but it seems like this suffers from the same > issue described above for linking PIO and RIO information (that inspired > draft-pfister-6man-sadr-ra) -- we aren't guaranteed an information link > between (source) address to use and DNS recursive to use. I do see a > note in 8106 that requires this linkage when link-local addresses are > used as DNS recursives, but not in the general case. While one might > counter that this doesn't matter, since the DNS is a globally consistent > database, in practice that proves to not be the case, with "walled > gardens" being available only within a given ISP, etc., so it does seem > like we could at least mention the potential for issues. And in fact we > do have such discussion a couple paragraphs later, so maybe all we want > is a hint that there's more to come. Updated the text in https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.8.1 > > It should be noted that [RFC8106] explicitly prohibits using DNS > information if the RA router Lifetime expired: "An RDNSS address or a > DNSSL domain name MUST be used only as long as both the RA router > Lifetime (advertised by a Router Advertisement message) and the > corresponding option Lifetime have not expired.". Therefore hosts > might ignore RDNSS information provided in ULA-scoped RAs as those > RAs would have router lifetime set to 0. However the updated version > of RFC6106 ([RFC8106]) has that requirement removed. > > It seems that the first reference here needs to be the old one, 6106, > not 8106 as presently indicated. Correct, fixed. > > Section 9 > > Section 5.2.3 discusses a mechanism for controlling source address > selection on hosts using ICMPv6 messages. It describes how an > attacker could exploit this mechansim by sending spoofed ICMPv6 > messages. It recommends that a given host verify the original packet > header included into ICMPv6 error message was actually sent by the > host itself. > > Section 5.2.3 also talks about a potential extension to ICMPv6 that > would indicate what source address to use, in addition to noting that > the selected source address does not work. Such an extension would also > have some new security considerations, in that it would provide an > attacker some measure of control over where the resulting traffic ended > up, as (e.g.) might be useful in steering a DDoS. I've added some text about "However this approach has some security implications such as an ability for an attacker to send spoofed ICMPv6 messages to signal invalid/unreachable source prefix causing DoS-type attack. " 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. Please let me know if I've missed/not address you comments (with the exception of those two where I'd like to hear from my co-authors..). Thanks! -- SY, Jen Linkova aka Furry _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
