[Cryptography] Implementing full Internet IPv6 end-to-end encryption based on Cryptographically Generated Address

[Christian Huitema]

On 1/24/2019 12:52 PM, grarpamp wrote:

> Yes, one cannot rationally overload all 128 bits for that without colliding
> upon allocated IPv6 space that may appear in one's host stack.
> However the 1:1 key network can be larger than 64 or 80 bit. One could
> easily play with up to say 125 bits by squatting on entirely
> unallocated space. (Unlike the clear mistake CJDNS made by
> squatting on space already allocated for a specific and conflicting
> real world in stack purpose.) Obviously the common library widths
> of 96 and 112 could be keyed. And request could be made for a
> formal allocation if compatibility and compliance was felt needed
> by some mental gymnastics

Let's first state that just being compliant with the address
architecture brings you little by itself, apart from preventing
collisions. Claiming address=X only makes sense if your peers can do a
socket call, send a packet towards X, and have a reasonable expectation
that it will arrive. In the current state of the routing, that means
that the address should be of the form "<prefix>|<host-id>", and that
some variation of the "prefix" needs to be known in the routing tables
all the way from source to destination. If you are connected to a
network with prefix P, the address that you give to your peers must be
of the form "X=P|H" if you want to receive data. Most final destinations
are identified by a 64 bit prefix, unique to the specific network link
on which the host is attached, which means that H is constrained to be
no more than 64 bit long.

The plausible exception would be a "network link" identified by a much
shorter prefix. In theory, you could obtain that through the current
system if you justify a large enough number of users. In practice, very
large networks do get 32 bit network prefixes.

You could claim that a network overlay like TOR qualifies as one such
big network, and it should be given a short prefix. Data sent to these
addresses would be routed to the closest overlay access point, and the
overlay would route messages to their final destination based on the
host ID. I can easily conceive a proof of concept using for example a
DHT, although a production version would have to be address issues like
DOS, Sybil attacks, frequent address changes to maintain privacy, etc.
How short the prefix should be is an interesting discussion. Just 48
bits would be a no-brainer. I can see converging an a 32 bits after some
discussion -- and that would match the 96 bits length that you mention.
Anything less would probably require a lot more discussion.

But squatting on a large portion of the address space, no, that's not
going to end well.

-- Christian Huitema