[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.
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
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.