[Cross-posting to hipsec since this analysis seems to be important for HIP, too. CC:s appropriately, please.]
The recent discussion on the ML has led me to believe that we have a fairly poor understanding on what we are speaking about. (Dave Crocker has also privately pointed this out, thereby making my mind clearer.) This is yet another strawman attempt to try to clarify the problem scope, or at least something.
After some thought, I think that we have at least three main classes of needs for (loosely speaking) end-point identifiers, and some subclasses:
1) Identification
1a) identification for the purpose of mobility and
multi-homing 1b) identification for the purpose of referral
or rendezvous (related to 1a but slightly
different) 1c) identification for other, e.g. administrative,
purposes2) Referral
3) Rendezvous
3a) initial rendezvous with no existing connection
3b) subsequent rendezvous, e.g., after concurrent movement
There are probably others, but these are the ones that my poor brains managed to (small pun) identify.
The *point* of this mail is that the different needs have different requirements, and that it may be very difficult or even impossible to design one class of identifiers that would fulfil all of the primary needs plus the related secondary needs, such as privacy and security.
Let me try to brefly analyze the above outlined needs one by one, in reverse order.
3) Rendezvous -------------
I haven't seen any good definition for rendezvous in the meaning that we seem to be using it. (If you have, please post a reference). So, here is an attempt:
End-point rendezvous refers to the situation where one end-point makes a contact with an explicitly identified other end-point over the network.
To be able to perform rendezvous, the first end point seems to need
- a means to identify the second end-point (1a or 1b) - a means to reach the second end-point, i.e., locator
In the case of 3b), the end-points have been in contact with each other and share explicit "fresh" state. Hence, they can identify each other just based on this state, and they do not necessarily need any stable, long-living end-point identifiers. Due to mobility, they need a service that gives the currently active locator for the other end-point, i.e., the equivalent of mobile IP home agent.
In the case of 3a), the end-points have not been in contact with each other, and the only "state" that they share is that the first end-point has an identifier that denotes the second one. The service giving locators does not seem to be very fast or dynamic, as long as the given locator will reach the given end-point. That is, if we have the equivalent of mobile ip home agent, the locator used for 3a) can be the equivalent of mobile ip home address.
2) Referral -----------
Again, I haven't seen any good definitions (and again, please post if you have). Another attempt:
Inter-end-point referral refers to a situation where one end-point hands over information about a second end-point to a third end-point, with the purpose of allowing the third end-point to make a rendezvous with the second end-point.
For referral to succeed, the transferred information must give the receiving end-point
- a means to identify the second end-point (1b) - a means to reach the second end-point
Note that in this case the "means to reach" does not need to be a locator. It can be a name that the rendezvous (3b) service is able to convert to a locator.
1) Identification -----------------
Now we get to the real business. Just to refresh the mind, here are again the suggested subclasses:
1a) identification for mobility and multi-homing 1b) identification for referral or rendezvous 1c) identification for other, e.g. administrative, purposes
1a) To me, identification for mobility and multi-homing seems to
be the easiest one. There we are only interested in gaining
assurance that the peer remains the same. That is, for the
sole purpose of mobility or multi-homing, we do not really
care with whom we are communicating with, but only that the
peer end-point is not changed in mid-communication due to
mobility, multi-homing, or attacks based on mobility or
multi-homing mechanisms.[There is also the need of keeping the apparent identifier to TCP or UDP stable, but that is really a secondary need, created by the desire of backwards compatibility.]
For the purposes of 1a) it seems to be sufficient to create an ephemeral identifier, only known to the participating end-points (and a sufficiently limited class of potential attackers). There is no need for long-lasting stable identifiers.
Identification at the mobility related rendezvous (3b) is really a special case of the generic mobility related identification, and therefore the argumentation above holds.
1b) For initial rendezvous and referral, we need something stable.
That is, we need to have an identifier that allows us to
identify the peer end-point even if it does not share any state
(but the identifier/identity) with us.Note that I have explicitly separated the function of locating the end-point from the function of identifying the end-point. For rendezvous and referral we naturally need both. However, they are distinct functions, and it is technically *possible* to use different tokes for these purposes. On the other hand, if there is a need for two tokens, we can also define that the end-point identifier (for referral or initial rendezvous) consists of a *pair* of tokens, ones used for identification and one used for finding the current address.
1c) The final class of needs for identification seems to have
nothing to do with mobility, multi-homing or even referral
or even rendezvous. There are other needs for identifying
end-points:
- Human GUI needs: to allow humans to type in names that
refer to end-points
- Various administrative needs:
- configuration management
- inventory management
- monitoring and intrusion detection
- etc.
- (running out of coffee.... can't think of others)-------------------------------------------------------------
The next step is to analyse the security and privacy threats associated with all of the above mentioned needs for identifiers. However, that is a subject of another mail.
--Pekka Nikander
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
