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

Re: address pair exploration, flooding and state loss

Hi Erik,

After Greg's message, i have been rethinking your comments here, and i would like to express further comments...

El 17/05/2005, a las 23:14, Erik Nordmark escribió:

State Loss:
-----------
The goal here is to detect if the context state has been lost. The reasons for this lost may be related with failures, or with early garbage collection.
The packet exchange would require the following information:
- a packet that refers to an existent context. This packet need to be identified as a shim packet and must contain context identification (i.e. context tag). In addition, the packet needs to include a packet identifier, so that it is possible to bound the reply to this initial packet (this is so in order to prevent some forms of attacks similar to TCP reset attacks, where an attacker can force a node to act as if the peer has lost its state)

This makes me realize that the approach to use a separate packet to detect state loss is a bit less effective than defining a "missing context" error message which is sent in response to data packets.


but this would require to include in all data packets of a context session the following information:
- some indication that this is a shim data packets (note that until now, data packets exchanged within a shim session that used ULIDs as locators were not necesarily tagged as shim packets i.e. there were simple IP packets. this would need to change if these data packets are to be used to detect context loss)
- some context identifier in order to properly id to involved context
- some random nonce in order to limit TCP rst type of attacks to mitm

Note that the flow label option for carrying context id can carry a context id, perhaps a shim flag bit but i guess it cannot carry the random nonce.
The extension header can carry the three of them, but it may be required to carry it in all shim data packets

Here is an example with an error message.
Assume A is communicating with B using <A1, B1> as the locator pair.
A is seeing upper layer advise indicating that things are ok.
At time t0 A receives the last positive upper layer advise.

At some time later (t1), A should send some "test" to B.
But there could be two possible failures to handle:
1. B lost (or garbage collected) the context state.
2. <A1, B1> stopped working.

In #1 the best thing for A would be to test <A1, B1>.
In #2 the best thing for A would be to try a different locator pair.

If we had a "missing context" error message, then in case #1 A would have received such an error with high probability. Hence when it sees nothing coming back it can assume #2 and explore a different locator pair.


well, i think we still need to explore the potential triggers for a rehoming event, but my feeling is that some of those will be hints, rather than triggers, and that in many situations the currently used locator pair will have to be explictly verified through a reachability test.

regards, marcelo


Without such an error message in the protocol it isn't clear to me what A's strategy should be.

   Erik