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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 26 June 2019 22:14 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtgwg@ietf.org
Delivered-To: rtgwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E75012018A; Wed, 26 Jun 2019 15:14:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, Ron Bonica <rbonica@juniper.net>, rtgwg-chairs@ietf.org, rbonica@juniper.net, rtgwg@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156158728441.20135.9632421726659042986.idtracker@ietfa.amsl.com>
Date: Wed, 26 Jun 2019 15:14:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/NlNddN-r4aNx-OskHeIkqY_HKAs>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Jun 2019 22:14:44 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-rtgwg-enterprise-pa-multihoming-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

   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.

                                   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.

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.

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

   An interesting side-effect of deploying SADR is if all routers in a
   given network support SADR and have a scoped forwarding table, then
   the unscoped forwarding table can be eliminated which ensures that
   packets with legitimate source addresses only can leave the network

nit: s/packets with legitimate source addresses only/only packets with
legitimate source addresses/

                It would prevent accidental leaks of ULA/reserved/link-
   local sources to the Internet as well as ensures that no spoofing is
   possible from the SADR-enabled network.

nit: s/ensures/ensuring/

Section 5

   If all of the ISP uplinks are working, the choice of source address
   by the host may be driven by the desire to load share across ISP
   uplinks, or it may be driven by the desire to take advantage of
   certain properties of a particular uplink or ISP.  If any of the ISP
   uplinks is not working, then the choice of source address by the host
   can determine if packets get dropped.

nit: maybe s/determine if packets get dropped/cause packets to be
dropped/ ?  It seems unlikely that a host would specifically choose a
source address in order to provide the "will be dropped" behavior, since
it could just not send the packet in the first place instead.

               For a session originated from an external host to an
   internal host, the choice of source address used by the internal host
   is simple.  The internal host has no choice but to use the
   destination address in the received packet as the source address of
   the transmitted packet.

(side note) I guess there may be cases where the internal host has a
prearranged agreement with the external host to triangle-route packets,
but (quibbles about "no choice" aside) that doesn't seem pedagogically
relevant to mention here.

Section 5.2

   Again we return to the topology in Figure 3.  Suppose that the site
   administrator wants to implement a policy by which all hosts need to
   use ISP-A to reach H01 at D=2001:db8:0:1234::101.  [...]

nit: I think this wants s/H01/H101/

Section 5.2.3

   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?

   However using ICMPv6 for signalling source address information back
   to hosts introduces new challenges.  [...]

New security risks, too!

                                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.

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.

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?

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?)

   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 [...]"

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"? ;)

   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?

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.

   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.

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.