Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

From: [email-masked]
Date: Thu, 14 Sep 2017 12:09:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Unique IPv6 Prefix Per Host
        Authors         : John Jason Brzozowski
                          Gunter Van De Velde
	Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt
	Pages           : 9
	Date            : 2017-09-14

Abstract:
   This document outlines an approach utilising existing IPv6 protocols
   to allow hosts to be assigned a unique IPv6 prefix (instead of a
   unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
   IPv6 prefix over a unique service provider IPv6 address include
   improved host isolation and enhanced subscriber management on shared
   network segments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 14 Sep 2017 19:16:01 +0000

This -09 version includes new text to address the idnits (i.e. versus e.g.) noted by Brian and the clarification text pointed out on the first hop router solicited/Unicast RA response using the suggested text from David Farmer in section 4 para 3.

Also the text suggested by Lorenzo is included in the text to make the benefits of UE/subscriber more clear in section 1 para 3.

G/

On 14/09/2017, 21:09, "v6ops on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Sep 2017 08:02:14 +1200

Thanks, I'm happy with the changes now.

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 14 Sep 2017 15:21:50 -0500

One of the changes made between version 7 and 8 was to remove "UE/" from
"UE/subscriber" in several places, so maybe you want to remove them from
the text just inserted.  Regardless, there is a typo in the following;

   This solicited RA contains two important parameters for the EU/
   subscriber to consume: ...

I think you mean

   This solicited RA contains two important parameters for the UE/
   subscriber to consume: ...

Further, you could also change "This solicited RA" in the sentence to "The
RA", so it will be understood to apply to both solicited or periodic RAs.

   The RA contains two important parameters for the subscriber
   to consume: ...

Otherwise looks good to me.

Thanks

On Thu, Sep 14, 2017 at 2:16 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> This -09 version includes new text to address the idnits (i.e. versus
> e.g.) noted by Brian and the clarification text pointed out on the first
> hop router solicited/Unicast RA response using the suggested text from
> David Farmer in section 4 para 3.
>
> Also the text suggested by Lorenzo is included in the text to make the
> benefits of UE/subscriber more clear in section 1 para 3.
>
> G/
>
> On 14/09/2017, 21:09, "v6ops on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Sep 2017 18:18:16 -0700

Thanks for fixing these issues. I think there are two issues remaining.

First, the document needs to say something about periodic RAs. These are
necessary or the device will fall off the network after the initial 1800s
RA has expired. For initial RAs, the document covers two cases:

   1. RAs are sent to the link-local address that the RS came from.
   2. RAs are sent to ff02::1 but unicasted to the link-layer unicast
   address of the UE/subscriber.

Case #2 is easy: just send it to the MAC address of the subcriber.

Case #1 is not so easy.Which address should the router send it to? Does it
need to cache the link-local address from the first RA it sees?  What if
the RS comes from the unspecified address (AFAIK that's explicitly allowed
by 4861)? What if the host changes its link-local address? This is a
problem for the first RS as well, so #2 seems like a better option in
general.

Second, the RA lifetimes should be longer. Bear in mind that many current
mobile devices drop substantial percentage of multicast packets (1/2 or
even 2/3). If the battery life recommendations of RFC 7772 are followed,
the network will send RAs every 600s with a lifetime of 1800s. That means
that if the device drops all three packets, it will fall off the network
after 1800s. On a device that drops 2/3 multicast packets, that will happen
.66**3 = 28.7% of the time. We should increase the router lifetime
accordingly. Even if the lifetimes are increased to 3600s, the probability
of connection loss after 1 hour is .66^3 = 8.3% of the time.

If reliability is important I would suggest setting the RA lifetime to 5400
or 7200. In any case, the 3600 currently being recommended is too low.

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 00:54:44 -0500

> RA has expired. For initial RAs, the document covers two cases:

The text added does cover unsolicited RAs, A.K.A periodic RAs.

> problem for the first RS as well, so #2 seems like a better option in

The new text refers you to [RFC4861] section 6.2.6 for details about a
Unicast RA response and sections 6.2.4 and 6.2.6 for details about a
Multicast RA response or unsolicited RA. Further, section 6.2.6 says "but
the usual case is to multicast the response to the all-nodes group."
However, I'm not sure case #1, as you put it, is that much harder,
everything needed to do a Unicast RA response is knowing the RS packet, and
once the Unicast RA is sent that information isn't needed any longer and
can be forgotten. So from the perspective of this document I don't think
there needs to be a preference that differs for what is stated in [RFC4861]
section 6.2.6. As for an RS sourced from the unspecified address, [RFC4861]
section 6.2.6, is quit clear you can't use a Unicast RA response in that
case, and since that is referenced, I'm not sure it needs to be restated in
this document.

Maybe it should be noted that RFC7772 prefers the use of a Unicast RA
responses to reduce the energy consumption of RAs, however since this
document requires that any Multicast RAs are sent as a Link-layer Unicast,
the Unicast RA responses is not necessary to reduce the energy consumption
of RAs.

> If reliability is important I would suggest setting the RA lifetime to
> 5400 or 7200. In any case, the 3600 currently being recommended is too low.
>

Yea, I was thinking about that; maybe there should be a complete set of
alternate IPv6 router discovery and neighbor discovery timers, provided for
when battery consumption is a concern and referencing RFC7772, instead of
just an alternate Maximum IPv6 Router Advertisement Interval.

>
> On Thu, Sep 14, 2017 at 12:16 PM, Van De Velde, Gunter (Nokia -
> BE/Antwerp) <[email-masked]> wrote:
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Sep 2017 23:17:16 -0700

>>    address of the UE/subscriber.
Ah yes, it does say that. So if I understand correctly, solicited RAs can
be either #1 (assuming the RS doesn't come from the unspecified address) or
#2, but periodic RAs must be #2.

Given that periodic RAs must be #2, what's the reason to do #1 at all?

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 02:01:10 -0500

> Given that periodic RAs must be #2, what's the reason to do #1 at all?

While I'm not sure there is a good reason to implement anything more than
#2. On the other hand, I see no good reason for this document to disallow
#1 since it's allows by RFC4861.  There is a lot of basic router code that
doesn't implement #1, no one had to say anything more than what is already
in RFC4861 for that to be the case, why do you think anything more needs to
be said in this case?

Like I said; Maybe it should be noted that RFC7772 prefers the use of a
Unicast RA responses to reduce the energy consumption of RAs, however since
this document requires that any Multicast RAs are sent as a Link-layer
Unicast, a Unicast RA responses is not necessary to reduce the energy
consumption of RAs.

Since RFC4861 allows Unicast RAs and I don't see any reason requiring they
MUST NOT be used within this use case, I don't see any reason to discourage
their use more than what RFC4861 says already. I don't think the text says
anything to encourage there use, if you feel otherwise please point out
what you think is encouraging there use.  Anyway, who knows, maybe someone
will might come up a variant of this use case where they are useful, I
doubt it, but I can't rule it out.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 00:15:05 -0700

> Unicast, a Unicast RA responses is not necessary to reduce the energy

Agreed on both the interpretation of the RFCs. Also, this is not about
energy consumption - in both cases the packets are unicast at layer 2, so
there is no difference in power.

My comment is regarding simplicity of router implementation. Ideally,
anyone implementing this RFC would realize that #2 has to be done
regardless (for periodic RAs) and that #1 is optional. If they then decide
to implement #1 as well, that's fine.

Unfortunately I'm not sure the text is clear enough for that. Specifically
I worry that implementers won't realize that #2 is mandatory, implement #1
first, and then implement periodic RAs with something hacky like "cache the
last-seen link-local address, and always send unicast RAs to that address".

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 14:34:19 +0000

I am OK with the changes, but there is still something missing. The router needs to
be able to send ICMPv6 Destination Unreachables for IPv6 destination addresses
that do not match one of the host's current addresses. That means that the router
needs to consider the prefix as on-link and perform address resolution for each
destination address covered by the prefix.

The document should mention this, because it is currently silent on how routers
regard PIOs with A=1;L=0.

This is also an important distinction between what this document recommends
and true prefix delegation.

Fred 

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, September 14, 2017 12:10 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt
> 
>

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 09:40:50 -0500

> last-seen link-local address, and always send unicast RAs to that address".

Ok, maybe by discussing the unicast RA fist, there could be some unintended
emphasis put on that option, how about a minor rearrangement of the
paragraph, adding that unsolicited RAs are always multicast, and adding the
few editorial nits I mentioned earlier for the following paragraph;

When the First Hop Provider Router sends a solicited RA response, or
periodically sends unsolicited RAs, the RA MUST be sent only to the
subscriber that has been assigned the Unique IPv6 prefix contained in the
RA. This is achieved by sending a multicast RA response or unsolicited RAs
to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6,
but instead of using the link-layer multicast address associated with the
all-nodes group, the link-layer unicast address of the subscriber that has
been assigned the Unique IPv6 prefix contained in the RA MUST be used as
the link-layer destination RFC6085 [RFC6085].  Or, optionally in some
cases, a unicast RA response could be sent as detailed in [RFC4861] section
6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group.

The RA contains two important parameters for the subscriber to consume: ...

I think that removes any unintended emphasis the unicast RA option, while
at the same time putting a little more emphasis on the multicast RA option.

What do you think?

Thanks.

---

From: james woodyatt <[email-masked]>
Date: Fri, 15 Sep 2017 10:01:20 -0700

On Sep 15, 2017, at 07:34, Templin, Fred L <[email-masked]> wrote:
> 
> That means that the router needs to consider the prefix as on-link and perform address resolution for each

I think it suffices to say that the router sends ICMP errors destined for addresses in the Host Unique Prefix to the link-layer address of the host in the same way that multicast RA messages are sent to the link-layer unicast address of the host. No address resolution necessary.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 12:04:31 -0500

> and true prefix delegation.

RFC4443 section 3.1 simply says "a Destination Unreachable message SHOULD
be generated by a router, or by the IPv6 layer in the originating node, in
response to a packet that cannot be delivered to its destination address
for reasons other than congestion."

Therefore Destination Unreachable messages are not REQUIRED, and the whole
motivation of this draft is to not to do neighbor discovery on the unique
prefix assigned to each host.  I believe per RFC2119, that is sufficient
reason to ignore this particular SHOULD.  So at most it might be worth
noting someplace in the draft, as the actual addresses that are used by
each host within it's unique prefix are not intended to be tracked by the
first hop router, the first hop router will not be able to generate
Destination Unreachable messages, RECOMMENDED in RFC4443 section 3.1, for
the unused addresses within each unique prefix.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 10:15:21 -0700

On Fri, Sep 15, 2017 at 7:34 AM, Templin, Fred L <[email-masked]>
wrote:

> that do not match one of the host's current addresses.

I disagree. That prefix belongs to the host. If the host wishes to send
unreachables, then it can choose to do so. If not, it can choose not to do
so. Additionally, one of the desirable properties of this scheme is that
the router does not need to store all host addresses in its ND cache. That
simplifies implementation and protects from a number of state exhaustion
attacks.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 17:16:14 +0000

Hi David,

Thanks for the insights, and see below for follow-ups:

Fred

From: David Farmer [mailto:[email-masked]]
Sent: Friday, September 15, 2017 10:05 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

On Fri, Sep 15, 2017 at 9:34 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

RFC4443 section 3.1 simply says "a Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion."

Ø    That is right. It is a SHOULD. But in this case, I think it is a strong SHOULD.

Therefore Destination Unreachable messages are not REQUIRED, and the whole motivation of this draft is to not to do neighbor discovery on the unique prefix assigned to each host.

Ø  Let’s assume the prefix is 2001:db8::/64. What if the host only configures the

Ø  address 2001:db8::f00, and the router receives an IPv6 packet with destination

Ø  2001:db8::baa. Should the router send the packet to the host, which will drop

Ø  it silently? Then, what if there is a flood of packets with IPv6 destination

Ø  address 2001:db8::*? Should the router send all of them to the host? I

Ø  don’t think so. Instead, the router SHOULD perform address resolution

Ø  and drop any packets for which address resolution fails and then SHOULD

Ø  return a Destination Unreachable.
I believe per RFC2119, that is sufficient reason to ignore this particular SHOULD.  So at most it might be worth noting someplace in the draft, as the actual addresses that are used by each host within it's unique prefix are not intended to be tracked by the first hop router, the first hop router will not be able to generate Destination Unreachable messages, RECOMMENDED in RFC4443 section 3.1, for the unused addresses within each unique prefix.

Ø    See above. I don’t think the flood of packets should be sent to the host. I think

Ø    the router should perform address resolution, and drop and send DUs per the

Ø    RFC4443 SHOULD.

Thanks.

--
===============================================
David Farmer               Email:[email-masked]<mailto:[email-masked]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815<tel:(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952<tel:(612)%20812-9952>
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 10:18:34 -0700

> 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group.
That would help, yes. I would replace "unicast RA response" with "solicited
RAs" but otherwise LGTM.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 17:19:33 +0000

Hi Lorenzo,

See below:

Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, September 15, 2017 10:15 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

On Fri, Sep 15, 2017 at 7:34 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I am OK with the changes, but there is still something missing. The router needs to
be able to send ICMPv6 Destination Unreachables for IPv6 destination addresses
that do not match one of the host's current addresses.

I disagree. That prefix belongs to the host.

Ø  That would only be true for prefix delegation. This is not prefix delegation.

If the host wishes to send unreachables, then it can choose to do so.

Ø  Hosts do not send Destination Unreachables with code Address Unreachable;

Ø  only routers can do that. that is why the router needs to consider the prefix

Ø  as on-link and do address resolution on behalf of the host.

If not, it can choose not to do so. Additionally, one of the desirable properties of this scheme is that the router does not need to store all host addresses in its ND cache. That simplifies implementation and protects from a number of state exhaustion attacks.

Ø    See my reply to David. I think the router needs to protect the host against

Ø    a flood of packets with (potentially) spoofed destination addresses.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 10:20:37 -0700

On Fri, Sep 15, 2017 at 10:16 AM, Templin, Fred L <[email-masked]

> Ø  address 2001:db8::*? Should the router send all of them to the host?
>
I think so, yes.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 17:21:59 +0000

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, September 15, 2017 10:21 AM
To: Templin, Fred L <[email-masked]>
Cc: David Farmer <[email-masked]>; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

On Fri, Sep 15, 2017 at 10:16 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
>  Let’s assume the prefix is 2001:db8::/64. What if the host only configures the

>  address 2001:db8::f00, and the router receives an IPv6 packet with destination

>  2001:db8::baa. Should the router send the packet to the host, which will drop

>  it silently? Then, what if there is a flood of packets with IPv6 destination

>  address 2001:db8::*? Should the router send all of them to the host?
I think so, yes.

Ø  OK, so then the attacker can DoS the host.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 10:25:13 -0700

On Fri, Sep 15, 2017 at 10:19 AM, Templin, Fred L <[email-masked]
> Ø  as on-link and do address resolution on behalf of the host.
If you want to distinguish "host" vs "router" in this sense, then the host
will not send destination unreachables at all, and I think that's fine.

>  If not, it can choose not to do so. Additionally, one of the desirable
> properties of this scheme is that the router does not need to store all
> host addresses in its ND cache. That simplifies implementation and protects
> from a number of state exhaustion attacks.
>
I disagree. If it's a host, it will just silently drop those packets. Such
an attack can do no more damage than a flood of packets to the host's own
address, and in most cases it will do much less.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 17:30:08 +0000

Below:

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, September 15, 2017 10:25 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

On Fri, Sep 15, 2017 at 10:19 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

>  Hosts do not send Destination Unreachables with code Address Unreachable;

>  only routers can do that. that is why the router needs to consider the prefix

>  as on-link and do address resolution on behalf of the host.
If you want to distinguish "host" vs "router" in this sense, then the host will not send destination unreachables at all, and I think that's fine.

Ø    My understanding is that this is about simple hosts, and not hosts that act as routers.

Ø    Hosts can send Destination Unreachable – Port Unreachable; they cannot send

Ø    Destination Unreachable – Address Unreachable except to their own local

Ø    applications.

>    See my reply to David. I think the router needs to protect the host against

>    a flood of packets with (potentially) spoofed destination addresses.
I disagree. If it's a host, it will just silently drop those packets. Such an attack can do no more damage than a flood of packets to the host's own address, and in most cases it will do much less.

Ø    A flood of packets to the hosts’s own address will result in Destination Unreachable

Ø    Port Unreachable messages. This will  cause a legitimate source to cease sending

Ø    packets to the unreachable port.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 17:36:20 +0000

There is a bit more to this discussion regarding having the router perform address
resolution. The router is likely to be connected to very robust infrastructure, e.g.,
10GB Ethernet or the like. Meanwhile, the host will be connected to some wireless
link with bandwidth several orders of magnitude less. That is why I think the router
should protect the host.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Friday, September 15, 2017 10:30 AM
To: Lorenzo Colitti <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

Below:

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, September 15, 2017 10:25 AM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

Ø   applications.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 10:38:57 -0700

On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L <[email-masked]
> Ø    Destination Unreachable – Address Unreachable except to their own
Right. Then the attack that you are theorizing will not cause any
unreachables to be sent, and that's fine.

> Ø    packets to the unreachable port.
Sure. But you were talking about DOS attacks, and those are neither
legitimate sources nor likely to stop sending packets in response to
unreachable errors :-)

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 12:51:48 -0500

On Fri, Sep 15, 2017 at 12:18 PM, Lorenzo Colitti <[email-masked]>
wrote:

> That would help, yes. I would replace "unicast RA response" with
> "solicited RAs" but otherwise LGTM.
>

Ok how about this then, as the word "unicast" does need to be in the
sentence someplace, otherwise how do you distinguish it from the option
above, or find the right part of section 6.2.6 for the details;

When the First Hop Provider Router sends a solicited RA response, or
periodically sends unsolicited RAs, the RA MUST be sent only to the
subscriber that has been assigned the Unique IPv6 prefix contained in the
RA. This is achieved by sending a solicited RA response or unsolicited RAs
to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6,
but instead of using the link-layer multicast address associated with the
all-nodes group, the link-layer unicast address of the subscriber that has
been assigned the Unique IPv6 prefix contained in the RA MUST be used as
the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases,
a solicited RA response could be sent unicast as detailed in [RFC4861]
section 6.2.6, nevertheless unsolicited RAs are always sent to the
all-nodes group.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 11:22:07 -0700

> section 6.2.6, nevertheless unsolicited RAs are always sent to the
It's a bit confusing to say "unicast" in both options. How about saying, "a
solicited response could be sent unicast to the link-local address of the
host as detailed in [RFC4861] section 6.2.6"?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 18:54:59 +0000

I have identified a DoS vector that can be mitigated if the router uses address
resolution to protect the host. If it does that, the router SHOULD send DUs.

Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, September 15, 2017 10:39 AM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

>    My understanding is that this is about simple hosts, and not hosts that act as routers.

>    Hosts can send Destination Unreachable – Port Unreachable; they cannot send

>    Destination Unreachable – Address Unreachable except to their own local

>    applications.
Right. Then the attack that you are theorizing will not cause any unreachables to be sent, and that's fine.

>    A flood of packets to the hosts’s own address will result in Destination Unreachable

>    Port Unreachable messages. This will  cause a legitimate source to cease sending

>    packets to the unreachable port.
Sure. But you were talking about DOS attacks, and those are neither legitimate sources nor likely to stop sending packets in response to unreachable errors :-)

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 14:03:38 -0500

