Re: address pair exploration, flooding and state loss

[Greg Daley <greg.daley@eng.monash.edu.au>]

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