Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 03 July 2019 20:12 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7595C120168; Wed, 3 Jul 2019 13:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGl6izqU9KOV; Wed, 3 Jul 2019 13:12:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7048F1200C7; Wed, 3 Jul 2019 13:12:08 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x63KC2gg009941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jul 2019 16:12:04 -0400
Date: Wed, 03 Jul 2019 15:12:01 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jen Linkova <furry13@gmail.com>, Chris Bowers <chrisbowers.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, Ronald Bonica <rbonica@juniper.net>, rtgwg-chairs <rtgwg-chairs@ietf.org>, draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, Routing WG <rtgwg@ietf.org>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
Message-ID: <20190703185314.GL13810@kduck.mit.edu>
References: <156158728441.20135.9632421726659042986.idtracker@ietfa.amsl.com> <CAFU7BASqGX1u4hiaVNxBcMi+7y6fHnP5=xi=phJeOWoymy7Rjg@mail.gmail.com> <CAHzoHbuiP9cqOv5KAkYN=oDhrU_Og98AuN_kbE73Ao9ns5ZquQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHzoHbuiP9cqOv5KAkYN=oDhrU_Og98AuN_kbE73Ao9ns5ZquQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/Hof1A3D1cFaZridujc_Cbg6sREk>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 20:12:12 -0000
Replying to both Jen and Chris in one go... [re-sending as my client crashed while trying the first time] On Mon, Jul 01, 2019 at 04:27:13PM -0500, Chris Bowers wrote: > Please see responses inline with [CB]. > > Thanks, > Chris > > On Mon, Jul 1, 2019 at 9:59 AM Jen Linkova <furry13@gmail.com> wrote: > > > Hi Benjamin, > > > > Thanks for your comments! > > > > On Thu, Jun 27, 2019 at 8:14 AM Benjamin Kaduk via Datatracker > > <noreply@ietf.org> 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.' I think there was maybe a copy/paste issue here, as "it will not be delivered[...]" is duplicated. Ah, but this is already in the published -09, which looks fine; great. > > > > > 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. Ah, thank you! > > > 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? > > > > [CB] Below is proposed text to try to clarify this. "More specific" and > "less specific" were transposed in the original text which probably > confused things. I would definitely believe that! > 3. For a given source-prefix-scoped forwarding table T (scoped to > source prefix P), > consider a source-prefix-scoped forwarding table T', whose source > prefix P' contains P. > We call T the more specific source-prefix-scoped forwarding table, and > T' the less specific > source-prefix-scoped forwarding table. We select entries in the less specific > source-prefix-scoped forwarding table to augment the more specific > source-prefix-scoped > forwarding table based on the following rules. If a destination > prefix of an entry in the less specific > source-prefix-scoped forwarding table exactly matches the destination > prefix of an existing entry in the more > specific source-prefix-scoped forwarding table (including > destination prefix length), then do not add the entry to the more specific > source-prefix-scoped forwarding table. If the destination prefix > does NOT match an existing entry, then add the entry to the more > specific source-prefix-scoped forwarding table. As the unscoped > forwarding table is considered to be scoped to ::/0, this process > will propagate routes from the unscoped forwarding table > to the more specific source-prefix-scoped forwarding table. > If there exist multiple source-prefix-scoped forwarding tables whose > source prefixes contain P, > these source-prefix-scoped forwarding tables should be processed in order from > most specific to least specific. > > ========== > [CB The paragraph beginning with "The final step is for R8 to" also > suffers from the transposition of "more specific" and "less specific". > Corrected text > is proposed below. > > The final step is for R8 to augment the more specific source-prefix- > scoped forwarding tables with entries from less specific source-prefix-scoped > forwarding tables. The unscoped forwarding table is considered as being > scoped to ::/0, so both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 > are more specific prefixes of ::/0. Therefore, entries in the unscoped > forwarding table will be evaluated to be added to these two > more specific source-prefix-scoped forwarding tables. If a forwarding > entry from the less specific source-prefix-scoped forwarding table > has the exact same destination prefix (including destination prefix length) > as the forwarding entry from the more specific source-prefix-scoped > forwarding table, > then the existing forwarding entry in the more specific > source-prefix-scoped forwarding table wins. > > ============ Thanks; both chunks of new text now make sense to me as written. > > > > 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." (I think Suresh had looked at the same issue/text, and) this looks good in the -09. > > [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? > > > [CB] We're not defining an EXCLUSIVE flag in this document, so we could > add a sentence like : "The definition of an EXCLUSIVE flag for SADR > advertisements in IGPs > would require future standardization work." I'd lean towards doing so, for the sake of clarity (but either way is fine). > > > > > > 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.' Thanks! > > > > > > 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? Whoops, I didn't notice that there were two instances of "can" here, which makes my comment extra-confusing; sorry. My suggestion would be to replace both "can" with "could", yes. > > > > > > 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." Thanks! (s/immidiately/immediately/) > > > > > 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). I may have just been misreading and/or confused; thanks for clarifying. > > > 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! If you make another revision, please do add the comma as well. > > > 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'. Oh. It might be worth noting in a parenthetical "(which remains at the time of this writing not widely implemented)" > > > 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. So I was thinking that maybe some text like "first-hop routers need to implement SADR and be part of the same SADR domain as the SERs, as well as be able to send [...]" would be consistent with the text elsewhere in the document that reaffirms the need for a connected SADR domain. > > > > > > 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 Thanks -- split-horizon is indeed a hard problem :) > > > > > > 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. > > > > " 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. That seems likely, and thanks. > > 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! Luckily we did hear from your co-authors :) Thanks for all the updates, Ben
- Benjamin Kaduk's No Objection on draft-ietf-rtgwg… Benjamin Kaduk via Datatracker
- Re: Benjamin Kaduk's No Objection on draft-ietf-r… Jen Linkova
- Re: Benjamin Kaduk's No Objection on draft-ietf-r… Chris Bowers
- Re: Benjamin Kaduk's No Objection on draft-ietf-r… Benjamin Kaduk
- Re: Benjamin Kaduk's No Objection on draft-ietf-r… Jen Linkova
- Re: Benjamin Kaduk's No Objection on draft-ietf-r… Benjamin Kaduk