On Fri, Sep 15, 2017 at 1:22 PM, Lorenzo Colitti <[email-masked]> wrote:

> It's a bit confusing to say "unicast" in both options. How about saying,
> "a solicited response could be sent unicast to the link-local address of
> the host as detailed in [RFC4861] section 6.2.6"?
>

Ok, I think that will work, it lets you find the right part of section
6.2.6, but is sufficiently distinguished from the link-layer unicast
discussion above it. however a few minor tweaks, we're using the term
subscriber not host.

When the First Hop Provider Router sends a solicited RA response, or
periodically sends unsolicited RAs, the RA MUST be sent only to the
subscriber that has been assigned the Unique IPv6 prefix contained in the
RA. This is achieved by sending a solicited RA response or unsolicited RAs
to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6,
but instead of using the link-layer multicast address associated with the
all-nodes group, the link-layer unicast address of the subscriber that has
been assigned the Unique IPv6 prefix contained in the RA MUST be used as
the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases,
a solicited RA response could be sent unicast to the link-local address of
the subscriber as detailed in [RFC4861] section 6.2.6, nevertheless
unsolicited RAs are always sent to the all-nodes group.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 12:26:12 -0700

On Fri, Sep 15, 2017 at 11:54 AM, Templin, Fred L <[email-masked]

