Subject: [Hipsec] Recovery from state loss

From: [email-masked] (Julien Laganier)
Date: Thu Oct 7 16:14:01 2004

--Boundary_(ID_slDDtQREaSofIkrNVClEkg)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-disposition: inline

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

--Boundary_(ID_slDDtQREaSofIkrNVClEkg)
Content-type: text/plain; charset=iso-8859-1; name=hip_closeack.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=hip_closeack.txt

The mechanism uses two time constant: UAL (Unused Association Lifetime)
minutes and MSL (Maximum Segment Lifetime) minutes.

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

5.4.1  HIP States

   UNASSOCIATED State machine start
   I1-SENT Initiating HIP
   I2-SENT Waiting to finish HIP
   R2-SENT Waiting to finish HIP
   ESTABLISHED HIP SA established
   REKEYING HIP SA established, but UPDATE is outstanding for rekeying
   CLOSING HIP SA closing, no data (ESP) can be sent
   E-FAILED HIP exchange failed

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

5.4.2  HIP State Processes

   +------------+
   |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, send CLOSE_ACK and 
	stay at UNASSOCIATED
   Receive ANYOTHER, drop and stay at UNASSOCIATED

   +------------+
   |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 UNASSOCIATED
	if failed, stay at ESTABLISHED 

   +---------+
   | 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 UNASSOCIATED
	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

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

5.4.3  Simplified HIP State Diagram

       +-+
       | | CLOSE received, send CLOSE_ACK
       V ^
   +------------+
   |UNASSOCIATED|<=================+-+
   +------------+                  | |
         ^                         | |
         | CLOSE_ACK received, or  | |
         | UAL+MSL minutes CLOSE   | |
	 | re-xmits                | | CLOSE received,
         ^                         | | send CLOSE_ACK
    +---------+                    | |
    | CLOSING |>-------------------+ | 
    +---------+                      |
         ^                           |
         | No packet sent/received   |
	 | for UAL min, send CLOSE   |
         ^                           |
   +------------+                    |
   |ESTABLISHED |>-------------------+
   +------------+

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

7.10  CLOSE - the HIP association closing packet

   The HIP header values for the CLOSE packet:

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

   IP ( HIP ( ECHO_REQUEST, HMAC, HIP_SIGNATURE ) )

   Valid control bits: none

   The sender MUST include an ECHO_REPLY used to validate CLOSE_ACK
   received in response, and both an HMAC and a signature (calculated
   over the whole HIP envelope).
   
   The receiver peer MUST validate both the HMAC and the signature if it
   has a HIP association state, and MUST reply with a CLOSE_ACK containing
   an ECHO_REPLY corresponding to the received ECHO_REQUEST.

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

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) if it has a HIP association state.
   
   The receiver peer MUST validate both the HMAC and the signature 
   if present and it has an association state.

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

8.16 Processing CLOSE packets

   When the host receives a CLOSE message it discards the HIP association
   state and responds with a CLOSE_ACK message.  (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.

   Once the HIP association state has been discarded 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 CLOSE_ACK response to speed up
   the peer discarding the HIP association in the presence of packet loss.

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

8.17 Processing CLOSE_ACK packets

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

   It is possible to use stronger verification of the CLOSE_ACK based on
   optional HMAC and SIGNATURE but only for the first CLOSE message since
   the HIP state is discarded on its reception. Then, depending on policy,
   when the CLOSE_ACK response to the first CLOSE is lost, an
   implementation discards its HIP state by waiting for either subsequent
   not-signed and not-MACed CLOSE_ACK packets, or the full UAL+MSL
   minutes retransmission period.

--Boundary_(ID_slDDtQREaSofIkrNVClEkg)--

---

From: [email-masked] (Pekka Nikander)
Date: Fri Oct 8 03:44:01 2004

> 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

---

From: [email-masked] (Petri Jokela)
Date: Fri Oct 8 06:06:01 2004

> 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

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

    +------------+

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

    +------------+

    	if successful, send CLOSE_ACK and go to CLOSED

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

    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

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

    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

        +-+
        | | 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**>

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

    IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) )

    Valid control bits: none

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

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

    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: [email-masked] (Julien Laganier)
Date: Mon Oct 11 11:50:01 2004

--Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-disposition: inline

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

--Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA)
Content-type: text/plain; charset=iso-8859-1; name=CLOSEACK2
Content-transfer-encoding: quoted-printable
Content-disposition: attachment; filename=CLOSEACK2

5.4.2 =A0HIP State Processes

<**PJ**>
=A0 =A0 =A0 =A0 =A0In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOS=
E, not
=A0 =A0 =A0 =A0 =A0written down here
<**PJ**>

<**JL**>

Why not?

<**JL**>

=A0 =A0 +------------+
=A0 =A0 |UNASSOCIATED| =A0Start state
=A0 =A0 +------------+

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

=A0 =A0 Receive ESP for unknown SA, optionally send ICMP as defined
=A0=A0=A0=A0=A0=A0=A0=A0in Section 6.3 and stay at UNASSOCIATED
=A0 =A0 Receive CLOSE for unknown association, optionnaly send NOTIFY
 as defined in section XXX and stay at UNASSOCIATED
=A0 =A0 Receive ANYOTHER, drop and stay at UNASSOCIATED

<**PJ**>
=A0 =A0 =A0 =A0 =A0ESTABLISHED: Go to CLOSED instead of UNASSOCIATED
<**PJ**>

=A0 =A0 +------------+
=A0 =A0 |ESTABLISHED | HIP SA established
=A0 =A0 +------------+

=A0 =A0 Receive I1, send R1 and stay at ESTABLISHED
=A0=A0=A0=A0=A0=A0=A0=A0
=A0 =A0 Receive I2, process with cookie and possible Opaque data verificati=
on
=A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2, drop old SAs, establish new=
 SA, go to
=A0=A0=A0=A0=A0=A0=A0=A0R2-SENT
=A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at ESTABLISHED
=A0 =A0 Receive R1, drop and stay at ESTABLISHED
=A0 =A0 Receive R2, drop and stay at ESTABLISHED

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

<**PJ**>
=A0 =A0 =A0 =A0 =A0Closing: Move to CLOSED after sending CLOSE_ACK instead =
of
=A0 =A0 =A0 =A0 =A0UNASSOCIATED
<**PJ**>

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

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

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

=A0 =A0 Receive ANYOTHER, drop and stay at CLOSING

=A0 =A0 Timeout, increment timeout sum, reset timer
=A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is less than UAL+MSL minutes, retran=
smit CLOSE
=A0=A0=A0=A0=A0=A0=A0=A0 =A0and stay at CLOSING
=A0=A0=A0=A0=A0=A0=A0=A0if timeout sum is greater than UAL+MSL minutes, go =
to
=A0 =A0 =A0 =A0 =A0 =A0UNASSOCIATED

<**PJ**>
=A0 =A0 =A0 =A0 =A0CLOSED is a new state. Timeout sum should be 2*MSL or so=
mething
=A0 =A0 =A0 =A0 =A0else??
<**PJ**>

