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

[Jen Linkova <[e-mail]>]

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?

>    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