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

[Tom Herbert <[e-mail]>]

On Wed, Aug 16, 2017 at 7:51 PM, Mark Smith <[e-mail]> wrote:
> 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.
>
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