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

Re: about reachability detection draft

On 20-aug-2005, at 7:34, marcelo bagnulo braun wrote:

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.

but this is somehow weird, because A is performing a path exploration procedure, even if the path that A is using to send packet is working properly...

It's not so strange: A doesn't know if it's the path from A to B that has failed or the one from B to A (or both are still working and there was just some random packet loss).

I mean, actually, in this scenario, you are using the path exploration procedure initiated by A as a reliable mechanism to allow A to inform B that something is wrong in the path that B is using to send packets, so that B starts its own path exploration procedure, which is the one that is the one that in fact is relevant, since is the B->A path which is broken. 

I guess so.

So, in fact the FBD procedure has the following steps, as i see it:
1- Both ends send keepalives to preserve the traffic frequency required.
2- when something is wrong, the receiving end detects the failure 

Yes.

3- Then the receiving end convey the information about the failure to the sender (which the one that has to react). Such signaling must be performed in a somehow reliable way (in particular, you can use the path exploration procedure since it tries multiple paths)
4- The the sender can react, performing in its turn a path exploration procedure.

agree? 

Yes, except that we don't know for sure which direction failed.

i think it is important to identify that step 3 is required in order to complete the failure detection procedure, since it is not only important to detect the failure but also to inform the party that can actually do something about it (i.e. the sender) that the failure has occurred

I suppose I didn't feel the need to state this so explicitly, but it's certainly true.

If we use the other mechanism described in the draft (i don't remember how did you call this in your presentation) the sender is the one that actually detects the failure so there is no need for step 3 

No, that's not exactly true. Let me present a different model:

1. Traffic is flowing in both directions, transport is happy
2. Traffic is no longer flowing in both directions, transport is unhappy
3. Side A starts full path exploration
4a. It is determined that the path from A to B failed
5a. A changes to a different locator pair
4b. It is determined that the path from B to A failed
5b. B changes to a different locator pair

As you can see there is no difference, except in the inner workings in steps 1 and 2, where FBD just monitors incoming packets, and CUD either relies on the transport feedback or sends probes and gets back replies.

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.

the attack that you have in mind then is that an attacker generates a reachability test packet and the host reads this packets as the other end starting the path exploration procedure, which implies that itself should do the same because of a potential outage, right? 

Yes.

But this would be in the case of FBD right? i mean does this applies in the other mechanism too? I think not, becuase in this case, reachability tests are a two way exchange and wouldn't imply that the other end starts doing its own reachability test, i think 

?

In any case, you could also include some cookie generated during the session establishment exchange to even make this stronger. 

Yes, should be no problem.

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. :-)

Suppose that a prefix PrefA is being renumbered.
In order to remove this prefix, all addresses containing PrefA are deprecated. This means that this prefix should not be used for establishing new communications, but can be used for ongoing communications, right? 

Right.

Now a certain point in time the prefix is actually removed, this means that packets containing a destination address with this prefix won't reach the site any more. 

Right.

this would be that the prefix and the associated addresses are no longer available according to your terminology right? So my question is how does the host knows that the prefix is no longer available? is there any other signaling tool besides deprecation through RAdv?

First the "preferred lifetime" expires and the address is deprecated. A bit later, the "valid lifetime" expires and the address is no longer valid. Most OSes then remove it from the system.

I guess if we're rewriting addresses anyway, we may as well give deprecated addresses a slightly lower priority, so all else being equal non-deprecated addresses are used. However, it's probably better to stick in backward compatibility mode as long as we can (= no rewriting) rather than to avoid deprecated addresses.

BEsides, in order to return to the original path, the shim needs to the probing it all the time, so that it can detect when the original path is back up. I mean, this wouldn't normally occur for other paths, since the shim won't be probing alternative paths while the current path is working, so if we want this feature, the default behaviour needs to be modified i guess.

It's probably a good idea to make the probe frequency depend on the difference in address preference. So when A1-B1 has a preference of 10 and A2-B2 also has a preference of 10, we really don't need to do much probing to see if we can return to A1-B1. But if A2-B2 has a preference of 1, then we'd want to move back sooner rather than later so we'd send probes relatively frequently. An interesting situation occurs when the original session uses A1-B1 which as preference 10, but A2-B2 has preference 25...

Iljitsch