[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] Recovery from state loss
Pekka Nikander wrote:
Looks good, thanks!
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.
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.