On Mon, Nov 30, 2009 at 7:35 AM, Christian Vogt <[email protected]> wrote: > > On Nov 19, 2009, Patrick Frejborg wrote: > >>> Locators are necessarily about network attachments (per stack). If a >>> host has multiple points of attachment, then it should have multiple >>> locators. 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?? > > Patrick - > > One can certainly think of multiple types of endpoint identifiers. But > shouldn't we focus on the identifiers that are required to establish > and maintain communication sessions? A PKI certificate is not of this > nature, as it is used by applications given an existing session. >
Hi Christian, correct - that is what we should focus on, an identifier on how to establish and maintain communication sessions. But it opens up a possibility to hijack sessions, if the control packets during the session transition are not protected - not all sessions need to be protected that well, the SCTP verification tag or MPTCP token is sufficient to provide mobility for basic browsing. What if the existing session, that is protected by TLS or a PKI solution, is moved from one endpoint locator to another endpoint locator - is it still the same remote host after the transition? Think multi-path enable transport protocols need to deal with this issue - studies and proposals for SCTP has been done , e.g. http://www.academypublisher.com/ojs/index.php/jcp/article/viewFile/02043140/302 But perhaps MPTCP can get around this problem in an easier way? -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
