Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)

Jen Linkova <> Mon, 01 July 2019 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 630A41202F1; Mon, 1 Jul 2019 07:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jAKZg_p4ebm3; Mon, 1 Jul 2019 07:59:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6D0B1202FD; Mon, 1 Jul 2019 07:59:15 -0700 (PDT)
Received: by with SMTP id a15so14930602qtn.7; Mon, 01 Jul 2019 07:59:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Tue, 2 Jul 2019 00:59:02 +1000
Message-ID: <>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
To: Benjamin Kaduk <>
Cc: The IESG <>, Ronald Bonica <>, rtgwg-chairs <>,, Routing WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
<>; 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


> 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


> 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"


>    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.
> 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.


>              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

> 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

>    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..).
SY, Jen Linkova aka Furry