Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
Jen Linkova <furry13@gmail.com> Mon, 01 July 2019 14:59 UTC
Return-Path: <furry13@gmail.com>
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 630A41202F1; Mon, 1 Jul 2019 07:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jAKZg_p4ebm3; Mon, 1 Jul 2019 07:59:16 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D0B1202FD; Mon, 1 Jul 2019 07:59:15 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id a15so14930602qtn.7; Mon, 01 Jul 2019 07:59:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KEupUd+0BLZL/33VYFcsdFnybZ0Zlvlm13Hw3qn3VAE=; b=YBlx9BqnWjlareVkhpgaDYowMSH6bWOhk4VUf1vHY74aCrRKRG9PtJA8JvO+qwPXFo 9Sz9OF7k0c7vQNPQuhEy9x/t308YqGX6bKOae8vu6H2Og71c3Q3LdNhGRvDZYeJK8Yp4 wcv3GmV/w13b6cyWb0ivp6NhjgnQTRyZ5mwlhqfu0eG+gsciBu2hJbIpMLQc8Nhys7jm uY5czxSQC7wPuwH1zxIL7f3BdJnbhTW11pcfJ7woYgtL8bFyUdHLPrU0NfYruIYjUHRI wuxDzw2tgTcrOou44li1zqObi3eooBHtytdsrYBkjV3NP40tlNldBO6bQ1/XjE+7Ti36 5RPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KEupUd+0BLZL/33VYFcsdFnybZ0Zlvlm13Hw3qn3VAE=; b=MIG9AJkL5L5aPBOvtfUujVeGMYgajSVw9HVMq0hBQtBo2upA2BQW+3b2Otlj3V8tDI jB63CSYS8gyYmWpjGmcaGFCOnDnr4Qvp3tmb4cgHpu5ZsvH/oHQZkhkf5f/SXKun7nmk 9ie9jAk3UC5a30ALnM9jp+PMBO7OEmV428iXSltoM205ecORhWt3vk7Dpxi/my1JCPly KmxpsERNVtTbzopwI2flgNtMA208fHvuWJjH+8eXPgYvF4wAIzBaByCUSQeyzH7qNFB/ 3M8VhxNiX58x7DWdVrk2UcRiABNvn3EXR0TLCpRHl4w2a53qE12BAQSQ7xkxzuUfYZsG JCyA==
X-Gm-Message-State: APjAAAVhDYVZwwkIrQ8F6Cnz+l0YTEskaHiUDhJ/pu4MRKfSXjrbftnu mKLBAZFGq9C7PO/K6yfFSCCxKvrPAfvLDq8/aDs=
X-Google-Smtp-Source: APXvYqxDIItgppg3oXDztpSfOHO8DygoMZLU5wnZW/qubuaziIoM7PejNuIbT1am3y7pZs0d0OWNCb6FPeMpcWeV4rc=
X-Received: by 2002:a0c:ea34:: with SMTP id t20mr17827146qvp.11.1561993154532; Mon, 01 Jul 2019 07:59:14 -0700 (PDT)
MIME-Version: 1.0
References: <156158728441.20135.9632421726659042986.idtracker@ietfa.amsl.com>
In-Reply-To: <156158728441.20135.9632421726659042986.idtracker@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 02 Jul 2019 00:59:02 +1000
Message-ID: <CAFU7BASqGX1u4hiaVNxBcMi+7y6fHnP5=xi=phJeOWoymy7Rjg@mail.gmail.com>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/7D5n3A_oRSIi3TgwwvwdoS8K3Rg>
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: Mon, 01 Jul 2019 14:59:19 -0000
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.' > 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
- 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