Re: address pair exploration, flooding and state loss

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

Hi Marcelo.

marcelo bagnulo braun wrote:
[cut]
> > 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.
>
> I think that the security achieved by including some random nonce 
> present in the original packet in the error packet would be good enough. 
> such approach would imply that only on path attackers can generate fake 
> error messages.
> Probably this can be complemented by a context reestablishment strategy, 
> in order to re create the lost context. In case that the context has not 
> been lost, peers should be able to detect it.
>
> As i think we concluded a while ago, the key point is that these 
> particular error messages cannot be sent spontaneously, but must be sent 
> as a reply to a packet of the context (which must carry this random nonce)
>
> this, i guess imposes that data packets of the context, that need to be 
> demuxed, need not only to carry the context tag, but also this security 
> nonce.

I really don't like where that's going.  In order to get any sort of
reasonable sized nonce, there will have to be nonces or sequence numbers
big enough to handle at least an RTT worth of data.

That's because we're not necessarily able to rely on the data contents
of the packet itself being dissimilar enough to allow matching.

This means that for the advantage of a rare occurrence of context loss,
we'd have overhead of 2, 4, 6 or 8 bytes (not looked into the details,
but even two bytes may be unpleasant if it doesn't already fit into a
proposed extension header) in every data packet.

I'd really dislike such a mechanism if it wasn't able to be carried
within the existing overheads from the context tag.

It's actually more likely that the sender will get a
"Destination Unreachable" message than a context lost message, and less
is done for that.

I like the idea of Erik's that the context is included in the error,
and subsequent queries may be used to determine a live end-point has
actually lost the context.

Greg