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

Re: about reachability detection draft

On 17-aug-2005, at 16:24, marcelo bagnulo braun wrote:

Suppose that A is communicating with B
Suppose that we are using FBD so that a given frequency of packets (data or just signaling) is guaranteed by the shim in each direction

Suppose now that A stops receiving packets. This implies a failure in the B->A path.

Yes. (Assuming that A is still sending, if not the session could simply be idle.)

Now are you assuming that when A stops receiving packets A should try with alternative paths?
I am not sure this is good approach, since the path A->B may be working properly.. moreover, maybe this path A->B is the only one working. 

There are three possible actions:

1. Do a "lightweight" reachability test using the currently used locator pairs for both directions.
2. Start a full reachability evaluation procedure that will look at all locator pairs until it finds one that works.
3. Switch to a new address pair.

I think 3. is the wrong thing to do. Most importantly, because if one pair fails it's very likely that at least some other pairs also fail, so jumping to a new address pair blindly makes little sense. Also, in order to be able to do this, we must have previously authenticated the alternative address for the correspondent (or the correspondent for our alternative address) to avoid redirection attacks. So this basically means authenticating all possible addresses for both sides when the shim state is created. That's a waste of resources.

1. may make sense, but if we know there should be packets flowing in both directions but they're missing in one direction, it's very unlikely that the current address pair is still working. We should probably still test it, but I think we should also start looking at the first secondary address pair because it's likely that the currently used pair is dead. So that lands us at 2.

As i see the FBD mechanism would be the following: 

A and B are communicating
they are using FBD
A stops receiving packets

So, A informs B that the B->A path has failed (this implies some form of signaling from A to B, which is likely to be required to be somehow reliable, which is why i see a potential difficulty here)

The way I see it, A just starts a path exploration procedure. This means it will try address pairs until it gets an answer from B, so unless the path from A to B is completely broken at some point B will see a path exploration packet from A, which indicates to B that there is probably something wrong, so B would start doing its own path exploration.

A continues using the path from A->B while B starts exploring alternative paths

Right. You don't throw away your old shoes until you have new ones. Maybe the failure is temporary, so keep sending packets makes sense. And it's also the simplest thing to do. :-)

So you think that we need one packet type for periodic keepalives for failure detection and another type of packet for exploring alternative paths?

Yes. Assuming we go with the forced bidirectional thing, in the event that there is traffic from A to B, but no traffic from B to A, B needs to generate a packet anyway in order to let A know that everything is still working. Since A presumably monitors all packet types, the nature of this packet is of no importance. It could even be an IP header without any payload.

But for the full reachability evaluation we need lots of extra stuff.

So it makes sense to have this in different packet types, especially since the simple filler packets will probably be the most common.

I am not sure about this since when two different unidirectional paths are being used for a communication then the keepalive packet will need to carry information about the locator pair used for incoming packets. 

Not sure what you mean.

I mean, consider that a and Bare communicating, but they are using two different unidirectional paths i.e. A->B is using locators A1 and B2, while B->A is using locators A2 and B2

In this case when A sends a reachabilitity test request to B it will use A1 and B1. However, when B replies, it will use B2 and A2, 

Yes. Why would that be a problem?

so i guess it would a good idea to include in this reply packet information about the address used for the request packet i.e. A1 and B1 

No, don't get the problem...

And we need a reasonable level of authentication too, because we haven't previously established that these addresses indeed belong to the correspondent.

I am not sure what is the level of security we need here yet, but in any case imho it will be very related to the security used during the shim context establishment.

I mean, imho the critical part of the security if the addition of new locators to the locator set. Once the locators have been validated, using them shouldn't require to tight security requirements imho

Agree, but on the other hand we don't want to give attackers the capability to make hosts think there are reachability problems, especially attackers that aren't able to sniff any of the setup traffic. So something simple like the TCP sequence number or the IPsec replay counter would be useful here.

On the other hand, when A1 <-> B1 is working happily, there is no need to use such a complex protocol: we are only testing one pair in each direction, and the correspondent has been authenticated earlier. If we wanted we could even use pings to determine whether this still works. (Well, sort of...)

But as i see it, we are only going to try locators that are included in the locator set available for that shim context, which means that they have already been validated....

Since we need to test them for reachability right before we use them anyway, I tink it makes more sense to defer this validation until that time.

Deprecation is irrelevant, as we can continue to use deprecated addresses.

Well, deprecation means that somewhere in the near future, the address won't be available anymore, right? 

Right, so we keep using it until it's not available anymore.  :-)

So i guess it make sense to keep on using it as ULID, but i wonder if it wouldn't be a good strategy to try to rehome the ongoing communications to an alternative locator...? 

Are there any bad side effects when using deprecated addresses?

A more interesting case is when an address is removed from the system. I don't remember which session it was, but in Paris someone was talking about how systems keep using addresses they no longer have because upper layers still use those addresses.

well, in the shim this address should be kept as a possible ULID but not as a valid locator i guess

Yes, it makes sense to keep addresses as ULIDs for a while after they've become unavailable. On the other hand, in theory the address could be assigned to someone else so we problably want to limit this.

On the other hand, if the address is an HBA address, presumably nobody else would be able to use it (certainly not as a ULID, only possibly as an RFC 3041 semi-collision), so there is no harm in keeping it around as a ULID.

IMO this is a feature: if I unplug my ethernet from my powerbook and turn on my wifi, I get the same address on a different interface and my sessions are still alive. Under windows, things like this kill your sessions immediately.

in this case i guess that this address should be:
- kept as a ULID during all the time
- should be removed from the locator set during the period which the address was not available (i.e. during the time it took to remove it from the ethernet and it is back in the wifi)

Maybe we should keep using the ULID as long as there is shim state that refers to it, but it's removed when the shim state that uses the ULID is removed.

The way I see it there is an ordered list of address pairs. The more probes fail to make it to the other side the lower the address pair ends up on the list, I imagine. :-)

but what happens when you only have 2 address paris for instance? you may end up trying with the same two address pairs forever... I mean, i guess we need a mechanism to give up trying, right? 

Hm, maybe, maybe not... How does this work for current IP?

I guess that while the shim is still trying to move the session to a different address pair, we should block ICMP errors and such so the application won't give up, but when the shim can't find a working address pair, we should pass on the ICMP errors to the upper layer. At the same time, I'm not sure if we should ever really give up as long as upper layers keep sending traffic: connectivity can come back at any time.

We need to think about the situation where a fast primary link fails and we switch to a slow backup, though. Presumably, we'll want to switch back to the fast primary address pair when possible.

Right, the same arguments may apply for other reasons like cost of the link, security/privacy features of the path... But the question is how does the shim is aware of such information? i guess that these are policy issues and we could include some means to express this type of considerations in the shim

Right. For destination addresses and to some degree, source addresses, this can work through the RFC 3484 policy table, but it gets more difficult when we have to select an output interface or ISP/ site exit, possibly though the source address in the packet.