Re: national security
Paul Vixie <vixie@vix.com> Mon, 01 December 2003 04:49 UTC
Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23713 for <ietf-web-archive@odin.ietf.org>; Sun, 30 Nov 2003 23:49:21 -0500 (EST)
Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AQfmM-0004QC-KO for ietf-list@asgard.ietf.org; Sun, 30 Nov 2003 23:35:22 -0500
Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AQfmJ-0004PM-G2 for ietf@asgard.ietf.org; Sun, 30 Nov 2003 23:35:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23300 for <ietf@ietf.org>; Sun, 30 Nov 2003 23:35:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQfmH-0002QS-00 for ietf@ietf.org; Sun, 30 Nov 2003 23:35:17 -0500
Received: from sa.vix.com ([204.152.187.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQfmG-0002QF-00 for ietf@ietf.org; Sun, 30 Nov 2003 23:35:16 -0500
Received: by sa.vix.com (Postfix, from userid 716) id 21BB413976; Mon, 1 Dec 2003 04:34:45 +0000 (GMT)
To: ietf@ietf.org
Subject: Re: national security
References: <5.2.0.9.2.20031129184134.02fe5178@pop.mcilink.com> <Pine.LNX.4.44.0311301723240.10319-100000@npax.cavebear.com>
From: Paul Vixie <vixie@vix.com>
Date: Mon, 01 Dec 2003 04:34:44 +0000
In-Reply-To: <Pine.LNX.4.44.0311301723240.10319-100000@npax.cavebear.com>
Message-ID: <g3zned88bf.fsf@sa.vix.com>
Lines: 204
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf@ietf.org
Precedence: bulk
karl wrote: > ... > ICANN's job is not to make decisions in secret, by unknown members of > "staff", based on unknown criteria and using unknown assumptions. ... that sentence is punctuated incorrectly. there's a period after "decisions." > ... so, which is what you are saying has been done, is simply yet another > abandonment of ICANN's obligations. i think there's a tense problem here. icann cannot abandon that which it never had. perhaps a pretense was abandoned, but not an actual obligation. > The switch to anycast for root servers is a good thing. again there's a tense problem. there was no "switch to" anycast. the last time those thirteen (or eight) ip addresses were each served by a single host in a single location was some time in the early 1990's. > But it was hardly > without risks. For example, do we really fully comprehend the dynamics of > anycast should there be a large scale disturbance to routing on the order > of 9/11? yes, actually, we do. (or at least the f-root operator does.) > Could the machinery that damps rapid swings of routes turn out > to create blacked out areas of the net in which some portion of the root > servers become invisible for several hours? nope. or at least, that risk is unchanged from the multihomed servers that have actual backhaul between their points of presense. (those of you who are bgp-aware all know that there is no way to tell the difference between a robustly multihomed network and a robustly anycasted network.) if karl is going to start worrying about flapdamping, he's late to the party, and the things to worry about aren't all or even mostly anycasted. > Could one introduce bogus > routing information into the net and drag some portion of resolvers to > bogus root servers? of course! but then that was always true and will always be true. the only fix to it is some form of secure BGP which i guess means route-signing and route-verification and oh my what a mess that turns into very quickly. and the affected ("at risk") elements are, again, overwhelmingly NOT anycasted. > I'm pretty sure that the root server operators have answers to these > questions. However, it is incumbent on ICANN not to simply accept that > these people know what they are doing; ICANN must document it, ICANN must > inquire whether some of the decisions are made on public-policy > assumptions (in which case "the public" needs to become a party to those > decisions). that's an interesting view. i'm not sure i don't share it! but that's not how things work now, or how things have ever worked, and i'm shocked that karl of all people would want to see ICANN's mission "creep" in this way. > Considering that we know that there would be no ill effects to adding > even a hundred new top level domains, one has to wonder at the degree of > automatic deference (deference amounting to an institutional decision to > be blind) to the deployment of anycast as compared to the hyper detailed > inquiry into matters even as irrelevant as the pronouncability in English > of a few proposed new top level domains. well, in my role as a root operator i don't care about content either way, and even as an internet citizen i don't have strong views about adding TLDs (beyond what i wrote in http://sa.vix.com/~vixie/bad-dns-paper.pdf that is). but i can tell the difference between a user-visible change that will affect the internet's financial and information economy, such as adding TLD's, as opposied to an operator-visible change that users won't even notice and which creates no new business opportunities. one of those, and i really do mean only one of them, is in ICANN's ballywick. > In addition, an argument could well be made that anycast violates the > end-to-end principle. For instance, it's hard, or impossible, to > maintain a TCP connection that spans a routing change that sunsets one > anycast partner and sunrises another. i suspect that concerns of this kind were the main reason why the rootops waited to see several years of results from nominum's and ultradns's use of dns anycast before doing widescale anycast. in fact, one concern learned by watching nominum and ultradns led to the namespace piracy known as either HOSTNAME.BIND or ID.SERVER (depending on the age of the software). all of this was in class CHAOS of course. but widescale anycast would have been impractical without this extension. as to karl's end-to-end argument, anyone using a hash-based load balancer, including Stupid OSPF Tricks, for local load balancing would be subject to the same issues. it is therefore very notable that DNS TCP sessions are short-lived, and that the "end" can change identities with radically high frequencies, and there is no observed impact on network load or likelihood of retrieving a correct and useful answer. > ... > But you miss the point - the deployment of anycast for root servers was a > bold operational decision. It was a decision made by the root server > operators alone, without ICANN. the implied social contract for ISC as a "volunteer" rootop is that we will serve the data, the whole data, and only the data provided to us by IANA, and that we will use our (considerable) best efforts to serve it to the greatest possible number of DNS initiators with the lowest latency and lowest error rate we can arrange. this is all the original IANA asked of us, and the current IANA has not (yet?) complained about our performance. whether it's done with anycast, or with smoke signals, or with one's complement vs. two's complement arithmetic, is a purely local affair. > ICANN's obligation is to guarantee to the public the stability of DNS at > the root layer. i disagree... > ICANN's failure to engage in the issue of anycast > deployment was simply and clearly and abandonment of ICANN's > responsibilities. ...which makes this statement, to me, a nonsequitur. > > Anycast may even have preceded the creation of ICANN > > Yes, anycast has been around for a long time. Multicast, NATs, and OSI > all also preceded the creation of ICANN. But does that mean that ICANN > should freely and and without question allow the deployment of those > technologies for DNS root servers? use of anycast for root name service did indeed predate ICANN's existence. > > >I have serious doubts that ICANN will be able to meet its obligations > > >under the most recent terms of the oft-amended Memorandum of Understanding > > >between ICANN and the Department of Commerce. I see no sign that the DNS > > >root server operators or the RIRs are going to allow themselves to become > > >dependencies of ICANN and to allow their decisions to be superseded by > > >decisions of ICANN's Board of Directors. > > > > they don't need to become "dependencies" for this process to work indeed not. > Either ICANN has the final authority to dictate decisions to the root > server operators and RIRs or it does not. If ICANN does not then ICANN > has simply abandoned its responsibilities to the root server operators > and the RIRs. this kind of black-and-white analysis is too truncative of information to give us any insight. if ICANN could not get what it wanted from a rootop then it would have recourse, called "redelegation". this would be a last resort and very expensive for all parties concerned. but there's recourse, even if it's probably not what you mean by "final authority." there is no final authority in the sense that i think you mean, and can never be. (does karl think anyone outside china has final authority over what Google will show as its results to chinese web users when taiwan is involved? and that's just for starters..) > "Coordination" is a weasel word. coordination is as good as it gets, and anyone who has a god ought to pray that we can get it and keep on getting more of it. > Either ICANN has the authority to > make a guarantee of internet stability to the community of internet users > or it does not. that is a false dichotomy. on the internet there can be no dictatorship since anyone who wants to dig their own sandbox can just go out and do that. therefore coordination and voluntary participation is really all we can ever hope for, and i sit here right now, hoping for it, and hoping for more of it. > As I read your comments you seem to be saying that ICANN > does not have that authority. If that is the case, I can only ask, why > should be have an ICANN if it is simply a toothless bureaucracy whose job > is simply to stand by and let other more competent bodies made final > decisions. "tooth" is a contextual term. there is much good that ICANN can do, but it will never be the "authority" karl seems to be envisioning here. > ... > ICANN can be merely a "coordinator" if it wants. But to do so it needs to > stop trying to deceive the public that it is a player and start being > truthful that its role is merely that of a cheerleader. that's a straw man argument. coordination is not a definitionally toothless activity. consider the IEEE802 48-bit address space. i don't think the coordinating body would sue a manufacturer who started minting their own prefixes, and in that sense there is no "final authority." however, the coordinator's will would reign supreme in the long run, even without the "authority" karl seems to be questing for. > Harry Truman was famous for his desk plaque that said "The buck stops > here." But in the land of ICANN it is clear that the ultimate > responsibility is not ledged in ICANN; it is in the hands, good will, and > expertise of the root server operators and the RIRs. At the present time > those hands are competent, the will is good, and the expertise great. > But in the absence of clear ultimate authority in ICANN, things could > change leaving the internet community vulnerable and without protection. i guess what karl has shown here is that on the internet there is no buck or that it doesn't stop anywhere or some combination thereof. -- Paul Vixie
- AW: IETF58 - Network Facts Hans Peter Dittler
- national security jfcm
- RE: national security jfcm
- Re: national security Iljitsch van Beijnum
- Re[2]: national security Anthony G. Atkielski
- Re: Re[2]: national security Iljitsch van Beijnum
- Re: national security Jari Arkko
- Re[4]: national security Anthony G. Atkielski
- Re: national security Paul Vixie
- Re[2]: national security Anthony G. Atkielski
- Re: national security Jaap Akkerhuis
- Re: Re[2]: national security Spencer Dawkins
- Re[4]: national security Donald Eastlake 3rd
- Re: national security John Kristoff
- Re: Re[2]: national security Valdis.Kletnieks
- Re: Re[4]: national security Iljitsch van Beijnum
- Re[4]: national security Anthony G. Atkielski
- Re[5]: national security Anthony G. Atkielski
- Re[4]: national security Anthony G. Atkielski
- Re[6]: national security Anthony G. Atkielski
- Re: Re[4]: national security Valdis.Kletnieks
- Re[6]: national security Anthony G. Atkielski
- Re: national security jfcm
- Re[2]: national security jfcm
- Re[3]: national security Anthony G. Atkielski
- Re: Re[3]: national security Valdis.Kletnieks
- Re[3]: national security jfcm
- Re: Re[3]: national security jfcm
- Re: Re[3]: national security John C Klensin
- Re: national security Paul Robinson
- Re: national security vinton g. cerf
- Re: national security Karl Auerbach
- Re: national security vinton g. cerf
- Re: national security Karl Auerbach
- Re: national security vinton g. cerf
- Re: Re[3]: national security jfcm
- Re: national security vinton g. cerf
- Re: national security jfcm
- Re: national security Bill Manning
- Re: national security Paul Vixie
- Re: national security jfcm
- Re: national security Dean Anderson
- Re: national security Valdis.Kletnieks
- Re: national security Karl Auerbach
- Re: national security J-F C. (Jefsey) Morfin
- Re: national security Karl Auerbach
- Re: national security Masataka Ohta
- Re: national security vinton g. cerf
- Re: national security Paul Vixie
- Re[2]: national security Philip J. Nesser II
- Re: national security Michael H. Lambert
- Re: national security John C Klensin
- Re: national security jfcm
- Re: national security Michael Froomkin - U.Miami School of Law
- IPv6 addressing limitations (was "national securi… Keith Moore
- Re: IPv6 addressing limitations (was "national se… Anthony G. Atkielski
- Re: IPv6 addressing limitations (was "national se… Keith Moore
- Re: IPv6 addressing limitations (was "national se… Iljitsch van Beijnum
- Re: Re[6]: national security Kurt Erik Lindqvist
- Re: national security Kurt Erik Lindqvist
- Re: Re[3]: national security Kurt Erik Lindqvist
- Re: IPv6 addressing limitations (was "national se… Iljitsch van Beijnum
- Re[2]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re[2]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re[8]: national security Anthony G. Atkielski
- Re: IPv6 addressing limitations (was "national se… Masataka Ohta
- Re: national security Franck Martin
- Re: national security Kurt Erik Lindqvist
- Re: IPv6 addressing limitations (was "national se… Bob Hinden
- Re[2]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re: national security Dean Anderson
- Re: Re[2]: IPv6 addressing limitations (was "nati… Iljitsch van Beijnum
- Re[4]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re: Re[4]: IPv6 addressing limitations (was "nati… Valdis.Kletnieks
- Re: IPv6 addressing limitations (was "national se… Masataka Ohta
- Re[6]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re: IPv6 addressing limitations (was "national se… Masataka Ohta
- Re[2]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re: IPv6 addressing limitations (was "national se… jfcm
- Re: national security jfcm
- Re: national security jfcm
- Re: national security Kurt Erik Lindqvist
- Re: national security Kurt Erik Lindqvist
- Re: IPv6 addressing limitations (was "national se… Masataka Ohta
- Re: IPv6 addressing limitations (was "national se… Masataka Ohta
- Re: national security Franck Martin
- Re: national security Franck Martin
- Re: national security Paul Vixie
- Re: national security Dean Anderson
- Re: national security jfcm
- Re: national security Franck Martin
- Re: national security Kurt Erik Lindqvist
- Re: IPv6 addressing limitations (was "national se… Masataka Ohta
- Re[2]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re[2]: IPv6 addressing limitations (was "national… Anthony G. Atkielski
- Re: national security Iljitsch van Beijnum
- Re: Re[3]: national security jfcm
- Re: national security Dean Anderson
- Re: Re[3]: national security John C Klensin
- Re: Re[3]: national security Kurt Erik Lindqvist
- Re: national security Matt Larson
- Re: national security jfcm
- Re: national security Iljitsch van Beijnum
- Re: national security Harald Tveit Alvestrand
- Re: Re[3]: national security jfcm
- Re: national security jfcm
- Re: national security Dean Anderson
- Re: Re[3]: national security vinton g. cerf
- Re: national security Iljitsch van Beijnum
- Re: national security Jaap Akkerhuis
- Re: national security Bill Manning
- Re: national security Paul Vixie
- Re: national security Iljitsch van Beijnum
- Re: national security Franck Martin
- Re: Re[3]: national security jfcm
- Re: national security Dean Anderson
- Re: national security Joe Abley
- Re: national security Joe Abley
- Re: national security Masataka Ohta
- Re: national security Masataka Ohta
- Re: national security Joe Abley