Hi,
Sorry about the delay in responding, I've been catching up.
Erik Nordmark wrote:
[cut]
- 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.
In order to ensure that context error messages aren't ignored like
destination unreachables, it may be valuable to work out a way
of verifying the messages.
So either the error message needs to self-authenticate (potentially
difficult considering context has been lost), or be used as a hint
to the peer to check the path with further signalling.
This works so long as in a resultant state checking exchange, there's
a liveness mechanism at least (nonce?) which can be known to be fresh.
For self-authentication, you'd basically require the original
data sender to have enough context left to authenticate the peer,
based on their IP address information (For example if CGA
addresses were locators, and the public key was known).
Timestamp information gathered previously for the CGA address
may be able to be used to ensure freshness.
Some of these mechanisms were used in SEND, but become suspect
for devices which have lost context state on the other side of the
Internet. It's possible to say though, that if the error message
contains a valid signature and timestamp, it's immediately verified.
I guess the "hint+check" mechanism is a fair one in general though.
The hint could be afforded more or less weight if it was impossible
to verify a CGA signature or the timestamp was out of bounds.
Greg