On dinsdag, sep 9, 2003, at 10:16 Europe/Amsterdam, Pekka Nikander wrote:
The trouble isn't that IP addresses don't make for good end-point identifiers or that they don't make for good topology/interface identifiers, but that they can't do both at the same time.
Well, almost but not quite. We also have the limitations of the current routing technology, which make IP addresses really suitable only as topology/network/interface identifiers.
I don't think IP addresses are inherently unsuitable as identifiers. But obviously they are locators. So if we want to separate the two functions, either we invent a new "thing" to provide either one of these functions or we need identifier IP addresses and separate locator IP addresses.
What exactly do you mean here? A 128 bit value that we can put in all the right places inside the applications and transport protocols (but not on the wire), or something that isn't such a 128 bit value?
Well, my current personal opinion is that actual end-point identifiers should most probably be cryptographic in nature, due to a number of security reasons. On the other hand, 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 (but probably not on the wire).
So the 128/32 bit representation wouldn't _be_ the identifier but only a representation?
It is the a third issue whether we want to use the cryptographic nature of the actual identifiers in all transactions. Probably not: sometimes using them just as bit strings is likely to be appropriate.
I can't give you my opinion on this just yet because I don't have one, except that I'm not a huge fan of using crypto if not absolutely necessary.
Now, when I say that "end-point identifiers replace IP addresses", I am mostly speaking about the semantic change. In a way, already using Mobile IPv6 route optimization presents such a semantic change, though in very primitive form. Using stable PI addresses locally to name hosts for administrative purposes might be another primitive example of such a semantic change. On the other hand, the real change only occurs when the end-point identifiers cease to be IP addresses; MIPv6 RO and PI addresses both fail on this test.
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? IMO, having an identifier that can also be used as a locator is a big plus, since that way you can be compatible with legacy operation without much effort and you can defer expensive operations necessary to actually do multihoming until the time you need it, i.e. when the identifier isn't reachable as a locator anymore.
Yes, this is somewhat messy but all the best things in life are. :-)
What comes to domain names, my primary concern is their lack of security,
How bad is this exactly? I know it was possible to play all kinds of nasty DNS tricks in the past (see the alternic pranks) but I think that's not the case anymore. I think the only way to fool the DNS is spoofing replies which is very difficult unless you can sniff the wire.
and DNSsec does not seem to be the answer. There are also other problems with DNS names, including the difficulties of integrating DynDNS and DNSsec, long update times (due to caching), dependency of centralized (hierarchical) administration, etc.
Yes, the DNS is ready for an overhaul, but I don't see it happening any time soon as this means global agreement, unlike simple stuff such as id/loc separation which can be done by two consenting endpoints.
One very important property of [end-point] identifiers is that they have enough structure to be used as a key in a lookup process.
I didn't mean to say that they all have such structure, but whether or not they do is a very important property.
I haven't seen a write-up of HH addresses, but from what I understand they lack this property.
Well, my (perhaps poor) understanding from the FARA work (by Bob Braden, Aaron Falk and others) seems to indicate that it may be perfectly OK to use identifiers even if they cannot be used as keys in a lookup process.
I'm sure it's possible to build something like that, but I do we want to? Not being able to do such lookups makes everything much harder, maybe even to the point of having to use yet another layer of indirection.
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...
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.
And note that the use of non-routable, stable addresses isn't free: you need to go through a lookup process to find the locators.
Using any address-independent identifiers or names costs something. On the other hand, if you use the domain name system anyway, you can make a single query to get both the end-point identifier and a set of locators.
You would think that, wouldn't you? :-) But it starts to look like we need FQDN -> id -> loc so this would add an extra lookup.
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. And if your locator doesn't work you're in for a timeout anyway, whether it overlaps with the identifier or not.
Which is one dependency that we are trying to avoid.
Obviously it should still work if the PA address is unreachable.
Note that systems that negotiate in-band, such as MAST or IPsec, need the original address to be reachable.
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? The problem is then what you put in the DNS. If the PI addresses are recognizable as such, we get to try PA first and fall back on PI if PA doesn't work, so there is no harm in having PI in the global DNS. With multihoming it's even better because then you can have a logical connection to PI while using the PA du jour.
Actually I think MAST is very close to mobility, and could, if developed further, easily replace what's on the table now for mobility, while at the same time attack the multihoming problem, for which current MIPv6 doesn't provide many useful hooks.
Sure it could. In perhaps 4-5 years. MIPv6 is here, now.
Really? Where is it implemented then?
Again, what I am basically saying is that we seem to need a roadmap, with short term solutions and longer term solutions.
Sure.
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.
The way I see it:
1. Define a generic address mangling system between IP and transports based on stable host identifiers OR simple session identifiers
This, as such, is already a long term goal, in my opinion. Since this is likely to require code changes, just deployment alone is likely take a long time, not counting the time needed to reach consensus at the IETF.
Not sure what your point is. Yes, the IETF is slow, and yes, this needs code.
2. Make no assumptions about the identifiers except that the transports must understand them, so: PA, PI/non 2000::/3 or even IPv4
Sorry, but I don't understand what you are trying to say. Are you trying to say that we need to have 128 and 32 bit handles so that they can be used by legacy applications and APIs? If so, I do agree.
Yes. However, we don't have "legacy" APIs as those are the only APIs we have. Another point is/was that locators and identifiers may overlap.
3. Define mechanisms to populate the hostid/sesid+mangling table. Can be:
a. out of band using distributed lookup database
b. using in-band negotiation (= like MAST)
c. crypto: modified IPsec or HIP
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'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? 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.
Iljitsch
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
