On Thu, Nov 19, 2009 at 2:35 PM, Dae Young KIM <[email protected]> wrote: > On Thu, Nov 19, 2009 at 6:23 PM, Patrick Frejborg <[email protected]> > wrote: > >> >> > And only one identifier. >> > >> >> Only one...? >> >> IMHO, a PKI certificate identifies a stack/person/host so it is a >> identifier in the RRG terminology, right? >> http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGTerminology >> >> A second identifier is needed, that will provide mobility (fixed and >> mobile site, endpoint) and not as complex to deploy as a PKI >> infrastructure, also less secure than the PKI infrastructure. Think >> this needs be clarified, if not - there is a risk that the new >> identifier will have too much security features and start to compete >> with the PKI infrastructure?? > > When moving, your identifier will still be kept, not changed, but your > locator will be changed. The mapping between the identifier and the changing > locator (and its retrieval) will have to be done a server in the > infrastructure (perhaps an extended DNS or rendezvous server(?) in HIT) a > very efficient manner. >
Yes, this is the host identifier approach - very similar as a PKI infrastructure but the PKI doesn't offer mobility, the PKI certificate do have global uniqueness . Another approach is to use a session identifier that can offer mobility, the session identifier is not globally unique - it is just used to identify the session when the endpoint is moving from one attachment point to another. Both identifiers can be used concurrently, if the context of the session is sensitive then use the session identifier for mobility and to identify the remote endpoint after the transition authenticate again the endpoints by the PKI infrastructure. If the content is not sensitive - do you need to authenticate the remote endpoint again? Probably not, but mobility might be required and for that the session identifier is good enough - usually it is the client that moves around and the server is fixed. Or if both endpoints moves around you would need a rendezvous server - but I think has been solved on the application layer already, e.g. SIP registrar&proxy, Skype, Instant Message solutions, peer-to-peer applications etc. The problem is that some applications uses IP addresses to identify the session, because there is no session layer in the TCP/IP-model (the OSI model and Appletalk do have) - the lack of the session layer is in my opinion the problem. So if the application could identify the session with the help of a token much better mobility could be achieved. Unfortunately it would require changes to some applications - but it is the right place to fix the problem. If the application can not be changed and mobility is required, then use Mobile IP. A simple session layer would make the networking so much easier. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
