Re: identity persistence and comparison issues

[Erik Nordmark <Erik.Nordmark@Sun.COM>]

> It  seems to me  that Multi6 wedge3.5 protocols could benefit from IPSec SA
> kind of semantics. That is, each host specifies its own policy for 
> context lifetime.
> (It is good to notice that this proposal is not related to actual IPSec 
> in anyway).
> Once the context lifetime expires, it triggers a new context lifetime 
> update exhange.
> If the Multi6 implementation does not find out any traffic during a 
> while, it
> just deletes the context (like with IPSec in BSD). However, the next packet
> sent via the open socket would trigger a new full context establishment 
> exchange.

A potential problem (don't know how serious it is for multi6) with
having each end indepdently decide when to discard its state is that you
can end up with one end retaining state and the other not.
Normally this is not an issue, but when the end which retained the state 
(call it A) again wants to communicat with the other (call it B)
then B will need to send back some error saying "I've lost or intentionally
discarded my state". With such a mechanism one might need to be careful
about attackers, which were not on the path when communication started
but has since arrived on the path, being able to fake the "lost state" message
thereby being able to insert itself as a MiTM.

The problem is we don't have any existing (IPv4) experience to compare with
there to determine whether this is something we need to be concerned about,
because so far nodes have not been moving around that much in the topology.
I don't know if there are examples of attacks at WiFi hotspots
that can help us understand whether we need to be concerned about this.

If we do, one potential way to address it would be for the endpoints
to coordinate discarding their state e.g by using timers known to the peer
and/or explicit messages.

  Erik

can end up with the case when either end