Dave Crocker wrote: DC> uh oh. when discussion starts including dictionary definitions, it is DC> often worth stepping back and making sure that the right issue is being DC> discussed.
My apology. I was merely trying to be precise. Sorry for the detour.
DC> .... And that observation was only intended to be DC> relevant as an indicator that we (the community) probably do not have DC> sufficient commonality to our use of the terms...
I see. And tend to agree. Furthermore, for me and perhaps a number of other non-natives the issues are sometimes fairly difficult since we often don't know the everyday meanings of many words. That is, at least I sometimes know a word from a very specific technical (linguistic) context and have no idea about its everday meaning and connotations. "Identifier" may be one such word.
PN> Well, in my thinking a specific identifier is only able PN> to denote a specific entity. That is, the relationship PN> between an identifier and the corresponding identity should PN> be a function, i.e., there must not be any identifiers PN> that denote more than one entities. Typically the PN> relationship is (or should be) bijective.
DC> Apologies, but I am still not understanding well enough, I think. ... DC> DC> Some mappings between strings and objects are by arbitrary assignment. DC> Some have a "semantic" process so that the string actually can be DC> analyzed. ...
I completely agree. My thinking about identifiers (as names that identify) is that an identifier is a different from a mere name in the sense that an identifier does have such a "semantic" process associated with it.
For example, consider IP addresses. They can be considered to be identifiers for topological locations. In that sense, the IP address can be analyzed and understood to act as a pointer to a certain topological location.
Let me take another example, public cryptographic keys. A public key can be "analysed" and understood as a pointer to (the sole holder of) the corresponding private key.
Thus, we can say that IP addresses are identifiers for locations and public keys are identifiers for (the holders of) private keys.
PN> In other words, an identifier implies sameness and stability of PN> the identified entity, while a name does not have those connotations PN> to the same extent.
DC> I guess I need some examples to understand this.
Let me take this the other way around. It seems to be a fairly common practise in computer science to create an identifier space, and then to make the assumption that the set of potentially identifiable entities is isomorphic with the set of identifiers. That is, you first create a set of identifiers, and then define that the world consist of a subset of the set of entities that can be named with those identifiers.
This seems to be the case with IP addresses. Even though we have NAT today, we still seem to think that the set of topological locations in the Internet is the set of locations that can be given a unique globally routable IP address.
The same more or less applies to public keys. If we use the set of public keys as the set of identifiers, then the set of identifiable entities consists of things that are able to hold and process corresponding private keys.
PN> Well, as I wrote above, I think that a name can be re-bound PN> while an identifier should not be re-bindable.
DC> In the Internet context. what would be an example of an identifier that DC> cannot be re-bound?
As I wrote, identifiers *should* not be re-bindable, not that it is impossible to re-bind them. The desired property can be achieved by at least two ways: - through some administrative procedure that ensures uniqueness - by using the "reverse process", as described above, i.e. by defining identity from identifiers and not vice versa.
Take the public keys example above. If you define that the identity of an entity is intrinsically bound to the private key, then if you move the private key to another device, the "entity" and its identity move at the same time, too.
DC> (And let me alert you to my belief that all of them DC> can be. ... In other words, all this stuff depends DC> on precise -- and often arbitrary -- definitions and policy.)
We seem to agree :-)
--------------- [Moving from the definition of identifiers and identity to mobility.] ---------------
DC> I'm finding myself viewing multi-homing as a simple (ie, degenerate) DC> case of mobility.
Well, I tend to view multi-homing as a dual of mobility. If you are mobile, your topological presense spans several locations over time. If you are multi-homed, your topological presense spans several locations over space.
PN> As you write, the difference between client-side mobilty and P2P PN> mobility lies in rendezvous. On the other hand, we also have to PN> remember that more and more servers are becoming mobile, in some way PN> or another (re-hosting, network re-numbering, etc). Hence, I would PN> not consider these two types of mobility that different.
DC> In the long term, no. but it's worth considering a simpler solution, DC> for the simpler case, if a) we think there will be significant benefit, DC> and b) deferring the more difficult part does not make it harder or less DC> likely to be solved.
So far so good. We seem to agree....
DC> The mobile-client/stable-server example requires no new rendezvous DC> mechanism and I think it covers a very, very large portion of current DC> mobility needs.
... But now comes the problem point. While I agree with what you say, I am concerned about the implications. That is, if we limit out view to stable servers, we loose the possibility of deminishing the importanse of stable addresses. That is, the current Internet practise requires stable addresses, and the mobile-client/stable-server approach also requires stable addresses, for the server. The requirement of stable addresses, in turn, is the reason why people are crying for provider independent addresses, and for much of the recent brawl at the IPv6 mailing list.
DC> And I think that the rendezvous function needed for DC> mutual mobility can be solved independently.
While I tend to agree, I'd also like to see that whatever solution we adopt, it would also allow servers to change their IP addresses while they have active connections. In other words, IMHO we may well leave the problem of simultaneous movements for later, but we should create a rendezvous function that allows slow movements of servers. DynDNS may be sufficient for that.
PN> No problem here. On the other hand, if we had proper and secure PN> identifiers, packet forwarding would not be an architectural PN> problem, either. DC> DC> we probably disagree. packet forwarding requires creating additional DC> infrastructure, as we have been seeing for the considerable number of DC> years of effort for the mobile ip work. That's another reason for DC> carving off forwarding to be separate from higher-level DC> (non-infrastructure) mobility support. At that point, forwarding DC> becomes an optimization, rather than a necessity.
Actually I think that we agree. I forgot that some people may consider packet forwarding as a fundamental mobility mechanism; for me it has been a mere optimization for at least four or five yers now. Hence, as an optimization, I don't necessarily consider it as an architectural problem. However, without proper security support, even as an optimization it may become an architectural problem.
--------------- [Moving from mobility to security.] ---------------
DC> I didn't mean that security wasn't important. I mean that separating DC> the security mechanism from the name administration (and, therefore, the DC> "meaning" of the name) is usually better.
Well, I am not quite sure what you mean with name administration.
At least since 1996 or so I have been fairly convinced that most probably only public keys (or other similar "things") are good primary identifiers for entities in the network. That is, it is better first to assign a public key pair to an entity, and then worry about "naming" the entity with some name that has any semantic meaning to the applications.
DC> Clearly, the ability to hijack a name can be a very serious danger.
Under fairly benign assumptions, it is fairly hard to hijack public keys. (But not impossible, of course.) Other names are then assigned by the application, and only meaningful in the application context. The application is also responsible for establishing the secure relationship between the application specific names and the entity identifiers, i.e., public keys. This is the approach used in SDSI, SPKI, and related work.
PN> Well, I am mostly concerned secure identifiability. Is that PN> clear enough, or should I pursue the issue more?
DC> a bit more, please. remember that we are trying to understand why DC> end-point identifiers are required, or at least what they are required DC> for. i'm not seeing how security is a serious issue for that goal.
In our 2002 Cambridge paper, we use the following classes of "weak authentication" methods:
- challenge response (e.g. Return Routability) - anonymous encryption (e.g. unauthenticated D-H) - leap of faith (e.g. SSH)
With secure, long lasting identifiers we are able to achieve leap of faith. That is, we can recognize a party the next time we encounter it. Without secure, long lasting identifiers we can't do more but simultaneous challenge response and anonymous authentication.
These two different security models have different implications to the cost of attacks, and to the overall level of trust that can be achieved.
DC> Alas, the IETF has an essentially unbroken track record of failing to DC> gain large-scale use for any security technology created in the IETF.
I have started to think that one reason behind this may be lack of economic understanding.
--Pekka Nikander
