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

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

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

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.

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
not be using the received source address as destination address for outgoing
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
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.

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.