Subject: Re: [Hipsec] Recovery from state loss

From: Julien Laganier <[email-masked]>
Date: Thu, 07 Oct 2004 23:23:31 +0200

On Friday 16 July 2004 19:00, Pekka Nikander wrote:
> >> 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.
> >
> > IMHO, this scheme fills a hole in the HIP specification,
> > particularly since we removed the RESYNC-related stuff. Hence, I
> > am strongly in favor of adopting (and adapting) the proposed
> > approach.
> >
> > There's  a remaining question, though: Does it belongs to the
> > base protocol spec, or rather to an extension? I would vote for
> > the first but I'm not 100% sure...
> >
> > What do other people think?
>
> I don't have any strong opinion.  If someone makes a good write up
> for the base spec, I don't have anything against including it.

Folks,

Attached is an attempted write down containing additional sections 
complementing the HIP protocol specification with a CLOSE/CLOSE_ACK 
handshake, based on Erik's approach.

Please let me know what you think, especially things still missing, 
and your opinion on its maturity for a possible integration within 
the base spec draft (-01 or later).

Thanks,

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 8 Oct 2004 10:53:11 +0300

> handshake, based on Erik's approach.

Looks good, thanks!

The only thing I was left wondering is the overloading of
the CLOSE_ACK message.  In the text provided, CLOSE_ACK works
both as an ack to a received CLOSE and as a kind of error
message telling that there is no such association.  In the
former case, it is protected with HMAC and SIG, in the latter
case it is not.

Maybe it would be better to have different messages for these
purposes?  That is, in the UNASSOCIATED state, if you receive
a CLOSE (or UPDATE, I guess), you send a NOTIFY with a suitable
error code.  In that way the CLOSE_ACK message would be only
used for acknowledging CLOSE.

A related issue is whether we should allow/require a "CLOSED"
state.  A host sending a CLOSE_ACK would enter a "CLOSED"
state for a certain period (2 * timeout?), and during that
time it would be able to send further CLOSE_ACK messages in the
case it gets another CLOSE.  (Maybe the CLOSE_ACK was lost.)
It would then automatically move to UNASSOCIATED if it receives
no CLOSE messages within that period.

I don't think the CLOSED state is necessarily needed, or should
be mandated, but it sounds to be as a nice engineering optimisation
that some implementations might want to do.

---

We probably need also some text to the security considerations
section, considering the potential DoS attacks related to the
CLOSE mechanism.  It should note that since the CLOSE (and
CLOSE_ACK?) messages have HMAC, an outsider cannot CLOSE a
connection.  It has SIG, allowing middle boxes to inspect the
messages and immediately close the related SAs.

--Pekka

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

---

From: Petri Jokela <[email-masked]>
Date: Fri, 08 Oct 2004 14:13:17 +0300

> that some implementations might want to do.

Thanks Julien for the text!

I modified a bit Julien's proposal according to Pekka's comments.
My notes are included in the text. Outgoing/incoming data traffic text 
needs still something For example when the association is not dropped in 
the CLOSED state and there is some data that would belong to this 
association.

/petri

5.4.2  HIP State Processes

<**PJ**>
         In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOSE, not
         written down here
<**PJ**>

    +------------+
    |UNASSOCIATED|  Start state
    +------------+

    Datagram to send requiring a new SA, send I1 and go to I1-SENT
    Receive I1, send R1 and stay at UNASSOCIATED
    Receive I2, process
	if successful, send R2 and go to R2-SENT
	if fail, stay at UNASSOCIATED

    Receive ESP for unknown SA, optionally send ICMP as defined
	in Section 6.3 and stay at UNASSOCIATED
    Receive CLOSE for unknown association, stay at UNASSOCIATED
    Receive ANYOTHER, drop and stay at UNASSOCIATED

<**PJ**>
         ESTABLISHED: Go to CLOSED instead of UNASSOCIATED
<**PJ**>

    +------------+
    |ESTABLISHED | HIP SA established
    +------------+

    Receive I1, send R1 and stay at ESTABLISHED
	
    Receive I2, process with cookie and possible Opaque data verification
	if successful, send R2, drop old SAs, establish new SA, go to
	R2-SENT
	if fail, stay at ESTABLISHED
    Receive R1, drop and stay at ESTABLISHED
    Receive R2, drop and stay at ESTABLISHED

    Receive ESP for SA, process and stay at ESTABLISHED
    Receive UPDATE, process
	if successful, send UPDATE in reply and go to REKEYING
	if failed, stay at ESTABLISHED
    Need rekey, send UPDATE and go to REKEYING
    No packet sent/received during UAL minutes, send CLOSE and
    	go to CLOSING.
    Receive CLOSE, process
    	if successful, send CLOSE_ACK and go to CLOSED
	if failed, stay at ESTABLISHED

