Re: [dns-wg] Re: ORSN-SERVERS.NET

["JFC (Jefsey) Morfin" <]

At 16:14 28/10/2004, Jim Reid wrote:
> >>>>> "JFC" == JFC (Jefsey) Morfin jefsey@localhost writes:
>
>     JFC> what ORSN does is risk containment. Suppose the ICANN/NTIA
>     JFC> root is hacked.  The ORSN file is not affected. This provides
>     JFC> a protection.
>
> Could I please have some of whatever drugs you're taking? :-)
Dear Mr. Reid,
I have given you a public source: http://whitehouse.gov/pcipb.
I suppose that your speed in responding did not permit you to
fully inhalate that long document. I am sure that you have in
your own country some Intelligence or Critical Risks service
which can brief you on your national blend.

> IIUC this ORSN nonsense uses the root zone file as a starting
> point. So presumably any errors that get introduced there will be
> passed on to ORSN and its fellow travellers, no?
You presume wrong in this case. The last one which presume
risk containment was OK was named "Titanic". Let stop criticizing
for the fun of it, and let us start criticizing things for the serious
of them and security and in this case national security.

>    JFC> Let imagine that a terrorist atomic bomb blows
>     JFC> Washington-West (the top worldwide target and an US working
>     JFC> hypothesis). The propagation through the internet would be
>     JFC> times devastating than the bomb itself on the USA.
>
> First of all, I think most people would accept that any loss of life
> is far, far more devastating than the ability to route packets and
> make DNS lookups.
I am afraid you missed the point. A WH evaluation in a preparatory
document, established the death toll of an accumulation of network
incident affecting critical installations or population behaviors to 2
millions deaths (in Chicago if my memories are correct). It also
documented the number of typical attack which would lead to a
situation and their hyperbolic increase in number and penetration
over the last two years.

Let understand there are two situations. One is the one you
consider which is to keep in mind and which is much unlikely.
This would be a root file hacking. The problem is the one that
Brazil and others documented at the WSIS. It would be quite
hurting in term of cost and the indirect death toll would in most
of the cases be low and difficult to establish (non performed
access to vital services for examples, accidents resulting from
a stress, duress, etc. created).

The other situation which the big one is when there is critical
attack on some network systems of importance and that
a response is to be provided. Then Authorities are to take
decisions which are necessarily create technical, political
or even military conflicts. I took the case of Iraq as a situation
everyone can understand and everyone accepts as an exception.

The what will create a problem is the consequence of that
decision (reallocating a ccTLD for example - ie an e-embargo
on a contry without UN mandate - which is disapproved by
some other countries which will introduce their own ccTLD
manager creating a pollution, which may chain to others).

When Peter De Blanc told Mike Roberts that he should not
push ccTLDs to use their nulcear arsenal, this is exactly
what he meant, and the impact today would not be far.

Obviously there are many other issues to this. And I
know you are you cute and experienced enough to
imagine them, what it implies for the DNS, etc.

All the best.
jfcm






> Secondly, the root zone doesn't change much: TLDs renumber one of
> their servers now and again. Even if a major catastrophe destroyed the
> ability to change the root zone for a while -- I very much doubt that
> -- this would at worst be a minor inconvenience for TLD operators and
> the DNS in general. Good TLD managements will keep the old name
> servers running for at least a month or two after a renumbering. In
> fact a strong case can be made for NOT changing the root zone after
> such an event for stability reasons.
>
> Finally, suppose Something Bad has happened and the root can't be
> changed. Why would a TLD then choose to update their info in this
> bogus ORSN root while the info in the real root was unchanged?
> Wouldn't that lead to precisely the sort of inconsistency and network
> partitioning that the ORSN people claim they want to avoid?