Subject: Reporter re: Technical solution for robust interconnection if Russia & BRICs set own root?

From: Dave Burstein <[email-masked]>
Date: Tue, 2 Jan 2018 12:08:56 -0500

<http://bit.ly/RussiaDNS>
​Folks <http://bit.ly/RussiaDNS>

​I've mostly been a lurker here, but I working on a story I'd welcome help
for. This is for Netpolicynews.com.

What technical measures will be needed for "robust interconnection" if
Russia and the BRICS create their own root? ​
Vladimir Putin is creating an alternate root <http://bit.ly/RussiaDNS>,
with support from India and China. <http://bit.ly/Bricssi>
​*

They say they are afraid ICANN might shut them off ​as part of U.S.
sanctions. That seems unlikely to me but not crazy; U.S. Senators have
called for blocking Russia from SWIFT, the international banking system.
Russia has built an alternative, "just in case."

Censorship is a real issue but my question here is technical.
How could we make that work, if everyone is acting in good faith?
(Unproven, of course.)

I'm on the U.S. State Department ITAC and know the U.S. position is that
DNS must be controlled by ICANN (which does a decent job.)
Columbia Professor Eli Noam convinced me a "network of networks" was
possible <http://bit.ly/ManyNets>
​. With "robust interconnection" Noam and ICANN CEO Fadi Chehadi confirmed
to me there was no technical reason the Chinese, Hebrews, Verizon or any
other competent party couldn't set up independently. With "robust
inteerconnection" the primary benefits of "The Internet" could be
maintained. Fadi added the rub was how to ensure that robust
interconnection.

Thousands of people, especially at the IETF, have worked to build the
Internet we have today. The principles are simple; the implementation is
demanding. So I'm asking engineers, "What technical systems must must be
built to ensure robust interconnection, assuming everyone wants to work in
good faith?"

​Thoughts welcomed, on and off list. I have sources on the policy
questions, but not on the technical side.​

For the background.

Russia Orders Alternate Root Internet System <http://bit.ly/RussiaDNS>

Professor Noam's Many Internets; <http://bit.ly/ManyNets>

Putin, Xi, Modi, Temer, Zuma: Our 3,000,000,000 People Think the U.S.
Shouldn’t Run the Internet (Xiamen Statement) First Look
<http://bit.ly/Bricssi>

ICANN Continues Excluding Russia & China From the Board
<http://bit.ly/CEOPromises>

ICANN CEO's Promise to China of a Seat At The Table
<http://bit.ly/ChinaSeat>

 * ICANN, a California corporation subject to U.S. law, may already be
legally obligated to shut down any URLs connected to Chechen
strongman Ramzan Kadyrov. He's a thug, but didn't do anything on Facebook
to cause him to be blocked from his 4M followers.

U.S. Treasury Secretary Stephan Mnuchin has threatened
<http://bit.ly/2CtA378> to block the Russians and Chinese from the
essential international banking system SWIFT. In response, the Russians have
built an alternative. <http://bit.ly/2CsAsGU>Setting up similar may be a
sensible precaution.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Jan 2018 10:24:43 -0800

