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[2]: national security
Iljitsch van Beijnum writes: > 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?
Re: Re[2]: national security
On 28-nov-03, at 13:04, Anthony G. Atkielski wrote: 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 guess not because I have no idea what you're talking about.
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[4]: national security
Iljitsch van Beijnum writes: > I guess not because I have no idea what you're talking about. There is a natural tendency to think that by dividing a 128-bit address field into two 64-bit fields, the address space is cut in half (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. For example, if you assign addresses sequentially, you can address up to 2^128 hosts with a 128-bit address. If you divide the address field into two 64-bit fields--one for the country and one for those within the country, say--intuitively you might think that you've only slightly reduced the total number of available addresses. In fact, however, you've dramatically diminished the size of the address space. Unless you have exactly 2^64 countries in the world, each of which contains exactly 2^64 hosts, very large segments of the address space will be wasted. The effective address space may be many trillions of times smaller than you expect. And you may find yourself exhausting that address space far more quickly than you ever thought possible. When you divided an address field into bit-wise fields, you encode information into the address. This introduces redundancy, which reduces the usable address space. If you allocate a country code to one country in the example above, for instance, and that country has only 1000 computers, you've just wasted roughly 18,446,744,073,700,000,000 machine addresses. Do this for multiple countries, and you could easily waste almost all your address space simply due to this extremely foolish division of the address field. It's unlikely you'll have 2^64 countries to accommodate; and it's equally unlikely that each of these countries will have exactly 2^64 hosts (no more, no less) to address, so you are wasting many bits of the address field. And the wasted space increases exponentially with the number of wasted bits. Wasting ten bits instead of five bits doesn't waste twice the space, it wastes _32 times_ the space. I've often felt that the most common mistake made by engineers in designing systems, especially computer systems, is underestimation of capacity, and wastage of existing capacity. Dividing address fields into preallocated zones is the most common example of this. They just never learn, and they cannot be told. They are always convinced that there's more space than anyone will ever need in their address field, and by the time they find out otherwise, it's too late. It happened with IPv4, 16-bit addresses, and 32-bit addresses; it will soon happen with 64-bit addresses and with IPv6. I don't understand how engineers can be so stupid in this one specific domain.
Re[2]: national security
Jari Arkko writes: > However, I do not believe these proposals consume any > more address space than, say, manual or EUI-64 > based address assignment. In order to use the full potential address space, you must devise a scheme that allocates every single combination of bits. The simplest scheme of this kind is sequential allocation of addresses. > There's still just one address consumed per > node. It's not the number consumed; it's the number excluded from availability by the encoding of information into the address field. You might easily waste 99% of the address space in this way. > Perhaps you were thinking that the address contains a MAC field? No. I'm thinking that the address field is being divided into zones, thus wasting a tremendous amount of space. A 128-bit field contains 2^128 addresses. If you divide that into two 64-bit fields, you may get as few as 2^64*2 addresses; that's 18 million trillion times smaller than the 128-bit field.
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: Re[2]: national security
From: "Anthony G. Atkielski" <[EMAIL PROTECTED]> To: "IETF Discussion" <[EMAIL PROTECTED]> Sent: Friday, November 28, 2003 7:52 AM Subject: Re[2]: national security > > In order to use the full potential address space, you must devise a > scheme that allocates every single combination of bits. The simplest > scheme of this kind is sequential allocation of addresses. Well, sure. And then you do routing aggregation how? I also deplore the waste of bits, and would love to hear alternatives... Spencer
Re[4]: national security
See RFC 1715, November 1994, and the endless discussions that appeared on a variety of mailing list about IPv6 addresses. Thanks, Donald == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-786-7554(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Fri, 28 Nov 2003, Anthony G. Atkielski wrote: > Date: Fri, 28 Nov 2003 14:47:41 +0100 > From: Anthony G. Atkielski <[EMAIL PROTECTED]> > To: IETF Discussion <[EMAIL PROTECTED]> > Subject: Re[4]: national security > > Iljitsch van Beijnum writes: > > > I guess not because I have no idea what you're talking about. > > There is a natural tendency to think that by dividing a 128-bit address > field into two 64-bit fields, the address space is cut in half (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. > > ...
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: Re[2]: national security
On Fri, 28 Nov 2003 14:52:11 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said: > A 128-bit field contains 2^128 addresses. If you divide that into two > 64-bit fields, you may get as few as 2^64*2 addresses; that's 18 > million trillion times smaller than the 128-bit field. Exactly. And the *reason* why IPv6 has 128 bit addresses is because the designers realized that such losses happen, and ruled out 64-bit addresses because of that effect. I suggest you figure out just how much bigger 2^65 is than the current 2^32, and factor in the current burn rate on the unused IPv4 addresses, and from there figure out if there's really a problem there at all pgp0.pgp Description: PGP signature
Re: Re[4]: national security
On 28-nov-03, at 14:47, Anthony G. Atkielski wrote: I guess not because I have no idea what you're talking about. There is a natural tendency to think that by dividing a 128-bit address field into two 64-bit fields, the address space is cut in half (or perhaps not diminished at all). Ah, I see what you mean now. However, the devision is a done deal as RFC 3513 mandates that all unicast IPv6 addresses except the ones starting with the bits 000 must have a 64-bit interface identifier in the lower 64 bits. This has some important advantages, most notably it allows stateless autoconfiguration. (However, this could have been done with 48 bits too.) But it does have the downside you mention by only leaving 64 bits for numbering subnets. The practice of giving all sites a /48 further deminishes the available bits. The situation is most notable in the case of a home user, who would get a single IPv4 address but gets a /48 in IPv6. So we've quadrupled our address space (in bits) for a 50% gain... (Obviously the situation is much better when looking at a university that has a /16 now and also gets a /48 as well.) Putting a 64-bit crypto-based host identifier in the bottom 64 bits of IPv6 addresses shouldn't get in the way of regular IPv6 addressing mechanisms and/or operation. There is even a trick to make sure there is no overlap with either MAC addresses/EUI-64s on the one hand and most manually configured addresses and RFC 3041 on the other hand by only using EUI-64 compatible values with the universal/local bit set to globally unique, but with the group bit set. It's unlikely you'll have 2^64 countries to accommodate; and it's equally unlikely that each of these countries will have exactly 2^64 hosts (no more, no less) to address, so you are wasting many bits of the address field. The plan isn't to encode a country in the first 64 bits. However, together with someone else I came up with an unrelated proposal a while ago that does encode a country in the IPv6 address. (You can find it at http://www.muada.com/drafts/ under the name "gapi".) In this proposal we use 16 bits to allocate a /32 to regions with 250 - 500 thousand inhabitants, so there is no fixed boundary for the country number.
Re[5]: national security
Donald Eastlake 3rd writes: > See RFC 1715, November 1994, and the endless discussions that appeared > on a variety of mailing list about IPv6 addresses. I guess the endless discussions didn't help, but that doesn't surprise me.
Re[4]: national security
Spencer Dawkins writes: > Well, sure. And then you do routing aggregation how? I was describing the simplest scheme that ensures use of the entire address space, nothing more. > I also deplore the waste of bits, and would love to hear > alternatives... I've described alternatives before, but nobody was interested.
Re[4]: national security
[EMAIL PROTECTED] writes: > Exactly. And the *reason* why IPv6 has 128 bit addresses is because > the designers realized that such losses happen ... Such losses don't just happen. They are the result of incompetent engineering.
Re[4]: national security
[EMAIL PROTECTED] writes: > Exactly. And the *reason* why IPv6 has 128 bit addresses is because > the designers realized that such losses happen, and ruled out 64-bit > addresses because of that effect. Since those losses are not significantly diminished by doubling the address length, why bother? The problem arises when zones of the address are reserved. Setting aside n bits of an m-bit address diminishes the address space by 2^n, not by (m-n)/m. > I suggest you figure out just how much bigger 2^65 is than the > current 2^32 ... 33 bits You're making the same mistake as everyone else: You calculate the size of the address space as 2^n, but you believe that reserving m bits diminishes the address space by only m.
Re[6]: national security
Iljitsch van Beijnum writes: > Ah, I see what you mean now. However, the devision is a done deal as > RFC 3513 mandates that all unicast IPv6 addresses except the ones > starting with the bits 000 must have a 64-bit interface identifier in > the lower 64 bits. This has some important advantages, most notably it > allows stateless autoconfiguration. (However, this could have been done > with 48 bits too.) But it does have the downside you mention by only > leaving 64 bits for numbering subnets. The practice of giving all sites > a /48 further deminishes the available bits. Wow ... it's even worse than I thought! Why bother even going to IPv6? > So we've quadrupled our address space (in bits) for a 50% gain ... A 50% gain in what? Has it occurred to anyone that allocating entire bit ranges in advance is a bit presumptuous, since nobody really has any idea how addresses will be used decades from now? > In this proposal we use 16 bits to allocate a /32 to regions > with 250 - 500 thousand inhabitants, so there is no fixed boundary > for the country number. See above. It's a mistake, and time will prove this.
RE: national security
Iljitsch, Stop feeding the troll please. Michel.
Re: Re[4]: national security
On Fri, 28 Nov 2003 20:06:26 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said: > 33 bits 8,589,934,592 times as many addresses. At current burn rates, it will take us some 20 years to go through the *current* free IPv4 space. And nobody's proposed any killer app that will take millions of times more address space. pgp0.pgp Description: PGP signature
Re: Re[4]: national security
On Fri, 28 Nov 2003 18:40:53 +0100, Iljitsch van Beijnum said: > a /48 further deminishes the available bits. The situation is most > notable in the case of a home user, who would get a single IPv4 address > but gets a /48 in IPv6. So we've quadrupled our address space (in bits) > for a 50% gain... (Obviously the situation is much better when looking > at a university that has a /16 now and also gets a /48 as well.) OK, so a /48 has 50% more bits than a /32. On the other hand, I've heard no *major* problems with end users getting their /32 from their provider, and there's 65,536 more /48s. Also, remember that many end users are getting *multiple* IP's from their provider for SOHO use, and they'll only need one /48. pgp0.pgp Description: PGP signature
Re[6]: national security
[EMAIL PROTECTED] writes: > OK, so a /48 has 50% more bits than a /32. On the other hand, > I've heard no *major* problems with end users getting their /32 from > their provider, and there's 65,536 more /48s. Also, remember that many > end users are getting *multiple* IP's from their provider for SOHO use, > and they'll only need one /48. A problem with this reasoning is that it makes a lot of questionable assumptions about who needs how many addresses ... assumptions that will have consequences for many decades to come, even though they will almost certainly be wrong. Isn't /48 far too much for one end user? Then again, isn't it far too little? Who really knows either way? What will the requirements be 30 years from now? Why not resist the engineer's temptation to try to make all these decisions immediately? I've always been surprised by how few software engineers are willing to mark anything "reserved for future use." They feel a compulsion to find a purpose and allocation for every single bit right now, no matter how foolish or ill-conceived that might turn out to be twenty years from now. It's as if leaving a fudge factor for the unknown were some sort of admission of weakness.
Crypto tokens in addresses
> 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. There is a very advanced proposal to do just that in the SEND working group. You should check the drafts, and in particular the definition of "Cryptographically Generated Addresses (CGA)": http://www.ietf.org/internet-drafts/draft-ietf-send-cga-02.txt The purpose of SEND is "secure neighbor discovery", i.e. preventing such things as ARP spoofing. -- Christian Huitema
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[2]: national security
Dear Anthony, RFC 2373 permits 6 plans. The best would be to organize them by purpose. Not them all to do the same thing. Here we talk about national security not about intellectual elegance. When you are at war, you want your network to continue operating, not to depend on a numeration optimisation by your ennemy. If, due to that, you must lose some fancy facilities you probably find that acceptable. To evaluate what you lose is the purpose of my question, to permit governements to decide what they want - not to be imposed by the nsicanntiab. I am sure that many security officers or generals would feel unatease if they known their HQ IPv6 address can be just one unknown bit different from the IPv6 address of a ennemy computer. Makes security very complex. What they want is an address mask, if possible manual, telling them where they are and where the call comes from. This is also the need of commercial international sites, who want to indentify the country of origin to speak in the proper language. As well as VOiP users. And please do not tell me that this is a breach on the calling party's privacy. The breach is the call by nature. jfc At 14:52 28/11/03, Anthony G. Atkielski wrote: Content-Transfer-Encoding: 7bit Jari Arkko writes: > However, I do not believe these proposals consume any > more address space than, say, manual or EUI-64 > based address assignment. In order to use the full potential address space, you must devise a scheme that allocates every single combination of bits. The simplest scheme of this kind is sequential allocation of addresses. > There's still just one address consumed per > node. It's not the number consumed; it's the number excluded from availability by the encoding of information into the address field. You might easily waste 99% of the address space in this way. > Perhaps you were thinking that the address contains a MAC field? No. I'm thinking that the address field is being divided into zones, thus wasting a tremendous amount of space. A 128-bit field contains 2^128 addresses. If you divide that into two 64-bit fields, you may get as few as 2^64*2 addresses; that's 18 million trillion times smaller than the 128-bit field.
Re[3]: national security
jfcm writes: > I am sure that many security officers or generals would feel unatease if > they known their HQ IPv6 address can be just one unknown bit different from > the IPv6 address of a ennemy computer. Nah ... security officers and generals--if they are competent--don't put their HQ computers on an open network in the first place. That only happens in the movies.
Re: Re[3]: national security
On Fri, 28 Nov 2003 23:20:20 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said: > jfcm writes: > > > I am sure that many security officers or generals would feel unatease if > > they known their HQ IPv6 address can be just one unknown bit different from > > the IPv6 address of a ennemy computer. > > Nah ... security officers and generals--if they are competent--don't put > their HQ computers on an open network in the first place. That only > happens in the movies. OK.. change "HQ computer" to "www.ANYTHINGBIG.com", and change "enemy" to "random hacker in another country". There's boxes that *have* to be visible to the world because they provide service and connectivity to the outside world - and you can't even hand-wave "put them in a DMZ" because then you still need that address mask to tell if the other end of the connection is coming from outside, another DMZ machine, or an internal machine. pgp0.pgp Description: PGP signature
Re[3]: national security
At 23:20 28/11/03, Anthony G. Atkielski wrote: > I am sure that many security officers or generals would feel unatease if > they known their HQ IPv6 address can be just one unknown bit different from > the IPv6 address of a ennemy computer. Nah ... security officers and generals--if they are competent--don't put their HQ computers on an open network in the first place. That only happens in the movies. hmm... competence in this area is to accept that what happens in movies is just a small part of the real life. This being said, I note that this thread is only oriented to prospective numbering issues. May I take from that that none of the suggested propositions rises any concern ? In particular, that there is no problem with two parallel roots file if they want to be identical? What would happen if one was hacked? (I note that this is the current situation of the Internet where two deliveries of the same file are proposed). The same, no one comments on secondary source for the root, meaning that the ICANN unicity is not an intrisic need, provided the different root files collectors strive to collect the real data from the TLD Managers (who are authoritative, while the root file is not). Not a problem to anyone? No one either comment on private TLDs, or the creation of a virtual TLD used through Host.txt only. No one objects to the generalization of users resolvers, the possible resulting dissemination of the root file to all the users and their resulting ability to fight an ICANN redelegation what is a major issue at WSIS. If there are no major objection I will suggest that a "Nations Security propositions" dratf be written as Best Practices, based upon the introduced suggestions and the one the participants may want to add. This will be introduced at the comming WSIS december 5/6th final preparatory meeting and will help addressing concerns expressed by several countries. jfc
