Subject: RE: [Hipsec] Recovery from state loss

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 4 Jul 2004 12:42:09 -0700

Erik, thanks for writing this up.  comments and questions inline.

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, July 01, 2004 4:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Hipsec] Recovery from state loss
> 
> 
> 
> So here is my attempted approach and a close handshake that
> can apply to HIP as well as NOID. The goal is to remove the case when
> one end retains association state and the other end has discarded it,
> since this seems to open up some DoS opportunity.
> 
> Comments appreciated.
> 
>   Erik
> 
> 
> This scheme is robust against arbitrary network partitioning and loss,
> whether in both directions or one direction, through the use of timers
> plus a "close" and "closeack" message.
> 
> The underlying observation is that the network doesn't spontaenously
> generate packets, thus for a packet to be received it must have
> been sent by the peer, and if the host does not send a packet
> no packet will be received by the peer.
> (But packets might be sent and never received.)
> 
> In the basic analysis we assume that the network delay
> (propagation and queuing) is zero that is a packet
> is received by the peer either immediately when sent, or
> never (in the case of loss).
> 
> The mechanism uses a time constant: X minutes.
> 
> The mechanism works as follows:
> 1. When no packet has been received on the association for X minutes
>    the association transitions to "closing" state.
>    A "close" message is transmitted to the peer.

I am assuming that you mean "HIP association" by your use of the
word association above, since in HIP there is the HIP association
(state machine) and then there are individual BEET security
associations-- kind of like IKE phase 1/phase 2.

If so, then I think you are meaning "when no packet has been received
on any of the child SAs of this HIP association for X minutes"?

> 
>    When in "closing" state the host must not send any data packets
>    using the association. If there is a need to send a data packet
>    a new association must be created by starting by sending an I1.
> 
> 2. When the host receives a "close" message it discards the
>    association state and responds with a "closeack" message.
>    (The authenticity of the "close" message can be verified
>    the same way data messages are verified.)

do you mean PK signing of close? (which is not how "data" messages
are verified, but how other HIP messages are verified)

>    This processing applies whether or not the state is "closing"
>    in order to handle "close" messages from both ends crossing
>    in flight.
> 
>    Once the association state has been discarded any need to
>    send data packets will trigger establishing a new 
> association, starting
>    with sending an I1.
> 
> 3. A "close" message which is received when there is no 
> association state
>    can not be verified but will result in a "closeack" response
>    to speed up the peer discarding the state in the precense of
>    packet loss.
> 
> 4. The "close" message is retransmitted until either a "closeack"
>    message is received, or it has been retransmitted for a total of
>    X minutes. When either occurs the association state is discarded.
> 
> 5. When a host receives a "closeack" message it verifies
>    that it is in "closing" state and that the "closeack" was in
>    response to the "close" (using e.g. a nonce).
> 
>    It is possible to use stronger verification of the "closeack"
>    based on secrets tied to the association state, but only
>    for the first "close" message since the state is discarded
>    on its reception. Thus if the "closeack" response to the first
>    "close" is lost, the host would need to wait for the full X minutes
>    until discarding its state.

It might be possible (optional) to cache these closeacks-- maybe
something analogous to the "R2_SENT" state that was introduced
to allow for retransmission of R2 for a short period of time.
Then it is not so much a problem to use elements of previous 
association state in the closeack-- but could it also be signed
in any case?

> 
> Due to packet loss the two sides can have different views
> of when the last packet might have been sent, but because no
> received packets in X minutes causes a state transition, this
> difference can not be larger than X. Since the "close" messages
> are retransmitted for X minutes (during which the peer can not
> possibly receive any data packets) the peer will transition to
> "closing" and stop sending data packets before the host will
> discard its state. Example 2 shows a case when this happens.
> 

<snip> 

> Since the difference between T1 and T2 can't be more than X,
> we know that the session state can not be discarded
> before the other end has transitioned to "closing".
> 
> AFAIK the above examples generalize to arbitrary packet loss;
> in no case will a data packet be received when there is no
> association state. Hence data packet that are received and have no
> matching session state can be silently dropped; no need to send
> an error or an I1.

I think we still have the reboot scenario even with this (A reboots
and loses state, B sends data to A).  This mechanism would imply
that eventually B would time out, after X minutes.  

> 
> Intuitively it seems like network delays can be handled
> to make the period for the retransmission of the "close" message
> be X+MSL (Maximum segment lifetime) instead of X, but I haven't
> verified this.
> 
> ---
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
> 
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Jul 2004 02:53:06 -0700 (PDT)

> associations-- kind of like IKE phase 1/phase 2.

I actually wrote it up to make it applicable to other multihoming
solutions as well, so I was intentionally vague.

> on any of the child SAs of this HIP association for X minutes"?

Makes sense.

> are verified, but how other HIP messages are verified)

For HIP I think in principle one could take either approach;
either PK signed or protected by IPsec.
But since we want to be allow retransmitted close messages, e.g. due to
the closeack being dropped by the network, to receive a closeack
the verification needs to be such that the packet can be processed
even after the association state has been deleted.
Thus IPsec ESP wouldn't work; IPsec AH would work in pricinple.
But PK signing would be expensive.

Is there some encrypted set of bits exchange when the HIP association
is setup which could be used just to apply a keyed hash on the close message?

> association state in the closeack-- but could it also be signed

ok

> that eventually B would time out, after X minutes.  

Yes, if a host reboots it would take X minutes for the host to
behave as if it hadn't rebooted.
Thus a peer which is retransmitting TCP packets would not see the TCP RST
until
 - X minutes has passed since the rebooted host sent the last packet before
   it rebooted, followed by
 - A new HIP association is established (triggered by one of the TCP
   retransmissions)

Alternatively, the reboot count could be used to make it possible
for the rebooted host to convince the peer that it indeed has lost
state, which would make the recovery be faster.

  Erik