> resolution to protect the host. If it does that, the router SHOULD send

Right. But OTOH, the DoS vector that you found is strictly less damaging
than if the DoS targeted one of the host's IP addresses.

Also, your suggested mitigation (sending DUs) requires that the router must
keep all addresses in its ND cache, and that means that the DoS vector you
identified is still a DoS vector, but this time on the router's ND cache.

Also, your suggested mitigation creates an additional attack vector:
malicious customers can mount an ND cache entry on the router by
configuring lots of addresses and arranging to receive traffic on them.
This is extremely simple to mount: a host can simply send a trivial 10pps
of ping packets (or DNS queries, or...) to each of 100 remote destinations,
with each packet coming from a different address. That can cause the router
to attempt to create 1000 ND cache entries per second. You might want to
try that on some routers and see how badly they fall over.

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Sep 2017 14:57:33 -0500

But in order to mitigate one DDOS vector, and not a very typical one for
that matter, you eliminate the scaleability advantages provided by not
tracking the addresses used within each unique prefix. Furthermore, that
and many other DDOS vectors can be detected and mitigated by several other
means. I can't think of how else to provide the scaleability advantages
from not tracking the addresses used in the unique prefixes.

I have routers that can handle several millions of IPv6 routes, but they
can only track 250k neighbor associations.  Thats is effectively 50K hosts
as we see on average 5 neighbor associations per host, I need better
neighbor discovery scaleability.  I already separate DDOS detection and
mittigation, that will cover that more effectively than the one DDOS vector
you are talking about.

