[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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