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

Re: address pair exploration, flooding and state loss



marcelo bagnulo braun wrote:

So, each poll packet needs to contain the following information:
- its own poll packet identifier
- the poll packet identifiers of previously received poll packets, in the case that this poll packet is issued as a reply to a poll packet.


Anything else? security stuff?

You might want to include an echo of a nonce (echoed from the previously received poll packets) to prevent off-path attackers from being able to confuse the protocol.


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.


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.

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

   Erik