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

[Chris Bowers <[e-mail]>]

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

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

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


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


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