Subject: RE: [Hipsec] Recovery from state loss

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 7 Jun 2004 08:09:29 -0700

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Sunday, June 06, 2004 11:37 PM
> To: Erik Nordmark
> Cc: Henderson, Thomas R; [email-masked]
> Subject: Re: [Hipsec] Recovery from state loss
> 
> 
> > Thanks for the pointers. But I'm still concerned. The above
> > email makes this assumption, which I don't see discussed in the 
> > archive:
> >  Case iii)
> >   Data will be sent on an SPI that will be unknown
> >   to the peer.  In this case, either the peer will
> >   drop it silently or send the HIP NOTIFY-- in either
> >   case, the local host will eventually kill off its
> >   local HIP state, start over, and we are back to
> >   case i).
> >
> > Given that either end can (per section 8.9) drop a HIP association
> > whenever it wants, isn't it likely that case iii (and case 
> ii as well,
> > but that one is resolved in a more predictable manner) happen quite 
> > frequently?
> 
> There was some discussion that in iii) the recipient should
> send an ICMP Parameter Problem, the Pointer pointing to the
> SPI value.  I don't know if this ended up in the actual
> text; I vaguely remember that I prepared a write up, but
> maybe I forgot to send it.  (Apparently it did, based on
> what you write below.  My memory is just failing these days.)

Here is the text that is in the current draft that Petri
sent around this morning (from Section 5.3).

   If a system receives an ESP packet for an unknown SPI, it is possible
   that it has lost the state and its peer has not.  It MAY send an ICMP
   packet with the Parameter Problem type, the Pointer pointing to the
   SPI value within the ESP header. Reacting to ESP traffic with unknown
   SPI depends on the implementation and the environment where the
   implementation is used.

> 
> > I haven't found anything in the document that describes 
> what makes the 
> > local
> > host eventually kill off its local HIP state (it is just happily 
> > sending ESP
> > packets; perhaps receiving some ICMP parameter problem) 
> hence it has 
> > no HIP
> > timer running.
> 
> Yes, this is probably missing.

This has been relegated to the "implementation dependent" category
so far.  

Another thing that is missing is the ability to explicitly disassociate
or drop a HIP association, or perhaps to suspend one if one
of the hosts goes off line for a while (this latter case could
be part of the mobility/multi-homing work).

I suggest an open issue on handling the removal of HIP state for
ICMP, timeout, or other reasons.

> 
> > So what limits how long time case iii) stays around?
> 
> I think some text should be added on how to react to
> received ICMP Parameter Problem messages.  Unfortunately
> I don't have time to write up anything now.
> 
> > Is the intent that the document actually recommend some behavior
> > when receiving ICMP pameter problem pointing at the SPI field?
> 
> Yes, that was my intention, but apparently I failed to do so.
> Anyone, please?  A reasonable thing would be to start establishing
> a new HIP assoc, by sending I1, but _not_ to drop the existing SAs
> yet.  Maybe rate limit them or something, but not drop, as the
> ICMP Parameter Problem may be forged.
> 

How do we avoid that a spoofed ICMP Parameter Problem could trigger
a re-establishment of HIP state?  Perhaps the I2 needs to carry
some indication that the I2 is due to receipt of a Parameter Problem,
and allowing the responder to send something other than R2 to tell
the initiator to keep using the existing SAs?  And then once the
host had detected a spoofed parameter problem, it could be more
cautious about responding to them in the near future.

Tom
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 8 Jun 2004 14:09:23 +0300

> ICMP, timeout, or other reasons.

Ok for me.  I guess we need some freedom on implementations here.

> cautious about responding to them in the near future.

Well, when you receive the R1, you can double check to see if you've
received any traffic on the existing incoming SA in the meanwhile.
If so, the ICMP was probably spoofed.

Including something on I2 sounds like a good idea, but complicated.
I would leave that for a future extension, just in the name of
simplicity.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Jun 2004 18:46:31 -0700 (PDT)

> be part of the mobility/multi-homing work).

I've been looking at doing this for the NOID draft (which has signalling
similar to HIP if you ignore the security part).

Basically it seems to be possible to add a CLOSE and CLOSE-ACK message
plus time based rules (that the association is dropped if no packet
is received on the association in X minutes) and have the result
never end up with an unknown SPI due to one end dropping the association
while the other end retains the association.
This appears robust even if the network doesn't provide reachability
in one or both directions as an endpoint tries to  disassociate.

Would folks be interested in a writeup on something like this?

  Erik