Have you reviewed RFC 2826? (https://tools.ietf.org/html/rfc2826)

regards,

Ted
(Not wearing any hats)

---

From: Dave Burstein <[email-masked]>
Date: Tue, 2 Jan 2018 16:54:54 -0500

Ted

I'm a network guy, not a DNS/TCP/etc geek, which is why I reached out.

re: RFC 2826 requirement for a "globally unique public name space," I would
think that could have several different technical solutions beyond a single
root. The Google & Amazon clouds and worldwide distributed databases show
many possibilities, I would think.  Two occur to this layman:

Roots that regularly update each other, so that both have the same data.
Something similar is in the current replication system and in the Google
server system. If that were cut, Russia would have many choices to go on,
including buying transit in a neutral country.
Separate roots that maintained logically separated data. For example, .ru,
.cn, all TLDs with Chinese Russian or Portuguese could be in the new
system. Queries could automatically go based on TLDs. Cached and duplicate
servers could pull from both,

But I could be wrong about this, which is why I'm reaching out before
printing anything.

The Russian decision came from the State Council with a 6 month
deadline. It still could be stopped but I think should be addressed before
it creates a crisis.
------------------
The "Nobody who pays any attention to ICANN (inside or out) thinks ICANN
should get wound up in politics over who is the Correct Internet People,"
seems right to me. But we may not have any choice in the matter, according
to the lawyers for Facebook and the Internet Society.

At the request of the U.S. government, Facebook just canceled the account
of Ramzan Kadyrov, ruler of Chechnya, with 4M followers. They claimed it
was required by U.S. law. The U.S. gov put him on an enemies list. The guy
appears to be a murderous thug who should be in jail, not running a
country, but no evidence was presented he did anything wrong on Facebook.
You have to protect the free speech of people you despise or it can be lost
by everyone.
At the Internet Society, Kathy Brown revoked the travel funds that had been
awarded to an Iranian to go to an IGF in Mexico City. It broke the Iranian
embargo and ISOC didn't even seek n exemption.

ICANN probably would have no choice but to obey a court order to shut down
connections to Palestine, where a majority supported Hamas, on U.S.
terrorist lists. What if the factions we oppose took over Libya, Somalia,
or Mali.

I've said from the beginning I think an ICANN boycott of Russia was
unlikely but it's not crazy to fear it. ICANN is a U.S. corporation under
U.S. law.

So I believe it's time to think about this.

Dave

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Jan 2018 14:04:48 -0800

On 1/2/2018 1:54 PM, Dave Burstein wrote:
> re: RFC 2826 requirement for a "globally unique public name space," I
> would think that could have several different technical solutions
> beyond a single root. The Google & Amazon clouds and worldwide
> distributed databases show many possibilities, I would think.  Two
> occur to this layman:
>
 
Which one is authoritative when they disagree? I.e., which root is
allowed to add entries?

If it's always ICANN's, then you have just a root cache. That's not an
issue.

If it's ever the other root, then you end up with the problem in that
RFC of having multiple name spaces.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Jan 2018 16:25:37 +1300

On 03/01/2018 10:54, Dave Burstein wrote:
...> ICANN probably would have no choice but to obey a court order to shut down
> connections to <random country>

ICANN has no control over network connections; that's in the realm of internet service providers and telecommunications carriers, most of which are outside US jurisdiction. All ICANN could conceivably do is remove a country code top-level domain from the root servers that ICANN controls. That is of course the motivation for most moves to bypass the ICANN root. It's also the reason that many people have been very concerned since 1998 that ICANN was created as a US corporation in the first place. If it had been created as an NGO in a neutral jurisidiction, we wouldn't be having this conversation.

Regard
    Brian

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Jan 2018 15:13:50 -0800

Hi Dave,
At 09:08 AM 02-01-2018, Dave Burstein wrote:
>today. The principles are simple; the implementation is demanding. 
>So I'm asking engineers, "What technical systems must must be built 
>to ensure robust interconnection, assuming everyone wants to work in 
>good faith?"

The proceedings of SIGCOMM 1988, 106-114, discuss about survivability 
in the face of failure.  That might be similar to the "robust 
interconnection" which is mentioned above. Part of the message [1] is 
about DNS.  There is a 2006 document about that (SSAC 009).

Regards,
S. Moonesamy

1. https://www.ietf.org/mail-archive/web/ietf/current/msg105855.html

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Jan 2018 23:54:42 +0000

S Moonesamy wrote:
>> today. The principles are simple; the implementation is demanding. So
>> I'm asking engineers, "What technical systems must must be built to
>> ensure robust interconnection, assuming everyone wants to work in good
>> faith?"
> 
> The proceedings of SIGCOMM 1988, 106-114, discuss about survivability in
> the face of failure.  That might be similar to the "robust

it would be important to be careful about language.  "Interconnection"
refers to IP layer connectivity, but this is a discussion about
alternative DNS roots.

The technical work on this was done in two tranches: the first works in
the 1990s were a result of the AlterNIC saga, when BIND 4.9 was hardened
against dns pollution from alternative servers.  Until then, DNS
poisoning from misconfigured and malconfigured DNS server had been an
ongoing problem, but this formed a new baseline standard for handling
cache pollution.

The second major improvement was dnssec, which requires a single root
per resolver. If Russia or anyone else sets up an alternative root, then
dnssec-enabled resolution will fail for dnssec domains on other roots.

Incidentally, alternative DNS roots are nothing new. ICANN even has an
info page on them:

https://icannwiki.org/Alternative_Roots

Nick

---

From: Mark Andrews <[email-masked]>
Date: Thu, 4 Jan 2018 13:48:34 +1100

> On 4 Jan 2018, at 10:54 am, Nick Hilliard <[email-masked]> wrote:
> 
> S Moonesamy wrote:
>> Hi Dave,

It requires that trust anchors be install for each of the namespaces so
that DNSSEC will work. Its a bit brittle but not impossible.  If ICANN
was to remove .ru from the root you could restore validation by configuring
the validators to know about .ru DNSSEC key.

e.g. (for BIND/named)

managed-keys {
	. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
	ru. initial 257 3 8 "AwEAAcqaT0pNXB/C84rvc/ola8FMLUBF4roNNt4062EjXlUcKIHCCy/Xw4gkQzYG4pfr4MVsjUwp2D1SFFGGwx3Gp2/gZ1za7mGDoNHUeIZqGRxJmHlWatwaFcFh2yteyHRHh5L0WaJkMhoWrojXBf5S/Cl4BFr/5VuSFMuFV7JrEFkv9ybsiGEvsLT6c/bEhduqHSYj5wAvwHep7If92UO8accRP5AxAphkb6dlRc6kv+yJ+GABaNvxHMYJLwYai2/yvhpvvluT9BB/BtIct85Xh1BTcDpGnv1fhJo/dJPTcynjXY0i5GPVvQaOZbuyHdZEaCUJfSWAmERjYvpPlcamiTE=“;
};

zone “ru” {
	type stub;
	masters { 194.190.124.17; 193.232.156.17; 193.232.128.6; 193.232.142.17; 194.85.252.62; };
	file “ru.stub”;
};

Similar is possible for all other nameservers.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Amreesh Phokeer <[email-masked]>
Date: Thu, 4 Jan 2018 10:04:30 +0400

Hi Dave,

> maintained. Fadi added the rub was how to ensure that robust

Indeed. A truly decentralized internet is what we should aim for. But think
of DNSSEC, things are very much centralized at the moment.

There have been some attempts:

https://en.wikipedia.org/wiki/OpenNIC
http://www.open-root.eu/?lang=en

And also some blockchain-based alternatives:
https://en.wikipedia.org/wiki/Namecoin
https://blockstack.org/

Regards,
-- 
Amreesh Phokeer

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Jan 2018 23:18:50 -0800

Hi Nick,
>refers to IP layer connectivity, but this is a discussion about

Yes.  There isn't much to add to an "alternative DNS roots" 
discussion as there has been numerous discussions about that topic.

Regards,
S. Moonesamy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 4 Jan 2018 21:21:25 +0100

On Tue, Jan 02, 2018 at 12:08:56PM -0500,
 Dave Burstein <[email-masked]> wrote 
 a message of 146 lines which said:

> What technical measures will be needed for "robust interconnection"
> if Russia and the BRICS create their own root? ​ Vladimir Putin is
> creating an alternate root <http://bit.ly/RussiaDNS>, with support
> from India and China. <http://bit.ly/Bricssi>

I've seen this announcement repeated in several places, always without
fact-checking. So, first thing: this is a Russia-only announcement. No
BRICS country every supported publically this project. There is *zero*
"support from India and China".

Even for Russia itself, it is not the first time there is such
claims. Russia *can* create a DNS root but I'm not sure they *will*.

> Censorship is a real issue but my question here is technical.  How
> could we make that work, if everyone is acting in good faith?

Basically, you cannot. Let's ask simple questions: who will manage
.home (a real example since .home, not delegated in the ICANN root, is
delegated to different persons in different alternative roots)?

* if there is a body to arbitrate between the competing roots, then
this body is the root. May be it will be better than ICANN (it's not
too difficult) and may be not.

* if there is none, an URL <http://something.home/> will go to different
Web sites depending on the root your resolver use. 

I've seen a lot of hand-waving how how a rootless system may work, but
never a detailed technical analysis, covering all the cases, specially
the inconvenient ones (such as .home).

Same issues for alternative (non-DNS) naming systems: most sweep the
problem of consistency under the carpet. (GNUnet is one of the few who
honestly declare that they don't try to have unique names.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 4 Jan 2018 21:31:30 +0100

On Tue, Jan 02, 2018 at 04:54:54PM -0500,
 Dave Burstein <[email-masked]> wrote 
 a message of 176 lines which said:

> I would think that could have several different technical solutions
> beyond a single root.

No. And if someone challenges this "no", I ask for references (not
one-paragraph ads, or YouTube videos, but actual technical
publications and running code).

> The Google & Amazon clouds and worldwide distributed databases show
> many possibilities, I would think.

Bad example since Google or Amazon is a company, with an internal
hierarchy. They can always set rules and make every actor in their
distributed system follow it. Distributed systems are possible (I
wouldn't say easy) when there is one management / one root. The hard
part is when there are several actors, without a Leader. The great
thing about the Internet is not the protocols, they have nothing
extraordinary. The great thing is that it is a network of several
actors, without clear hierarchical relations between them. That's the
hard part.

> Roots that regularly update each other, so that both have the same

What if there is a conflict? If two roots create .home to two
different actors? In single-organization distributed databases, there
are rules for that (such as "the router with the lowest ID wins"). But
in the Internet?

> Separate roots that maintained logically separated data. For
> example, .ru, .cn, all TLDs with Chinese Russian or Portuguese could
> be in the new system. Queries could automatically go based on
> TLDs. Cached and duplicate servers could pull from both,

Not sure I understand what you propose here. It seems too sketchy to
be actually discussed.

> ICANN probably would have no choice but to obey a court order to
> shut down connections to Palestine, where a majority supported
> Hamas, on U.S.  terrorist lists. What if the factions we oppose took
> over Libya, Somalia, or Mali.

In theory, yes, ICANN can remove from the root a ccTLD. This is
certainly a concern. (I agree with Brian Carpenter here.) In practice,
well, we don't have to speculate, the case actually occurred and,
here, ICANN handled it well, and refused to remove .ir
<http://www.circleid.com/posts/20160802_court_of_appeals_avoids_doomsday_effect_in_iran_cctld_decision/>.

Until now, all the ccTLD removed were with their "agreement". That's
why .su is still there.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 4 Jan 2018 21:35:35 +0100

On Wed, Jan 03, 2018 at 11:54:42PM +0000,
 Nick Hilliard <[email-masked]> wrote 

> ongoing problem, but this formed a new baseline standard for handling

I don't see the relationship with the structure of the domain name
tree, or with the role of the root.

> The second major improvement was dnssec, which requires a single
> root per resolver. If Russia or anyone else sets up an alternative
> root, then dnssec-enabled resolution will fail for dnssec domains on
> other roots.

No, they would simply put the new key in their resolver. This is how
all the DNSSEC-signed alternative roots work, like Yeti
<draft-song-yeti-testbed-experience>.

> https://icannwiki.org/Alternative_Roots

icannwiki.org is NOT managed by ICANN.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 04 Jan 2018 20:55:13 +0000

Stephane Bortzmeyer wrote:
> On Wed, Jan 03, 2018 at 11:54:42PM +0000, Nick Hilliard <[email-masked]> wrote 

early versions of bind were notoriously prone to cache poisoning from
arbitrary replies to dns requests.  When some of the early alternate
roots appeared on the scene (AlterNIC and eDNS come to mind), DNS
servers from root X would reply authoritatively to requests from DNS
resolvers, and the resolvers would reply to clients with both records
and glue from the alternative roots.  There were other bugs where you
could include authoritative responses to domains that the resolvers were
authoritative for, and this information would be served as authoritative.

[As a side note, the auth+resolver on the same box problem happened
because it wasn't possible to configure multiple IP addresses on the
same interface for many years on any of the standard operating systems
(sunos3/sunos4, freebsd1/2, linux 0.9*), and there was no such thing as
virtualisation, which meant that if you wanted 2 auth servers and 2
resolvers, that meant 4 physical boxes, and they cost a fortune at the
time.]

>From our perspective in 2017, this was cripplingly broken behaviour, but
nevertheless it was the state of affairs in the mid 1990s and a bunch of
the cache poisoning fixes were implemented partly because the
alternative roots created cross-contamination problems.

> icannwiki.org is NOT managed by ICANN.

didn't realise - thanks for the correction. The point I was making was
that alternative roots have been on the scene for a long time.

Nick

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 4 Jan 2018 21:55:45 +0100

On Thu, Jan 04, 2018 at 10:04:30AM +0400,
 Amreesh Phokeer <[email-masked]> wrote 

> http://www.open-root.eu/?lang=en

The two are very different. OpenNIC is real. You may like its
policies, or its operational quality, or you may dislike them, but it
is a real system, with real users.

Open Root is completely void. You'll notice on their Web page that they
don't even indicate the IP addresses of their root name servers
(because they have none), something that every alternative root
advertise proudly (see OpenNIC home page, for instance).

If you know DNS, Open Root texts will probably amuse you
<http://www.open-root.eu/about-open-root/open-roots/>. One of the best
sentences: "However Google (and Chrome) use their own root (copy of
the ICANN root); its IP address is 8.8.8.8 or 8.8.6.6."

> https://en.wikipedia.org/wiki/Namecoin

I think there are much more people who mention Namecoin that people
who actually use it. I'm one of them (d/bortzmeyer, alias
bortzmeyer.bit if you use a DNS gateway such as OpenNIC). There are
three points to note with Namecoin:

* it works fine
* it is policyless, by construction. Pure FCFS. If someone wants to
 register a name, you can do nothing. I let you decide if it is a bug
 or a feature
* the security of your domain entirely depends on your ability to
 properly manage your private key (backup it, but keep it private). As
 the Bitcoin users discovered, this is not easy. There are possible
 solutions but they are not deployed yet.

<https://www.centr.org/library/library/centr-event/rd6-bortzmeyer-namecoin-20140604.html>
(a bit old but still mostly true)

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Jan 2018 16:00:15 -0500

Dave,

While agreeing with Ted's and Joe's comments (and several
others), let me try to a different take on this.  Inline below...

> I'm a network guy, not a DNS/TCP/etc geek, which is why I

First of all, note that there are two entirely different
scenarios driving these discussions (or, if you prefer, plans or
threats).  One is just posturing.  If that is the goal,
especially if it is combined with a desire to preserve global
connectivity and a global name space [1], they can just copy the
root zone onto their services, announce that they are running
root servers of their own, hold a parade, and we all move on.
Technically and operationally, that approach was easier to get
right when the number of entries in the root zone was small and
changes were relatively infrequent, but, in part because the DNS
was designed so that, if used as intended [2], it is fairly
robust about slow updates.  

If, having established a national, but consistent, copy of the
root, one decides to add a few TLDs to one's local copy for
national use, perhaps as links to or duplicates of existing
zones from deeper in the tree, that is fairly close to harmless
in practice as long as those apparent TLDs don't "leak" or
conflict with names in other people's root zones.  We have
worked examples of that behavior and its non-disruptive effects.

At the other extreme, one's intention might be to either isolate
oneself or one's country (perhaps along with some friends) or
disrupt others.  These are, again, different, but let's come
back to that.   

The second important point is that, while the DNS is important
for finding things by name, it has almost nothing to do with
Internet connectivity.  If I know, or can figure out a reliable
way for you to tell me, your IP address or the address of a
server you want me to look at, then, for most purposes and
applications, we don't need the DNS (public and single-root) or
otherwise.  A good analogy of a local address book would do as
well.  For other purposes, I might need to know what you call
the host, but that is probably trivial if I can obtain the
address.  A number of recent decisions and protocol designs have
increased our dependence on the DNS for more than name to
address translation functions, but, if getting away from the
public DNS and its root arrangements is really an important goal
in which one is willing to invest resources, it appears to me
that none of those are insurmountable either.  

It is also worth remembering that many people who are using
Internet facilities to get information in and out of countries
believed to be excessively hostile to the free flow of
information are already using mechanisms that are not dependent
on the DNS, so it is unlikely that a disruption in DNS service
would have any negative effects on them at all.

But there is a more fundamental issue in all of this.  If some
country decides it wants to withdraw from the DNS, or even
disconnect from the Internet, it isn't clear why the rest of the
community should do anything, especially from a technical
standpoint, other than wish them the best, send them on their
way, and go about our business.   There might also be good
reasons to wish them a speedy revolution, but that is a
different matter.  Attempts to disrupt anyone else are another
matter; DNSSec is one of our defenses against one family of such
attacks.  

Finally, having been somewhat involved with the decisions to
delegate TLDs to countries whom the US Government viewed as
hostile at the time, I think that, in the present climate, any
attempt by ICANN to remove TLDs on that basis would fairly
rapidly result in ICANN's downfall (I do not believe that anyone
in ICANN's leadership is seriously considering such a thing
either).
 