<**JL**>
The 'active closer' might retransmit a CLOSE during UAL + MSL, so I think
a host entering CLOSED should wait for UAL + 2MSL before going to=20
UNASSOCIATED. Also, there's no need for 'timeout sun' or 'counter',
nor to reset timer here.
</**JL**>

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

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

=A0 =A0 Receive CLOSE, process
=A0 =A0 =A0=A0=A0=A0if successful, send CLOSE_ACK, stay at CLOSED
=A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED

=A0 =A0 Receive CLOSE_ACK, process
=A0=A0=A0=A0=A0=A0=A0=A0if successful, discard state and go to UNASSOCIATED
=A0=A0=A0=A0=A0=A0=A0=A0if failed, stay at CLOSED

=A0 =A0 Receive ANYOTHER, drop and stay at CLOSED

    Timeout (UAL + 2MSL), discard state and go to UNASSOCIATED

5.4.3 =A0Simplified HIP State Diagram

=A0 =A0 =A0 =A0 +-+
=A0 =A0 =A0 =A0 | | CLOSE received, send NOTIFY
=A0 =A0 =A0 =A0 V ^
=A0 =A0 +------------+
=A0 =A0 |UNASSOCIATED|<----------------------+
=A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0| Timeout, move to
=A0 =A0 =A0 =A0 =A0 | CLOSE_ACK received, or =A0 =A0 =A0 | UNASSOCIATED
=A0 =A0 =A0 =A0 =A0 | timeout sum > UAL+MSL =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-=
=2D------+
=A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0rec CLOSE, =A0 =A0 +--->| CLOSED |----+
=A0 =A0 =A0+---------+ send CLOSE_ACK | =A0 =A0+--------+ =A0 =A0| CLOSE re=
ceived,
=A0 =A0 =A0| CLOSING |----------------+ =A0 =A0 =A0 =A0| =A0 ^ =A0 =A0 | se=
nd CLOSE_ACK
=A0 =A0 =A0| =A0 =A0 =A0 =A0 |-----+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =
=A0 | =A0 =A0 |
=A0 =A0 =A0+---------+ =A0 =A0 | timeout sum =A0 =A0 =A0 | =A0 +-----+
=A0 =A0 =A0 =A0 =A0 ^ =A0 ^ =A0 =A0 =A0| < UAL+MSL, =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 | =A0 +------+ retransmit CLOSE =A0|
=A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0|
=A0 =A0 =A0 =A0 =A0 | No packet sent/received =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 | for UAL min, send CLOSE =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0| CLOSE received,
=A0 =A0 +------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | send C=
LOSE_ACK
=A0 =A0 |ESTABLISHED |>----------------------+
=A0 =A0 +------------+

=2D----------------------------------------------------------------

<**PJ**>
=A0 =A0 =A0 =A0 =A0Removed optional things, NOTIFY is sent in UNASSOCIATED =
state
<**PJ**>

7.11 =A0CLOSE_ACK - the HIP closing acknowledgment packet

=A0 =A0 The HIP header values for the CLOSE_ACK packet:

=A0 =A0 Header:
=A0=A0=A0=A0=A0=A0=A0=A0Packet Type =3D XXX Tbd.
=A0=A0=A0=A0=A0=A0=A0=A0SRC HIT =3D Sender's HIT
=A0=A0=A0=A0=A0=A0=A0=A0DST HIT =3D Recipient's HIT

=A0 =A0 IP ( HIP ( ECHO_REPLY, HMAC, HIP_SIGNATURE ) )

=A0 =A0 Valid control bits: none

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

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

=2D----------------------------------------------------------------

<**PJ**>
=A0 =A0 =A0 =A0 =A0We don't discard the state before we move to UNASSOCIATE=
D.
=A0 =A0 =A0 =A0 =A0- If we want to send data? We cannot use the old associa=
tion
=A0 =A0 =A0 =A0 =A0any longer, we need to start a new negotiation. That par=
t of
=A0 =A0 =A0 =A0 =A0the text needs maybe some clarification.
<**PJ**>

<**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=20
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=20
create another HIP state and handle all inbound packets but CLOSE and=20
CLOSE_ACK with this new state. I found this approach ambiguous and a=20
bit naive (what happens if the new association is then closed ??).=20
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=20
might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and CLOSE_ACK=20
and use it to demultiplex the packets to the correct state.

What does other people think?
<**JL**>

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

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

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

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

=2D----------------------------------------------------------------

<**PJ**>
=A0 =A0 =A0 =A0 =A0Optional things removed. ACK also accepted in CLOSED sta=
te if we
=A0 =A0 =A0 =A0 =A0have earlier sent CLOSE related to the same association:
=A0 =A0 =A0 =A0 =A0ASSOCIATED -> send CLOSE -> CLOSING -> receive CLOSE, se=
nd
=A0 =A0 =A0 =A0 =A0CLOSE_ACK -> CLOSED -> receive CLOSE_ACK to earlier sent=
 CLOSE
=A0 =A0 =A0 =A0 =A0->...
<**PJ**>

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

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

=2D----------------------------------------------------------------

<**PJ**>
=A0 =A0 =A0 =A0 =A0New NOTIFY
<**PJ**>

6.2.19 NOTIFY

=A0 =A0 =A0 =A0UNKNOWN ASSOCIATION =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A044

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

=2D------------------------------------------------------------------

<**JL**>
Below is suggested text to replace this paragraph of the Security Considera=
tions:

   A fourth form of DoS attack is emulating the end of state.  HIP has
   no end of state packet.  It relies on a local policy timer to end
   state.

</**JL**>

   A fourth form of DoS attack is emulating the end of state. HIP relies on=
 timers plus
   a CLOSE/CLOSE_ACK handshake to explicitly signals the end of a state. Be=
cause both
   CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a=
 connection.
   The presence of an additional SIGNATURE allows middle-boxes to inspect t=
hese messages
   and discard the associated state (for e.g., firewalling, SPI-based NATin=
g, etc.).
   However, the optionnal behavior of replying to CLOSE with a NOTIFY while=
 in UNASSOCIATED state
   might allow a spoofer sending CLOSE messages to launch reflexion attacks=
=2E=20

=2D------------------------------------------------------------------------=
=2D---=

--Boundary_(ID_E7chyaMZY6sG58Aq4XBUOA)--

---

From: [email-masked] (Pekka Nikander)
Date: Mon Oct 11 13:19:01 2004

Some details:

> =A0 =A0 =A0 =A0 =A0In UNASSOCIATED: MAY answer with NOTIFY to incoming =
CLOSE, not
> =A0 =A0 =A0 =A0 =A0written down here

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.

> =A0 =A0 Receive ANYOTHER, drop 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=20=

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=20
successful,
move to R2-SENT, otherwise stay where where you are.

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

> exchange must be initiated by sending an I1. The problem is that both
> 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=20
> 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=20=

> either
> NONCE, SEQUENCE_NUMBER or even TRANSACTION_ID in HIP. Another=20
> possibility
> might be to embed ECHO_REQ/REP exchanged in R1/I2 in CLOSE and=20
> CLOSE_ACK

Reuse SEQ from UPDATE for CLOSE?

> =A0 =A0 =A0 =A0UNKNOWN ASSOCIATION =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A044
> =A0 =A0 =A0 =A0 =A0 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: [email-masked] (Julien Laganier)
Date: Tue Oct 12 06:11:00 2004

--Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-disposition: inline

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

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

--Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw)
Content-type: text/plain; charset=iso-8859-1; name=CLOSEACK3
Content-transfer-encoding: quoted-printable
Content-disposition: attachment; filename=CLOSEACK3

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

=A0 =A0 +------------+

=A0 =A0 +------------+

=A0 =A0 +---------+

=A0 =A0 Datagram to send, requires the creation of another incarnation
 of the HIP association, started by sending an I1,
 and stay at CLOSING

=A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED
=A0 =A0 Receive I2, process
=A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT
=A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at CLOSING

    Receive R1, process
        if successful, send I2 and go to I2-SENT
        if fail, stay at CLOSING

=A0 =A0 +--------+

=A0 =A0 Datagram to send, requires the creation of another incarnation
 of the HIP association, started by sending an I1,
 and stay at CLOSED

=A0 =A0 Receive I1, send R1 and stay at UNASSOCIATED
=A0 =A0 Receive I2, process
=A0=A0=A0=A0=A0=A0=A0=A0if successful, send R2 and go to R2-SENT
=A0=A0=A0=A0=A0=A0=A0=A0if fail, stay at CLOSED

    Receive R1, process
        if successful, send I2 and go to I2-SENT
        if fail, stay at CLOSED

=A0 =A0 =A0 =A0 +-+

<ADD>

<INSERT>

8.11  Processing UPDATE packets

<ADD>

=A0 =A0 Header:

<ADD>

    If there is no corresponding HIP association, the implementation
        MAY reply to a CLOSE with an ICMP Parameter Problem, as i
 specified in 6.3.5.
=2D----------------------------------------------------------------

<ADD>

<SUBSTITUTE>

<WITH>

   A fourth form of DoS attack is emulating the end of state. HIP relies on=
 timers plus
   a CLOSE/CLOSE_ACK handshake to explicitly signals the end of a state. Be=
cause both
   CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a=
 connection.
   The presence of an additional SIGNATURE allows middle-boxes to inspect t=
hese messages
   and discard the associated state (for e.g., firewalling, SPI-based NATin=
g, etc.).
   However, the optionnal behavior of replying to CLOSE with an ICMP Parame=
ter Problem=20
   packet (as described in Section 6.3.5), might allow an IP spoofer sendin=
g CLOSE
   messages to launch reflexion attacks.=20

--Boundary_(ID_YV96UoWpQ1XJ7a+GWjP0Vw)--