On Fri, Jan 22, 2021 at 1:24 AM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
On 1/21/2021 9:57 PM, Phillip Hallam-Baker wrote:
That should work if the "block chain" signatures can only be appended by the organization maintaining the registry. I wonder why just $0.10, given that for the normal user just learning the process will cost way more than that. Also, just the credit card fees are larger than that. Plus, if you want to guarantee the ownership "forever", you probably need sustained revenues in the long termOn Fri, Jan 22, 2021 at 12:45 AM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
On 1/21/2021 5:02 PM, Phillip Hallam-Baker wrote:
On Thu, Jan 21, 2021 at 2:56 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
Putting two things together:
On 22-Jan-21 07:57, Phillip Hallam-Baker wrote:
...
> 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.
Yes, but afaik you (or I) can't claim ownership of random numbers. So if my ULA prefix is fd63:45eb:dc14::/48 and I provide a public key for it, what's to stop you using the same prefix and providing your own public key for it?
The registry undertakes to only issue each prefix once and bind it to a public key specified by the holder.
The registry publishes the allocation in an append only log which is attested by a blockchain type technique. So there is (almost) no scope for the registry to defect.How do you protect the registry against a Sybil attack?
-- Christian Huitema
There is a one-time charge of $0.10 per registration. No renewal fees.
I was in that business for a decade. I know exactly where the costs are and I am planning to configure my businesses accordingly.
The IPv6 part is just a bolton to the Mesh callsign registry I am already building. I can throw a /62 at every registrant with no hassle.
1) The Mesh Foundation, a not-for-profit runs the registry as public goods. Sells blocks of 10,000 Mesh registrations for $100 each to anyone who wants to set up a Mesh Service Provider (MSP) or just issue registrations.
2) Threshold Secrets, a for profit MSP that provides customer service, account hosting etc. at commercial rates.
The big difference between my model and the traditional Internet account model is that accounts are portable. You own your account, it is bound to the public keys you own. So you can register with my MSP, use it for a year, decide you don't like the service I provide and switch to Fred's. That change is advertised through the registry.
All the costs of the registry are offloaded onto the MSPs. VeriSign sheds the cost of customer service to the registrars. I am proposing to shed the cost of resolution service as well.
So if I want to contact you on Signal, SMTP, etc. via your Mesh callsign (@christian), my client goes to my MSP, and finds the location of your current MSP servicing the account and presents an authenticated request for your current contact info. If authorised, your client gets my current contact info (or the contact info you are allowed, if I don't know you, its probably just info on how to request a contact exchange).
I expect the operating expenses of the registry to be in the low seven figures operating at scale. If I am incorrect, we raise the rates. If we raise the rates higher than people find acceptable, we will get competition.
So a DoS attack would merely swell the coffers of the not-for-profit Mesh foundation which will pay for development of code, etc.
I am not sure that a Sybil attack is relevant as there is absolutely no accreditation going on here except between the registry and the small set of chosen peer notaries. And they are merely cross notarising. There are no subjective or unconstrained inputs here. Every input is deterministic, the only non determinism comes from timing.There are variants of the Sybil attack that concentrate on fractions of the address space. Also, if the space is just 40 bit wide, the attacker will start causing random collisions after registering 1 million entries.
I am proposing to issue in the registered space FC00::/8, not the random space FD00:/8. And I am asking* for a /32 from which I will allocate /62s so, I have room for 2^30 registrations in my initial allocation. If I start to run out, I ask for an extra /32. There are 16 million /32s in that space. So we don't run out till we have allocated a trillion registrations. And these are densely packed.
[*] Asking for advice, not necessarily permission.
Speaking of collisions, is there a way for registrants to test for collisions before registering? Is it correct to assume a publicly available blockchain?
-- Christian Huitema
I don't see the random approach being feasible for the reasons you raise. Since my plan is to add this to a registration service, I will be allocating in dense blocks with a transparent allocation rubric.