> re: RFC 2826 requirement for a "globally unique public name
> space," I would think that could have several different
> technical solutions beyond a single root. The Google & Amazon
> clouds and worldwide distributed databases show many
> possibilities, I would think.  Two occur to this layman:
> Roots that regularly update each other, so that both have the
> same data. Something similar is in the current replication
> system and in the Google server system. If that were cut,
> Russia would have many choices to go on, including buying
> transit in a neutral country.
> example, .ru, .cn, all TLDs with Chinese Russian or Portuguese
> could be in the new system. Queries could automatically go
> based on TLDs. Cached and duplicate servers could pull from
> both,

> But I could be wrong about this, which is why I'm reaching out
> before printing anything.

Whether you are wrong or not is almost irrelevant in the light
of understanding that all of the alternatives one might
hypothesize for the DNS have their own advantages and
disadvantages too and, more important, the observation that the
DNS is deployed on enough systems that a transition plan to a
different model would be hard and, under the most optimistic
assumptions, would probably take years.

> deadline. It still could be stopped but I think should be
> addressed before it creates a crisis.

Crisis for whom?  Russian companies wishing to be reached from
outside the country would rapidly register in some generic TLD
(and have probably already done so) and start publicizing those
addresses unless prevented from doing so and might suffer a loss
of external customers.  Russian residents wanting to reach
outside Internet sites might be more or less inconvenienced, but
see above.  Seems to me it would mostly hurt Russians and
Russian companies without creating anything resembling a crisis
for anyone else.

