Re: 2nd part Re: revision of architecture draft is now published

[Erik Nordmark <Erik.Nordmark@sun.com>]

> What I was attempting to point out is that packet header rewriting by 
> _remote_ network elements is effectively a description of a session 
> hijacking technique. In order to allow locator rewriting in a manner that 
> is resilient to hijacking there needs to be some element of 
> visible  authorization of the locator substitution. A session hijack is an 
> unauthorized and undetected rewriting of packet headers, while a path 
> switch is in effect a authorized rewrite of the packet headers. If this is 
> performed within the host then the authority issues are somewhat different 
> than when such a header rewrite is performed at some point in the network
> path.

This is a discussion comment - I don't think it has any impact on the
text that Marcelo suggested for the architecture draft.

You don't necessarily need to authorize the locator rewriting itself.
The constraintis that you need to verify that the use of the new
locator is propertly authenticated and authorized.
One way to perform this without authorizing the routers is to
treat the locator rewritten by the router as a hint (due to reachability
or policy) to use a different locator and have the endpoints do their
e2e handshake before they take action on the hint.

  Erik