[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
2- when something is wrong, the receiving end detects the failure
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
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
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
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?
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
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.
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
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...