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.
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 <touch@xxxxxxxxxxxxxx> wrote:
> On Jan 20, 2021, at 3:27 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
>
> On 20/1/21 17:25, Joe Touch wrote:
>>> On Jan 20, 2021, at 12:07 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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
