Patte - I agree with you that, for security purposes, tokens of additional namespaces will have to be used. And I hadn't seen from your comment that you referred to such stack-internal tokens.
This said, I tend to mentally separate the identifiers that are used by applications to initiate and maintain communication sessions, from other tokens that may be used for security purposes at the transport and IP layers. The reason is that the former are first-class elements of an Internet architecture, whereas the latter are engineering choices. This is a personal preference, however, and cannot be backed technically. FWIW: I agree with you regarding the strength of security needed to protect IP address updates. What we need is a solution that maintains the level of security we have today. Stronger protection of IP address updates would be in vain given the vulnerabilities we have today. - Christian On Nov 30, 2009, Patrick Frejborg wrote: > 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
