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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 03/07/2004, a las 0:11, Geoff Huston escribió:

> 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?

Ok, this is not what i thought you were considering at this point.
Since you are aiming to a security issue, i would suggest that you 
include a reference to the threats document here. I mean, i would say 
that :

Packet header rewriting by remote network elements has a large number 
of associated security considerations, and any packet rewriting 
mechanism has to provide proper protection against the attacks 
described in [threats], in particular against Redirection Attacks

regards, marcelo

> regards,
>
>   Geoff