Re: Proposal, open up .arpa

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

On Mon, Dec 20, 2021 at 6:15 PM John C Klensin <[e-mail]> wrote:

> Hi.
>
> Aside from the more substantive content of the suggestion,
> including whether this could actually be done and all costs
> covered for one time charges of USD 0.10, I see three major
> concerns / questions that you should probably address:
>
> (1) Why .ARPA?  In addition to the concern Nick raised, my
> recollection of the agreement between IETF and ICANN is that the
> TLD is supposed to be used for _network_ infrastructure, not as
> a cheap substitute for a gTLD.  Granted that boundary has been
> pushed a bit in the past, but what you are talking about sounds
> like personal identifiers and definitely not network
> infrastructure.
>

Because it is the TLD that has been traditionally used for permanent
delegations.

When I was originally thinking of this scheme, my expectation was that ISOC
would divest itself of the .NET registry and the massive conflict of
interest that creates for IETF.

As far as my approach goes, mesh.arpa is a lot costlier to me (an RFC at
least) than .mesh (free as in beer).



(2) Assuming the IETF went along with this (and ICANN did not
> have a fit about their perception of the agreement), what would
> be the acceptance or rejection criterion for whenever the next
> such request came along?  In other words, when someone proposed
> a different scheme for, say, "hsem.arpa." or "tangle.arpa."
> rather than "mesh.arpa.", what criteria would the IETF use to
> accept or reject it?   Equally important, when a fight breaks
> out as to who is the real Alice, or, as in the mistakes that
> were made in the delegation of the NAME TLD illustrate, who gets
> to administer the *.alice.mesh.arpa" subtree?  Given that, at
> least in the absence of some complex administrative adjudication
> procedure (like ICANN's UDRP), debates about "who is the real
> Alice" tend to attract lawyers, some of whom find our theories
> about DNS delegations and delegated authority inconvenient, how
> would you propose to protect the IETF (or the IETF LLC) from
> becoming enmeshed in such disputes?   If nothing else, that set
> of issues might be a strong argument for "mesh" second level
> domains underneath ccTLDs: countries are, if they choose to get
> involved, good at determining the legitimate owners of a name
> and associated attributes and can immunize themselves from
> disputes about those questions in ways in which the IETF or your
> hypothetical non-profit probably cannot.
>

There are really two separate sets of issues there.

First there is the 'how does a registry shift the cost of the inevitable
disputes onto the parties with the complaint'. I am very familiar with that
whole process, it was a major concern for us long before VRSN bought
network solutions. I was also heavily involved in the 'how does VRSN
operate a PKI and not get sued into pieces' which Michael Baum spent a lot
of time working on.

The short answer is that obviously @microsoft has to resolve to Microsoft
Inc or really bad things start happening besides the IP issues. And so you
have to have a process, you can't just ignore it (one reason most proposals
are non starters). But once you have a process and you tell the courts that
you will abide by their decision, there are ways to control/contain the
liability.

But it doesn't eliminate the issue and there is the risk of the liability
leaking up the chain as you observe. So that probably seems to rule out
.mesh.arpa.

Fine, I will use .mesh



> (3) The DNS was not designed for, and has never been good at,
> handling very large zones (independent of the level of the tree
> at which they occur).  In the last couple of decades, throwing
> some database technology and a great deal of computer horsepower
> at the DNS has increased the plausible maximum zone size by
> several orders of magnitude over what I believe were the
> expectations in 1987 or even 1994, but the fundamental problem
> remains.  Perhaps I don't understand your explanation and
> example, but if the subnodes of mesh.arpa are going to be
> callsigns bound to people and this model is successful, then you
> are talking about a zone with four or five billion nodes in it
> today (and growing).   I can think of some plausible ways around
> that, perhaps including your idea about separating the resolver
> function from that of a registry, but they fall well short of
> "respects the DNS data model" and the computationally intensive
> versions would, at scale, causes Alice's coffee to get rather
> cold before she could drink it.
>

I have always regarded the DNS hierarchy as a blunder. All that dividing
the root zone has meant is that instead of there being one place to reserve
a name, there were first three and then a hundred and now thousands and
they are all primarily rent seekers.

The registry log will grow by less than 1K per entry. So a billion
callsigns is only 1TB. I have built very big iron but this is really not
that demanding. The registry can run on a regular PC, I have run
simulations with millions of add operations an hour using magnetic disks
and would definitely use SSD in production.

Resolvers can run incrementally. They can process the log and map out to a
lookup table mapped out on SSD. Haven't written one yet but it's really not
much of a concern. Updating the mapping table can be parallelized and
resolution can be parallelized if needed.


Unlike in the DNS system, the resolver service is not provided by the
registry. That immediately brings robustness. Taking out VeriSign's ATLAS
brinds down DNS for the whole Internet. If Verizon, Comcast and such all
ran their own resolvers that did not depend on connection to the registry,
the incentive to abuse the DNS root and TLDs would be very much reduced.
Further, the providers can limit external access or shut it down completely
if they come under attack. They have much more ability to control abuse
coming from the inside.

