Subject: [v6ops] "The Internet is for End Users" (Re: I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt)

From: Mark Smith <[email-masked]>
Date: Thu, 17 Aug 2017 12:51:39 +1000

So how do we evaluate what is the best solution? What are the criteria to use?

This discussion is going in circles because I think people have
different opinions on what the criteria are.

Mark Nottingham has been working on the following draft,

"The Internet is for End Users"
https://tools.ietf.org/id/draft-nottingham-for-the-users-05.txt

which says that what is best for the end-user needs should trump any
other parties' needs. I entirely agree.

What is best for end-users is the fundamental goal. I've thought it
would be useful to have a set of high level and end-user oriented
criteria to use to evaluate various technical choices, in particular
when there are situations such as this one.

I've thought there are the following 3 high level end-user criteria to
use for evaluation:

* Available and Reliable

* Secure and Private

* Cost Effective

It seems to me that all IETF solutions should meet all of these
criteria, ensuring they are prioritising end-user needs.

I've suggested these to Mark for his ID, and to demonstrate their use,
I used the 64 bit IID example. My evaluation was rushed for the
purposes of example in the email. There are other Secure and Private
impacts other than just being able to successfully scan a 32 bit
address space. Another example is that reducing shrinking IIDs to
increase the number of prefixes available within an assignment e.g. a
/32 doesn't improve Cost Effectiveness because their RIR cost is
trivial (a /48 is 1 or 2 cents per annum), and route table slot use
doesn't change.

"If IPv6 IIDs were reduced to something like 32 bits, would any of the
above be impacted:

- Available and Reliable: No. May have a positive influence, as
availability and reliability possibly could be increased, as ND cache
resource exhaustion attacks effectiveness would be reduced.

- Secure and Private: Yes, negatively. It is practical to scan 32 bit
address spaces e.g., shodan.io. 64 bit random addresses are effective
at mitigating device discovery via unsolicited packet probing, 32 bit
random addresses would not be.

- Cost Effective: Yes, negatively. 64 bit IIDs have been the standard
since July 1998 per RFC2373, meaning many protocols and
implementations assume them. Code would have to be audited and
possibly modified, and that code update distributed; there would be a
population of devices that won't receive the update etc. End-user
services outages could result due to incompatibility."

As smaller IIDs have more negative than positive Secure and Private,
and Cost Effective impacts compared to what we have today, it seems to
me that they should be left alone, as the drawbacks of changing them
outweigh the benefits.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 12:01:21 +0900

> resource exhaustion attacks effectiveness would be reduced.

Actually the answer here is also "yes, negatively". It means that networks
with large numbers of users would become unreliable because of IID
collisions. There are networks that run 10k or 20k nodes on a single
subnet. Large corporate networks are an example, or large conferences such
as MWC.

---

From: Tim Chown <[email-masked]>
Date: Thu, 17 Aug 2017 10:12:16 +0000

> On 17 Aug 2017, at 04:01, Lorenzo Colitti <[email-masked]> wrote:
> 
> Actually the answer here is also "yes, negatively". It means that networks with large numbers of users would become unreliable because of IID collisions. There are networks that run 10k or 20k nodes on a single subnet. Large corporate networks are an example, or large conferences such as MWC.

Is there info anywhere on what the common OSes do when they encounter a DAD failure - do they give up or try a new tentative address?  

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 19:22:05 +0900

For non-EUI-64 addresses Linux usually retries.

However, the problem is not so much when DAD works as when it *doesn't
work* (e.g., because devices drop multicast when asleep). In that case you
end up with duplicate addresses.

On Thu, Aug 17, 2017 at 7:12 PM, Tim Chown <[email-masked]> wrote:

> > Actually the answer here is also "yes, negatively". It means that
> networks with large numbers of users would become unreliable because of IID
> Is there info anywhere on what the common OSes do when they encounter a
> DAD failure - do they give up or try a new tentative address?
>
> Tim
>
>

---

From: Timothy Winters <[email-masked]>
Date: Thu, 17 Aug 2017 10:47:56 +0000

Most operating systems give up if they fail DAD.

Tim

On Thu, Aug 17, 2017 at 6:22 AM Lorenzo Colitti <[email-masked]> wrote:

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

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Lee Howard <[email-masked]>
Date: Thu, 17 Aug 2017 11:35:20 -0400

>other parties' needs. I entirely agree.

I disagree with that characterization of the draft. I worked with Mark to
try to make it clear that it does NOT say “end users uber alles."
  Our goal is not to avoid all potential harm to or constraint of end
  users; rather, it's to give guidance in a particular situation - when
  we've identified a conflict between the needs of end users and
  another stakeholder (e.g., a network operator), and need a
  "tiebreaker", we should err on the side of finding a solution that
  doesn't harm end users.

