[ga] Re: [ncdnhc-discuss] Revised security resolution

[Jefsey Morfin <jefsey@wanadoo.fr>]

Dear Chun,
as you know I am a small root operator and I wrote the document on Root and 
TLD Best Practices. So my camp is clear.

However I fully support the wording of Milton/Alejandro (I would be more 
dubious cautious about Dave's only because terse wording is usually less 
committing).

Since we are in a consensual approach, I would like to make understood that 
there are essential  differences between an "alternative root", an 
"alternative root operator" and an "alternative root administrator". Most 
of the confusion comes from the confusion of these concepts as "alt.root".

- alternative roots are root files which do not lead to the same addresses. 
The best example I know is last year's USG root: if you were to use it you 
would lend in different places when a transfer of DN owner occurred. This 
is why - as several ccTLDs - I oppose transfers (sales and non user 
demanded UDRP)

- an alternative root operator is someone who proposes alternative 
root-servers to the users. This is something that ISPs, extranet managers 
and ccTLDs may do. The ideal situation in term of security is when everyone 
has a local root server so he does not depends on any one to connect.

- an alternative root administrator is someone who manages a list of TLDs 
into a root list to the benefits of the users who want to use it. A Root 
Administrator uses TLD criteria. ICANN uses ICP-1 and the subjective 
contractual selective and commercial criteria. Inclusive roots Root 
Administrators accept every self-declared TLDs in applying no money based 
verification criteria. ICANN being in the "international TLD business" 
(Mike Roberts) considers free inclusive root administrators as absolute 
competition. The same as Windows and Linux. Inclusive root administrators 
consider ICANN as one them.

This explains why Milton's wording is OK for me. We need anti TLD squatting 
solutions. ICANN is one of them as soon as it gets "manu pulite" (honest, 
transparent, open and equal to all, common good oriented, conforming with 
bylaws, charters, MoU, previous commitments, etc...).

Security wise we all share the same concerns (however a larger number of 
alternative root-operators will decrease some risks: as ccTLDs consider it, 
GovNet may implement it, and several existing softwares permit everyone to 
do it today).

I am only sorry that a real lack of that small analysis by several 
elsewhere brilliant university people helps to maintain a commercial 
anti-competition confusion resulting in network development and innovation 
delays and in a network security and stability weakness due to many 
people's frustration.

Jefsey


On 06:47 05/11/01, Chun Eung Hwi said:
>Dear all,
>
>I have no objection to this draft document. And I fully agree to those
>deliberate opinions that ICANN's scope should be rigidly limited. Then, I
>am wondering why this document contains only very plain things even
>though it is told that security and stability is very serious subject
>today. What I want to raise up is as the following.
>
>- "The single DNS root leads to excessive administrative centralization.
>ICANN should support the evolutionary development of the DNS away from a
>centralized architecture."
>(Excerpts from Civil Society Statement approved in principle at the
>Yokohama Forum 13 July 2000 in Yokohama Japan,
>http://www.cpsr.org/internetdemocracy/Statement_July-13.html)
>
>Recently, Karl Auerbach raised up this question again in his interesting
>article - http://www.cavebear.com/rw/steps-to-protect-dns.htm. I think
>this topic should be discussed in our constituency.
>
>- In considering the stability of root server access among many countries,
>it should be taken account having an elaborate cache in those countries if
>they do not have one of the root server in their countries. The future
>addition of root server should be seriously considered for many countries
>where root server access is substantial.
>
>- For the stability and security of TLD name servers, some guidelines for
>those TLDs' name server operation should be developed. And some
>cooperation and support for vulnerable TLD name servers should be
>practically encouraged.
>
>
>
>Regards,
>
>
>Chun Eung Hwi
>------------------------------------------------------------
>Chun Eung Hwi
>General Secretary, PeaceNet | phone:     (+82) 2- 583-3033
>Seoul Yangchun P.O.Box 81   |   pcs:     (+82) 019-259-2667
>Seoul, 158-600, Korea       | eMail:   ehchun@peacenet.or.kr
>------------------------------------------------------------
>
>
>On Fri, 2 Nov 2001, Milton Mueller wrote:
>
> > Resolution on Security
> > Submitted by Alejandro Pisanty (with amendments)
> >
> > Recent, tragic events have heightened
> > the need to assess the security of the
> > Internet's centrally coordinated resources,
> > and the need for strong international
> > cooperation for this purpose.
> >
> > The Internet's robustness relies largely
> > on its distributed, decentralized nature.
> > ICANN is responsible for central coordination
> > of key resources critical to its operation;
> > namely, domain names, Internet addresses,
> > and protocol parameters.  Ensuring the
> > security of the DNS root servers, the IP
> > allocation system, and other central
> > resources within ICANN's deliberately
> > limited purview, is a responsibility shared
> > by all organizations within ICANN.
> >
> > The non-commercial organizations and
> > entities represented in the Non-Commercial
> > Domain-Name Holders Constituency
> > (NCDNHC) of ICANN's DNSO may be less
> > able to recover from disruptions in their
> > operations caused by attacks on the DNS.
> >
> > Many non-commercial interests in the DNS
> > and IP allocation system are in universities
> > and research institutes with high levels of
> > technical expertise. Many others, however,
> > have very limited financial and technical
> > resources to train for defense against and
> > prevention of attacks or to recover from a
> > crisis.
> >
> > Because the expertise embodied in non-
> > commercial organizations is usually more
> > accessible to a wider community and not
> > restricted to proprietary interests, academic
> > and other non-commercial organizations may
> > be optimal points for the diffusion of knowledge
> > about threats to the security of the systems
> > under ICANN's administration.
> >
> > Therefore the NCDNHC calls upon the Names
> > Council, the ASO, the PSO, the ICANN Board,
> > and Education and Research Networks
> > throughout the world to promptly assess the
> > threats to the security of the resources under
> > ICANN's coordination, and to establish measures
> > to address these threats, their avoidance, and
> > the minimization or avoidance of the collateral
> > damage they may produce, in order that non-
> > commercial organizations with limited technical,
> > human and financial resources can be protected
> > from such threats, and have affordable access
> > to preventive measures.
> >
> > Further, the NCDNHC calls upon its technically
> > strong members and their peers to aid ICANN
> > in the aforementioned effort to assess the
> > threats to the stability security of the DNS and
> > address allocation system and to provide the
> > community with their expertise. The NCDNHC
> > organization representatives will call on people
> > from their communities to provide further
> > assistance.
> >
> > The NCDNHC offers the technical and policy
> > expertise of its members, the high standing
> > of some of them in their societies, and the
> > intercultural experience of the constituency
> > to the process of assessing and securing the
> > security of the resources under ICANN's
> > administration.
> >
> >
> >
> > _______________________________________________
> > Discuss mailing list
> > Discuss@icann-ncc.org
> > http://www.icann-ncc.org/mailman/listinfo/discuss
> >
>
>_______________________________________________
>Discuss mailing list
>Discuss@icann-ncc.org
>http://www.icann-ncc.org/mailman/listinfo/discuss

--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html