[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] Recovery from state loss
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
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.