<**PJ**>
         Closing: Move to CLOSED after sending CLOSE_ACK instead of
         UNASSOCIATED
<**PJ**>

    +---------+
    | CLOSING | HIP association has not been used for UAL (Unused
    +---------+ Association Lifetime) minutes.

    Datagram to send, requires creation of another HIP association
	in UNASSOCIATED state (which will send I1 and go to I1-SENT)

    Receive CLOSE, process
    	if successful, send CLOSE_ACK, discard state and go to CLOSED
	if failed, stay at CLOSING
    Receive CLOSE_ACK, process
	if successful, discard state and go to UNASSOCIATED
	if failed, stay at CLOSING

    Receive ANYOTHER, drop and stay at CLOSING

    Timeout, increment timeout sum, reset timer
	if timeout sum is less than UAL+MSL minutes, retransmit CLOSE
	  and stay at CLOSING
	if timeout sum is greater than UAL+MSL minutes, go to
           UNASSOCIATED

<**PJ**>
         CLOSED is a new state. Timeout sum should be 2*MSL or something
         else??
<**PJ**>

    +--------+
    | CLOSED | CLOSE_ACK sent, resending CLOSE_ACK if necessary
    +--------+

    Datagram to send, requires creation of another HIP association
	in UNASSOCIATED state (which will send I1 and go to I1-SENT)

    Receive CLOSE, process
    	if successful, send CLOSE_ACK, stay at CLOSED
	if failed, stay at CLOSED

    Receive CLOSE_ACK, process
	if successful, discard state and go to UNASSOCIATED
	if failed, stay at CLOSED

    Receive ANYOTHER, drop and stay at CLOSED

    Timeout, increment timeout sum, reset timer
      if timeout counter > 2 * MSL, discard state and go to UNASSOCIATED
      else stay at CLOSED

5.4.3  Simplified HIP State Diagram

        +-+
        | | CLOSE received, send NOTIFY
        V ^
    +------------+
    |UNASSOCIATED|<----------------------+
    +------------+                       |
          ^                              | Timeout, move to
          | CLOSE_ACK received, or       | UNASSOCIATED
          | timeout sum > UAL+MSL        |
          |                          +--------+
          ^      rec CLOSE,     +--->| CLOSED |----+
     +---------+ send CLOSE_ACK |    +--------+    | CLOSE received,
     | CLOSING |----------------+        |   ^     | send CLOSE_ACK
     |         |-----+                   |   |     |
     +---------+     | timeout sum       |   +-----+
          ^   ^      | < UAL+MSL,        |
          |   +------+ retransmit CLOSE  |
          |                              |
          | No packet sent/received      |
          | for UAL min, send CLOSE      |
          ^                              | CLOSE received,
    +------------+                       | send CLOSE_ACK
    |ESTABLISHED |>----------------------+
    +------------+

-----------------------------------------------------------------

<**PJ**>
         Removed optional things, NOTIFY is sent in UNASSOCIATED state
<**PJ**>

7.11  CLOSE_ACK - the HIP closing acknowledgment packet

    The HIP header values for the CLOSE_ACK packet:

    Header:
	Packet Type = XXX Tbd.
	SRC HIT = Sender's HIT
	DST HIT = Recipient's HIT

    IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) )

    Valid control bits: none

    The sender MUST include both an HMAC and signature (calculated over
    the whole HIP envelope).

    The receiver peer MUST validate both the HMAC and the signature.

-----------------------------------------------------------------

<**PJ**>
         We don't discard the state before we move to UNASSOCIATED.
         - If we want to send data? We cannot use the old association
         any longer, we need to start a new negotiation. That part of
         the text needs maybe some clarification.
<**PJ**>

8.16 Processing CLOSE packets

    When the host receives a CLOSE message it responds with a CLOSE_ACK
    message and moves to CLOSED state.  (The authenticity of the CLOSE
    message is verified using both HMAC and SIGNATURE). This processing
    applies whether or not the HIP association state is CLOSING in order
    to handle CLOSE messages from both ends crossing in flight.

    The HIP association is not discarded before the host moves from the
    UNASSOCIATED state.

    Once the closing process has started, any need to send data packets
    will trigger creating and establishing of a new HIP association,
    starting with sending an I1.

    A CLOSE message which is received when there is no HIP association
    state can not be verified but will result in a NOTIFY response.

-----------------------------------------------------------------

<**PJ**>
         Optional things removed. ACK also accepted in CLOSED state if we
         have earlier sent CLOSE related to the same association:
         ASSOCIATED -> send CLOSE -> CLOSING -> receive CLOSE, send
         CLOSE_ACK -> CLOSED -> receive CLOSE_ACK to earlier sent CLOSE
         ->...
