[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
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
A continues using the path from A->B while B starts exploring
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
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
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
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
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
Deprecation is irrelevant, as we can continue to use deprecated
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.