> ------------------
> The "Nobody who pays any attention to ICANN (inside or out)
> thinks ICANN should get wound up in politics over who is the
> Correct Internet People," seems right to me. But we may not
> have any choice in the matter, according to the lawyers for
> Facebook and the Internet Society.

IANAL, but I dou't believe your analogies hold.

> At the request of the U.S. government, Facebook just canceled
> the account of Ramzan Kadyrov, ruler of Chechnya, with 4M
> followers. They claimed it was required by U.S. law. The U.S.
> gov put him on an enemies list. The guy appears to be a
> murderous thug who should be in jail, not running a country,
> but no evidence was presented he did anything wrong on
> Facebook. You have to protect the free speech of people you
> despise or it can be lost by everyone.

Sure, but this targets a specific individual, not a country, and
has nothing to do with the DNS.

> At the Internet Society, Kathy Brown revoked the travel funds
> that had been awarded to an Iranian to go to an IGF in Mexico
> City. It broke the Iranian embargo and ISOC didn't even seek n
> exemption.

Has nothing to do with the DNS either.  If you want to take it
up with the ISOC BoT, this is not the right list.

> ICANN probably would have no choice but to obey a court order
> to shut down connections to Palestine, where a majority
> supported Hamas, on U.S. terrorist lists. What if the factions
> we oppose took over Libya, Somalia, or Mali.