Taking out the registry will be challenging. The attackers would have to
find it first.





> best,
>    john
>
>
>
> --On Monday, December 20, 2021 13:28 -0500 Phillip Hallam-Baker
> <[e-mail]> wrote:
>
> > TL;DR; I have two ways of achieving my desired end. One of
> > which people are not going to like, the other of which they
> > are totally going to hate. I do not actually require IETF
> > permission for either, nor am I the only person thinking along
> > these lines, I am merely the person whose approach is least
> > likely to result in collateral damage, consider responses in
> > those terms.
> >
> > I have been following various naming proposals in the
> > PonziCoin world for some time. There are many companies who
> > for a mere $10-200/year will register a shortname for your
> > ethereum wallet so people can give you money. And of course,
> > the cost of ethereum gas for making the payments only makes
> > the cost even stupider. But don't worry, there will be a
> > technical fix for that the minute they find themselves a
> > virgin and a unicorn.
> >
> > OK, so those proposals are obvious nonsense but the notion of
> > using a Certificate Transparency type log to issue names for
> > life on a first come first served basis is not. Hence my
> > callsign proposal:
> >
> > https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsig
> > n-01.html
> >
> > [A very similar proposal has been made to ITU by the Chinese
> > delegation under their 'New Internet' scheme though I only
> > became aware of the details of that after I wrote my own. It
> > is my belief that the primary motivation behind the ITU
> > proposal is to prevent the abuse of DNS as a control point in
> > the Internet infrastructure.]
> >
> > Running infrastructure costs real money but I see no reason
> > for the cost of running the infrastructure proposed to be more
> > than a one-time $0.10 per name. No renewal fees. Names are
> > sold freehold, not rented.
> >
> > The objective here is to give Internet users a name they can
> > use for life. And yes, I realize that it is impossible to
> > collect $0.10 fees so I plan to sell names in packs of 50 or
> > so. So for the price of a pint of beer you can buy a permanent
> > callsign for yourself and pass out the means to grab one to
> > your friends.
> >
> > There are of course many social issues to be considered, not
> > least of which where does the surplus go. My proposal being
> > that the whole show to be run by a not-for-profit and the
> > surplus go to fund open source development of secure Internet
> > software, specifications and standards.
> >
> >
> > But that is not the part I want to talk about right now. What
> > I do want to talk about is how a new naming scheme interfaces
> > to the DNS so that it can be used to connect to legacy
> > applications. Legacy in this context meaning 'the stuff that
> > is working'.
> >
> > So Alice registers the callsign @alice and can use that in
> > messaging applications that understand the callsign scheme.
> > Which is not hard, just hook up to a callsign resolver and
> > send over a query. As with blockchain, the resolver maintains
> > a complete copy of the log. Queries go to a resolver, not the
> > registry. This means far greater robustness than DNS and
> > offloads almost all the cost from the registry.
> >
> >
> > But what about that doorbell, that WiFi camera, etc. that
> > Alice has? To talk to them she needs to use her browser and
> > that runs HTTP.
> >
> > The obvious solution for this is to put a statement in the
> > delegation assertion for @alice to specify an authoritative
> > DNS resolver for the DNS addresses *.alice.mesh. The callsign
> > resolver then delegates to the authoritatives. The net result
> > is that all Alice needs to do to resolve these names is to use
> > a DNS resolver that redirects requests in .mesh to one of the
> > callsign resolvers.
> >
> > The net result is a protocol that respects the DNS data model
> > at the lower levels while modernizing the root level.
> >
> >
> > OK so nobody expects me to pay to register .mesh. I am not
> > even going to lift a finger to make a proposal to ICANN.
> >
> > But I am not the only person making a proposal in this area
> > and while a single pirate TLD designed by someone who knows
> > something of what they are doing is likely to be amusing, a
> > hundred or more is likely to be less so.
> >
> > Which has me looking at .ARPA instead.
> >
> > Having Alice type http://coffee.alice.mesh.arpa/ instead of
> > https://coffee.alice.mesh/ is not as nice but she will live
> > with it. or if open callsigns win the naming game, the anybox
> > in her browser will probably let her type coffee@alice and
> > route to the place she expects to go.
> >
> >
> > Problem here is that RFC 3172 was written in a different era
> > when people were still frightened about the loss of control.
> > The notion that registries are not control points had not yet
> > been understood.
> >
> > So which would people prefer for the pseudo-delegation?
> >
> > alice.mesh or alice.mesh.arpa?
> >
> > This would be a reservation in .arpa, not a delegation.
> >
> >
> > PHB
> >
> >
> > (Oh and yes, I do have a browser implementation thanks to the
> > heroes who developed WebView2 at Microsoft. It's Windows only
> > at the moment but should be fixed with MAUI.)
> >
> > (Oh and yes, I do understand how complex naming gets, I
> > watched it all happening in real time.)
>
>
>