<**PJ**>

8.17 Processing CLOSE_ACK packets

    When a host receives a CLOSE_ACK message it verifies that it is in
    CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
    CLOSE (using the included ECHO_REPLY in response to the sent
    ECHO_REQUEST).

    The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state
    is discarded when the state changes to UNASSOCIATED and, after that,
    NOTIFY is sent as a response to a CLOSE message.

-----------------------------------------------------------------

<**PJ**>
         New NOTIFY
<**PJ**>

6.2.19 NOTIFY

       UNKNOWN ASSOCIATION                          44

          The received CLOSE message referred to an
          association that does not exist.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 Oct 2004 18:58:58 +0200

On Friday 08 October 2004 13:13, Petri Jokela wrote:
> > be mandated, but it sounds to be as a nice engineering
> > optimisation that some implementations might want to do.
>
> My notes are included in the text. Outgoing/incoming data traffic
> text needs still something For example when the association is not
> dropped in the CLOSED state and there is some data that would
> belong to this association.

Thanks Pekka and Petri, the modified text looks quite good. Attached 
are some answers/questions, correction to the text and suggested text 
for Security Considerations.

Cheers,

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 11 Oct 2004 21:27:03 +0300

Some details:

> <**JL**>
> Why not?
> <**JL**>

Actually, it should be ICMP parameter problem with pointer
pointing to something useful, e.g., sender's HIT.  That would
be an indication that such an association does not exist.
The same could be used also for received UPDATE, R2,
and perhaps PAYLOAD, when the HIP association has been dropped.

I would suggest a new section 6.3.5.

6.3.5.  Non-existing HIP association

    If a HIP implementation receives a CLOSE, UPDATE, or PAYLOAD
    packet, or any other packet whose handling requires an existing
    association, that has either a Receiver or Sender HIT that does
    not match with any existing HIP association, the implementation
    MAY respond, rate limited, with an ICMP packet with the type
    Parameter Problem, the Pointer pointing to the the beginning of
    the first HIT that does not match.

    A host MUST NOT reply with such an ICMP if it receives any of
    the following messages: I1, R2, I2, R2, BOS, CER, and NOTIFY.  When
    introducing new packet types, a specification SHOULD define the
    appropriate rules for sending or not sending this kind of ICMP
    replies.

8.11.

    0.  If there is no corresponding HIP association, the implementation
        MAY reply with an ICMP Parameter Problem, as specified in 6.3.5.

>     Receive CLOSE for unknown association, optionnaly send NOTIFY
>  as defined in section XXX and stay at UNASSOCIATED

Before "receive anyother":

      Receive CLOSE, UPDATE, or PAYLOAD, optionally send ICMP Parameter
      Problem and stay in UNASSOCIATED.

In CLOSING and CLOSED, if you receive I1 or I2, you should handle them 
just
as if you were in UNASSOCIATED.  In I1 case, stay in the state where you
are but reply with an R1.  In I2 case, try to process, and if 
successful,
move to R2-SENT, otherwise stay where where you are.

Some more text in Sec 8 probably needs to be revised.  Please check.

> <**JL**>
>   If a node needs to send data while in CLOSING or CLOSED state, a new
> exchange must be initiated by sending an I1. The problem is that both
> nodes needs a means to distinguish packets from two incarnations of a
> same HIP association between two HIs. If a node receives an I1 while in
> CLOSING or CLOSED, or even if ESTABLISHED (if a CLOSE was lost), it 
> would
> create another HIP state and handle all inbound packets but CLOSE and
> CLOSE_ACK with this new state. I found this approach ambiguous and a
> bit naive (what happens if the new association is then closed ??).
> That's one of the reason I've been advocating in the past for having 
> either
> NONCE, SEQUENCE_NUMBER or even TRANSACTION_ID in HIP. Another 
> possibility
> might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and 
> CLOSE_ACK
> and use it to demultiplex the packets to the correct state.
>
> What does other people think?
> <**JL**>

Reuse SEQ from UPDATE for CLOSE?

>           association that does not exist.

Not needed as we should use ICMP.  Sorry for forgetting about my
own guidelines.

The last line of the suggested Sec Cons text must refer to ICMP,
not NOTIFY.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 Oct 2004 13:20:35 +0200

On Monday 11 October 2004 20:27, Pekka Nikander wrote:
> Some details

<snip>

Taking Pekka's comments in account, and adding a rule for transition 
to I2_SENT while receiving R1 in CLOSING or CLOSED, the new modified
text should include what follows (I didn't modified the state diagram
to reflect transition to I2-SENT and R2-SENT from CLOSING/CLOSED).

Thanks,

--julien

-----------------------------------------------------------------------