RE: using the received source address as destiantion locator (was RE: architecture draft)

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> -----Mensaje original-----
> De: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
> Enviado el: miercoles, 05 de mayo de 2004 11:58
> Para: mbagnulo@ing.uc3m.es
> CC: Multi6 List
> Asunto: Re: using the received source address as destiantion locator
> (was RE: architecture draft)
>
>
> On 4-mei-04, at 19:42, marcelo bagnulo wrote:
>
> >>> While I agree that doing this sounds reasonable, there is no
> >>> requirement that this should be the case.
>
> >> I can't think of a scenario where the same would not be true, even if
> >> this was not a requirement. You need the src address to map to the
> >> communication stream in one way or the other. Unless I am to tried.
>
> > I guess that there could be security issues with this. I mean, if the
> > source
> > address used will be used as destiantion address, then the sending
> > host has
> > a simple way to redirect the reply packets to another host and produce
> > for
> > instance a flooding attack.
>
> Right. This is one of the points I've been hammering on extensively a
> while back: you can't trust that the source address belongs to the
> actual correspondent, and you also can't trust that it's reachable. So
> both for security and robustness, a host has to determine which
> destination address it's going to use to reach a correspondent
> regardless of the original source address.
>

An option for this is to verify the proposed new address contained in the
source address of incoming packets before using it as a destination address
for outgoing packets. In any case, this may mean that the receiving host may
not be using the received source address as destination address for outgoing
packets immediately. This is so for the addition of new address in an
established communication. For establishing a communication, when the first
packet is received, i guess that the option of using the received source
address as destination address of reply packets seems attractive. Otherwise
you would need to discover at least one locator of the other party through
alternative mechanisms, like a directory, based for instance in the
identifier, which would at least add some latency to the process.

Regards, marcelo