[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] Recovery from state loss
On Friday 08 October 2004 13:13, Petri Jokela wrote:
> 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.
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
5.4.2 HIP State Processes
<**PJ**>
In UNASSOCIATED: MAY answer with NOTIFY to incoming CLOSE, not
written down here
<**PJ**>
<**JL**>
Why not?
<**JL**>
+------------+
|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, optionnaly send NOTIFY
as defined in section XXX and 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**>
<**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
UNASSOCIATED. Also, there's no need for 'timeout sun' or 'counter',
nor to reset timer here.
</**JL**>
+--------+
| 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 (UAL + 2MSL), discard state and go to UNASSOCIATED
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**>
<**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**>
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.
-------------------------------------------------------------------
<**JL**>
Below is suggested text to replace this paragraph of the Security Considerations:
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. Because 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 these messages
and discard the associated state (for e.g., firewalling, SPI-based NATing, 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.
-----------------------------------------------------------------------------