At 16:44 03/10/2005, Hallam-Baker, Phillip wrote:
This is certainly true in theory. In practice any attempt to do this
would lead to the root being fractured. It would lead to a monumental
diplomatic incident.
Dear Phillip,
I am afraid this is not what is the main concern of Governments,
because if such a breach would occur this would certainly mean war.
And in such cases Govs use to have contingency plans rather than
depending on a group of volunteers including two military servers of
the adverse country.
A more insidious version of a breach is a uncertain "e-embargo" when
a confused UN situation would permit it. This can be the devolution
of a ccTLD to a fraction, in a revolution, as part of a peace
road-map. Delayed updates of the root files may delay/destabilise an
economy or be used as a diplomatic signal other countries have not.
We all have in memory the KPN-Quest story (60 ccTLD secondaries have
been closed overnight, all their new IP addresses have been
documented in hours. Root updates took from a few hours to several
months. The name of the delayed countries was very diplomatically
instructive on the US policy. States did not forget.).
But without going to such extremes, typical cases could be:
- there is a bug in the US file. It is a military target for many. We
recently had a case of a manual patch in the root file to correct a bug.
- a general black-out in the USA or in another country one has to
rely upon (like it also happened Italy). The restoration priorities
will go to national needs before other countries. If only because
local needs will be better documented.
- a critical situation in a given country may call for special urgent
decisions. Let for example consider a nuclear plant accident in
Europe. The TV screens will be polluted. The best way to address
population through clean, calm screens will be ADSL. You want then
priority to civil security.
Another issue is legal and police root logs. The root archives (logs,
agreement, policy statements, people, etc.) represents an important
national sensible economic intelligence leak.
But most of all the problem is now the control of national
innovation/protection. USA is in economic competition to many as
every other country. If the DNS is managed by the USA, it is managed
by competition. Status quo protects the US interests in protecting
the US industry usage of the Internet against more innovative uses
elsewhere. A country may be imposed an US permitted innovation it
does not want (ex. PathFinder). There are legal issues: if for
example a country wants to block/filter access to the names of
another country (for example simply due to different anti-spam
enforcement attitude). Example: if a State decides against access to ".xxx".
The USA just expressed clearly a very simple rule everyone agrees,
including Europe a few days ago: a sovereign State cannot delegate
national security and sovereignty issues to foreign voluntaries.
There is also a simple consideration which should rise a lot of
concern: this is the legal responsibility in case of major incident.
There will be costs and deaths. Who will be considered as
responsible. Who will pay? The volunteers out of their pocket? ISOC
for the possible protocol flaws Justice could discover?
There is also the technical evolution. The Root servers work well.
But is the root server system the most adequate solution? There are
alternatives in use and under consideration everywhere. This may
destabilise the DNS, protection are necessary. The DNS is like the
Titanic. We need compartmentalisation for risk containment. The
question is not "IF", but "HOW".
I explained 2 years ago I was holding meetings on this issue in
France, after a 2 years experiment along the ICANN ICP-3 call's to
test the matter. Which resulted in part from New.Net and in part from
security considerations (http://whitehouse.gov/pcipb) after 9/11. All
this was mostly ignored. The Govs and analysis have slowly proceeded.
Govs now are on the verge of deciding. New architectures are on the
verge to emerge.
jfc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf