Re: address pair exploration, flooding and state loss

[Erik Nordmark <erik.nordmark@sun.com>]

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