At most noting that DUs are not provided by the First hop router for unused
addresses within the unique prefix, seems reasonable so no one is surprised
by the behavior.

Furthermore, ICMP is by no mean guaranteed to get across the Internet
anyway, it's filtered in far too many places.

Thanks.

On Fri, Sep 15, 2017 at 1:54 PM, Templin, Fred L <[email-masked]>
wrote:

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Friday, September 15, 2017 10:39 AM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-
> prefix-per-host-09.txt
>
>
>
> On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L <
> [email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 21:15:06 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, September 15, 2017 12:26 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

On Fri, Sep 15, 2017 at 11:54 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I have identified a DoS vector that can be mitigated if the router uses address
resolution to protect the host. If it does that, the router SHOULD send DUs.

Right. But OTOH, the DoS vector that you found is strictly less damaging than if the DoS targeted one of the host's IP addresses.

Ø  The host can address this by using privacy addresses.

Also, your suggested mitigation (sending DUs)

Ø  Actually, the primary mitigation is for the router to do address resolution. Sending or

Ø  not sending DUs would be decided following success or failure of address resolution.

requires that the router must keep all addresses in its ND cache, and that means that the DoS vector you identified is still a DoS vector, but this time on the router's ND cache.

Ø  Presumably the router maintains an LRU collection of a finite supply of nbr cache

Ø  entries instead of just eating up all of its memory.

Also, your suggested mitigation creates an additional attack vector: malicious customers can mount an ND cache entry on the router by configuring lots of addresses and arranging to receive traffic on them. This is extremely simple to mount: a host can simply send a trivial 10pps of ping packets (or DNS queries, or...) to each of 100 remote destinations, with each packet coming from a different address. That can cause the router to attempt to create 1000 ND cache entries per second. You might want to try that on some routers and see how badly they fall over.

Ø  The router can maintain an LRU nbr cache entry on a per subscriber

Ø  basis so that a malicious subscriber cannot degrade the service for all.

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Sep 2017 23:23:18 +0200

> resolution to protect the host. If it does that, the router SHOULD send DUs.

The implementation we did of this was for the sole purpose of _not_ having to do address resolution...

Cheers,
Ole

> On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L <[email-masked]> wrote:

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 21:24:42 +0000

Hi David,

See below:

Fred

From: David Farmer [mailto:[email-masked]]
Sent: Friday, September 15, 2017 12:58 PM
To: Templin, Fred L <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt

But in order to mitigate one DDOS vector, and not a very typical one for that matter,

Ø  What matters is that the attack was not known until now. Now it is

Ø  known, so if we will deploy this we will see if it becomes typical.

you eliminate the scaleability advantages provided by not tracking the addresses used within each unique prefix. Furthermore, that and many other DDOS vectors can be detected and mitigated by several other means. I can't think of how else to provide the scaleability advantages from not tracking the addresses used in the unique prefixes.

Ø  The router has a finite neighbor cache, but it has the means to manage

Ø  the cache (e.g., LRU) in the face of an attack. And, I think it is reasonable

Ø  to expect that an attack of this nature would be short-lived and not

Ø  one that would persist for days and days until the source is identified.

I have routers that can handle several millions of IPv6 routes, but they can only track 250k neighbor associations.  Thats is effectively 50K hosts as we see on average 5 neighbor associations per host, I need better neighbor discovery scaleability.

Ø  Right, but the neighbor cache limit does not limit the number of hosts

Ø  if the router manages it using LRU replacement of stale entries. Worst

Ø  case is that there may be extra NS/NA traffic if the system is under

Ø  attack or all subscribers are using all of their addresses all of the time.

I already separate DDOS detection and mittigation, that will cover that more effectively than the one DDOS vector you are talking about.

Ø    I can’t parse this.

At most noting that DUs are not provided by the First hop router for unused addresses within the unique prefix, seems reasonable so no one is surprised by the behavior.

Ø    DU is only a SHOULD as I have already agreed. But, address resolution protection

Ø    of hosts is the primary mitigation.

Furthermore, ICMP is by no mean guaranteed to get across the Internet anyway, it's filtered in far too many places.

Ø    Right, DU is only a SHOULD. But, it is a strong SHOULD.

Thanks.

On Fri, Sep 15, 2017 at 1:54 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I have identified a DoS vector that can be mitigated if the router uses address
resolution to protect the host. If it does that, the router SHOULD send DUs.

Fred

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 21:26:20 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Friday, September 15, 2017 2:23 PM

Then, the floodgates are open and the host can be DoS'd. The attack profile
would not be too far different than the DYN attack back last October.

Thanks - Fred

> > I disagree. If it's a host, it will just silently drop those packets. Such an attack can do no more damage than a flood of packets to the
> host's own address, and in most cases it will do much less.
> >

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Sep 2017 23:55:08 +0200

> would not be too far different than the DYN attack back last October.

as in the host will receive packets that it will drop?
how is that any different from an attacker just sending more traffic to one of the host's addresses than it can handle.

not sure I'm getting what the issue is here.

Cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2017 23:07:31 +0000

Hi Ole,

> Sent: Friday, September 15, 2017 2:55 PM

Here, the attacker only needs to know the host's prefix; it does not need
to know any of the host's addresses. The router will deliver all packets
destined to any address within the prefix to the host unconditionally.
This defeats the host's mitigation of using privacy addresses to avoid
an off-path attacker somehow discovering its address and sending a
flood of packets.

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Sep 2017 16:28:54 -0700

> to do address resolution...

Exactly.