But ICANN has absolutely no power, even if it wanted to, to
"shut down connections" to Palestine or anywhere else (see
above).  They could, in principle, remove the "ps." TLD from the
root, but I think it would go badly for them (see above), even
with an order from a US Court, and they would presumably argue
that such a court was overreaching its reasonable authority
especially in  the absence of evidence that the proposed
solution would be effective.  Even if ICANN did that, presumably
the affected parties in Palestine would reregister somewhere
else (most likely in a different ccTLD or in some gTLD not
obviously subject to US law).  And our colleagues at the ITU
would point out that these sorts of situations are high on the
list of reasons why they have been suggesting for years that the
top level of the DNS needs treaty protection.

> I've said from the beginning I think an ICANN boycott of
> Russia was unlikely but it's not crazy to fear it. ICANN is a
> U.S. corporation under U.S. law.
> 

Good analogies escape me, but it is perhaps not crazy to fear an
asteroid collision that would wipe out most of life on earth
either.  That doesn't imply that spending a lot of time worrying
about it, especially without proposals for useful defenses, is a
particularly good use of time.

best,
   john

[1] Note that their may be important trade or other economic
motives for wanting to preserve global connectivity that might
complicate more obvious political considerations.  For example,
a colleague suggested some years ago that we might be nearing
the point at which some types of Internet disruptions could be
considered non-tariff trade barriers.

