Subject: RE: [Hipsec] Recovery from state loss

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 6 Jun 2004 17:14:48 -0700

Erik,
responses inline below.

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Friday, June 04, 2004 3:02 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Hipsec] Recovery from state loss
> 
> 
> 
> I'm reading the HIP spec (hip-09.txt) and I'm trying to figure out 
> the assumptions underlying the recovery from state loss 
> (using the birthday 
> stuff).

The birthday text has changed since -09 draft.  Please see section 4.1.3
of the latest working copy:
http://hip4inter.net/documentation/drafts/draft-moskowitz-hip-10-pre3.txt

In particular, there is now a "R1 generation counter" instead of 
a birthday count.  The thread of this discussion can be found starting 
here:
http://honor.trusecure.com/pipermail/hipsec/2004-April/000704.html
and continuing through May.

> 
> The document talks about this being used when one host has crashed
> and lost all state.
> But won't hosts end up discarding the ESP SA after some time of
> non-use?
> In fact, section 11 seems to recommend that the ESP SA be 
> discarded after
> 15 minutes.

I believe that is the case, but I think the motivation for the
reboot procedures was to avoid having to wait for things to time
out. I do not know the origin of the recommended 15 minutes.  

> Since both ends don't seem to not coordinate discarding this 
> state, does
> it mean that the birthday counter need to be incremented each time
> an SA is discarded?
> 

Previously, this was the implication, when birthday count was
in use.  

Presently, the way that it should work is as follows:  suppose 
host A and B have an association and B reboots.  B starts
up some application that wants again to have a HIP association
with A.  B will send A the I1 packet, and will receive an R1
(A will send R1 even when it is in ESTABLISHED state).  B will
then send an I2.  Now A, in state ESTABLISHED, will process a
I2 and if successful, will drop the existing SAs that it thinks
it has with B in favor of the new ones.  Both sides will then
be back in sync after A sends the R2.

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

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 7 Jun 2004 09:03:07 +0300

>> non-use?  In fact, section 11 seems to recommend that the
>> ESP SA be discarded after 15 minutes.
>

The 15 minutes recommendation was there when I inherited
the documents from Bob M.  I don't know its origin, either.
As a (perhaps-educated) guess, I think that it is more or less
arbitrary, based on no real analysis.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 6 Jun 2004 23:22:27 -0700 (PDT)

> and continuing through May.

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?
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.

So what limits how long time case iii) stays around?
Is the intent that the document actually recommend some behavior 
when receiving ICMP pameter problem pointing at the SPI field?

An alternative would be to try to coordinate when the two peers
drop their HIP association state somehow.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 7 Jun 2004 09:37:21 +0300

> but that one is resolved in a more predictable manner) happen quite 

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.)

> packets; perhaps receiving some ICMP parameter problem) hence it has 

Yes, this is probably missing.

> 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.

> 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.

--Pekka