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

Hi Marcelo,

At 02:54 AM 1/07/2004, marcelo bagnulo braun wrote:
>- about section 4.5
>
>I am not sure about the following comment:
>
>   "Packet header rewriting by remote network elements has a large number
>    of associated considerations, and documentation relating to the
>    considerations of the use of Network Address Translators [4] contains
>    much of this material."
>
>I mean, if the multi6 layer within the host replaces the received locator 
>by the ULP identifier, then it doesn't really matter the locator than was 
>actually carried in the packet, right? I mean, in any case, the locator is 
>transparent to the ULP which only deals with the identifier.
>
>Moreover, perhaps replacing locators by identifiers introduce some of the 
>nat problems, but in any case, i don't see how this  related to the fact 
>that the locator is replaced by the host or by the edge router. So perhaps 
>some comment like this one is required but imho is not restricted to this 
>section but to all mechanisms that replace locators by identifiers.
>Perhaps you were considering other issues here?

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.

If this part of the document is unclear, then perhaps you could suggest a 
clearer rewording of this?

regards,

   Geoff