[2] "Used as intended" is another matter.  See, e.g.,
https://datatracker.ietf.org/doc/draft-klensin-dns-function-considerations/

---

From: Christian Huitema <[email-masked]>
Date: Thu, 4 Jan 2018 11:03:02 -1000

> honestly declare that they don't try to have unique names.)

Yes. The key to decentralization is support for non-uniqueness. It
requires one level of indirection from "mnemonic names" such as
"example.com" to "decentralized unique identifiers", typically derived
from public keys. But that still does not work if the resolution system
gives a single answer, as in "this is who the system believes is
example.com". The client would ask for the key, see that it doesn't
match, and be stuck. So the resolution system needs to answer "there are
multiple entities who claim to be example.com, here is a list", and the
client would then have to check which one has the right key. And then of
course there is the question of first contact, when the client does not
know yet the "right key" for example.com. This could be done, but it
would require a huge amount of work -- boiling the ocean comes to mind.

-- Christian Huitema

---

From: Dmitry Burkov <[email-masked]>
Date: Fri, 5 Jan 2018 02:35:58 +0300

I think that uniqueness is driven by business reasons even more then 
technical.
I don't believe in any political decisions without economical interests 
behind.

If someone will make a decision to split a DNS space - I don't care. 
They are still are interested in to be integrated
in global market.

