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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> wrote:
> 
> > Hi Benjamin,
> >
> > Thanks for your comments!
> >
> > On Thu, Jun 27, 2019 at 8:14 AM Benjamin Kaduk via Datatracker
> > <[e-mail]> 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