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

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Jul 2019 00:59:02 +1000

Hi Benjamin,

Thanks for your comments!

On Thu, Jun 27, 2019 at 8:14 AM Benjamin Kaduk via Datatracker
<[email-masked]> 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

---

From: Chris Bowers <[email-masked]>
Date: Mon, 1 Jul 2019 16:27:13 -0500

Please see responses inline with [CB].

Thanks,
Chris

> I'm not really sure how to re-phrase it...

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

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.

============

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Jul 2019 15:12:01 -0500

Replying to both Jen and Chris in one go...
[re-sending as my client crashed while trying the first time]

> > ISP-A has failed. Two-way communication would require some uplink with

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.

> > Reference to the section 4.3 of [RFC3704] added.

Ah, thank you!

> "less specific" were transposed in the original text which probably

I would definitely believe that!

> most specific to least specific.

Thanks; both chunks of new text now make sense to me as written.

> > domain MUST be logically connected."

(I think Suresh had looked at the same issue/text, and) this looks good in
the -09.

> would require future standardization work."

I'd lean towards doing so, for the sake of clarity (but either way is
fine).

Thanks!

> > Hmmm....As a non-native speaker I'd need some advice....Would 'could' be

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.

> >    trigger a large number of ICMPv6 packets being sent to hosts in that

Thanks!  (s/immidiately/immediately/)

> > (well, the default address selection shall take care of it anyway).

I may have just been misreading and/or confused; thanks for clarifying.

> > > failure hosts would lose [...]"

If you make another revision, please do add the comma as well.

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

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

> > https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.8.1

Thanks -- split-horizon is indeed a hard problem :)

> >    ICMPv6 messages to signal invalid/unreachable source prefix causing

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.

> > limited to the same L2 domain which is a bit better..I'll add the text

That seems likely, and thanks.

> > exception of those two where I'd like to hear from my co-authors..).

Luckily we did hear from your co-authors :)

Thanks for all the updates,

Ben

---

From: Jen Linkova <[email-masked]>
Date: Thu, 4 Jul 2019 10:42:35 +1000

Hi Ben,

I've just submitted -10 version which has Chris's changes integrated
as well as all suggestions you made.

The diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-enterprise-pa-multihoming-10

Full text:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10

A few comments below:

On Thu, Jul 4, 2019 at 6:12 AM Benjamin Kaduk <[email-masked]> wrote:
> R5 would seem to produce a disconnected domain and thus problems.

That's why we are saying:
"Therefore all SADR-capable routers within the domain MUST be
logically connected."
Having R3 and SERs in the SADR domain with non-SADR capable R5 between
them might lead to a routing loop.

The changes made in -10 to clarify this:
1) Replaced:
"To fully benefit from the RA-based solution, first-hop routers need
to implement SADR and be able to send dedicated RAs per scoped
forwarding table as discussed above,"

with
"To fully benefit from the RA-based solution, first-hop routers need
to implement SADR, belong to the SADR domain and be able to send
dedicated RAs per scoped forwarding table as discussed above.."

2) Added another item to the Deployment Considerations section:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-7.1
"During the incremental SADR domain expansion from the SERs down
towards first-hop routers it's important to ensure that at any
moment of time all SADR-capable routers within the domain are
logically connected (see Section 5)."

Is it less confusing now?

> > > limited to the same L2 domain which is a bit better..I'll add the text

After thinking about it I've realized that GTSM would not help here.
Those messages could be sent from SERs (which are a few hops away).
I've moved all security considerations from that section to Section 10:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-10

Please let me know if you have any comments for -10 version.

Thanks!

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Jul 2019 19:16:54 -0500

> Is it less confusing now?

Greatly so; thank you!

> Please let me know if you have any comments for -10 version.

It looks good here (just one typo "tra ffic" that may be my fault anyway).

Thanks again,

Ben