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

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 May 2004 11:58:08 +0200

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.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 5 May 2004 12:05:30 +0200

> -----Mensaje original-----
> De: Iljitsch van Beijnum [mailto:[email-masked]]
> Enviado el: miercoles, 05 de mayo de 2004 11:58
> Para: [email-masked]
> CC: Multi6 List
> Asunto: Re: using the received source address as destiantion locator
> (was RE: architecture draft)
>
>

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 May 2004 14:15:47 +0200

On 5-mei-04, at 12:05, marcelo bagnulo wrote:

>> This is one of the points I've been hammering on extensively a

> for outgoing packets.

The trouble is that this still assumes we use the source address in the 
incoming packet as the destination for the outgoing packet. It's 
possible to fix the things that go wrong as exceptions and keep this as 
a general rule of course. (Note that checking isn't enough, if there is 
an outage at some point one of the ends must jump addresses or there 
will be no failover.) However, I would rather ditch this assumption and 
only make "take the source address" the default in the absense of 
better information. We *have* to make available to a multi6 host a list 
of all valid locators for the correspondent, and for each (or at least 
a good subset) of those reachability / preference information.

> In any case, this may mean that the receiving host may
> packets immediately.

With the approaches that are on the table now (NOID), it would be the 
other way around, as a negotiation must happen before the correspondent 
knows alternative locators. What you say could happen in a system where 
locators are learned by looking up identifiers in using a mapping 
service, though.

> For establishing a communication, when the first

Yes. This goes directly to the question whether we want provider 
independent identifiers, which implies a mapping mechanism or initial 
negotiation before the actual communication can happen (or both), or we 
want to steer clear of new identifiers that sit between the FQDN and 
the PA address, which has the advantage that we can be backward 
compatible and start communicating first and negotiate afterwards.

Personally, I think we should make both possible if this is possible 
with reasonable (additional) effort.