We even can get an advantage - we will cancel long term tabu on 
alternative implementations and deployments.

Of course - it will create image problems for some personalities who 
tried to prove the world - that there are no alternatives and personal 
problems for some of them who was paid to deploy such system.
Who care - I don't think that this the end of the internet.
Technically it is possible (please, don't think that I am so naive and 
know nothing about all riffes/stones).

Historically - we always did our work formally ignoring existence of states.
But if states will make a step - they will put of us in different 
dimesion with different rules where our artificial tabu and restrictions 
will be broken.

I still believe that we can do it before any state will develop really 
working solution which can satisfy their need - the best example China 
(don't want detailed  their solution - ot you enough clue  or no matter) 
that already provided  as minimum independence - but prefer follow 
mainstream yet.

I believe that it is possible to change our minds and to try find how we 
can design and deploy really distributed approach which can satisfied 
all old raising needs.

regards
Dima Burkov

---

From: Dmitry Burkov <[email-masked]>
Date: Fri, 5 Jan 2018 02:51:45 +0300

John,

Icann will  failed if they will continue their current approach.

ICANN works as typical corporation now and interested in status quo.

I never expected that ICANN can initiate development which will allow to 
migrate to really distributed system.

It is against their basic interests.

Another point - if we will agree that it is a real issue that can affect 
all of us - we should try to find a design which can satisfy all actors 
and interested parties to provide safe and reliable distributed name system.

Dima

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Jan 2018 09:58:55 +0900

dima,

> I believe that it is possible to change our minds and to try find how
> we can design and deploy really distributed approach which can
> satisfied all old raising needs.

while i can see this as possible (note 'possible') technically, i worry
that, as you said, our social structure has too much invested, ego and
financial, in the status quo.

i have little to no faith in the icn, ndn, nnnnnn, paths.  so what clues
do we have as to where we can evolve?  and it has to be evolve, not
reinvent the whole bleeping internet; learn from the ipv6 incompatible
disaster.

randy

---

From: Christian Huitema <[email-masked]>
Date: Thu, 4 Jan 2018 15:19:14 -1000

Is it about alternative root management, or is it something else? For
example, in the case of the Russian Federation, one recurring theme is
that they don't want the US government to be able to disconnect Russia
from the Internet. On one hand, it is a political problem. But on the
other hand, it is also a technical problem. Can we design some kind of
redundant system so that even if ICANN wanted to, they could not replace
the ownership of a national domain like .RU without explicit agreement
of the corresponding government?

And by the way, I did not come up with this question by myself -- Steve
Crocker did, during is final address as departing ICANN chairman.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Jan 2018 00:33:25 -0500

Dima,

This conversation is rapidly drifting away from what I consider
appropriate for the IETF list, so this is likely to be my last
posting on the subject.

In a number of ways, I believe that ICANN has already failed and
did so several years ago.  If one can judge from the observation
that they are still in business, the Internet community
(whatever that means) either doesn't care, believes that they
(failures and all) are a better option than any of the other
ideas that have been seriously proposed, or is ineffectual in
doing anything about it.

But, from my point of view at least, ICANN's initiating protocol
development would almost certain be an even bigger failure...
and lead to yet bigger ones.

So I'm not certain I understand what you are talking about.  In
particular (and going back to my understanding of Dave's
question), rather than pushing back on TLDs whose operators it
does not like or that have misbehaved in important ways (such as
by violating standards about what can be registered), I believe
it has been excessively deferential to them and especially to
ccTLDs associated with large and/or powerful countries.

I think we have a "safe and reliable distributed name system",
one that has the advantage of being widely deployed and very
heavily used in practice.  I don't believe it is adequate for
many things people "want to do", in some cases because the
desires are unrealistic and in others because it is just the
wrong technology, but that is different from whether it is (at
least relatively) safe and reliable.   As far as the need to
"satisfy all actors and interested parties", I think that is
impossible, if only because there are observably multiple actors
out there who will not be satisfied with any system of which
they are not in charge, in many cases exclusively so.   As long
as that is a requirement, they are not all going to be satisfied.

best,
    john

--On Friday, January 5, 2018 02:51 +0300 Dmitry Burkov
<[email-masked]> wrote:

> I never expected that ICANN can initiate development which
> will allow to migrate to really distributed system.
> 
> Another point - if we will agree that it is a real issue that
> can affect all of us - we should try to find a design which
> can satisfy all actors and interested parties to provide safe
> and reliable distributed name system.
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 8 Jan 2018 18:49:07 -0500

Hi,

On Thu, Jan 04, 2018 at 11:03:02AM -1000, Christian Huitema wrote:

> client would then have to check which one has the right key.

I know you know this, but just for observers who maybe don't: the
"client" there may not be a human, and indeed the client that is
presenting the request might not be any longer in touch with the
originating node for the query.  The usual example of this is SMTP,
because it is a hop-by-hop protocol and so an SMTP server attempting
to deliver a mail might not be in touch with a human who started the
mail going.  But we can easily imagine additional cases --
particularly with the current mania for hooking up new devices
programmed by people who have never worked in an Internet context
before ("Internet of Broken Things").

Now, in such cases, the clients need to know how to handle the
disambiguation, which means that the indirection layer can actually
only ever be useful for human-computer interaction.  That's maybe a
nice constraint on development, but it causes trouble when the human
who configured the system walks away and then the naming universe
changes, creating an ambiguity (that now needs resolution) when before
there was no such problem.

The FCFS solution (cf. namecoin) is one answer, but of course that's
really the answer that the DNS used in its early period.  As soon as
people with money and lawyers got involved, the arbitrary identifiers
of the DNS became trademarks of WIPO and ICANN's UDRP.  FCFS just
doesn't work in that context, and attempting to build it in as a
technical limitation does not make for a realisticly useful system.

I am interested in these problems, but I also remain completely
confounded about how to make the indirection layer work without
creating a new class of design problem that we don't know how to fix.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]