Re: Non routable IPv6 registry proposal

[Phillip Hallam-Baker <[e-mail]>]

This post and various others have helped me clarify the proposal a bit. I
think there is (potentially) something very useful here that makes it
easier to solve a lot of 'niggling administration' type issues.

The payoff for IETF is that I think the combination provides the right
level of incentive to drive IPv6 adoption. And that is one of the major
reasons I want to incorporate it into my Mesh callsigns registry. As folk
know, I have a really low tolerance for administration/configuration cruft
and especially so when it is my wife asking me to do the IT support her
work IT support should be doing for her.


OK so what do I mean by the right level of incentive? Well, simply saying
IPv4 addresses will run out doesn't provide me with a personal incentive to
go to IPv6 as my ISP will simply pay whatever it takes to get me a one and
the bulk of their customers won't notice if they are shoved behind a
carrier grade NAT. Nor does making use of IPv6 a requirement to use some
new application help because getting critical mass for an application is
also a hard problem and I am not going to handicap myself by making IPv6 a
requirement until deployment has reached a minimum of 98%.

A ULA->Public key registry provides exactly the right degree of incentive.
It allows us to take an area that is currently flaky as heck and make it
'just work'. That area is VPN access.

The original idea of IPSEC was that we were going to encrypt the whole net.
And that didn't really happen because there is no PKI for IP addresses (and
no, the RPKI doesn't really count in that regard). And PKIX is a really
really bad match for that problem because certs expire.

Nor is it really possible to solve the problem of VPN access in IPv4 space
because you inevitably end up with collisions. My wife's machine was
10.0.1.42 on our home net. It was trying to reach the file server which is
10.0.1.42 on the work net. And that doesn't work for the combination of VPN
client/server software that was in use. And why would we expect that? Nor
is this really a corner case, its actually going to be a situation that
occurs to some users with approaching 100% certainty.

Map this all out onto disjoint ULA IPv6 addresses and we can guarantee that
the addresses are unique at each end. That is our first win.


Our second win comes when we have a registry that maps public keys to the
ULA address ranges like the one I am planning to add to my existing
callsign registry. This is based on a DARE sequence.

Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE) (ietf.org)
<https://tools.ietf.org/id/draft-hallambaker-mesh-dare-11.html>


So to receive an allocation Alice:

1) Generates a new key pair {public, private}
2) Submits the request for an allocation.
3) Receives notification of the allocated address range
4) Waits for the sequence apex to be signed and sufficiently notarized.

For purposes of exposition, the registry consists of a Haber-Stornetta
One-way Sequence:

S0 = { A, FC00:0001:0000:0000::/62 , 0}
S1 = { B, FC00:0001:0000:0004::/62 , SHA2(S0)}
S2 = { C, FC00:0001:0000:0008::/62 , SHA2(S1)}
S3 = { D, FC00:0001:0000:000C::/62 , SHA2(S2)}
S4 = { E, FC00:0001:0000:0010::/62 , SHA2(S3)}
S5 = SHA2(S4) + Na(t) + Nb(t)
S6 = Sign (S5)

Where Na(t), Nb(t) are the notary tokens issued by notaries A, B at time t.

[Yes, the actual implementation will use a Merkle Tree for efficiency]
[Yes, bumped the allocation up to a /62 as per Michael's suggestion]

This approach is not completely foolproof. But the idea here is that the
notaries are independent parties doing something of the sort (e.g. CT logs)
with a reciprocal relationship, I include the output of your notary chain
and you include mine. The result is more robust than blockchain without the
criminality, proof of work or environmental harm.

So Alice can verify that her allocation is unique as soon as she can get
confirmation of the ULA registry output value from one of the other
notaries she trusts.

These logs are not going to be all that big. Its 1KB per entry at most. So
10K entries per day is only 10MB appended to the end of the chain. That's
less than the size of a single photograph with the camera I use these days.
Even at Internet scale of 10 billion entries we are talking about 10TB of
data. That is just not a lot of data these days.

All an IPSEC gateway would need to verify a public key chain to this
registry would be the mapping of IP address range to hash of public key.
Which is ~50 bytes. So 0.5 TB for a complete dump. These are practical
values we can use in current tech.

Worst cases are 1) that I give up and stop allocating new addresses, 2) I
mess up and allocate space I am not allowed to or double allocate. Both of
these are externally visible. The choice of incremental allocation is
deliberate as it makes it easier to verify that my allocations are within
policy (and yes, I would have to modify things a little bit so I can
allocate larger chunks without making spaces, but details)

Alice is only going to start using her block after I publish it. So I
really have little scope to attack her.

I can make a report once a year to state where I am at. But anyone starting
a similar registry is going to get FC00:0002::/96 to allocate.


We have burned far more address space with far less to show for it. Either
this works in which case my non profit gets a revenue stream that can
support work for the whole community or it doesn't and we maybe learn
something from the experience.


On Thu, Jan 21, 2021 at 12:17 PM Joseph Touch <[e-mail]> wrote:

>
>
> > On Jan 20, 2021, at 3:27 PM, Fernando Gont <[e-mail]>
> wrote:
> >
> > On 20/1/21 17:25, Joe Touch wrote:
> >>> On Jan 20, 2021, at 12:07 PM, Phillip Hallam-Baker <
> [e-mail]> wrote:
> >>>
> >>> 0) Nowhere does the 'end to end' principle demand that the source and
> destination addresses on an IP packet remain constant
> >> IP addresses is the only means for identifying an Internet endpoint per
> RFC 1122. While I agree that there may be utility of having proxied
> endpoints (e.g. NATs) with effectively internal addresses behind them, it
> doesn’t help the case to begin with this inaccurate assertion.
> >
> > I'd have agreed with you. BUt since
> draft-ietf-spring-srv6-network-programming has been approved by the IESG,
> you probably cannot make such assertion anymore.
>
> One draft that doesn’t update or obsolete numerous others does not
> undermine 40 yrs of E2E.
>
> Esp. when (AFAICT) that doc series never mentions how transport protocols
> are supposed to deal with indeterminate endpoint addresses in their pseudo
> headers or the impact to security protocols at the transport (not transport
> content) layer.
>
> Joe