... I also think that we need some way of representing those end-point identifiers as 128- or even 32-bit value, to be used in legacy APIs and withing the stack...
So the 128/32 bit representation wouldn't _be_ the identifier but only a representation?
Yes. See draft-moskowitz-hip-arch-03.txt for more reasoning behind this. But the basic reason for this is security, as I mentioned above. See also below.
Now, when I say that "end-point identifiers replace IP addresses", I am mostly speaking about the semantic change. ...
Are you saying that we should make a clear distinction between identifiers and locators, and not have any values that are valid in both realms?
Yes, in the long run. In the short run, we probably have to continue living in a world where there is no clear distinction between the two.
I do understand your point about the benefits of an identifier also being a locator, but I also believe that the benefits of clean separation will more than pay the drawbacks in the long run. (I don't have any analysis or data to support this belief, though.)
What comes to domain names, my primary concern is their lack of security,
How bad is this exactly?
The problems become worse when you add mobility. See below.
On the other hand, my (again poor) understanding from the recent Distributed Hash Table papers seems to indicate that it is fairly easy to use random strings as lookup keys in a distributed, Byzantineously robust lookup system.
Ok, not sure what you mean by "byzantineously robust" exactly and maybe I've missed a few of those papers, but so far nobody has been able to explain to me how you can build a DHT system using untrustworthy nodes. The best you can do is replicate the data to such a degree that it becomes very unlikely that all the nodes that hold the data collude to deceive you. If you think the DNS is bad, consider having a system where you need to depend on random strangers to be reachable...
With byzantine robustness I am more or less referring to the principles that Radia Perlman used in her PhD these. I think others have used the same principles before, but I am most familiar with Radia's work. It must be noted, though, that Radia used the term in the context of routing protocols, while here we are dealing with DHT directory services.
The basic assumption in byzantine robustness is that as long as the number of dishonest participants do not exceed a treshold ratio (e.g. one third of all participants), the system does not fail.
In the case of DHT servers, the more servers there are, the less likely it is that the treshold would be exceeded. Hence, even if you are relying on strangers, you are relying on them in a random manner, making any collusion highly unlikely, and impossible in practise.
Thirdly, nothing prevents one from arranging the identifier space in such a manner that they can be used as hierarchical lookup keys whenever such a lookup process is needed. I think that should be possible even for Hinden/Haberman addresses, since such a lookup system would have limited scope.
For administratively assigned address space this isn't a problem, but for randomly chosen address space it is.
If we need a global directory, then yes. However, if the directory only needs to deal with locally assigned "identifiers" (as in the case of Hinden/Haberman addresses), I don't see why it should be a problem.
If you use reachable PA as identifiers you have the option of connecting first and adding multihomedness later.
Yes, provided that your PA address works, right now.
It does _most_ of the time. ...
If you restrict your thinking to multi-homing, then yes. But if you add mobility, the situation is not that simple any more.
Let me take a counterexample. If you use PI addresses locally for administrative purposes (think SSH), you can use them even if your network is disconnected, going through renumbering, or otherwise failing to get any PA prefixes.
So you're saying: use PI first, PA as fallback?
I am saying that depending on application. When I last time used to run networks, I used different DNS names for administrative purposes (the "real" host names if you will) and for giving out to the users (the "service" names).
.... MIPv6 is here, now.
Really? Where is it implemented then?
E.g. http://www.mipl.mediapoli.com/. I think KAME will soon have it, too, if not already now in the snapshots.
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec- 01.txt tries to explain the most important ones of these problems.
Sorry, too long for a full read, and nothing really jumps out doing a quick scan.
Ok, some excerpts below.
Hmm. It may be a good idea to have multiple mechanisms to get the identifier->addresses mappings. However, it would be good if we had just a single control protocol and security mechanism for verifying that the mappings are "authorized" and do not endanger the infrastructure.
The control protocol IS the mechanism. Rather than spend a few years trying to make one that is all things to all people, I think we should start by making the simplest one we can possibly make and let everyone who feels they can do better have a go after that.
I am always in favour of beauty contests and market evaluations.
I'm not worried about security as these are end-to-end mechanisms. If two hosts feel they don't have to protect their communication, who are we to say that they must?
We need to protect the infrastructure. As I wrote, the danger is not that mcuh to the communicating hosts but to the infrastructure.
Some excepts from the above mentioned draft:
2.1 Target
Basically, the target of an attack can be any node or network in the Internet (stationary or mobile). The basic differences lie in the goals of the attack: does the attacker aim to *divert* (steal) the traffic destined to and/or sourced at the target node, or does it aim to cause denial-of-service to the target node or network. The target does not typically play much of a active role attack. As an example, an attacker may launch a denial-of-service attack on a given node A by contacting a large number of nodes, claiming to be A, and subsequently diverting the traffic at these other nodes so that A is harmed. A itself need not be involved at all before its communications start to break. Furthermore, A is not necessarily a mobile node; it may very well be stationary.
3.1.2 Stealing addresses of stationary nodes
The attacker needs to know or guess the IP addresses of both the source of the packets to be diverted (A in the example above) and the destination of the packets (B). This means that it is difficult to redirect *all* packets to or from a specific node because the attacker would need to know the IP addresses of all the nodes with which it is communicating.
Nodes with well-known addresses, such as servers and those using stateful configuration, are most vulnerable. Nodes that are a part of the network infrastructure, such as DNS servers, are particularly interesting targets for attackers, and particularly easy to identify.
If you feel a mechanism is too insecure, either slap some additional IPsec or TLS on top of it, or don't use the mechanism.
Unfortunately neither IPsec nor TLS pixie dust helps here.
--Pekka Nikander
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
