Re: national security
On 8 Dec 2003, at 15:25, Masataka Ohta wrote: I'm afraid F servers does not follow the intention of my original proposal of anycast root servers. This may well be the case (I haven't read your original proposal). Apologies if I gave the impression that I thought to the contrary. Finally, using only a single address, F, does not provide any real robustness. Fortunately there are twelve other root nameservers. Joe
Re: national security
Joe Abley; I'm afraid F servers does not follow the intention of my original proposal of anycast root servers. This may well be the case (I haven't read your original proposal). The IDs have expired. I'm working on a revised one. Apologies if I gave the impression that I thought to the contrary. No, no need of apologies. Finally, using only a single address, F, does not provide any real robustness. Fortunately there are twelve other root nameservers. But, one should have one's own three root servers with different addresses. Masataka Ohta
Re: national security
Joe Abley; I don't think this is an oversight, I'm pretty sure this was intentional. However, since in practice the BGP best path selection algorithm boils down to looking at the AS path length and this has the tendency to be the same length for many paths, BGP is fairly useless for deciding the best path for even low ambition definitions of the word. For the service aspects of F we're more concerned with reliability than performance. Recursive resolvers ask questions to the root relatively infrequently, and the important thing is that they have *a* path to use to talk to a root server, not necessarily that they are able to automagically select the instance with the lowest instantaneous RTT (and continue to find a root regardless of what damage might exist in the network elsewhere). I'm afraid F servers does not follow the intention of my original proposal of anycast root servers. The intention is to allow millions or trillions of root servers. While you can rely on someone else's root server with the BGP best path selection, it is a lot better to have your own root server. In addition, it is not necessary to have any hierarchy between anycast servers at all, as long as there is a single source of information. Hierarchy may be useful if a single entity manages all the anycast root servers. However, you can manage your own. Finally, using only a single address, F, does not provide any real robustness. Masataka Ohta
Re: national security
On 7 Dec 2003, at 07:21, Iljitsch van Beijnum wrote: I don't think this is an oversight, I'm pretty sure this was intentional. However, since in practice the BGP best path selection algorithm boils down to looking at the AS path length and this has the tendency to be the same length for many paths, BGP is fairly useless for deciding the best path for even low ambition definitions of the word. For the service aspects of F we're more concerned with reliability than performance. Recursive resolvers ask questions to the root relatively infrequently, and the important thing is that they have *a* path to use to talk to a root server, not necessarily that they are able to automagically select the instance with the lowest instantaneous RTT (and continue to find a root regardless of what damage might exist in the network elsewhere). For example, local routing policies might lead a resolver in South Africa to select a path to 192.5.5.0/24 in California over the node in Johannesburg under normal operation. We hope, though, that in the event that the resolver becomes isolated from California, a path exists to Johannesburg which will allow F-root service to continue reliably (and, for example, to allow names under ZA corresponding to local, reachable, services to continue to resolve). The selection of anycast node has more importance when you consider the other, non-service role of F, which is to sink attack traffic: we'd like to sink attack traffic as close to its source as possible. Fortunately the rough-hewn and clumsy hammer of BGP path selection seems good enough to attempt to attain that goal right now, since our routing policy generally leads people to favour a local node (peer) over a global node (transit) through application of pre-existing routing policy. This is a natural result of the common truth that peering paths are cheaper than transit ones. Joe
Re: national security
On 8 Dec 2003, at 10:14, Dean Anderson wrote: Also, anycasting doesn't work for TCP. Would you care to elaborate on "doesn't work"? I agree. It is easy to create a blackhole, or even a DDOS on an anycast address. It is much harder to DDOS 600 IP addresses spread through some 200 countries. It's arguably easier for a distributed attack to cause degrade the availability of a service bound to a unicast-reachable address than an anycast-reachable address. The former will tend to collect traffic along a progressively narrow funnel until congestion occurs; with an anycast target the pain is distributed over a set of funnels, and in general not all will experience the same degree (or any) pain, depending on the distribution and behaviour of the attacking nodes. In a non-distributed attack anycast victims fare subtantially better (since non-select anycast targets are unaffected, and only suffer topological fallout from the node sinking the attack traffic). Joe
Re: national security
On Sun, 7 Dec 2003, Iljitsch van Beijnum wrote: > On 6-dec-03, at 23:04, Dean Anderson wrote: > > >> I don't think this stealth business is a very good idea. If you want a > >> root servers somewhere, use anycast. That means importing BGP problems > >> into the DNS, which is iffy enough as it is. > > > That seems to argue against anycast... > > If there were 65 actual root servers, I would very much prefer the > situation where I could contact each and any one of those, rather than > a subset of 13 that are chosen by a protocol that was NOT designed for > this. (Selecting the "best" path is pretty much an after thought in > BGP: the RFC doesn't even bother giving suggestions on how to do this.) > But the DNS protocol has problems supporting 65 (or 45 or even 25) > individual root server addresses, it's either no more than around 13 > individual servers or a larger number of anycasted ones. I don't need any more than 13, and I would, were I director of some country's telecom, much prefer that I had several within my borders. So that argues for at least 3 * 190, or about 600+ root servers worldwide (large countries like the US and China having more than 3). Anycasting probably isn't going to easily scale that large, and requires more complexity, which makes thinks much harder at the lower end. Also, anycasting doesn't work for TCP. > I don't have a problem with some controlled anycasting, but the root > operators shouldn't go overboard. For instance, the .org zone is only > served by two addresses, which are then anycast. There have been > reports from people who were unable to reach either of these addresses > when there was some kind of reachability problem. The people managing > the .org zone are clearly lacking in responsibility by limiting the > number of addresses from which the zone is available without any good > reason. A much larger number of root servers also tends to avoid this problem, and localize problems. As someone pointed out, it is fast becoming the case that no one has enough knowledge of what's happening to understand the problems. Obviously, the solution is to make sure that problems are localized, and can be partitioned without bringing down the global or national infrastructure. > The situation that must be avoided is where all or most root servers > seem to be in the same location from a certain viewpoint, as a BGP > black hole towards that location will then make them all unreachable. I > would prefer it if several root servers weren't anycast at all, just to > be on the safe side. I agree. It is easy to create a blackhole, or even a DDOS on an anycast address. It is much harder to DDOS 600 IP addresses spread through some 200 countries. > > Its the same "deal" as distributing the "official" root nameserver > > updates. Some people don't pay attention to this until they can't get > > nameservice to work. Its a problem, but it isn't made better or worse. > > The difference is that official root servers are updated through the > official channels, which I have no reason to distrust. Having a stealth > root server means you can't listen to the real root servers anymore > (because then you'd have a 13/14th chance of learning the list of > official root servers and forgetting about the stealth one when a > resolver starts) which is a big fat single point of failure. Err, no. The "root servers", from the point of view of a person in a given country, is the list given by the countries' telecom authority. Just like the SS7 point codes for that country. There is no reason to distrust the FCC. For the United States, they are the "official authority" The official contents of the root zone is controlled by an international commission. This would be distributed to the root server operators by some agreed channel: FTP, Certified Letter, Diplomatic pouch, or carrier pidgeon ;-) The root zone is not very big. It probably could be distributed by carrier pidgeon. Exaggeration and humor aside, distribution is not a big problem. > >> So I have to trust these fake roots a 100%: > > > They aren't exactly fake. They are just not listed by the "dig . ns" > > query, so they aren't technically authoritative. Though, I suppose they > > could be--I'm just assuming they aren't. > > Ok, let's not debate the word "fake". > > > As far as trust goes, since they > > are run by your government, yes, you can trust them. > > Their intentions, maybe. Their DNS operating prowess, I don't think so. Oh please. Root server operation is not that difficult. The government is responsible to find someone to run it competently. But if their operators are incompetent, they only affect that country. They would not be able to affect other countries by their incompetence. Other countries do not trust the US (to run things competently, fairly, whatever) The solution (if possible) is to distribute the responsibilty to each country, so that mal intent or simple inco
Re: national security
On Sat, 2003-12-06 at 10:18, Iljitsch van Beijnum wrote: On 5-dec-03, at 17:16, Dean Anderson wrote: > Indeed, this is what they do when the agree to put the "national" root > nameservers in their own nameserver root configs. It is far easier to > have per-country stealth root slaves than it is to make every > nameserver > the stealth slave of every other domain in that country. I don't think this stealth business is a very good idea. If you want a root servers somewhere, use anycast. That means importing BGP problems into the DNS, which is iffy enough as it is. But for a small network island just having a single set of resolvers and make sure those have all the needed information isn't a huge deal. Obviously such a place doesn't have a huge number of ISPs so the number of DNS servers will be quite limited in the first place. I'm a little bit confused here, but I'm starting to get the ideas... In the Pacific Islands: http://map.sopac.org/tiki/tiki-map.phtml?mapfile=pacific.map&zoom=1&size=400&Redraw=Redraw&minx=110&miny=-67.6&maxx=230&maxy=52.6&Topography=1&EEZ=1&12+miles+zone=1&Country+Names=1 Countries there have about in general 1000 Internet users, and one ISP usually some 2 or 3 max... I think what we need to really solve this is a redesign of the DNS, as the way it is now it breaks a fundamental design principle of the internet: when two nodes have reachability, they should be able to communicate, regardless of what else is (un)reachable. (I'm not volunteering, though.) Are we going to something like the Kaza protocol (or peer sharing). The DNS know their environement and other DNS around and get the ones that are available to solve ANY query? I've been in a situation where root servers where unavailable for the better part of a day, and it's pretty frustrating to see your resolver cache disappear over tiem so you can no longer reach places to which you still have connectivity. Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard
Re: national security
> > ... oversight. > > I don't think this is an oversight, I'm pretty sure this was > intentional. However, since in practice the BGP best path selection > algorithm boils down to looking at the AS path length and this has the > tendency to be the same length for many paths, BGP is fairly useless > for deciding the best path for even low ambition definitions of the word. that depends on what you want to use it for. not all routes are transitted. for f-root we do limited-horizon peering in all locations outside the SFbay area, and bgp's path selection machinery almost never has any work to do. i'm a little more worried about j-root which receives transit everywhere and is somewhat at the mercy of not only its own ISP's but other ISP's as well. however, "diversity is good". i'm glad that different roots are different. > >> (And some IPv6 roots wouldn't be bad either.) > > > there are several. see www.root-servers.org. (now if we can just > > advertise.) > > Just for fun, I cooked up a named.root file with only those IPv6 addresses > in it. This seems to confuse BIND such that its behavior becomes very > unpredictable. hmmm. that configuration works fine for me here. > And only 2 of the 4 v6 addresses are reachable as one isn't > advertised at all those issues are probably going to influence which RR's go into the root-servers.net zone and the named.cache files. > and the other as a /48 which are heavily filtered. not according to the RIR's. at least in ARIN's case the micro-allocation policy seems to have met with approval by the membership, which is why we're using a /48 for f-root. if this is a bad idea because all kinds of ISP's won't be accepting such routes even though they seem to be grouped together in a place where a different prefix filter could be employed, then you ought to tell the RIR's this and get the microallocation policies altered or torn down. (i personally don't think a /35 route with just one host in it makes much sense, but i guess ipv6 has a lot of space to burn on stuff like this.)
Re: national security
On 7-dec-03, at 2:26, Paul Vixie wrote: ... (Selecting the "best" path is pretty much an after thought in BGP: the RFC doesn't even bother giving suggestions on how to do this.) congradulations, you're the millionth person to think that was an oversight. I don't think this is an oversight, I'm pretty sure this was intentional. However, since in practice the BGP best path selection algorithm boils down to looking at the AS path length and this has the tendency to be the same length for many paths, BGP is fairly useless for deciding the best path for even low ambition definitions of the word. I don't have a problem with some controlled anycasting, but the root operators shouldn't go overboard. i don't think you will ever meet a more conservative bunch of people, so, OK. Excellent. For instance, the .org zone is only served by two addresses, which are then anycast. There have been reports from people who were unable to reach either of these addresses when there was some kind of reachability problem. The people managing the .org zone are clearly lacking in responsibility by limiting the number of addresses from which the zone is available without any good reason. see the icann agreements to find out how much of this was ultradns's choice. Hm, nothing about this in http://www.icann.org/tlds/agreements/org/. In fact, it talks about a maximum of 13 servers in some places. Not that it matters much who's bright idea it was. (And some IPv6 roots wouldn't be bad either.) there are several. see www.root-servers.org. (now if we can just advertise.) Just for fun, I cooked up a named.root file with only those IPv6 addresses in it. This seems to confuse BIND such that its behavior becomes very unpredictable. And only 2 of the 4 v6 addresses are reachable as one isn't advertised at all and the other as a /48 which are heavily filtered.
Re: national security - proposed follow-up
jfcm wrote: [..] > I suggest we > start a specialized WG with a clean shit study charter. Well you've come to the right place! Don't get it much cleaner than around here, that's for sure. gja
Re: national security
[EMAIL PROTECTED] (Iljitsch van Beijnum) writes: > ... (Selecting the "best" path is pretty much an after thought in > BGP: the RFC doesn't even bother giving suggestions on how to do this.) congradulations, you're the millionth person to think that was an oversight. > I don't have a problem with some controlled anycasting, but the root > operators shouldn't go overboard. i don't think you will ever meet a more conservative bunch of people, so, OK. > For instance, the .org zone is only served by two addresses, which are > then anycast. There have been reports from people who were unable to > reach either of these addresses when there was some kind of reachability > problem. The people managing the .org zone are clearly lacking in > responsibility by limiting the number of addresses from which the zone is > available without any good reason. see the icann agreements to find out how much of this was ultradns's choice. > The situation that must be avoided is where all or most root servers > seem to be in the same location from a certain viewpoint, as a BGP > black hole towards that location will then make them all unreachable. I > would prefer it if several root servers weren't anycast at all, just to > be on the safe side. that's exactly what's likely to continue happening. diversity is good. > (And some IPv6 roots wouldn't be bad either.) there are several. see www.root-servers.org. (now if we can just advertise.) > You missed the point in one of my previous messages: there is no > officially supported way to do zone transfers for the root. This can stop > working at any time. indeed, it's been downhill ever since 10.0.0.53 went away. now it's chaos. -- Paul Vixie
Re: national security
% % have we figures about the frequency of changes in the root file? % % The serial # changes twice a day. The contents hardly as far as I % can see. other contents change about three times a week. % jaap % % PS. I wonder how soon someone will tell me I shouldn't be feeding ... you shouldn't, not w/out a permit. :) --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: national security
have we figures about the frequency of changes in the root file? The serial # changes twice a day. The contents hardly as far as I can see. Always wanted to check that, but since it is of interest on a substantial duration never did. It is very easy to check. Just pull over the zone file at a regulary base and do a diff. The only serious figure I have is that ICANN decided that three months and half to update major ccTLD secondaries was OK (after KPNQuest). Document your figures. Note that ns.eu.net was never dead, so I wonder what the relevance is anyway. jaap PS. I wonder how soon someone will tell me I shouldn't be feeding ...
Re: national security
On 6-dec-03, at 23:04, Dean Anderson wrote: I don't think this stealth business is a very good idea. If you want a root servers somewhere, use anycast. That means importing BGP problems into the DNS, which is iffy enough as it is. That seems to argue against anycast... If there were 65 actual root servers, I would very much prefer the situation where I could contact each and any one of those, rather than a subset of 13 that are chosen by a protocol that was NOT designed for this. (Selecting the "best" path is pretty much an after thought in BGP: the RFC doesn't even bother giving suggestions on how to do this.) But the DNS protocol has problems supporting 65 (or 45 or even 25) individual root server addresses, it's either no more than around 13 individual servers or a larger number of anycasted ones. I don't have a problem with some controlled anycasting, but the root operators shouldn't go overboard. For instance, the .org zone is only served by two addresses, which are then anycast. There have been reports from people who were unable to reach either of these addresses when there was some kind of reachability problem. The people managing the .org zone are clearly lacking in responsibility by limiting the number of addresses from which the zone is available without any good reason. The situation that must be avoided is where all or most root servers seem to be in the same location from a certain viewpoint, as a BGP black hole towards that location will then make them all unreachable. I would prefer it if several root servers weren't anycast at all, just to be on the safe side. (And some IPv6 roots wouldn't be bad either.) But for a small network island just having a single set of resolvers and make sure those have all the needed information isn't a huge deal. Obviously such a place doesn't have a huge number of ISPs so the number of DNS servers will be quite limited in the first place. Its the same "deal" as distributing the "official" root nameserver updates. Some people don't pay attention to this until they can't get nameservice to work. Its a problem, but it isn't made better or worse. The difference is that official root servers are updated through the official channels, which I have no reason to distrust. Having a stealth root server means you can't listen to the real root servers anymore (because then you'd have a 13/14th chance of learning the list of official root servers and forgetting about the stealth one when a resolver starts) which is a big fat single point of failure. So I have to trust these fake roots a 100%: They aren't exactly fake. They are just not listed by the "dig . ns" query, so they aren't technically authoritative. Though, I suppose they could be--I'm just assuming they aren't. Ok, let's not debate the word "fake". As far as trust goes, since they are run by your government, yes, you can trust them. Their intentions, maybe. Their DNS operating prowess, I don't think so. Since these zones don't change much, they can be updated by zone transfers, You missed the point in one of my previous messages: there is no officially supported way to do zone transfers for the root. This can stop working at any time. or by other official distribution. Which I don't think there is either. I think what we need to really solve this is a redesign of the DNS, as the way it is now it breaks a fundamental design principle of the internet: when two nodes have reachability, they should be able to communicate, regardless of what else is (un)reachable. (I'm not volunteering, though.) I agree completely, but I don't think anything needs to change other than management of existing services. How is that agreeing with my point that we need a redisign (if we want to solve this)???
Re: national security
I think there are three confluences which tend to support the notion of national root nameservers: 1) Root Server scalability 2) Foriegn distrust of US control on the internet 3) Isolation due to technical or political issues. On Fri, 5 Dec 2003, Iljitsch van Beijnum wrote: > On 5-dec-03, at 17:16, Dean Anderson wrote: > > > Indeed, this is what they do when the agree to put the "national" root > > nameservers in their own nameserver root configs. It is far easier to > > have per-country stealth root slaves than it is to make every > > nameserver > > the stealth slave of every other domain in that country. > > I don't think this stealth business is a very good idea. If you want a > root servers somewhere, use anycast. That means importing BGP problems > into the DNS, which is iffy enough as it is. That seems to argue against anycast... > But for a small network island just having a single set of resolvers and > make sure those have all the needed information isn't a huge deal. > Obviously such a place doesn't have a huge number of ISPs so the number > of DNS servers will be quite limited in the first place. Its the same "deal" as distributing the "official" root nameserver updates. Some people don't pay attention to this until they can't get nameservice to work. Its a problem, but it isn't made better or worse. > > Yet a stealth root is comparably easy: You just tell your nameserver > > operators to configure in the IP addresses for your national root > > servers, instead of the "official" root servers. > > So I have to trust these fake roots a 100%: not only that they don't > change the root zone, but also that they're always up to date and never > down. Tall order. An official anycast setup is much better: updates are > done the way they should be (last year when I wrote an article I > checked this: there is no policy anywhere on access to the root > zonefile. You can download it through FTP or even do a zone transfer in > a few places, but nothing official) and when your local root clone is > down there should be at least 12 others elsewhere. They aren't exactly fake. They are just not listed by the "dig . ns" query, so they aren't technically authoritative. Though, I suppose they could be--I'm just assuming they aren't. As far as trust goes, since they are run by your government, yes, you can trust them. Since these zones don't change much, they can be updated by zone transfers, or by other official distribution. As far as reliability goes, that's why you have more than one. And you scale it just like any other part of infrastructure. Anycast doesn't make this job easier--it makes it harder. An Anycast server can't easily do a zone transfer from itself. This is just another complication of running anycast. Anycast is just a means of scaling up server infrastructure. There are other methods of scaling. Anycast doesn't particularly match the political interests. I also don't conceive of a single national stealth server. I assume that they may be many. Probably at least 2, and certainly more depending on the size of the country. The US would probably have a lot. > > Indeed, it is probably sensible for ISPs to do the same. This would > > keep things working internally in the event of an effective isolation > > due to a DOS attack, for example. > > I think what we need to really solve this is a redesign of the DNS, as > the way it is now it breaks a fundamental design principle of the > internet: when two nodes have reachability, they should be able to > communicate, regardless of what else is (un)reachable. (I'm not > volunteering, though.) I agree completely, but I don't think anything needs to change other than management of existing services. The internet has to continue to work when it is partitioned, regardless of the reasons for the partitioning. Those reasons could be technical, or political. And the internet should then just work when its glued back together again. But address and DNS delegations are hierarchical, so there is not reason that this can't be done. > I've been in a situation where root servers where unavailable for the > better part of a day, and it's pretty frustrating to see your resolver > cache disappear over tiem so you can no longer reach places to which > you still have connectivity. This is fixed by stealth slaves at large ISPs. Small ISPs, if isolated probably don't have enough customers to really care about getting to the other customers. But this might not be true for large ISPs, and might not be true of islands and small countries. A small island in the Pacific might have several ISPs but only one underwater cable. If the cable is cut, they could be isolated for a while. But there is no reason they shouldn't be able to get to other sites that are on the island.
Re: national security - proposed follow-up
On 03:13 06/12/03, Harald Tveit Alvestrand said: Jefsey, which "we" are you speaking on behalf of? --On 27. november 2003 23:20 +0100 jfcm <[EMAIL PROTECTED]> wrote: While parallel issues start being discussed and better understood at WSIS, we have next week a meeting on Internet national security, sovereignty and innovation capacity. Dear Harald, Sorry only sent to you by mistake. Question was public. Response must also be. I was asked and documented that and invited people interested and having French to join or to ask for the preparatory document. This is of lesser interest now: the outcome are. They will probably published with the engaged actions after the next meeting we have early January. I was writing you a mail when I received yours. I will swicth to it now. ___ My vision of the network and international relations is NOT the vision of ICANN, IAB, IETF. Everyone in here understood that. In a way, it is the vision that 189 Govs are going to publish in Geneva next week, giving responsiblity to ITU (unless the whole preparatory documents are scrapped). I welcome this. But with a big if. If an "I" sector is created for the Information/Internet (highest) layers. I started an action six months ago (http://i-sector.org) to create an ITU Focus Group that will use the inter-WSIS period (2004-2005) to make that Sector voted by the second Submit. This is not a small target, but the processus is simple : to write, document and propose a charter (or ToRs: Terms of Reference) for a Focus (Working) Group to Mr. Zao. The letter is to be signed by one Member. This permits us (internet community) to keep the initiative. Or we will be discussed as part of ITU-T by Govs. This kind of thing takes time and do not call for mails, but for work, personal direct links, time. Such a Focus Group will be open to everyone serious and work on the reasons why to have an I-Sector and how. It should start with a preparatory meeting in Geneva on the aftermath of the WSIS and gather the largest number of members from the Internet governance (you may object but no to participate to that kind of effort would be a mistake). To set-up a professionnal, Gov accepted, industry trusted, civil society supported, world wide governance for the WSIS network to develop and get approved. The important point is to understand what is IETF in this, where IETF wants to fit (and ICANN) and which support it may get and credentials it may provide. This is going to hurt many one's pride: we are to accept that WSIS declarations are the World's Project Description and the World's Network Specs for the World's higher layers system. You may dispute it, but this is what it is and this is the way it is going to be plaid. These loayers currently uses the IETF solutions and the ICANN network management. But it is to be renewed and the decision is, de facto, delegated to a "users" consensus advized by ITU. So IETF/ICANN have two tasks: 1. to make the current system better work along the customer's requirments to keep in tune, 2. to win the customer's trust and approval for an evolution of the system towards a total redesign that the US and other Govs or Corporations have otherwise already decided and engaged. To try to add some last minute competitve edge to IETF (sometimes works), in having the resolutions made more favorable, I started the "National Security" thread (something they could fully understand) and made sure that people I know, who could make a few words changed in the final declarations, would get a daily copy from it. So they might build by themselves an opinion on IETF and ICANN, from the horse's mouth. Today, due to the importance of the matter for our "customer", I suggest we start a specialized WG with a clean shit study charter. What to propose to transition to a clearly modelized and standardized open secure network technology that will internet with every communications systems and support a world wide continuity of services to the users and to the users relations. Under terms of quality, stability, innovation capacity, operational standard, costs, etc. that will match their expectations and win the trust of banks, industries, critical infrastructure managers, defense, airlines, police, cities, users from 189 countries, with a governance formula respecting the digital sovereignty and independence of each participating Gov and nation. If we do not do it in here, now, competitively, I am sorry, but we should all understand that it will be carried elsewhere. We know the IETF competition: it is also on this list. jfc
Re: national security
Iljitsch, have we figures about the frequency of changes in the root file? Always wanted to check that, but since it is of interest on a substantial duration never did. The only serious figure I have is that ICANN decided that three months and half to update major ccTLD secondaries was OK (after KPNQuest). thank you. jfc On 23:18 05/12/03, Iljitsch van Beijnum said: Content-Transfer-Encoding: 7bit On 5-dec-03, at 17:16, Dean Anderson wrote: Indeed, this is what they do when the agree to put the "national" root nameservers in their own nameserver root configs. It is far easier to have per-country stealth root slaves than it is to make every nameserver the stealth slave of every other domain in that country. I don't think this stealth business is a very good idea. If you want a root servers somewhere, use anycast. That means importing BGP problems into the DNS, which is iffy enough as it is. But for a small network island just having a single set of resolvers and make sure those have all the needed information isn't a huge deal. Obviously such a place doesn't have a huge number of ISPs so the number of DNS servers will be quite limited in the first place. Yet a stealth root is comparably easy: You just tell your nameserver operators to configure in the IP addresses for your national root servers, instead of the "official" root servers. So I have to trust these fake roots a 100%: not only that they don't change the root zone, but also that they're always up to date and never down. Tall order. An official anycast setup is much better: updates are done the way they should be (last year when I wrote an article I checked this: there is no policy anywhere on access to the root zonefile. You can download it through FTP or even do a zone transfer in a few places, but nothing official) and when your local root clone is down there should be at least 12 others elsewhere. Indeed, it is probably sensible for ISPs to do the same. This would keep things working internally in the event of an effective isolation due to a DOS attack, for example. I think what we need to really solve this is a redesign of the DNS, as the way it is now it breaks a fundamental design principle of the internet: when two nodes have reachability, they should be able to communicate, regardless of what else is (un)reachable. (I'm not volunteering, though.) I've been in a situation where root servers where unavailable for the better part of a day, and it's pretty frustrating to see your resolver cache disappear over tiem so you can no longer reach places to which you still have connectivity.
Re: national security
Jefsey, which "we" are you speaking on behalf of? --On 27. november 2003 23:20 +0100 jfcm <[EMAIL PROTECTED]> wrote: While parallel issues start being discussed and better understood at WSIS, we have next week a meeting on Internet national security, sovereignty and innovation capacity.
Re: national security
On 5-dec-03, at 17:16, Dean Anderson wrote: Indeed, this is what they do when the agree to put the "national" root nameservers in their own nameserver root configs. It is far easier to have per-country stealth root slaves than it is to make every nameserver the stealth slave of every other domain in that country. I don't think this stealth business is a very good idea. If you want a root servers somewhere, use anycast. That means importing BGP problems into the DNS, which is iffy enough as it is. But for a small network island just having a single set of resolvers and make sure those have all the needed information isn't a huge deal. Obviously such a place doesn't have a huge number of ISPs so the number of DNS servers will be quite limited in the first place. Yet a stealth root is comparably easy: You just tell your nameserver operators to configure in the IP addresses for your national root servers, instead of the "official" root servers. So I have to trust these fake roots a 100%: not only that they don't change the root zone, but also that they're always up to date and never down. Tall order. An official anycast setup is much better: updates are done the way they should be (last year when I wrote an article I checked this: there is no policy anywhere on access to the root zonefile. You can download it through FTP or even do a zone transfer in a few places, but nothing official) and when your local root clone is down there should be at least 12 others elsewhere. Indeed, it is probably sensible for ISPs to do the same. This would keep things working internally in the event of an effective isolation due to a DOS attack, for example. I think what we need to really solve this is a redesign of the DNS, as the way it is now it breaks a fundamental design principle of the internet: when two nodes have reachability, they should be able to communicate, regardless of what else is (un)reachable. (I'm not volunteering, though.) I've been in a situation where root servers where unavailable for the better part of a day, and it's pretty frustrating to see your resolver cache disappear over tiem so you can no longer reach places to which you still have connectivity.
Re: national security
At 05:12 05/12/03, Franck Martin wrote: On Fri, 2003-12-05 at 15:32, jfcm wrote: > Paul, > 1. all this presumes that the root file is in good shape and has not been > tampered. > How do you know the data in the file you disseminate are not polluted > or changed? Because somebody will complain... ;) Dear Franck, I am afraid you are right. This leaves however a few questions such as: 1. what/who does say he is right? 2. he complains to who? 3. and then what? 4. if a decision is taken how the pollution will be corrected? Just waiting for ttl (and may be people or businesses) to die? 5. who will the hurt parties sue? 6. are they insurred? 7. who pays for the insurrance? etc. I understand last time somebody complained, he called Ira Magaziner and they solved the case in calling on Joe Sims and subsequently creating ICANN. jfc
Re: national security
On Fri, 05 Dec 2003, Paul Vixie wrote: > note that f-root, i-root, j-root, k-root, and m-root are all doing anycast > now, and it's likely that even tonga would find that one or more of these > rootops could find a way to do a local install. Apologies for taking this thread perhaps even further off-topic. VeriSign is planning to anycast J root beyond the 13 sites where it is (or will be shortly) co-located with the com/net name servers. Currently under-served areas are particularly appealing as possible locations. Briefly, we'll supply the hardware for a J root instance and manage it if you supply the space, power and bandwidth. No fees are involved. Interested ISPs should please contact me privately. Matt -- Matt Larson <[EMAIL PROTECTED]> VeriSign Naming and Directory Services
Re: national security
Indeed, this is what they do when the agree to put the "national" root nameservers in their own nameserver root configs. It is far easier to have per-country stealth root slaves than it is to make every nameserver the stealth slave of every other domain in that country. When that country is isolated from the rest of the net, (due to single connection failure, multiple connection failure, war, etc), then they still have nameservice for their CCtld and its delegations, and those of whatever other countries they remain connected to. Stealth root slaves are such a far better solution, in terms of configuration, maintenance, and scaling than configuring every nameserver to be a stealth slave of every other domain. Imagine the difficulty of doing that... Even a small country with a few tens of thousands of domains makes that unrealistic. Yet a stealth root is comparably easy: You just tell your nameserver operators to configure in the IP addresses for your national root servers, instead of the "official" root servers. Now all you have to do is keep that set operating, which isn't that hard, and can be done even if the country becomes isolated from the world net, and the official nameservers. Indeed, it is probably sensible for ISPs to do the same. This would keep things working internally in the event of an effective isolation due to a DOS attack, for example. --Dean On Fri, 5 Dec 2003, Iljitsch van Beijnum wrote: > On 5-dec-03, at 1:37, Franck Martin wrote: > > > Finally before a root-server is installed somewhere, someone will do > > an assessment of the local conditions and taylor it adequately. I want > > countries to request installation of root servers, and I know about 20 > > Pacific Islands countries that need root-servers in case their > > Internet link goes dead. > > Might I suggest that there is a much easier way to do this: if the > constituency for such a root server is so small and so homogenous (= > they all share a single link to the rest of the net) then it would be > much simpler for all of these users to simply share a single set of > nameservers, which can then all be primary or secondary for all the > domains used locally. This allows communication to continue even if the > root servers are unreachable AND it allows users to register domain > names under any TLD they like. > > >
Re: national security
On 5-dec-03, at 1:37, Franck Martin wrote: Finally before a root-server is installed somewhere, someone will do an assessment of the local conditions and taylor it adequately. I want countries to request installation of root servers, and I know about 20 Pacific Islands countries that need root-servers in case their Internet link goes dead. Might I suggest that there is a much easier way to do this: if the constituency for such a root server is so small and so homogenous (= they all share a single link to the rest of the net) then it would be much simpler for all of these users to simply share a single set of nameservers, which can then all be primary or secondary for all the domains used locally. This allows communication to continue even if the root servers are unreachable AND it allows users to register domain names under any TLD they like.
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On torsdag, dec 4, 2003, at 23:44 Europe/Stockholm, Franck Martin wrote: > There are now organisations installing root servers in all countries > that want one. I am the CEO of one of those organizations. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP9Ah2qarNKXTPFCVEQL5JQCfWN6CFuYJA+du0Ybc2KXl6/k+qjcAnRF5 pZmB69DEIrq8HRF1X2tERurT =b7ow -END PGP SIGNATURE-
Re: national security
On Fri, 2003-12-05 at 15:32, jfcm wrote: > Paul, > 1. all this presumes that the root file is in good shape and has not been > tampered. > How do you know the data in the file you disseminate are not polluted > or changed? Because somebody will complain... ;) Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard
Re: national security
Paul, 1. all this presumes that the root file is in good shape and has not been tampered. How do you know the data in the file you disseminate are not polluted or changed? 2. where is the best documentation - from your own point of veiw - of a root server organization. thank you jfc At 02:53 05/12/03, Paul Vixie wrote: On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote: > Oh, btw to install a root server, any PC will do, it is not something > difficult as it carries only a couple of hundred records (200 countries > and a few gTLDs), not the millions of a .com. On Fri, 2003-12-05 at 12:16, Suzanne Woolf wrote: > Operationally, this is a dangerous half-truth. It may be the case that > you can run a nameserver that believes it is authoritative for the > root zone and will answer for it in this way. But under real world > conditions (significant numbers of queries, possibility of DDoS or > other attack, etc.) this is far from adequate. [EMAIL PROTECTED] (Franck Martin) writes: > This is not a dangerous half-truth, It has to be demystified. Let's take > the example of a country like Tonga. A simple PC will do for them because > the number of Internet Users there is may be about a 1000 people. With > anycast properly set up only the packet of that country will reach the > local root-server (proximity), so it is unlikely to be under heavy load > with a 1000 of people on the Internet there... my experience differs. when a root name server is present it has to be fully fleshed out, because if it isn't working properly or it falls over due to a ddos or if it's advertising a route but not answering queries, then any other problem will be magnified a hundredfold. doing root name service in a half-baked way is much worse than not doing it at all, since over time the costs of transit to a good server will be less than the costs of error handling and cleanup from having a bad one. moreover, your statement "only the packet(s) of that country will reach the local root server" is presumptive. under error conditions where transit is leaked, such a server could end up receiving global-scope query loads. in our current belt-and-suspenders model, we (f-root) closely monitor our peer routing, AND we are massively overprovisioned for "expected" loads, since a ddos or a transit-leak can give us dramatically "unexpected" loads. if you know someone who is willing to provision a "root" name server without a similar belt and similar suspenders, then please tell them to stop. > Finally before a root-server is installed somewhere, someone will do an > assessment of the local conditions and taylor it adequately. I want > countries to request installation of root servers, and I know about 20 > Pacific Islands countries that need root-servers in case their Internet > link goes dead. > > cf www.picisoc.org if you want to join us... on a connectivity island (which might be in the ocean or it might just be a campus or dwelling), the way to ensure that local service is not disrupted by connectivity breaks is to make your on-island recursive name servers stealth slaves of your locally-interesting zones. in new zealand for example it was the custom for many years to use a forwarding hierarchy where the nodes near the "top" were stealth slaves of .NZ, .CO.NZ, etc. that way if they lost a pacific cable system they could still reach the parts of the internet which were on the new zealand side of the break. using a half-baked root-like server to do the same thing would be grossly irresponsible, both to the local and the global populations. note that f-root, i-root, j-root, k-root, and m-root are all doing anycast now, and it's likely that even tonga would find that one or more of these rootops could find a way to do a local install. (c-root is also doing anycast but only inside the cogent/psi backbone; b-root has announced an intention to anycast, but has not formally launched the programme yet.)
Re: national security
On 5 Dec 2003, Paul Vixie wrote: > my experience differs. when a root name server is present it has to be > fully fleshed out, because if it isn't working properly or it falls over > due to a ddos or if it's advertising a route but not answering queries, > then any other problem will be magnified a hundredfold. It depends on the "problem profile" you working to avoid. > doing root name service in a half-baked way is much worse than not doing > it at all, since over time the costs of transit to a good server will be > less than the costs of error handling and cleanup from having a bad one. This could be true, but irrelevant. It depends on the costs of transit and cleanup. Transit to a remote island could be very expensive, while labor to cleanup any problems might be very cheap. > moreover, your statement "only the packet(s) of that country will reach the > local root server" is presumptive. Not necessarilly. If the country operates a root server that is only accessible from that country, that is, only in the preloaded in the caches of that countries' nameservers, then the 'presumption' is true. The list of root nameservers is determined by the lists that are pre-loaded into other nameservers, not by the 'dig . ns' query on a real root. You could have hundreds of root slaves, but only a small number of truly global root servers without any problems at all. This would probably be a good thing for the global servers. > under error conditions where transit is leaked, such a server could end > up receiving global-scope query loads. in our current > belt-and-suspenders model, we (f-root) closely monitor our peer routing, > AND we are massively overprovisioned for "expected" loads, since a ddos > or a transit-leak can give us dramatically "unexpected" loads. This is a feature that is specific to your anycast setup. Simpler, non-anycast setups wouldn't have this problem. > if you know someone who is willing to provision a "root" name server without > a similar belt and similar suspenders, then please tell them to stop. Are all the roots doing anycast? I've run private roots without any problems, and have experienced significant improvements for doing so. (see below) > on a connectivity island (which might be in the ocean or it might just be > a campus or dwelling), the way to ensure that local service is not disrupted > by connectivity breaks is to make your on-island recursive name servers > stealth slaves of your locally-interesting zones. in new zealand for > example it was the custom for many years to use a forwarding hierarchy > where the nodes near the "top" were stealth slaves of .NZ, .CO.NZ, etc. > that way if they lost a pacific cable system they could still reach the > parts of the internet which were on the new zealand side of the break. This assumes that you are mixing authoritative and caching nameservers. Something that many people (including you) advise against. Operating a root nameserver is much easier. Obviously, in the case of an island or small country that has only one connection, or perhaps one network center, a DDOS that affects the local root is going to affect all connectivity. Their only option may be to drop connectivity. Actual war could have the same impact, due to broken communications line. A local root in each country is probably a good idea. I've also found that when setting up non-connected laboratory networks, it is better to have a 'lab root' server, that acts like a root, since machines in the lab can't access real root servers. This greatly enhances performance in the case where a wrong, or just non-lab domainname is typed in, since you can get an nxdomain back right away instead of waiting for a timeout as the root servers at tried.
Re: national security
On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote: > Oh, btw to install a root server, any PC will do, it is not something > difficult as it carries only a couple of hundred records (200 countries > and a few gTLDs), not the millions of a .com. On Fri, 2003-12-05 at 12:16, Suzanne Woolf wrote: > Operationally, this is a dangerous half-truth. It may be the case that > you can run a nameserver that believes it is authoritative for the > root zone and will answer for it in this way. But under real world > conditions (significant numbers of queries, possibility of DDoS or > other attack, etc.) this is far from adequate. [EMAIL PROTECTED] (Franck Martin) writes: > This is not a dangerous half-truth, It has to be demystified. Let's take > the example of a country like Tonga. A simple PC will do for them because > the number of Internet Users there is may be about a 1000 people. With > anycast properly set up only the packet of that country will reach the > local root-server (proximity), so it is unlikely to be under heavy load > with a 1000 of people on the Internet there... my experience differs. when a root name server is present it has to be fully fleshed out, because if it isn't working properly or it falls over due to a ddos or if it's advertising a route but not answering queries, then any other problem will be magnified a hundredfold. doing root name service in a half-baked way is much worse than not doing it at all, since over time the costs of transit to a good server will be less than the costs of error handling and cleanup from having a bad one. moreover, your statement "only the packet(s) of that country will reach the local root server" is presumptive. under error conditions where transit is leaked, such a server could end up receiving global-scope query loads. in our current belt-and-suspenders model, we (f-root) closely monitor our peer routing, AND we are massively overprovisioned for "expected" loads, since a ddos or a transit-leak can give us dramatically "unexpected" loads. if you know someone who is willing to provision a "root" name server without a similar belt and similar suspenders, then please tell them to stop. > Finally before a root-server is installed somewhere, someone will do an > assessment of the local conditions and taylor it adequately. I want > countries to request installation of root servers, and I know about 20 > Pacific Islands countries that need root-servers in case their Internet > link goes dead. > > cf www.picisoc.org if you want to join us... on a connectivity island (which might be in the ocean or it might just be a campus or dwelling), the way to ensure that local service is not disrupted by connectivity breaks is to make your on-island recursive name servers stealth slaves of your locally-interesting zones. in new zealand for example it was the custom for many years to use a forwarding hierarchy where the nodes near the "top" were stealth slaves of .NZ, .CO.NZ, etc. that way if they lost a pacific cable system they could still reach the parts of the internet which were on the new zealand side of the break. using a half-baked root-like server to do the same thing would be grossly irresponsible, both to the local and the global populations. note that f-root, i-root, j-root, k-root, and m-root are all doing anycast now, and it's likely that even tonga would find that one or more of these rootops could find a way to do a local install. (c-root is also doing anycast but only inside the cogent/psi backbone; b-root has announced an intention to anycast, but has not formally launched the programme yet.)
Re: national security
On Fri, 2003-12-05 at 12:16, Suzanne Woolf wrote: On Fri, Dec 05, 2003 at 10:44:00AM +1200, Franck Martin wrote: > There are now organisations installing root servers in all countries > that want one. If you are operating a ccTLD, you may want have sitting > next to your machines a root server, so if the national Internet link > goes down (something major but not impossible when many countries have > only one link to the Internet) the system still works for all the > national domain names... We (ISC) are widely anycasting f.root-servers.net. Several of the other operators of root nameservers have begun to anycast their servers as well, or announced plans to do so. Is this what you meant? If not, could you elaborate? Yes this is what I mean > This is a not a very well known fact, and I stumbled upon it recently > after wanting to complain that root servers where only in developed > countries. It's hard to quantify what "developed" means in this context. Our anycast f-root systems, for example, do need some infrastructure around them in order to be useful, but we have anycast clusters in over a dozen locations, most outside of the G8. See f.root-servers.org. Well just use the LDS index of the UN if you are in doubt, but we are not here in any contest... Outside the G8 is "something". Yes they do need some infrastructure that you may not find in developing country... but then see my last point... > Oh, btw to install a root server, any PC will do, it is not something > difficult as it carries only a couple of hundred records (200 countries > and a few gTLDs), not the millions of a .com. Operationally, this is a dangerous half-truth. It may be the case that you can run a nameserver that believes it is authoritative for the root zone and will answer for it in this way. But under real world conditions (significant numbers of queries, possibility of DDoS or other attack, etc.) this is far from adequate. This is not a dangerous half-truth, It has to be demystified. Let's take the example of a country like Tonga. A simple PC will do for them because the number of Internet Users there is may be about a 1000 people. With anycast properly set up only the packet of that country will reach the local root-server (proximity), so it is unlikely to be under heavy load with a 1000 of people on the Internet there... Finally before a root-server is installed somewhere, someone will do an assessment of the local conditions and taylor it adequately. I want countries to request installation of root servers, and I know about 20 Pacific Islands countries that need root-servers in case their Internet link goes dead. cf www.picisoc.org if you want to join us... thanks, Suzanne Suzanne Woolf+1-650-423-1333 Senior Programme Manager, ISC ** Fortune favors the prepared mind ** Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard
Re: national security
On Fri, 2003-12-05 at 09:00, Kurt Erik Lindqvist wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> > The post KP&Quest updates are a good example of what Govs do not
>> want
>> > anymore.
>> I can't make this sentence out. Do you mean the diminish of KPNQwest?
>> In that case, please explain. And before you do: I probably know more
>> about KPNQwest than anyone else on this list with a handful of
>> exceptions that where all my colleagues doing the IP Engineering part
>> with me. Please go on...
>
> I am refering ("post" KPNQuest) to the reference management lesson
> ICANN gave concerning root management when the 66 ccTLD secondaries
> supported by KPNQuest were to be updated. NO one will forget at many
> ccTLDs, and Govs.
I was there when KPNQwest went down. I think I have concluded that what
you are referring to was a machine called ns.eu.net. That machine has a
history that goes back to the beginning of the Internet in Europe.
Through mergers and acquisitions it ended up on the KPNQWest network.
It was secondary for a large number of domains, including ccTLDs. When
KPNQwest down, the zone content and address block was transfered to
RIPE NCC. As far as I can tell it is still there. TLDs where asked to
move away from the machine over time.
As a matter of fact, several studies the year before KPNQwest went
down, pointed out the problem with having all the worlds TLDs using
just a few machines as slave servers. However, the DNS is designed to
work fine even with one slave not reachable. So even if ns.eu.net would
have gone off-line abruptly, which it never did, people got, and
apparently still have, plenty of time to move. I think this incident
clearly shows the robustness of the current system, more than anything
else.
There are now organisations installing root servers in all countries that want one. If you are operating a ccTLD, you may want have sitting next to your machines a root server, so if the national Internet link goes down (something major but not impossible when many countries have only one link to the Internet) the system still works for all the national domain names...
This is a not a very well known fact, and I stumbled upon it recently after wanting to complain that root servers where only in developed countries.
Oh, btw to install a root server, any PC will do, it is not something difficult as it carries only a couple of hundred records (200 countries and a few gTLDs), not the millions of a .com.
Cheers
Franck Martin
[EMAIL PROTECTED]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard
Re: national security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> > The post KP&Quest updates are a good example of what Govs do not
>> want
>> > anymore.
>> I can't make this sentence out. Do you mean the diminish of KPNQwest?
>> In that case, please explain. And before you do: I probably know more
>> about KPNQwest than anyone else on this list with a handful of
>> exceptions that where all my colleagues doing the IP Engineering part
>> with me. Please go on...
>
> I am refering ("post" KPNQuest) to the reference management lesson
> ICANN gave concerning root management when the 66 ccTLD secondaries
> supported by KPNQuest were to be updated. NO one will forget at many
> ccTLDs, and Govs.
I was there when KPNQwest went down. I think I have concluded that what
you are referring to was a machine called ns.eu.net. That machine has a
history that goes back to the beginning of the Internet in Europe.
Through mergers and acquisitions it ended up on the KPNQWest network.
It was secondary for a large number of domains, including ccTLDs. When
KPNQwest down, the zone content and address block was transfered to
RIPE NCC. As far as I can tell it is still there. TLDs where asked to
move away from the machine over time.
As a matter of fact, several studies the year before KPNQwest went
down, pointed out the problem with having all the worlds TLDs using
just a few machines as slave servers. However, the DNS is designed to
work fine even with one slave not reachable. So even if ns.eu.net would
have gone off-line abruptly, which it never did, people got, and
apparently still have, plenty of time to move. I think this incident
clearly shows the robustness of the current system, more than anything
else.
>> I just fail to see this. What is it with the ITU that will give us
>>
>>a) More openness? How do I as an individual impact the ITU process?
>
> This is not the topic (I come initially from a national point of view)
> and not to disuss but to listen.
> But this is also an IETF separted issue. As deeply involved for years
> in @large issues (ICANN) and far longer political, public, coporate,
> technology development network issues and for having shared for some
> years in the ITU process (at that time CCITT), I think I will say
> "Yes".
>
> 1. As a user I have no impact on IETF ICANN. Not even do not get heard.
IETF and ICANN in this prospect are two completely different
organizations and processes. In IETF, you are making yourself heard.
Quite a lot actually.
> 2. but (and with a big "but" unlil ITU adapts and created an "I"
> sector for us) ITU has the structures and procedures (Focus Groups and
> Members called meetings) just to do that.
>
> You may have studied/shared in the WSIS and observed the way it works?
It certainly doesn't strike me as open at least. I have read the
following : http://www.itu.int/wsis/participation/accreditation.html.
An organization where I have to apply for accreditation doesn't sound
open to me. Actually I am not even sure what WSIS expect as input. To
me it seems as a forum for governments to be seen. With the hope that
they will have a forum where they can raise issues to other governments.
What I am missing is a) The input of the professionals b) How they
expect to use any eventual output.
Again, I fail to see what the ITU process gives that have a clear
advantage over the current IETF process. And as said, there are also
governments who have come to understand this and learnt how to deal
with the IETF process at the same time as making contingency planning.
>>b) More effectiveness and a faster adoption rate?
>
> Probably yes. For a simple reason. Internet is just another technology
> to support users data communications needs. I may find faster, better;
> parallel solutions else where. Competition fosters speed and quality
> or death. As a user I am darwinian about the process I use.
So you are saying that the ITU will provide better standards at fast
speed? That has most certainly not been the case before...
>>c) A better representation of end-user needs?
>
> Certainly. This is a recurring issue. Quote me the way IETF listen to
> end-users needs. I have been flamed enough as a user representative to
> know it. And don't tell me "who do you represent?" or I will bore
> everyone responding. This thread show it. As a user I rose a question.
> Responses:
The IETF makes decisions by rough consensus. If you have a point that
is valid enough, you will get enough people to support you. If not,
life goes on.
> - question are disputed. I learned a long ago that questions are never
> stupid, but responses may be.
No, but the question might tell a lot about who you are and what your
motives are.
> - question asked back to me: who are you. I appreciate that you may
> warn me about KPNQuest to spare us a trolls response. But I wander why
> the author would have any impact on a new question.
Knowing peoples background is always helpful
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> I agree and realize this. However, the let's take that argument out >> in the open and not hide it behind "national security". > > I regret such an agressiveness. I simply listed suggestions I > collected to ask warning, advise, alternative to problems identified > not from inside the internet but from outside. Why don't you simply go inside and find out? There is nothing like first hand knowledge! > I was labelled as a topic of national security because it was to > prepare a menting on national vulnerability to Internet. If it had > been about a Web Information and Services Providers, or User Networks > demands, it would have been the same I know a number of countries that have looked at this from a national perspective. None of them have argued that the ITU is the solution. On the contrary, the distributed control of the Internet is a good value. > I expected warnings, advices, alternative propositions. If you need a > long discssion among specialists to come with that, please do. I am > only interested in an authorized outcome. And we will all thank you > for that. What the collective Internet thinks is documented largely through the IETF process, or related organizations. I think that the issues you are trying to raise are already answered at any point in history as being a reflection of the current set of standards. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP8+D+KarNKXTPFCVEQJm9QCgzecWX5+0R1RcADym1rrZHICjvPAAoK2o DBfR0ezNIcNGpKt4bb+J8bGl =HL9l -END PGP SIGNATURE-
Re: national security
At 09:21 03/12/03, Kurt Erik Lindqvist wrote: I agree and realize this. However, the let's take that argument out in the open and not hide it behind "national security". I regret such an agressiveness. I simply listed suggestions I collected to ask warning, advise, alternative to problems identified not from inside the internet but from outside. I was labelled as a topic of national security because it was to prepare a menting on national vulnerability to Internet. If it had been about a Web Information and Services Providers, or User Networks demands, it would have been the same I expected warnings, advices, alternative propositions. If you need a long discssion among specialists to come with that, please do. I am only interested in an authorized outcome. And we will all thank you for that. jfc
Re: national security
Dear Mr. Lindqvist,
I am afraid I do not understand some of the points you try to make. I will
give basic responses, please do not hesitate to elaborate.
On 21:27 02/12/03, Kurt Erik Lindqvist said:
> The post KP&Quest updates are a good example of what Govs do not want
> anymore.
I can't make this sentence out. Do you mean the diminish of KPNQwest?
In that case, please explain. And before you do: I probably know more
about KPNQwest than anyone else on this list with a handful of exceptions
that where all my colleagues doing the IP Engineering part with me. Please
go on...
I am refering ("post" KPNQuest) to the reference management lesson ICANN
gave concerning root management when the 66 ccTLD secondaries supported by
KPNQuest were to be updated. NO one will forget at many ccTLDs, and Govs.
> Consider the French (original) meaning of "gouvernance". For networks
> it would be "net keeping". Many ICANN relational problem would
> disappear.
Ok, enough of references to France/French/European. I am born and grown
up in Finland, I have more or less lived in Germany and the Netherlands
for 6-36 months, I live in Sweden since 9 years and I have a resident
in Switzerland. I have worked on building some of the largest Internet
projects in Europe and the largest pan-European networks. Even with
governments trying to meet their needs. So I should be the perfect
match of what you are trying to represent. And I just don't buy any of
your arguments. Sorry.
I suppose that you are living in a French speaking Switzerland part then.
May be people there have not a common command of the XIIIth century French
from North of France (where the word comes from) or from current Senegal
administration (where the word is in current legal use)?
> What would be the difference if the ccNSO resulted from an MoU? It
> would permit to help/join with ccTLDs, and RIRs, over a far more
> interesting ITU-I preparation. I suppose RIRs would not be afraid an
> ITU-I would not be here 2 years from now.
As someone who is somewhat involved in the policy work of the RIRs, I
really,really, really want you to elaborate on this.
Glad you do. I keep your entries to simplify the reading.
I just fail to see this. What is it with the ITU that will give us
a) More openness? How do I as an individual impact the ITU process?
This is not the topic (I come initially from a national point of view) and
not to disuss but to listen.
But this is also an IETF separted issue. As deeply involved for years in
@large issues (ICANN) and far longer political, public, coporate,
technology development network issues and for having shared for some years
in the ITU process (at that time CCITT), I think I will say "Yes".
1. As a user I have no impact on IETF ICANN. Not even do not get heard.
2. but (and with a big "but" unlil ITU adapts and created an "I" sector for
us) ITU has the structures and procedures (Focus Groups and Members called
meetings) just to do that.
You may have studied/shared in the WSIS and observed the way it works?
b) More effectiveness and a faster adoption rate?
Probably yes. For a simple reason. Internet is just another technology to
support users data communications needs. I may find faster, better;
parallel solutions else where. Competition fosters speed and quality or
death. As a user I am darwinian about the process I use.
c) A better representation of end-user needs?
Certainly. This is a recurring issue. Quote me the way IETF listen to
end-users needs. I have been flamed enough as a user representative to know
it. And don't tell me "who do you represent?" or I will bore everyone
responding. This thread show it. As a user I rose a question. Responses:
- question are disputed. I learned a long ago that questions are never
stupid, but responses may be.
- question asked back to me: who are you. I appreciate that you may warn me
about KPNQuest to spare us a trolls response. But I wander why the author
would have any impact on a new question.
> The lack of users networks. Multiorganization TLDs Jerry made
> introduced as a reality we started experiencing. Just consider that
> the large user networks (SWIFT, SITA, VISA, Amadeus, Mnitel, etc.)
> started before 85. OSI brought X.400. CERN brought the Web. But ICANN
> - and unreliable technology - blocks ULDs (User Level Domains).
To be honest, none of those networks are really large compared to the
Internet, or in terms of users and especially bandwidth to some of the
large providers.
I agree. But I fail to see howit relates to the point?
My point is that SWIFT should have been able to become .swift for a very
long. That .bank was denied to the World Bank Association and that SITA was
given a try with .aero.
So we can technically compare the capacity of Internet to support the needs
of a very, very old network like SITA. It does seem to be very appealing on
the air transportation community. Never saw any ad for "aerolinas.aero" yet
howver the mnemonic inter
Re: national security
On 3 Dec 2003, Franck Martin wrote: > ITU is worried like hell, because the Internet is a process that escapes > the Telcos. The telcos in most of our world are in fact governments and > governments/ITU are saying dealing with country names is a thing of > national sovereignty. What they most of the time fail to see, is that > most registry are willing to hand it over to the governments provided > they DO understand the issues, and not use DNS to empower telcos in more > exclusive licencing power. I'm not sure that this is really the case with respect to assignment of ccTLD registries. Though I can't personally vouch for this, I think all of the ccTLD's have been handed to government designated representatives when the governments asked. So I dispute the implied assertion that there is present evidence of ICANN, IETF, or IANA involvement or interference in political or governmental controls. But of course, governments have the sovereign right to control the communications of their citizens, and if the governments choose, can 'use DNS to empower telcos in more exclusive licencing power'. If governments are concerned about information anarchy, they will undoubtedly bring it up through the UN and through the ITU. Or perhaps they will just employ national firewalls like China did to block unwanted information. --Dean
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On onsdag, dec 3, 2003, at 04:12 Europe/Stockholm, Franck Martin wrote: > ITU is worried like hell, because the Internet is a process that > escapes the Telcos. The telcos in most of our world are in fact > governments and governments/ITU are saying dealing with country names > is a thing of national sovereignty. What they most of the time fail to > see, is that most registry are willing to hand it over to the > governments provided they DO understand the issues, and not use DNS to > empower telcos in more exclusive licencing power. > > ITU has been also misleading countries by making them think that DNS > issues will be solved at ITU meetings. I have been telling countries > that they must attend ICANN meetings and no other one. When this > happens, US corporations will have less power over ICANN and things > will be better. > I agree and realize this. However, the let's take that argument out in the open and not hide it behind "national security". The countries I have worked with, do have national disaster plans that can handle a IP network completely cut off from the rest of the world. But those plans are made together with the industry, as today you can not have this type of planning without co-operation of the large, world wide companies. Even if the governments own and control many of the telcos of the world, the operation of the sub-sea cables that transport the traffic is mostly run by organizations they have no control over. Best regards, - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP82dC6arNKXTPFCVEQIqZQCcDd1ffRAvtfBjvUSJXfoaw1ilVkQAnRqH V/3ZsmgatgorFVGQYmDmXLcM =yrRB -END PGP SIGNATURE-
Re: national security
On Wed, 2003-12-03 at 08:27, Kurt Erik Lindqvist wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > What would be the difference if the ccNSO resulted from an MoU? It > would permit to help/join with ccTLDs, and RIRs, over a far more > interesting ITU-I preparation. I suppose RIRs would not be afraid an > ITU-I would not be here 2 years from now. As someone who is somewhat involved in the policy work of the RIRs, I really, really, really want you to elaborate on this. [Quotes rearranged] > The complexity is that ICANN wants to be two conflicting things >(American and International) and to organize something multinational. > Vint, you will never change that IANA is part of the Internet and > Internet is the current solution of the world for its > datacommunications. So IANA must be involved. ITU is the way govs > cooperate in communications (data, telephone, TV, radio) and where > they have so many mixed interests that they must be cautious (this is > what protects us, the consumers). So ITU must be involved. > > If you are serious about becoming multinational, you must disengage > from the US Gov. But IANA will never lose its US Flag without ITU. ITU > will never develop an acceptable higher layers capacity (ITU-I) before > long, without ICANN, ccTLD etc. > > So, how long will we have to wait for you to ally (and not to try to > swallow) with ccTLDs and to sit down with Mr. Zao, stop WSIS worrying > and permits jointly care about fostering development and innovation. I just fail to see this. What is it with the ITU that will give us a) More openness? How do I as an individual impact the ITU process? b) More effectiveness and a faster adoption rate? c) A better representation of end-user needs? ITU is worried like hell, because the Internet is a process that escapes the Telcos. The telcos in most of our world are in fact governments and governments/ITU are saying dealing with country names is a thing of national sovereignty. What they most of the time fail to see, is that most registry are willing to hand it over to the governments provided they DO understand the issues, and not use DNS to empower telcos in more exclusive licencing power. ITU has been also misleading countries by making them think that DNS issues will be solved at ITU meetings. I have been telling countries that they must attend ICANN meetings and no other one. When this happens, US corporations will have less power over ICANN and things will be better. on a side note, Vint/ICANN if you are reading this, the Pacific Islands Chapter of the Internet Society will have its annual meeting in September 2004 in Vanuatu. I think it is time you send some outreach people to explain here, what the hell is ICANN and how you manage a DNS. (www.picisoc.org). Vint, wanna come? Port Vila, is a very very nice place... Cheers Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard
Re: national security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The post KP&Quest updates are a good example of what Govs do not want > anymore. I can't make this sentence out. Do you mean the diminish of KPNQwest? In that case, please explain. And before you do: I probably know more about KPNQwest than anyone else on this list with a handful of exceptions that where all my colleagues doing the IP Engineering part with me. Please go on... > > Consider the French (original) meaning of "gouvernance". For networks > it would be "net keeping". Many ICANN relational problem would > disappear. Ok, enough of references to France/French/European. I am born and grown up in Finland, I have more or less lived in Germany and the Netherlands for 6-36 months, I live in Sweden since 9 years and I have a resident in Switzerland. I have worked on building some of the largest Internet projects in Europe and the largest pan-European networks. Even with governments trying to meet their needs. So I should be the perfect match of what you are trying to represent. And I just don't buy any of your arguments. Sorry. > What would be the difference if the ccNSO resulted from an MoU? It > would permit to help/join with ccTLDs, and RIRs, over a far more > interesting ITU-I preparation. I suppose RIRs would not be afraid an > ITU-I would not be here 2 years from now. As someone who is somewhat involved in the policy work of the RIRs, I really, really, really want you to elaborate on this. [Quotes rearranged] > The complexity is that ICANN wants to be two conflicting things >(American and International) and to organize something multinational. > Vint, you will never change that IANA is part of the Internet and > Internet is the current solution of the world for its > datacommunications. So IANA must be involved. ITU is the way govs > cooperate in communications (data, telephone, TV, radio) and where > they have so many mixed interests that they must be cautious (this is > what protects us, the consumers). So ITU must be involved. > > If you are serious about becoming multinational, you must disengage > from the US Gov. But IANA will never lose its US Flag without ITU. ITU > will never develop an acceptable higher layers capacity (ITU-I) before > long, without ICANN, ccTLD etc. > > So, how long will we have to wait for you to ally (and not to try to > swallow) with ccTLDs and to sit down with Mr. Zao, stop WSIS worrying > and permits jointly care about fostering development and innovation. I just fail to see this. What is it with the ITU that will give us a) More openness? How do I as an individual impact the ITU process? b) More effectiveness and a faster adoption rate? c) A better representation of end-user needs? > The lack of users networks. Multiorganization TLDs Jerry made > introduced as a reality we started experiencing. Just consider that > the large user networks (SWIFT, SITA, VISA, Amadeus, Mnitel, etc.) > started before 85. OSI brought X.400. CERN brought the Web. But ICANN > - and unreliable technology - blocks ULDs (User Level Domains). To be honest, none of those networks are really large compared to the Internet, or in terms of users and especially bandwidth to some of the large providers. And, yes, OSI brought X.400 - but I am not really sure what to make out of that point...:-) > I just note that you never cared about Consumers organizationsn, while > a world e-consumer council would have given you the legitimacy of > billions and the weight to keep Gov partly at large, and satisfied. A > National Security Kit would then be one of the ICANN raisons d'être, > keeping Govs happy. I think that the national governments that are thinking they need control over ICANN in order to handle a national emergency simply needs to understand the problem better. There are non-US governments with contingency planning that works without any of the I* organizations being under the control of ITU. I just guess those have done a better job. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBP8z1zaarNKXTPFCVEQIl0ACgpdZ2UjHU3BoynpqZWqrXOYfAgPEAniOK +WPzBgPS0MlmT8whXLLEcWup =illt -END PGP SIGNATURE-
Re: national security
Alas for this rosy vision, ICANN *tried* to boss the RIRs and get them to sign contracts agreeing to pay it and obey it, but they balked. So all credit to the RIRs - and none to ICANN - on this one. On Mon, 1 Dec 2003, John C Klensin wrote: > > > --On Monday, 01 December, 2003 07:24 -0500 "vinton g. cerf" > <[EMAIL PROTECTED]> wrote: > > > karl, ICANN has responsibility to do what it can to make sure > > the DNS and ICANN root system work. It does not have to > > disenfranchise the RIRs and the root servers to do this. > > Vint, > > I would go even further than this. One of the best actions > ICANN can take, IMO, is to look at a particular situation (and > the root system and DNS operations generally are probably good > examples) and say "yep, it is working" followed by some version > of "if it ain't broke, don't fix it... or even intervene". One > corollary to this is that not only does "it not have to > disenfranchise..." but that it arguably should not intervene in > those activities at all unless there is a strong case that they > are not working in some significant way. > > In that sense, the observation that ICANN has not significantly > intervened in either the root system or with the address > registry environment should be judged as a success unless it is > argued that one or the other is seriously not working. > >john > > > > > -- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin |Professor of Law| [EMAIL PROTECTED] U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<--
Re: national security
At 22:21 01/12/03, Paul Vixie wrote:
[EMAIL PROTECTED] ("J-F C. (Jefsey) Morfin") writes:
> Most of all when the hacker seats in the Oval Office, what is the
solution?
> Kaspurcheff was not the only root hacker to be known. Jon Postel was too.
good bye, sir.
--
Paul Vixie
Dear Mr. Vixie,
Things will not fall a part on Dec 6th by midnight. But if 189 States and
USA do not agree on something reasonable on THIS point, we will enter a
period where there will be progressive disagreements over the naming, IMHO
to no one's benefit. And the necessary changes will then not occur
smoothly. Europe supports the US position with some internal differences
which permit to help a compromise.
Unless you really want to say good bye to the whole thing, why don't you help?
For example, are we not able to just devise a procedure and a system which
build the root file from the TLD Managers owns real time data? Would Vint
have responded that, it was stability for ICANN and IETF for years. OK,
ICANN's stablity through power greed is inadequate, but is that not also
inadequate to permit it? And not to consider who to change that situation?
Be sure that whatever the outcome of Dec. 5/6, the IANA US root file
management is condemned. And probably ICANN in two years time if it stick
to it. The USA are not going to support them. As they did not in Marrakech
for the IDNs. What would be their advantage?
The important issue is to know what will replace it? An automated
compilation of the TLD Managers data by IANA would be preferable to an ITU
system, after a rought debate and transfer.
Best regards
jfc morfin
Re: national security
Dear jfc, As far as I can tell, you have gone only by your initials on this thread. To help some of us weigh this discussion, could you please identify yourself by name and affiliation? Regards, Michael Lambert --- Michael H. Lambert Network Engineer Pittsburgh Supercomputing CenterV: +1 412 268 4960 4400 Fifth Avenue F: +1 412 268 8200 Pittsburgh, PA 15213 USA
Re: national security
--On Monday, 01 December, 2003 07:24 -0500 "vinton g. cerf" <[EMAIL PROTECTED]> wrote: karl, ICANN has responsibility to do what it can to make sure the DNS and ICANN root system work. It does not have to disenfranchise the RIRs and the root servers to do this. Vint, I would go even further than this. One of the best actions ICANN can take, IMO, is to look at a particular situation (and the root system and DNS operations generally are probably good examples) and say "yep, it is working" followed by some version of "if it ain't broke, don't fix it... or even intervene". One corollary to this is that not only does "it not have to disenfranchise..." but that it arguably should not intervene in those activities at all unless there is a strong case that they are not working in some significant way. In that sense, the observation that ICANN has not significantly intervened in either the root system or with the address registry environment should be judged as a success unless it is argued that one or the other is seriously not working. john
Re: national security
[EMAIL PROTECTED] ("J-F C. (Jefsey) Morfin") writes:
> Most of all when the hacker seats in the Oval Office, what is the solution?
> Kaspurcheff was not the only root hacker to be known. Jon Postel was too.
good bye, sir.
--
Paul Vixie
Re: national security
karl, ICANN has responsibility to do what it can to make sure the DNS and ICANN root system work. It does not have to disenfranchise the RIRs and the root servers to do this. vint At 12:02 AM 12/1/2003 -0800, Karl Auerbach wrote: >Verisign will wave the flag of bias and ask ICANN to demonstrate why >anycast got such an easy entree. because it did not change the results of queries. sitefinder did. Vint Cerf SVP Technology Strategy MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax [EMAIL PROTECTED] www.mci.com/cerfsup
Re: national security
Paul Vixie; 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. So? Service by multiple hosts in a single location is hardly anycast. When it was switched to anycast? 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.) Can you explain, the reactions of people who have been engaging in root server operations against anycast without comprehending the dynamics of anycast, as observed in the last month in IETF DNS OP ML? Masataka Ohta
Re: national security
On 1 Dec 2003, Paul Vixie wrote:
> > ICANN's obligation is to guarantee to the public the stability of DNS at
> > the root layer.
>
> i disagree...
>From ICANN's own bylaws:
The mission of The Internet Corporation for Assigned Names and Numbers
("ICANN") is to coordinate, at the overall level, the global Internet's
systems of unique identifiers, and in particular to ensure the stable
^
and secure operation of the Internet's unique identifier systems ...
[emphasis added]
According to m-w.com, "ensure" means "to make sure, certain, or safe :
Guarantee".
In other words, ICANN's mission is a promise, a guarantee.
But that's not all:
ICANN's contract, or rather "Memorandum of Understanding" with the United
States requires, yes requires, that ICANN, yes ICANN, not the RIRs, not
the root server operators, "to design, develop, and test the mechanisms,
methods, and procedures" ... to oversee "the operation of the
authoritative root server system" and "the allocation of IP number
blocks".
Those are ICANN's own promises that it has made, in legal document after
legal document, to the United States Government. ICANN may say otherwise,
you may believe otherwise. But that's the contractual words in black and
white. It has been the same language since 1998.
In other words, ICANN has made a contractual committment to tell you, as
an operator of a root server, what "mechanisms, methods, and procedures"
you must follow to operate your servers.
And that word "oversight" in the MoU does not mean that ICANN promises to
merely watch how you and the other root server operators do what you do
very well. The word "oversight" includes an ability to reject and to
command. In other words, ICANN has promised the USG that it's authority
over root operations supersedes your own.
We are all well aware that in actual fact that ICANN has no legal
authority over the root server operators. And we are all aware that the
root server operators have been wary of entering into agreements with
ICANN regarding the operation of the root servers. That, however, has not
stopped ICANN from making a written promise to the United States govenment
that it will both oversee the root server operations and "formalize" its
relationship with the root server operators.
Perhaps ICANN is willing to admit that it has no real authority -
presumably by declaring to the US Department of Commerce that it considers
those sections that I mentioned to be obsolete and not obligatory upon
ICANN, and by removing the obligation to "ensure the stable and secure
operation" that is contained in its own bylaws - and clearly articulating
to everyone, governments and businesses included, that ICANN is nothing
more than an advisory body that operates only by eminating good vibes in
the hope that others, who do have real power to act, will act in
resonance.
In the meantime ICANN goes about telling governments of the world that it
does far more than emit nudges and hopes; ICANN tells governments that it
ensures and guarantees.
And outside of the IETF and related communities ICANN does not say that it
is merely an advisory body lacking authority. ICANN's message to the
business and intellectual property communities is that ICANN stands strong
and firm and will let nothing interfere with the stable operation of the
internet.
Your note makes my point - that ICANN is in many regards an empty shell,
and has been one for years, that has no real power except in the realm of
the (over) protection of intellectual property, allocation of a very few
new top level domains, and the determination of who among compeiting
contenders is worthy to operate contested ccTLDs.
At the end of the day - and it is nearly the end of the day here - the
fact of the matter is that ICANN is telling different stories to different
groups. To the IETF, ICANN holds itself out as one of the guys, merely a
warm and fuzzy "coordinator". But to the business community, ICANN holds
itself forth as a guarantor of internet stability. And to the United
States Govenment, ICANN has undertaken to make legal promises to the
effect that it is in charge of DNS, including root server operations, and
IP address allocation.
--karl--
PS, if I am "late to the party" on anycast issues than it ought to be easy
for ICANN to articulate the answers to my concerns. This is not an idle
request. The internet community deserves proof that these questions are
truly answered by hard, reviewable, analysis. Moreover, with Verisign and
sitefinder lingering on the horizon it is not beyond conception that
Verisign will wave the flag of bias and ask ICANN to demonstrate why
anycast got such an easy entree.
Re: national security
Dear Paul, Thank you for your response even if it is not to the question asked. I never made any proposal. I have listed suggestions made by different parties (I certainly takes seriously) to address real life problems of immediate security for nations subject to catastrophe, war, international fights or confronted to a netwok collapse. And I asked for serious warnings, anlyses, advices, alternative suggestions. At 19:47 30/11/03, Paul Vixie wrote: this statement is akin to many others made in ignorance of what dns is. you are treating it as a mapping service. perhaps you have been successful at treating dns as a mapping service in some local context, and this may have led you to the impossible conclusion that dns itself is a mapping service. dns is a coherent, distributed, autonomous, reliable database. "distributing the root" as you claim to believe is necessary would create multiple domain name systems, Amusing. Yes I experimented that in 78. And some where unhappy :-). I will not tell you the DNS is several things to achieve a common purpose which addres maping. The way it does it _tryies_ to be a coherent, distibuted, autonomous, reliable database. What by essence it never is, except if you stop feeding it and you wait for all the TTL to die. Here, we are in the case it is impeached to continue trying. not *a* domain name system with a distributed root. there is no way to have *a* domain name system with a distributed root unless we (ietf or other similar agencies) first defined what that meant. Interesting. Which agency? An agency under cooperation agreement with ICANN or NTIA, or a standarization body like ITU, or the P2P standardization committee. Anyway, I do not look for a fundamental debate. But for serious, experienced and documented considerations about the flexiblity of the existing system and its capacity to effectively sustain some duress under necessity. And how to best specify/design the solutions then to use. when you're ready to commission a multiyear study which would yield documents of the same size and scope as rfcs 1033+1034+1035+2181, then you'll have demonstrated that you have some understanding of what you're asking for . NSA started the study. Work is engaged by the WH. http://whitehouse.gov/pcipb. ICANN has documented the way it should be done (ICP-3). NSI has commited a 500 million budget on DNS. Other projects are at works. The target now is to know what to in the meanwhile and what to do to protect onselef from their results. and note that you would then have to "sell" the resulting system to the internet populance which includes end users, domain holders, registrars, registries, ISPs, and as you point out, nations. lots of luck, but "that ship already sailed." :-) amusing. The world lived millions years without the DNS. For 20 years international data nets created naming but lived without the DNS. True, for less than a decade, since the Web, the world faces a management problem because IETF has kept with an early 80's applications architecture. 3/4 of the world is just telling USA (WSIS, this week) "okay for your 'root bluff': how much". Naming was not created by the DNS and will survive the DNS. The DNS application is a good example of an extended service but it must adapt to the current needs. It is a 1983 car. It is brillant, it has been refurbished a lot, but still it is a 1983 vintage. in no particular order, i'll address a couple of your other comments. > 5. the possibility of a redundant DNS system. Today the Internet has two > root files (the same file but presented on two main systems - DNS and FTP). > If one is hacked there is not reference. A redundant system would consist > in two or more root masters refereeing to different sets of TLD name > servers (all of them carrying the same files, but possibly of different > origins for security reasons). there is a reference. several references, actually. hey! Is not a reference unique? As, John would say: wich unique master is the master? there is no possibility of a "hack" going undetected or uncorrected. Not disputing that. The point is: what is the worst impact of one of the unique copies being hacked and detected. What are the recovery procedures? What are the control procedures? Are they fool proof? Are they accepted by users? Police is often immediately notified bank robberies. Yet hold-ups hurt and kill people every day. We are not salesmen here. But cops and insurance companies. Most of all when the hacker seats in the Oval Office, what is the solution? Kaspurcheff was not the only root hacker to be known. Jon Postel was too. WTC was built to resist the worst winds. Not 747s. Many people regret it. Our role is to make sure it does not to happen again. but more important, if you had several "root files" which indicated different servers for some TLD's, you would have (by definition) several domain name systems, 1. there are two different root files i
Re: national security
karl, we raised the question of anycast risk with SECSAC in response to your concerns and the conclusion was that the risks had not materialized in the operation of anycast in roots that had already deployed it. There are lots of ways in which routing can be wedged - until we get some form of authentication, that risk will be with us. Moreover, even with authentication it is possible to misconfigure routing. Any table driven system that does not have an obvious syntactic or semantic way of detection a bad configuration is subject to these risks. vint At 06:29 PM 11/30/2003 -0800, Karl Auerbach wrote: >The switch to anycast for root servers is a good thing. 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? 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? Could one introduce bogus >routing information into the net and drag some portion of resolvers to >bogus root servers? Vint Cerf SVP Technology Strategy MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax [EMAIL PROTECTED] www.mci.com/cerfsup
Re: national security
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
Re: national security
On Sat, 29 Nov 2003, vinton g. cerf wrote: > >I can't seem to recall during my 2 1/2 years on ICANN's board that there > >ever was any non-trivial discussion, even in the secrecy of the Board's > >private e-mail list or phone calls, on the matters of IP address > >allocation or operation of the DNS root servers. Because I was the person > >who repeatedly tried to raise these issues, only to be repeatedly met with > >silence, I am keenly aware of the absence of any substantive effort, much > >less results, by ICANN in these areas. > > The fact that there were few board discussions does not mean that staff > was not involved in these matters. Discussions with RIRs have been lengthy > and have involved a number of board members. Discussions "with staff" hardly constitutes responsible oversight by ICANN as a body responsible to the internet public. All you have said is that ICANN has not merely abandoned its oversight of DNS and IP addresses to the root server operators and the RIRs but also that the only elements within ICANN that even bother to observe are the occassional board member and some perhaps some unnamed staff members. I raised the anycast issue several times to the board. "Staff" received those e-mails. I do not except as valid an after fact explaination that says "Even though nobody bothered to answer Karl's inquiries, ICANN's staff was really making informed decisions, in secret, about anycast." ICANN's job is not to make decisions in secret, by unknown members of "staff", based on unknown criteria and using unknown assumptions. To do so, which is what you are saying has been done, is simply yet another abandonment of ICANN's obligations. The switch to anycast for root servers is a good thing. 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? 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? Could one introduce bogus routing information into the net and drag some portion of resolvers to bogus root servers? 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). 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. 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. Given that one of the strongest arguments against Verisign's Sitefinder is that it breaks things, and that it violates the end-to-end principle, Verisign lawyers must be very pleased that they can so easily demonstrate that ICANN is willing to act with overt bias, to let slide, without inquiry, those things proposed by ICANN "friends". > Sorry, anycast has been out there for quite a while; I am surprised you > didn't know that. No need for sarcasm. As you must be well aware, was the one who explained to ICANN's Board how anycast works. Indeed, I was the one who brought the deployment of anycast roots to the Board's attention. I know that the ICANN Board considers its communications secret. However if I am required to defend myself from what I consider to be an unwarranted and unsupportable assertion regarding my professional knowledge I would have to consider it my right to defend myself and publish any and all relevant materials from the archives of the Board's e-mail. 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. ICANN's obligation is to guarantee to the public the stability of DNS at the root layer. ICANN's failure to engage in the issue of anycast deployment was simply and clearly and abandonment of ICANN's responsibilities. > >[I believe that the anycast change was a good one. However, there is no > >way to deny that that change was made independently of ICANN.] > > 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 an
Re: national security
On Sun, 30 Nov 2003 20:42:18 EST, Dean Anderson said: > The main criticism of the IETF/IANA/ICANN by the rest of the world seems > to fall under the democratic constituencies issue. People outside the US > seem to distrust the US, and feel that their voices are not being heard, > and that they aren't being represented properly. I don't know whether > there is a truly genuine failing in this respect, but there is clearly a > widespread concern. The perception is just as serious as an actual > impropriety. I've not followed the innards of the ITU process - have they fixed the balloting/veto setup that resulted in such "all options for everybody" elephantine standards like X.[45]00? Democratic constituencies aren't always a good idea. pgp0.pgp Description: PGP signature
Re: national security
> IETF is to deliver technical solutions. IANA is to deliver a registry > service. What is ICANN up to? Except what we agree: "to guest forums" to > help consensus there. > > BTW is that very different from ITU? Just that Paul Twomey's Nov 19th > document would have resulted from a painstakingly g/sTLD consensus and > would not have worried ccTLDs. This doesn't completely cover it. For example, the IETF delivers standards. The ITU also delivers standards. The ITU has issued competing standards such as IS-IS, X.400, X.500 etc, etc, etc. The IANA and ICANN functions are also similarly performed by the ITU. For example, the allocation of Radio frequences, and radio call sign prefixes. Obviously, the functions of the IETF, IANA, and ICANN could be done by the ITU, and the ITU has considerable experience in these areas. I think there is very little credence to any legal benefits of being incorporated in Switzerland versus the US. Indeed, generally, one must incorporate in any country in which one has permanent employees. If the ITU were to take over the IETF/IANA/ICANN and their US employees, it would still be incorporated in the US, as well as in other countries. Organizations can be sued in any country they do business in whether they are incorporated there or not, so it doesn't matter too much where they are incorporated. There are variations in the fees to maintain a corporation, but these are minimal. For example, it costs about $300/yr in Massachussets, versus about $125/yr in Delaware. Delaware also has extensive support by the state department of corporations for finding the necessary corporate agents, who charge nominal fees to be the corporate agent. This causes most corporations to be incorporated in Delaware. Other than minor issues like that, there is little benefit. While different countries have different tax structures, these are likely to be of little to no consequence to a standards organization. The real issues with moving the IETF/IANA/ICANN functions under the ITU are questions of economics and democratic constituencies. It is these questions that really need to be addressed: Quite obviously, duplication of the administration efforts results in wasted money. The only reason to keep them separate is to perform this job better. As has been often pointed out, the IETF is fairly sloppy in its administration. Clearly, moving the administration of IETF activities and standards to the ITU would be a benefit for all in terms of savings and in terms of improved administration. The main criticism of the IETF/IANA/ICANN by the rest of the world seems to fall under the democratic constituencies issue. People outside the US seem to distrust the US, and feel that their voices are not being heard, and that they aren't being represented properly. I don't know whether there is a truly genuine failing in this respect, but there is clearly a widespread concern. The perception is just as serious as an actual impropriety. Given that the enconomics seems to point to consolidation with the ITU, and the fact that many seem to place more trust in the ITU, I think we ought to seriously consider this option. I've been though the merger of standards groups incorporated in different countries, as a technical consultant, and the results have been very positive. The benefits are similar to the benefits gained by the merger of companies. The main difference being that the "users" have much more say in the direction of a standards group than the customers of two private companies. Of course, the ITU also needs to agree to sign on to take over this responsibility, and it will require additional funding for the ITU, and it is unclear the that the funding for ICANN/IANA/IETF will be transferred to the ITU if such a change is made. Essentially, this means that the rest of the world will have to put more money into ITU funding. Dean Anderson CEO Av8 Internet, Inc
Re: national security
At 17:35 30/11/03, Michael H. Lambert wrote: Content-Transfer-Encoding: 7bit Dear jfc, As far as I can tell, you have gone only by your initials on this thread. To help some of us weigh this discussion, could you please identify yourself by name and affiliation? Sorry for this. The question was asked and replied to, but I did not note the list was not in copy. I am used to do this for long because I think what is debated is important, not the persons (when I want to know the competences of someone I go to the person's site). This is precisely a part of the concern: will IETF practically be able to understand and treat equally needs/inputs from Pittsburgh and from every other place and culture. What to suggest if not? Analysing and working together world and technical cultures wide is not that easy (look at my exchanges even with John Klensin). If you follow the WSIS you know that this type of concern is the crux of the current negociation. So who I am should not impact on the responses to what is a documented call for warning, advice or aternatives on vital issues. Or a specialized body must be created. I am JFC Morfin. You will find my professionnal site at http://utel.net. I created in 1978 the SIAT/Intlnet ( http://intlnet.org ) which assumed until 1986 the role of very very lean ICANN the international public packet switch network needs. After 9/11 I called a study group at the DNSO/BC to propose the writing of an ICP-4 ICANN Document over Global Security. The limited interest of the next MdR meeting on Security, the annoucements of M$ and Richard Clarke's mission led to launch a project and a study named dot-root (http://dot-root.com). It strictly abode by ICANN ICP-3 to organize a DNS double test bed with an unique and a parallel root systems. The study (French) was presented earlier this year to people in charge. As part of the follow up there is a meeting on national vulnerabilities to the DNS/IPv6 as identified by the study and readers feed-backs. This does not directly concern sites nor network protection, but lives, economy, culture, way of life, e-government, development, sovereignty, etc protection - not theoretical but right-now. jfc
Re: national security
i'm going to bend my own policy a bit and reply to a role account: [EMAIL PROTECTED] (jfcm) writes: > ... The interest is not sites nor network protection layers, but nations > protection from what happens on or with the networks. This is in line > with the White House document http://whitehouse.gov/pcipb with the > addition of the risks created by the US (and every other national) cyber > security effort, and from not mastering the root. In most of the cases > the identified risks come from a centralized [root] which has to be made > distributed. this statement is akin to many others made in ignorance of what dns is. you are treating it as a mapping service. perhaps you have been successful at treating dns as a mapping service in some local context, and this may have led you to the impossible conclusion that dns itself is a mapping service. dns is a coherent, distributed, autonomous, reliable database. "distributing the root" as you claim to believe is necessary would create multiple domain name systems, not *a* domain name system with a distributed root. there is no way to have *a* domain name system with a distributed root unless we (ietf or other similar agencies) first defined what that meant. when you're ready to commission a multiyear study which would yield documents of the same size and scope as rfcs 1033+1034+1035+2181, then you'll have demonstrated that you have some understanding of what you're asking for here. and note that you would then have to "sell" the resulting system to the internet populance which includes end users, domain holders, registrars, registries, ISPs, and as you point out, nations. lots of luck, but "that ship already sailed." in no particular order, i'll address a couple of your other comments. > 5. the possibility of a redundant DNS system. Today the Internet has two > root files (the same file but presented on two main systems - DNS and FTP). > If one is hacked there is not reference. A redundant system would consist > in two or more root masters refereeing to different sets of TLD name > servers (all of them carrying the same files, but possibly of different > origins for security reasons). there is a reference. several references, actually. there is no possibility of a "hack" going undetected or uncorrected. but more important, if you had several "root files" which indicated different servers for some TLD's, you would have (by definition) several domain name systems, not a domain name system with high redundancy. until you demonstrate some understanding of that fundamental and definitional aspect of dns, you won't be taken seriously among the community who does understand those things. > Thank you for your comments. > jfc please learn the basics before you come in here and start making proposals. -- Paul Vixie
Re: national security
% Anycast may even have preceded the creation of ICANN - perhaps an IETF % source or one of the root server operators can say when the first ANYCAST % deployments were done. Not an IETF source. In discussions on the earliest anycast instance, there was general agreement that "M" was anycast from the time it moved from LA to Tokyo, roughly 1997. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
Re: national security
Dear Vint, thank you for commenting on the Internet national survival kit issue this way (we are one week before the last Geneva prepcom, where ICANN is disputed in a way the survival kit may affect). Our common goal is to help consensus, not to increase tensions. At 19:54 29/11/03, vinton g. cerf wrote: >OK, the big issue for those countries that want ICANN to be disbanded and for the Internet to be handed over to the ITU is quite simple: ICANN is a US-government controlled entity subject to US/Californian law. Please read the most recent MOU. The US Department of Commerce has gone to considerable effort to outline the path by which ICANN becomes the party responsible for the updating of the DNS root. The control you assert is quite limited even today. Objection is not that you are the root registry, but the USA and you are the registrant. RFC 1591 says IANA is not in the business of defining a country. Why to intrefere with countries? What is the intrinsic difference between root and TLD updates? The post KP&Quest updates are a good example of what Govs do not want anymore. Any formal body has to have some jurisdiction in which it is constituted. One can argue whether California non-profit law is better or worse than being a UN entity. I believe there are arguments against the latter as much as there may arguments against the former. The complexity is that ICANN wants to be two conflicting things (American and International) and to organize something multinational. that's not at all clear. ICANN has tried to promote the adoption of IDN, for example, in a responsible way. John Klensin's efforts, and others, to promote international compatibility to enhance the ability for parties to communicate is commendable. What do you think is awful? The IDN solution! :-) it was doomed when ICANN refused it to be multilingual. Let not dispute on that. Vernacularization may come from a true internationalization (0 to Z) on the LHS. May be Keith Moore will find a reasonable way. >The IETF is about as close as we've got as an "authority" on the Internet that is not bounded by geographic boundaries, governmental control or commercial contract. You can make a reasonable argument that we should be running the show here, not ICANN. Not unless you want to take on the full burden of Internet Governance written large. Not even ICANN wishes to do that. In fact, ICANN's role is very limited compared to the full scope of Internet Governance. Four language problems in here I doubt we can reduce. ICANN understands its governance role as global coordination of the network. Our respective cultures have opposite understandings for governance, global, coordination (we will accept concertation), network. I suppose other cultures and languages have others. You probably stay in the middle. Hence your need to explain again and again "we are not what you believe we are". Should this not be plain obvious for now. Consider the French (original) meaning of "gouvernance". For networks it would be "net keeping". Many ICANN relational problem would disappear. Issues such as fraud, taxation, intellectual property protection, dispute resolution, illegal actions are governmental matters and not even UN has the appropriate jurisdiction. It will take cooperation among governments and thoughtful domestic legislation to deal with many of these matters. ICANN has high regard for IETF and IAB and for that reason there is an IAB liaison appointed to the Board of Directors. >The UNITC meeting needed to happen several years ago, but now we're there, realistically there is only one option left for a single, cohesive Internet to remain whilst taking into account ALL the World's population: ICANN needs to become a UN body. nonsense - as constituted today, ICANN is a better forum for interested constituencies to debate policy FOR THOSE AREAS THAT ARE IN ICANN'S PURVIEW (not shouting, just emphasis on limited purview of ICANN). We all will accept the word "forum". The role I assign to ICANN is to guest forums and to cross polenize among them. Why then to force participants to abide by your by-laws to come (ccTLDs). Paul Twomey's Nov. 19th paper is a contention point. It is seen as a bold ICANN move before the 5/6th meeting. And your own response about ccTLDs. What would be the difference if the ccNSO resulted from an MoU? It would permit to help/join with ccTLDs, and RIRs, over a far more interesting ITU-I preparation. I suppose RIRs would not be afraid an ITU-I would not be here 2 years from now. The problem with the arguments I have heard, including yours, is that you may be thinking of Internet Governance in the large while ICANN's role is small and should stay that way. We need other venues in which to deal with the larger problems and perhaps UN or some of its constituents have a role to play. Probably WIPO and WTO do as well. Agreement. Then why to have built a big machine to be the IANA + a
Re: national security
At 03:39 PM 11/29/2003 -0800, Karl Auerbach wrote: >On Sat, 29 Nov 2003, vinton g. cerf wrote: > >> I strongly object to your characterization of ICANN as "abandoning" >> the operation of roots and IP address allocation. These matters have >> been the subject of discussion for some time. > >I can't seem to recall during my 2 1/2 years on ICANN's board that there >ever was any non-trivial discussion, even in the secrecy of the Board's >private e-mail list or phone calls, on the matters of IP address >allocation or operation of the DNS root servers. Because I was the person >who repeatedly tried to raise these issues, only to be repeatedly met with >silence, I am keenly aware of the absence of any substantive effort, much >less results, by ICANN in these areas. The fact that there were few board discussions does not mean that staff was not involved in these matters. Discussions with RIRs have been lengthy and have involved a number of board members. >So, based on my source of information, which is a primary source - my own >experience as a Director of ICANN, I must disagree that ICANN has actually >faced either the issue of DNS root server operations or of IP address >allocation. And ICANN's "enhanced architecture for root server security" >was so devoid of content as to be embarrassing - See my note at >http://www.cavebear.com/cbblog-archives/07.html > >The DNS root server operators have not shown any willingness to let ICANN >impose requirements on the way they run their computers. Indeed, the >deployment of anycast-based root servers without even telling ICANN in >advance, much less asking for permission, is indicative of the distance >between the operations of the root servers and ICANN. Sorry, anycast has been out there for quite a while; I am surprised you didn't know that. We had discussions about anycast with the SECSAC and the RSSAC and confirmed that there were few risks. The GAC requested and received a briefing on this as well. >[I believe that the anycast change was a good one. However, there is no >way to deny that that change was made independently of ICANN.] Anycast may even have preceded the creation of ICANN - perhaps an IETF source or one of the root server operators can say when the first ANYCAST deployments were done. >Sure, ICANN prepares, or rather, Verisign prepares and ICANN someday hopes >to prepare, the root zone file that the DNS root servers download. But to >say that preparation of a small, relatively static, text file is the same >as overseeing the root servers is inaccurate. > >In addition, the root server operators have shown that they are very able >to coordinate among themselves without ICANN's assistance. > >> ICANN absolutely recognizes the critical role of the RIRs > >Again, recognizing the RIRs is an admission that ICANN has abandoned its >role as the forum in which public needs for IP addresses and technical >demands for space and controled growth of routing information are >discussed and balanced. Fortunately the RIRs have matured and are >themselves the IP address policy forums that ICANN was supposed to have >been. Moreover, the RIRs have shown that they are more than capable of >doing a quite good job of coordinating among themselves. The RIRs have agreed to use the ASO as the mechanism for conducting global policy discussions - you seem to think that unless ICANN is dictating everything it is doing nothing. Sorry, I don't buy it. >> There is still need for coordination of policy among these groups >> and the other interested constituents and that is the role that >> ICANN will play. > >Again, ICANN can not demonstrate that it has engaged, because it has not >engaged, in the "coordination" of IP address "policy". Sure, ICANN has >facilitated the creation of a couple of new RIRs. But again, there is >vast distance between that and ICANN being the vehicle for policy >formulation or oversight to ensure that those policies are in the interest >of the public and technically rational. > > >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 - you are setting up a strawman that I don't buy into, karl. What we are looking for is coordination of policy development in such a way that affected parties have an opportunity to raise issues. That's what the reform of the ICANN process was all about. I am not interested in having the decision of the Board of Directors supersede RIR or Root Server recommendations. I am interested in assuring that any policies developed have input from affected constituencies and that these are fa
Re: national security
On Sat, 29 Nov 2003, vinton g. cerf wrote: > I strongly object to your characterization of ICANN as "abandoning" > the operation of roots and IP address allocation. These matters have > been the subject of discussion for some time. I can't seem to recall during my 2 1/2 years on ICANN's board that there ever was any non-trivial discussion, even in the secrecy of the Board's private e-mail list or phone calls, on the matters of IP address allocation or operation of the DNS root servers. Because I was the person who repeatedly tried to raise these issues, only to be repeatedly met with silence, I am keenly aware of the absence of any substantive effort, much less results, by ICANN in these areas. So, based on my source of information, which is a primary source - my own experience as a Director of ICANN, I must disagree that ICANN has actually faced either the issue of DNS root server operations or of IP address allocation. And ICANN's "enhanced architecture for root server security" was so devoid of content as to be embarrassing - See my note at http://www.cavebear.com/cbblog-archives/07.html The DNS root server operators have not shown any willingness to let ICANN impose requirements on the way they run their computers. Indeed, the deployment of anycast-based root servers without even telling ICANN in advance, much less asking for permission, is indicative of the distance between the operations of the root servers and ICANN. [I believe that the anycast change was a good one. However, there is no way to deny that that change was made independently of ICANN.] Sure, ICANN prepares, or rather, Verisign prepares and ICANN someday hopes to prepare, the root zone file that the DNS root servers download. But to say that preparation of a small, relatively static, text file is the same as overseeing the root servers is inaccurate. In addition, the root server operators have shown that they are very able to coordinate among themselves without ICANN's assistance. > ICANN absolutely recognizes the critical role of the RIRs Again, recognizing the RIRs is an admission that ICANN has abandoned its role as the forum in which public needs for IP addresses and technical demands for space and controled growth of routing information are discussed and balanced. Fortunately the RIRs have matured and are themselves the IP address policy forums that ICANN was supposed to have been. Moreover, the RIRs have shown that they are more than capable of doing a quite good job of coordinating among themselves. > There is still need for coordination of policy among these groups > and the other interested constituents and that is the role that > ICANN will play. Again, ICANN can not demonstrate that it has engaged, because it has not engaged, in the "coordination" of IP address "policy". Sure, ICANN has facilitated the creation of a couple of new RIRs. But again, there is vast distance between that and ICANN being the vehicle for policy formulation or oversight to ensure that those policies are in the interest of the public and technically rational. 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. --karl--
Re: national security
Karl, I strongly object to your characterization of ICANN as "abandoning" the operation of roots and IP address allocation. These matters have been the subject of discussion for some time. ICANN absolutely recognizes the critical role of the RIRs and the voluntary root servers as part of the complex that makes up the operation Internet. There is still need for coordination of policy among these groups and the other interested constituents and that is the role that ICANN will play. At the completion of the MOU period, ICANN will also be responsible for the primary root zone file and the server that supplies it to the rest of the root server operators. At 01:14 PM 11/29/2003 -0800, Karl Auerbach wrote: >ICANN has abandoned the actual operation of the dns root servers to those >who are actually doing that job. This is a very good thing because the >latter group are not merely extremely competent, but they are also clearly >focused on the job of running root servers and have shown that they do not >care to use their role to enforce someone's idea of intellectual property >protection. > >And ICANN has abandoned the allocation of IP addresses to the regional IP >address registries. Again this is a good thing because there are few >within ICANN who remember that this was one of ICANN's three original >purposes, much less understand the technical and economic impact of >address allocation policies. The RIRs, on the otherhand *do* understand >this. Vint Cerf SVP Technology Strategy MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax [EMAIL PROTECTED] www.mci.com/cerfsup
Re: national security
On Sat, 29 Nov 2003, Paul Robinson wrote: > ... realistically there is only one option left for a single, > cohesive Internet to remain whilst taking into account ALL the World's > population: ICANN needs to become a UN body. If you look at what ICANN really and truly does you will see that it has little, if any, real role relating to internet technology. Rather it is an organization that, for the most part, imposes the business goals of a selected and limited set of priviliged "stakeholders" onto the operation of businesses that sell domain names. Moving ICANN from the blind-oversight of the US Deparment of Commerce to the UN or ITU ill only widen the stage for those privileged "stakeholders". A move to the UN or ITU, by itself, will not improve the security of the net or or any nation. Without major structural reforms (such as I suggest at http://www.cavebear.com/rw/apfi.htm ) ICANN will remain a non-technical body that regulates and governs internet business practices. As for this thread - national security - One has to remember that ICANN's reaction to 9/11 was to create a committee. That committee is filled with intelligent and skilled worthies, many of whom have deep IETF roots. However that committee, with respect to the matter of security, was essentially stillborn and silent. It has only come to life recently as a vehicle to rebut Verisign's "Sitefinder". As an institutional matter, ICANN has demonstrated that it really is not suited to deal with the technical issues of security, much less the intricate balancing of public policy in which security choices must necessarily be made. Moving ICANN to the UN will not, without major structural changes in ICANN, improve this. Some of those changes have occurred already: ICANN has abandoned the actual operation of the dns root servers to those who are actually doing that job. This is a very good thing because the latter group are not merely extremely competent, but they are also clearly focused on the job of running root servers and have shown that they do not care to use their role to enforce someone's idea of intellectual property protection. And ICANN has abandoned the allocation of IP addresses to the regional IP address registries. Again this is a good thing because there are few within ICANN who remember that this was one of ICANN's three original purposes, much less understand the technical and economic impact of address allocation policies. The RIRs, on the otherhand *do* understand this. Personally I do not care whether ICANN is under the US Department of Commerce or becomes a branch of the ITU. Both are imperfect. As a US Citizen I can (and have) gone to the DoC and argued my side. I'd probably have a smaller voice where things to move to the ITU. On the other hand, most of the people in the world are not US citizens and thus could find the ITU more open to them. For me the core issue is not under what banner ICANN exists. For me the issue is restructuring ICANN-like vehicles of internet governance into things that really have a synoptic view, that are not captured by a few selected commercial "stakeholders", and that need not be brought before a judge (as I had to do with ICANN) in order to compel them to be open, transparent, and accountable. > Neither do I, but ICANN have clearly demonstrated: > 3. Putting Computer Scientists in charge of anything is fundamentally a > bad idea Let's dispell a big chunk of that myth - ICANN has never been controlled by computer scientists. The board has a always had a few people with rich knowledge of the internet, but they were always a very tiny minority. Let us not forget that one of ICANN's first acts was to dismantle the job of "Chief Technology Officer". The myth that ICANN is run by network experts has caused great damage. First of all, there is no reason to believe that those versed in computer science are more capable of making public policy decisions than others. That myth of the Golden Age of Technical Kings died at the end of the 1930's. [Take a look at the H.G. Wells movie "Things To Come" to see that myth in full flower.] Second, the myth has created a screen of deference that hides the acts of those privileged "stakeholders" who have proven to be very skilled at using ICANN to promote certain intellectual property agendas to the exclusion of nearly everything else. > In fact, they have shown they are worse at being in charge than > politicians and lawyers... Most of the people involved in all of this affair are good, smart, and well intended. There are few Iagos. ICANN is a glimpse of the future that occurs when groups with different values and different uses of a common language don't spend the time to really work down to fundamental issues and goals. I blame much of this on e-mail. E-mail impedes the development of those personal contacts that are necessary to build the trust needed to bridge the differences of opinion and find the c
Re: national security
At 05:49 PM 11/29/2003 +, Paul Robinson wrote: >John C Klensin wrote: > >>With regard to ICANN and its processes, I don't much like the >>way a good deal of that has turned out, even while I believe >>that things are gradually getting better. I lament the set of >>decisions that led to the US Govt deciding that it needed to be >>actively involved and to some of the risks, delays, and socially >>undesirable statements that situation has created. > >OK, the big issue for those countries that want ICANN to be disbanded and for the >Internet to be handed over to the ITU is quite simple: ICANN is a US-government >controlled entity subject to US/Californian law. Please read the most recent MOU. The US Department of Commerce has gone to considerable effort to outline the path by which ICANN becomes the party responsible for the updating of the DNS root. The control you assert is quite limited even today. Any formal body has to have some jurisdiction in which it is constituted. One can argue whether California non-profit law is better or worse than being a UN entity. I believe there are arguments against the latter as much as there may arguments against the former. >That's great if you're the US government and even semi-reasonable if you're an >American. Absolutely awful if you're Chinese or Korean. that's not at all clear. ICANN has tried to promote the adoption of IDN, for example, in a responsible way. John Klensin's efforts, and others, to promote international compatibility to enhance the ability for parties to communicate is commendable. What do you think is awful? >The IETF is about as close as we've got as an "authority" on the Internet that is not >bounded by geographic boundaries, governmental control or commercial contract. You >can make a reasonable argument that we should be running the show here, not ICANN. Not unless you want to take on the full burden of Internet Governance written large. Not even ICANN wishes to do that. In fact, ICANN's role is very limited compared to the full scope of Internet Governance. Issues such as fraud, taxation, intellectual property protection, dispute resolution, illegal actions are governmental matters and not even UN has the appropriate jurisdiction. It will take cooperation among governments and thoughtful domestic legislation to deal with many of these matters. ICANN has high regard for IETF and IAB and for that reason there is an IAB liaison appointed to the Board of Directors. >The UNITC meeting needed to happen several years ago, but now we're there, >realistically there is only one option left for a single, cohesive Internet to remain >whilst taking into account ALL the World's population: ICANN needs to become a UN >body. nonsense - as constituted today, ICANN is a better forum for interested constituencies to debate policy FOR THOSE AREAS THAT ARE IN ICANN'S PURVIEW (not shouting, just emphasis on limited purview of ICANN). The problem with the arguments I have heard, including yours, is that you may be thinking of Internet Governance in the large while ICANN's role is small and should stay that way. We need other venues in which to deal with the larger problems and perhaps UN or some of its constituents have a role to play. Probably WIPO and WTO do as well. >>general". So, while ICANN, IMO, continues to need careful >>watching -- most importantly to be sure that it does not expand >>into "governance" issues that are outside its rational scope-- I >>don't see "give it to XXX" or "everyone runs off in his own >>direction" as viable alternatives. > >Neither do I, but ICANN have clearly demonstrated: > >1. They don't listen to us, or those parties who have a genuine vested interest in >the Internet, UNLESS that party is a US Commercial or Governmental entity. I disagree - please consider the last ICANN meeting in which the Board went some distance to making changes in its policies in response to international constituency inputs. >2. Their incompetence at politcal levels has actually caused a delay in making the >Internet available to those countries that need access to affordable communications >infrastructures the most. Sorry, it is a lot more complex than you seem to think - the question of who should have responsibility for a CCTLD is often very complex - it is sometimes not even clear who the government of country X is. >3. Putting Computer Scientists in charge of anything is fundamentally a bad idea. In >fact, they have shown they are worse at being in charge than politicians and >lawyers... they will never get another chance after this god-awful mess. The Board is not made up of computer scientists alone; nor is the staff of ICANN. By your assertion, IETF should not be in charge of anything either. I disagree with that, too. >In ICANN's support, the alternative - the "ITU idea" - is *horrible*. The ITU is not >about open communications infrastrucutres - it's about *closed* infra
Re: national security
John C Klensin wrote: With regard to ICANN and its processes, I don't much like the way a good deal of that has turned out, even while I believe that things are gradually getting better. I lament the set of decisions that led to the US Govt deciding that it needed to be actively involved and to some of the risks, delays, and socially undesirable statements that situation has created. OK, the big issue for those countries that want ICANN to be disbanded and for the Internet to be handed over to the ITU is quite simple: ICANN is a US-government controlled entity subject to US/Californian law. That's great if you're the US government and even semi-reasonable if you're an American. Absolutely awful if you're Chinese or Korean. The IETF is about as close as we've got as an "authority" on the Internet that is not bounded by geographic boundaries, governmental control or commercial contract. You can make a reasonable argument that we should be running the show here, not ICANN. The UNITC meeting needed to happen several years ago, but now we're there, realistically there is only one option left for a single, cohesive Internet to remain whilst taking into account ALL the World's population: ICANN needs to become a UN body. general". So, while ICANN, IMO, continues to need careful watching -- most importantly to be sure that it does not expand into "governance" issues that are outside its rational scope-- I don't see "give it to XXX" or "everyone runs off in his own direction" as viable alternatives. Neither do I, but ICANN have clearly demonstrated: 1. They don't listen to us, or those parties who have a genuine vested interest in the Internet, UNLESS that party is a US Commercial or Governmental entity. 2. Their incompetence at politcal levels has actually caused a delay in making the Internet available to those countries that need access to affordable communications infrastructures the most. 3. Putting Computer Scientists in charge of anything is fundamentally a bad idea. In fact, they have shown they are worse at being in charge than politicians and lawyers... they will never get another chance after this god-awful mess. In ICANN's support, the alternative - the "ITU idea" - is *horrible*. The ITU is not about open communications infrastrucutres - it's about *closed* infrastructures with contracts and licensing and costs and the other paraphenalia we want to limit the effect of in the context of the Internet. On the other hand, one of the nice things about the network as it is now constituted is that anyone has the option of opting-out: disconnecting, setting up a private DNS and a private addressing system, and communicating, if at all, through a restrictive, address-and-protocol-translating gateway. We No, no, no, NO. To allow this would to happen would be a genuine shame. How popular is Internet2? Why? I rest my case... -- Paul Robinson
Re: national security
At 15:20 28/11/03, Jaap Akkerhuis wrote: While parallel issues start being discussed and better understood at WSIS, we have next week a meeting on Internet national security, sovereignty and innovation capacity. Who is "we" in above paragraph? Hi! Jaap, "we" is a public open follow-up of the "dot-root" study. If you have French and want to participate you are welcome. It will be held in Paris on Dec. 3rd 14:30 PM. I can mail you the perparatory document if you want. It is reserved to decision makers in potential subsequent actions. jfc
RE: national security
Iljitsch, Stop feeding the troll please. Michel.
Re: national security
On Fri, 28 Nov 2003 14:47:41 +0100 "Anthony G. Atkielski" <[EMAIL PROTECTED]> wrote: > (or perhaps not diminished at all). However, in reality, dividing the > field in this way may reduce the address space by a factor of as much > as nineteen orders of magnitude. Again and again, engineers make this > mistake, and render large parts of an address space unusable through > careless, bit-wise allocation of addresses in advance. The 48-bit addresses in IEEE/L2 protocols are divided in half as well as have a couple bits set aside to denote local/global scope and unicast/multicast addresses. It seems to have worked out pretty well. John
Re: national security
While parallel issues start being discussed and better understood at WSIS, we have next week a meeting on Internet national security, sovereignty and innovation capacity. Who is "we" in above paragraph? jaap
Re: national security
Anthony, In the multi6 (multihoming in IPv6) working group, as one of many proposals, we've been looking at putting a 64 bit host identifier in the bottom 64 bits of an IPv6 address. If such a host identifier is crypto-based (ie, a hash of a public key) then it is possible to authenticate a host at any time regardless of where the host connects to the network at that particular time and without the need for a PKI or prior communication. This is precisely the kind of mistake that will exhaust the entire IPv6 address space just as quickly as the IPv4 address space. Don't engineers ever learn from the past? I can't claim to know too much about the specific details in the multi6 proposal, but there has been other efforts that use cryptographic identifiers as parts of addresses. However, I do not believe these proposals consume any more address space than, say, manual or EUI-64 based address assignment. There's still just one address consumed per node. Perhaps you were thinking that the address contains a MAC field? This isn't strictly speaking the case, at least not in the way that the MAC value would change from one packet to another. Anyway, back to the subject of "national security"... I have a question. The main goal appears to be the reduction of dependencies between network parts, in order to prepare for catastrophic situations. This is useful goal, though I'm not sure I agree with all the listed specific items. Are any of the issues that have been talked about being addressed in the IEPREP WG, or is that group mainly focused on the SIP/ telecom type of issues only? --Jari
Re: national security
On 27-nov-03, at 23:20, jfcm wrote: Some others have technical implications. I would like to quote some suggestions listed in the preparatory document, to get advices I could quote at the meeting or in its report. Also to list the alternative and additional suggestions some might do. Ok, I'm not going to quote all the details... This looks like a big old bag of DNS tricks. Obviously the virtue of each can be discussed individually, but wouldn't it make more sense to start thinking about a more structured approach to arrive at the intended benefits? For instance, one issue seems to be the ability to continue to reach systems using domain names when there is a problem with the DNS infrastructure. This could be addressed by modifying the caching mechanisms in DNS resolvers. The way things are done now is throw away the old shoes (cached information) and then see if new ones can be found. Rather bizarre if you think about it. 2. a menu server system permitting to access sites though their IP address only. This would be a good promotion for IPv6 due to the easiness to support IP virtual hosts addresses. As a security oriented alternative to the NSI network unstabilization. This could lead to pressure to make IP addresses more portable, which isn't a good thing. 6. an evolution towards an international root matrix supporting proximity root servers and proximity TLDs for abbreviated addressing through local TLDs. The organization and the procedure of the common authoritative root matrix should be internationally approved and subject to the ICP-3 proposed testing rules. A quoted example documents the target as "hart.sos" of pacemakers always resolving to the nearest hospital (as decided by local authorities). This isn't something you can do with simple (or even not so simple) n-faced DNS. For instance, here in the Netherlands many service providers backhaul all their traffic to Amsterdam over the phone infrastructure (dial-up) or ATM (DSL). Those customers then share IP address space and DNS resolvers. Getting the location info back in there would be almost impossible. However, it could be useful to create mechanisms that make it easier for hosts to discover location information. For instance, through a DHCP option. This information can then be used when searching directories or search engines. (This would have interesting commercial possibilities as well.) - a national host numbering scheme. With an immediate identification of any host on any network whatever the location change or connection organized. This second would also protect IPv6 technology and equipment from a K2 like syndrome when a new plan could be discussed, as it would have permitted to validate the multiple plan possibility. In the multi6 (multihoming in IPv6) working group, as one of many proposals, we've been looking at putting a 64 bit host identifier in the bottom 64 bits of an IPv6 address. If such a host identifier is crypto-based (ie, a hash of a public key) then it is possible to authenticate a host at any time regardless of where the host connects to the network at that particular time and without the need for a PKI or prior communication. (I have no idea what "K2 syndrome" means by the way, and it looks like Google doesn't either.)
RE: national security
Sorry for the typo - I miss my glasses :-) - http://rs.internic.net (not ns.internic.net as I typed). jfc