“Doesn’t harm” is different than “best for,” and various interests compete.
Of course, this document is still a draft, and we cannot call is a
consensus document.

>I've thought there are the following 3 high level end-user criteria to

Good/Fast/Cheap?

>random addresses would not be.

As I read RFC7707 "Network Reconnaissance in IPv6 Networks” I think you
may be overestimating that value.

Lee

---

From: Tim Chown <[email-masked]>
Date: Thu, 17 Aug 2017 16:03:55 +0000

Hi,

> On 17 Aug 2017, at 11:47, Timothy Winters <[email-masked]> wrote:
> 

For SLAAC, RFC7127 includes a DAD counter in the IID generation algorithm, and specifies how to use that in https://tools.ietf.org/html/rfc7217#section-6, but has anyone tested whether existing implementations are doing that?

DAD itself failing to detect the duplicate is a separate - but of course important - issue.

Tim 

> However, the problem is not so much when DAD works as when it *doesn't work* (e.g., because devices drop multicast when asleep). In that case you end up with duplicate addresses.
> 
> Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
>

---

From: "John A. Kilpatrick" <[email-masked]>
Date: Thu, 17 Aug 2017 09:49:50 -0700

> Actually the answer here is also "yes, negatively". It means that networks with large numbers of users would become unreliable because of IID collisions. There are networks that run 10k or 20k node…

I would love a way to instrument that.  We can do the probability math, but I’d be curious to see real stats for “On a network of X nodes, the average DAD failure rate was Y.”  I had a segment once with about 6k clients, but I didn’t consider figuring a way to instrument DAD collisions.  

-- 
                              John A. Kilpatrick
[email-masked]                Email|     http://www.hypergeek.net/
                remember:  no obstacles/only challenges

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Aug 2017 10:19:10 -0700

> random addresses would not be.
The corollary to "the Internet is for the end users" should be that
"end users should never trust the network". If you want security and
privacy it should be implemented end to end. Networks do not uniformly
provide security for users, which is to say that the base assumption
is that they do not provide any security and are themselves insecure.
For instance, the moment we send a packet with a source address into
the Internet the best security assumption is our address is now known
to the whole world-- the packet may be logged by switches, servers log
it, there may third party interception, etc. It follows that random
addresses are not real security from a user or host point of view.
There is a motivation to use different addresses for connections from
a host so that two flows cannot be correlated to originating from the
same device, but that only works if the device specific portion of the
address is different which would not currently be the case for UEs
assigned a single /64.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Aug 2017 13:38:37 -0400

El 17 ag 2017, a les 13:19, Tom Herbert <[email-masked]> va escriure:
> If you want security and
> privacy it should be implemented end to end.

Even that's not good enough, since your metadata can be tracked.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 17 Aug 2017 10:58:02 -0700

> Even that's not good enough, since your metadata can be tracked.
Ted,

That's a good argument that everything in a packet should be encrypted
except for the IP header and options that are necessary for delivery.
This becomes essential to prevent tracking. For instance, one of the
problems posed in IDEAS list is that long lived connections are easily
tracked in time. A proposed solution is to allow dynamically changing
addresses of an existing connection. This obfuscates the addresses
nicely, but if there's still connection acks #s, seq #s, and ports in
plaintext it's little bother to be able track the connection across an
address change. So to prevent such tracking, anything in the packet
that could be used for tracking identity needs to hidden or
obfuscated. Simply using random addresses is not nearly enough.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 Aug 2017 11:25:50 +0200

> Is there info anywhere on what the common OSes do when they encounter a DAD failure - do they give up or try a new tentative address?  

For legaxy (pre RFC7217) they give up -- after all, you wouldn't know
how to form a new IID if you have to base it on the undelying link layer
address.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Libor Polčák <[email-masked]>
Date: Mon, 28 Aug 2017 10:09:15 +0200

> For SLAAC, RFC7127 includes a DAD counter in the IID generation algorithm, and specifies how to use that in https://tools.ietf.org/html/rfc7217#section-6, but has anyone tested whether existing imp…

Hello,

We tested the number of retries performed by different OS for RFC4941 addresses several years ago http://6lab.cz/behaviour-of-various-operating-systems-during-slaac-dad-and-nd/. See the last column in the table.

In summary, Linux, Solaris, and Windows tried different RFC4941 addresses. FreeBSD, OpenBSD, MAC OS X tried only a single RFC4941 address.

Regards,

Libor