IESG F. Detienne
Internet-Draft P. Sethi
Expires: January 15, 2009 Cisco
Y. Nir
Check Point
July 14, 2008
Safe IKE Recovery
draft-detienne-ikev2-recovery-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Abstract
The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
limitation of not having a means to quickly recover from a stale
state known as dangling Security Associations (SA's) where one side
has SA's that the corresponding party does not have anymore.
This Draft proposes to address the limitation by offering an
immediate, DoS-free recovery mechanism for IKE.
Detienne, et al. Expires January 15, 2009 [Page 1]
Internet-Draft Safe IKE Recovery July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. High level description . . . . . . . . . . . . . . . . . . 3
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Protocol design guidelines . . . . . . . . . . . . . . . . 4
2.4. Protocol design rationale . . . . . . . . . . . . . . . . 4
3. IKE recovery . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IKE Recovery options . . . . . . . . . . . . . . . . . . . 5
3.2. Stateless IKE Recovery . . . . . . . . . . . . . . . . . . 5
3.2.1. Introducing CHECK_SPI . . . . . . . . . . . . . . . . 5
3.2.2. Stateless recovery by invalid IKE packets . . . . . . 6
3.2.3. Wait before rekey . . . . . . . . . . . . . . . . . . 8
3.2.4. Stateless IKE Recovery cookie . . . . . . . . . . . . 9
3.3. Ticket based IKE recovery using Session Resumption . . . . 10
3.3.1. Ticket Based Recovery . . . . . . . . . . . . . . . . 10
3.3.2. Choice of Recovery Mechanism . . . . . . . . . . . . . 10
3.3.3. Ticket based recovery by invalid IKE packets . . . . . 11
3.4. IPsec SA recovery . . . . . . . . . . . . . . . . . . . . 12
3.4.1. In the presence of an IKE_SA . . . . . . . . . . . . . 13
3.4.2. In the absence of an IKE_SA . . . . . . . . . . . . . 14
3.5. Mandatory Initiators . . . . . . . . . . . . . . . . . . . 15
3.6. Recovery closure . . . . . . . . . . . . . . . . . . . . . 17
3.7. Dealing with race conditions . . . . . . . . . . . . . . . 17
4. Throttling and dampening . . . . . . . . . . . . . . . . . . . 18
4.1. Invalid SPI throttling . . . . . . . . . . . . . . . . . . 18
4.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. User controls . . . . . . . . . . . . . . . . . . . . . . 19
5. Negotiating IKE recovery . . . . . . . . . . . . . . . . . . . 19
6. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Detienne, et al. Expires January 15, 2009 [Page 2]
Internet-Draft Safe IKE Recovery July 2008
1. Introduction
If an IKEv2 ([IKEv2]) endpoint receives an IPsec packet that it does
not recognize (invalid SPI), a specific notify (INVALID_SPI) can be
sent back to the originating peer to take action. This payload is
typically only going to be trusted if it is protected by a IKE_SA as
unprotected notifies can easily be forged. Similarly, an IKEv2
endpoint receiving an unrecognized IKE message MAY send back an
INVALID_IKE_SPI notify to the originating peer. In order to validate
those unauthenticated messages, a polling sequence has to be started.
This memo proposes to decrease the time incurred by this sequence.
The polling sequence works as follow. When a peer doubts the
liveness of its remote peer, it can send empty informational
exchanges expecting a reply confirming liveness. This works as
informational exchanges are supposed to be acknowledged in IKEv2.
Practical mechanisms offered so far suffer from one of the following
limitations:
o poll based and slow to react or resource hungry
o based on unauthenticated packets and hence open to denial of
service attacks
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [Bra97].
2. Protocol overview
2.1. High level description
The recovery procedure works in 3 stages:
1. An invalid IKE or ESP packet is received by either peer
2. The remote peer is notified through a protected or unprotected
notify
* Protected notifies are implicitly trusted
* The remote peer attemps to confirm the legitimacy of
Unprotected Notifies
3. The remote peer deletes or recreates the SA's in error
2.2. Notation
The IKEv2 notation will be used throughout this document with one
notable addition. Parent SA describes an IKE_SA from which a
CHILD_SA has been derived.
Detienne, et al. Expires January 15, 2009 [Page 3]
Internet-Draft Safe IKE Recovery July 2008
2.3. Protocol design guidelines
The general approach to recovering from dangling SA situations is to
send proofs of desynchronization and liveness. It is admittedly
difficult for two gateways to demonstrate they did have SA's but have
lost them without a secure, authenticated channel to do so. It is
however relatively easy for these gateways to provide valuable hints
about the lost SA's.
This memo presents a protocol that builds enough trust for those
hints to be taken in account. The basic principle is that an
attacker taking advantage of this recovery procedure would have to be
positioned on the network such that it could perform more interesting
attacks than tackling recovery. I.e. the barrier for attacking IKE
recovery is as high or higher than other parts of the IKE protocol.
The recovery of SA's as outlined in this memo occurs in three phases:
o Unrecognized SPI's are detected
o The protocol collects clues of previous connectivity
o The SA's are repaired by [IKEv2] or by reconstructing the SA from
the "ticket"
This memo follows the below guidelines:
o event driven protocol -- no polling involved
o re-create SA's instead of deleting them upon error
o let the side that still has the SA's negotiate fresh SA's after a
failure
o do not generate state when it can be avoided; reduce CPU cost
2.4. Protocol design rationale
IKEv2 already specifies a poll-based peer liveness detection
mechanism. While this type of mechanism helps recovery in most
situations, the time taken for recovery tends to be high.
Convergence time requirements are getting shorter and faster
protocols are becoming a necessity.
The protocol is triggered when dangling SA's are detected, i.e. when
a peer receives unrecognized SPI's. This event is in turn triggered
when there is actual traffic to be sent and there would be little
point in just deleting SA's then hoping for the systems to recreate
them. Instead, these SA's have to be repaired as fast as possible in
order for the underlying network traffic to be forwarded.
The device that has the SA's also has all the information needed to
rekey them and becomes the defacto initiator at the end of the
recovery procedure. This is particularly important for systems with
dynamic security policies that do not specify how to build the SA; it
Detienne, et al. Expires January 15, 2009 [Page 4]
Internet-Draft Safe IKE Recovery July 2008
may not be obvious for those peers to determine which security
parameter they should use to recreate the SA they are now missing.
When recreating the SA, the peer that has SA's implicitly knows what
to rebuild and can use the old SA as a template.
The choice of the rekeyer also brings in an added security value.
The side that wants to transmit data or at least that pretends having
SA's has to demonstrate 'willingness' to actually transmit.
Correspondingly it also means that the gateway that does not have
SA's is not forced to negotiate anything it may not need. It is
important to note that the initial effort of setting up timers and
retransmitting, etc... is left to the side that wants to transmit
data.
Last but not least, the protocol can remain stateless until
sufficient proof of liveness is discovered. In fact, one of the
protocol variations in this meme allows full statelessness at the
expense of a round trip time. In an other variation, some small but
reboot-resistant storage (a key) is used to accelerate the recovery.
3. IKE recovery
3.1. IKE Recovery options
During their IKEv2 exchange, two peers negotiate support for IKE
Recovery. If both peers can store ephemeral information as well as
longer term additional information related to IKE Recovery, an
accelerated procedure for setting up new SAs can be used. This
procedure is called Ticket Based IKE Recovery and is described in
Section 3.3.
If either peer cannot store ephemeral or long term information, peers
fall back to Sateless IKE Recovery described in Section 3.2.
3.2. Stateless IKE Recovery
3.2.1. Introducing CHECK_SPI
Stateless IKE Recovery is negotiated during the initial IKE exchange
by advertising capabilities as described in Section 5.
In order to achieve stateless IKE recovery, this memo introduces a
new notify type called CHECK_SPI. The CHECK_SPI payload carries an
SPI (IKE_SA or Child SA) and one of three sub-types (QUERY, ACK,
NACK). The semantic of the CHECK_SPI subtypes is the following:
Detienne, et al. Expires January 15, 2009 [Page 5]
Internet-Draft Safe IKE Recovery July 2008
o QUERY: a peer queries the remote peer SA DB for the presence of
the SA whose value is in the payload
o ACK: a peer confirms it has the SA specified in the payload
o NACK: a peer confirms it does not have the SA specified in the
payload
The payload format of the CHECK_SPI notify is covered in Section 6.
3.2.2. Stateless recovery by invalid IKE packets
When an IKE peer X receives an IKE packet with an unknown IKE SPI
(A,B), that is not an initialization offer (IKE_SA_INIT), peer X
SHOULD send an unprotected INVALID_IKE_SPI notification.
Peer X Peer Y
HDR(A,B) ...
<--------------------------------------------
HDR(A,B) INVALID_IKE_SPI(A,B)
-------------------------------------------->
Even if another IKE_SA exists with the remote peer Y, the
notification MUST NOT be sent protected since peer Y may not share
this SA either.
In order to limit the risk of Denial of Service attacks, the sending
of the INVALID_IKE_SPI notification MUST be rate limited.
When peer Y receives the unauthenticated INVALID_IKE_SPI referencing
the offending IKE SPI (A,B), Y MUST perform the following actions:
o verify that (A,B) is indeed an active IKE_SPI with X
o send to X a new notify type CHECK_SPI(QUERY, (A,B)) followed by a
N(Cookie) payload
Peer X Peer Y
HDR(A,B) INVALID_IKE_SPI(A,B)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(A,B)), N(Cookie)
<--------------------------------------------
The sending of the CHECK_SPI packet MUST be rate limited on a per
peer basis.
Y SHOULD NOT generate any state at this point. If the
INVALID_IKE_SPI notification gets lost, and X indeed does not have
Detienne, et al. Expires January 15, 2009 [Page 6]
Internet-Draft Safe IKE Recovery July 2008
the IKE SPI, the process will start again at the next IKE message
sent by Y to X.
When peer X receives an unauthenticated CHECK_SPI(QUERY,(A,B))
packet, it MUST perform a look up for (A,B) in its IKE_SA database.
Depending on whether X has or does not have the offending SA, it
SHOULD reply with an IKE packet CHECK_SPI(ACK|NACK,(A,B)) N(COOKIE).
The N(COOKIE) payload in the CHECK_SPI(ACK|NACK) packet is the same
as that recieved in the CHECK_SPI(QUERY), i.e. the N(COOKIE) payload
is reflected back in the response.
Section 3.2.4 discusses cookie generation in greater detail. For
now, it is enough to know that the cookie should contain enough
information for peer Y to validate the CHECK_SPI(ACK|NACK) response
without having to keep any state.
Peer X Peer Y
HDR(A,B) CHECK_SPI(QUERY,(A,B)), N(Cookie)
<--------------------------------------------
HDR(A,B) CHECK_SPI(ACK|NACK,(A,B)), N(Cookie)
-------------------------------------------->
When peer Y receives the CHECK_SPI(ACK|NACK)|N(Cookie) packet, it
MUST ensure the COOKIE is valid. If it is not, the packet MUST be
dropped and a rate limited message MUST be logged.
If the COOKIE is valid and the remote peer X confirms it has the IKE
SPI (via CHECK_SPI(ACK,...)), a rate limited message SHOULD be
logged; this could be a race condition or an attack from a spoofing
attacker.
If the COOKIE is valid and the remote peer X confirms it does NOT
have the IKE SPI (via CHECK_SPI(NACK,..), peer Y MUST delete the
IKE_SA(A,B) and any CHILD_SA's that belong to this IKE_SA, and it
SHOULD initiate a new IKE exchange to renegotiate the Parent SA. The
parameters of the negotiation SHOULD be taken primarily from the
configuration (security policy) and, if absent, taken from the
confirmed dangling SA. Renegotiation of CHILD_SA's SHOULD follow the
Parent IKE_SA creation.
A complete recovery exchange for IKE SA's would look like:
Detienne, et al. Expires January 15, 2009 [Page 7]
Internet-Draft Safe IKE Recovery July 2008
Peer X Peer Y
HDR(A,B) ...
<--------------------------------------------
HDR(A,B) INVALID_IKE_SPI(A,B)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(A,B)), N(Cookie)
<--------------------------------------------
HDR(A,B) CHECK_SPI(NACK,(A,B)), N(Cookie)
-------------------------------------------->
HDR(A',0) SAi1, KEi, Ni
<--------------------------------------------
...
3.2.3. Wait before rekey
There exists a particular attack where a man-in-the-middle can snoop
and inject traffic but can not block or drop packets. This attack
can spoof INVALID_SPI (allegedly from X), forcing a CHECK_SPI(QUERY)
from Y. The attacker would spoof back CHECK_SPI(NACK) to force an
undue rekey. Since the attacker can not block packets, the
CHECK_SPI(QUERY) will also reach X, who will reply with
CHECK_SPI(ACK).
Y receives CHECK_SPI(NACK) first and MAY wait for a few msec before
creating a new SA. Y will eventually receive BOTH a CHECK_SPI(ACK)
and a CHECK_SPI(NACK). Which is dubious. The SIR process should
then stop and log an error, saving the SA.
The process is illustrated below:
Detienne, et al. Expires January 15, 2009 [Page 8]
Internet-Draft Safe IKE Recovery July 2008
X Attacker Y
Inv SPI
------------------>
CHECK_SPI(QUERY)
<-------------------------------------
CHECK_SPI(NACK)
------------------> Should rekey
but wait a few msec
CHECK_SPI(ACK)
-------------------------------------> Hint of attack
=> no rekey
Ideally, the round-trip-time should be measured during the IKE
exchange and Y wait for a full RTT before initiating a rekey.
Given that IKE itself is subject to DH computation by a man-in-the-
middle, also considering that SA's are dampened after creation (see
Section 4.2), the staging complexity and limited interest of this
attack makes it rather impractical. An implementation MAY decided to
implement this final safety wait but this is strictly optional.
3.2.4. Stateless IKE Recovery cookie
The cookie information is chosen by the peer that emits it. As such,
the cookie has strictly no meaning for the remote peer and can thus
be chosen as seen fit. This section provides recommendations on how
to generate and validate those cookies.
When an IKE endpoint sends an unauthenticated CHECK_SPI, the cookie
payload following the notify is computed as follow:
Cookie = <VersionIDofSecret>
| H(<secret> | CHECK_SPI(..., Query)
| ip.src | ip.dst
| udp.src | udp.dst)
where
o <secret> is a randomly generated secret known only to the
responder and periodically changed
o <VersionIDofSecret> should be changed whenever <secret> is
regenerated
o CHECK_SPI(..., Query) is the content of the CHECK_SPI notify
payload where the operation subtype has been set to Query (cf.
Section 6)
Detienne, et al. Expires January 15, 2009 [Page 9]
Internet-Draft Safe IKE Recovery July 2008
o ip.src is the source ip address of the IKE packet
o ip.dst is the destination ip address of the IKE packet
o udp.src is the source udp post of the IKE packet
o udp.dst is the destination udp port of the IKE packet
Upon reception of a CHECK_SPI(ACK or NACK) response followed by a
N(Cookie), a peer can verify whether this is the reply to a Query it
placed by recomputing the cookie and comparing it to the COOKIE in
the IKE message.
In order to minimize the range of cryptographic attacks on <secret>,
messages SHOULD have a limited life time.
3.3. Ticket based IKE recovery using Session Resumption
3.3.1. Ticket Based Recovery
If both peers can store ephemeral information and support IKE Session
Resumption as described in [IKERESUME], an accelerated procedure can
be used. This procedure is called Ticket Based IKE Recovery.
The ticket based IKE Recovery method relies on an unauthenticated
INVALID_IKE_SPI along with a cookie for detection of a dangling SA.
Recovery is effected using session resumption exchange described in
[IKERESUME]to recover from a Dangling SA condition. This memo
introduces a variation to the Session Resumption Exchange for
protection against Denial of Service Attacks
3.3.2. Choice of Recovery Mechanism
The choice of using Stateless IKE Recovery or Ticket Based Recovery
depends upon the capabilities of the endpoint and its peer as well.It
could also depend on policy.
During Recovery, the endpoint that still has the SA, also knows about
the peers capabilities whereas the enpoint that has lost its SA can
be presumed to not know its peers capabilities. This endpoint only
offers a hint of its capabilities by responding to an inavlid packet
with an INVALID_SPI followed by a cookie.
The endpoint that has the SA can choose to respond to an
unauthenticated INVALID_SPI based on its knowledge of the peer
capabiliries. If it has a session_resumption ticket from the peer,
it SHOULD initiate an IKE_SESSION_RESUME exchange, else it SHOULD
send a CHECK_SPI query. If the peer is not capable of Safe IKE
Recovery, the endpoint SHOULD fall back to liveness checks or other
mechanisms recommended by [IKEv2].
Detienne, et al. Expires January 15, 2009 [Page 10]
Internet-Draft Safe IKE Recovery July 2008
If the endpoint that recieves an IKE_SESSION_RESUME packet is unable
to use the resumption ticket for any reason, it should respond with a
RESUME_NACK followed by the peer coookie it recieved in the clear.
This allows the peer to initiate a full IKEv2 exchange safely.
3.3.3. Ticket based recovery by invalid IKE packets
When a peer X receives an IKE packet with an unknown IKE_SPI, it
SHOULD send an unprotected INVALID_IKE_SPI notify to the sender Y.
The INVALID_IKE_SPI MUST be followed with a Cookie payload. The
cookie payload content is relevant only to the generator of the
cookie and a suggested format for it is described in Section 3.2.4
This cookie has been furhter referred to a s COOKIE_X
When peer Y receives the INVALID_IKE_SPI referencing the IKE_SPI(A,B)
followed by N(COOKIE_X), it MUST perform the following actions:
o verify that (A,B) is an active IKE_SA it has with X. If no such SA
exists a ate limited mesage SHOULD be logged.
o verify that it possess a ticket given to it by X and initiate a
IKE_SESSION_RESUME exchange with X. This memo requires that the
IKE_SESSION_RESUME packet MUST carry the cookie COOKIE_X it
received in the INVALID_SPI packet encrypted in the SK payload. Y
also generates and sends another cookie in the clear. This cookie
is referred to further in the draft as COOKIE_Y
Peer X Peer Y
HDR(A,B) ...
<--------------------------------------------
HDR(A,B) INVALID_IKE_SPI(A,B) N(COOKIE_X)
-------------------------------------------->
HDR(A,B) Ni N(COOKIE_Y) N(TICKET) SK( IDi, IDr...N(COOKIE_X))
<--------------------------------------------
...
The peer X on reeiving a SESSION_RESUME packet with a cookie payload
MUST perform the following actions
look up the SA (A,B) in its SA database. If the SA exists, it MUST
respond with a protected CHECK_SPI(ACK) that includes the peer cookie
COOKIE_Y and a rate limited message SHOULD be logged.
If the SA does not exist, X should decrypt the SK payload using the
contents of the ticket. and validate COOKIE_X. If the cookie is not
valid the packet should be dropped and a rate limited message SHOULD
Detienne, et al. Expires January 15, 2009 [Page 11]
Internet-Draft Safe IKE Recovery July 2008
be logged.
If the IKE_SESSION_RESUME packet is rejected for any other reason,
Peer X responds with a CHECK_SPI(NACK) followed by the cookie
COOKIE_Y
Else the Peer X sends back an IKE_SESSION_RESUME response to create a
new SA. The response packet also includes N(COOKIE_Y) which is
simply sent back unchanged but protected inside the SK payload. Peer
X can also proceed to computing and creating state for a new SA as
described in [IKERESUME]. A further cookie exchange as described in
[IKERESUME] is not required as X has already transmitted a cookie in
the clear and has got the it back from it's peer Y securely
encrypted. Thus X can be sure of the authenticity of Y as well as
the freshness of the exchange.
Peer X Peer Y
HDR(A,B) Ni N(COOKIE_Y) N(TICKET) SK{IDi, IDr,...,N(COOKIE_X))
<--------------------------------------------
HDR(A,B) SK{IDr,Nr, SAr2,...,N(COOKIE_Y)}
----------------------------------------------->
...
Peer Y performs the following actions depending on the response it
gets back from X
o On receiving a SESSION_RESUME response, Peer Y decrypts the SK
payload and validates the COOKIE_Y, and proceeds to create a new
SA. If the cookie is invalid a rate limiting message is logged
and the packet is dropped.
o If the Peer Y receives a CHECK_SPI(NACK) followed by the cookie
COOKIE_Y, Y SHOULD proceed to initiating a regular IKEv2 session.
o If a protected CHECK_SPI(ACK) response is received, a rate
limiting message is logged.
o If the Peer Y receives a N(TICKET_NACK) notification, Y MAY
initiate a regular IKEv2 exchange.
3.4. IPsec SA recovery
We are now considering the case of an IKE endpoint Y sending an ESP
or AH packet (or any type of traffic supported by a CHILD_SA) to peer
X who does not have the corresponding phase 2 SA. We will
differentiate two subcases depending on the presence or not of an IKE
SA between the two peers.
Detienne, et al. Expires January 15, 2009 [Page 12]
Internet-Draft Safe IKE Recovery July 2008
The recovery procedure will be roughly the same as for the Dangling
Parent SA case but for children SA's, we send protected notifications
whenever we can.
Peer X Peer Y
ESP(SPI) ...
<--------------------------------------------
On receiving an unrecognized ESP or AH packet, Peer X SHOULD notify
the remote peer Y. The method will be different, according to the
presence of an IKE_SA with Y.
3.4.1. In the presence of an IKE_SA
In IKEv2, when an IKE_SA is available between two peers, CHILD_SA's
SHOULD not be out of sync thanks to the acknowledgement and
retransmissons of notifies. IKEv2 however does not specify what to
do when a peer does not eventually respond to protected DELETE_SPI
notifies.
This section augments the IKEv2 specification in order to allow the
recovery of stale SA's in case peers decided to keep the Parent SA
nevertheless.
If an IKE_SA is available with the remote peer, peer X MUST send a
protected INVALID_SPI notification to the Y. The notification MUST be
protected by the Parent SA and MUST contain the SPI of the invalid
packet.
Peer X Peer Y
ESP(SPI) ...
<--------------------------------------------
HDR(A,B) SK{INVALID_SPI(SPI)}
-------------------------------------------->
At this point, Y MUST check whether it has the offending SA. If so,
it SHOULD re-key or delete the child SA according to its security
policy. This document suggests that Y SHOULD delete the dangling SA
but MAY rekey if deemed adequate. If the offending SA is not to be
found, a message SHOULD be logged as the triggering ESP packet or be
the result of a race condition. The logging MUST be rate limited.
Detienne, et al. Expires January 15, 2009 [Page 13]
Internet-Draft Safe IKE Recovery July 2008
3.4.2. In the absence of an IKE_SA
If an IKE_SA is not available with peer Y, an unprotected INVALID_SPI
notification MUST be sent. The notification MUST contain the SPI of
the invalid packet.
Peer X Peer Y
ESP(SPI) ...
<--------------------------------------------
HDR(0,0) INVALID_SPI(SPI)
-------------------------------------------->
Note: An IKE SPI of (0,0) is used since there is no other IKE SPI to
use (by construction)
Peer Y MUST verify whether it has the offending CHILD_SA; if it does
not, Y MUST log a rate limited message and drop the notify. If Y
owns the offending SA, Y MUST perform the following:
o ensure the unauthenticated INVALID_SPI notify is legitimate
o rebuild the dangling SA's with the remote peer if needed
The following procedure will help determining whether the INVALID_SPI
notify is legitimate.
Peer Y MUST send a protected CHECK_SPI notify to X. Since Y has the
CHILD_SA, it MUST have its Parent SA by construction.
Peer X Peer Y
HDR(0,0) INVALID_SPI(SPI)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY, SPI)
<--------------------------------------------
If X can decrypt the CHECK_SPI(QUERY) notification from Y, i.e it has
a valid IKE_SA(A,B), the situation can be either of the following:
o there is a logic error on X as it should have sent the INVALID_SPI
protected
o the INVALID_SPI request that led to the CHECK_SPI notify has been
forged
o there was a race condition in an earlier exchange
X MUST try to identify which condition it has met, e.g. by checking
SPI is in the SA database and MUST log a message about a possible
security alert.
Detienne, et al. Expires January 15, 2009 [Page 14]
Internet-Draft Safe IKE Recovery July 2008
Under normal recovery circumstances, X will not have the PARENT SA.
In this case, X MUST reply with an unprotected INVALID_IKE_SPI(A,B)
and fall back into the Parent SA recovery procedure.
The Parent SA recovery procedure could use either stateless or Ticket
based recovery. The overall recovery scheme for CHILD_SA's using the
Stateless IKE recovery procedure can be summarized as .
Peer X Peer Y
ESP(SPI) ...
<--------------------------------------------
HDR(0,0) INVALID_SPI(SPI)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(SPI))
<--------------------------------------------
HDR(A,B) INVALID_IKE_SPI (A,B)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(A,B)), N(Cookie)
<--------------------------------------------
HDR(A,B) CHECK_SPI(NACK,(A,B)), N(Cookie)
-------------------------------------------->
HDR(A',0) SAi1, KEi, Ni
<--------------------------------------------
3.5. Mandatory Initiators
There are cases where the side having the SA's cannot act as an
initiator in a recovery procedure and has to rely on the peer device
to initiate recovery . These exceptions include:
Specific implementations, typically in remote access, that rely on
the 'client' to be a pure initiator.
gateways that are behind a dynamic PAT device and that can not be
reached directly from outside. These devices have to be
initiators of the connection in order to set up the translation
rules.
We call such devices Mandatory Initiators and in the context of this
document, they will eventually become responsible for recovering the
SA's.
Mandatory Initiators SHOULD be determined by the system administrator
Detienne, et al. Expires January 15, 2009 [Page 15]
Internet-Draft Safe IKE Recovery July 2008
through their configuration or implicitly through the set of features
they are configured for. Mandatory Initiators MAY determine by
themselves whether they are behind a dynamic PAT device. The
determination can for instance arise from analyzing the NAT-T payload
described in [NAT-T].
Because Mandatory Initiators are actually IKEv2 initiators, they
typically know by configuration which peers they should have a
connection with, even if the SA's are missing. If this is indeed the
case, the following Mandatory Initiator recovery procedure SHOULD be
followed.
The recovery procedure for Mandatory Initiators is the same as for
other peers with change in the last step containing the
CHECK_SPI(NACK) where the Mandatory Initiator actually sends
initiates an an IKEv2 Initial Exchange along with the CHECK_SPI(NACK)
payload.
Example CHILD_SA recovery exchange with mandatory initiator (Parent
SA present):
Peer X Peer Y
HDR(A,B) ...
<--------------------------------------------
HDR(A,B) INVALID_IKE_SPI(A,B)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(A,B)), N(Cookie)
<--------------------------------------------
HDR(A',0) SAi1, KEi, Ni, CHECK_SPI(NACK,(A,B)), N(Cookie)
-------------------------------------------->
...
When Peer Y receives the Initial Offer, it MUST verify it has the IKE
SPI in the CHECK_SPI reply. In other words, the recovery procedure
HINTS the Mandatory Initiator about a need for resynchronizing the
SA's. This hint MAY be ignored, according to the local peer policy.
If it does not have the corresponding IKE SA, Y MUST log a rate
limited message and drop the message. If Y owns the IKE SPI, it MUST
validates the cookie as described in Section 3.2.4 and proceed with
the IKE exchange, according to its security policy.
In any case, X SHOULD NOT retransmit the Initial Offer. The process
Detienne, et al. Expires January 15, 2009 [Page 16]
Internet-Draft Safe IKE Recovery July 2008
will restart by itself if the IKE SA is indeed missing and further
offending ESP or IKE packets are emitted. If X receives a valid
Message 2, it can proceed with the rest of the IKEv2 negotiation and
retransmit as necessary.
Example CHILD_SA recovery exchange with mandatory initiator (no
Parent SA):
Peer X Peer Y
(Mandatory Initiator)
ESP(SPI) ...
<--------------------------------------------
HDR(0,0) INVALID_SPI(SPI)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(SPI))
<--------------------------------------------
HDR(A,B) INVALID_IKE_SPI (A,B)
-------------------------------------------->
HDR(A,B) CHECK_SPI(QUERY,(A,B)), N(Cookie)
<--------------------------------------------
HDR(A',0) SAi1, KEi, Ni, CHECK_SPI(NACK,(A,B)), N(Cookie)
-------------------------------------------->
3.6. Recovery closure
In many cases, the outcome of the recovery procedure yields to the
creation of a new IKE_SA. Either side may be left with an old IKE_SA
and dangling CHILD_SA's. In order to recover entirely, the old
CHILD_SA's SHOULD be recreated (entirely renegotiated) under the
protection of the new Parent SA. After which, the old SA's (IKE_SA
and CHILD_SA's) SHOULD be entirely deleted.
3.7. Dealing with race conditions
When a peer deletes SA's, a DELETE payload is sent that MUST be
acknowldeged. Before the delete notify reaches the remote peer,
further ESP packets for the now deleted SPI may be received. These
ESP packets MUST be silently discarded as long the DELETE Notify can
be retransmitted.
Detienne, et al. Expires January 15, 2009 [Page 17]
Internet-Draft Safe IKE Recovery July 2008
4. Throttling and dampening
An important aspect of the security in IKE recovery has to do with
limitating the CPU utilization. In order to thwart flood types
denial of service attacks, strict rate limiting and throttling
mechanisms have to be enforced.
All the notifications that are exchanged during IKE recovery SHOULD
be rate limited. This paragraph provides information on the way rate
limiting should take place.
4.1. Invalid SPI throttling
The sending of all Invalid SPI notifies MUST be rate limited one way
or an other. The rate limiting SHOULD be performed on a per peer
basis but dynamic state creation SHOULD be avoided as much as
possible. A recommended tradeoff is to limit the number of flows
that can undergo recovery at one point in time and avoid sending
Invalid SPI notifies for flows that are potentially already under
recovery.
Invalid SPI rate limiting protects against natural dangling SA
occurences. I.e. normal traffic conditions may cause unrecognized
SPI's to be received and this message is the most important to
protect. Indeed, it is not realistic to send one notification per
bad ESP packet received. On high speed links, this could mean
thousands of IKE notifies sent for the same offending SPI.
The receiving of unauthenticated Invalid SPI notifies MUST as well be
rate limited. Again, the rate limiting SHOULD be performed on a per
peer basis without dynamic state creation. In normal circumstances,
the peer receiving Invalid SPI notifies has an SA with the peer
sendig those notifies and already maintains peer-related data
structures that can help in maintaining adequate counters.
Authenticated Invalid SPI notifies can be accepted without
throttling.
4.2. Dampening
After one of the following conditions:
o the natural creation or rekey of one or more SA's
o the recovery of one or more SA's
o the failure in recovering an SA owned by the local security
gateway
o the logging of an error or warning message involving an SA owned
by the local security gateway
Detienne, et al. Expires January 15, 2009 [Page 18]
Internet-Draft Safe IKE Recovery July 2008
The peer with which SA's were created, attempted or against which a
log was emitted SHOULD be dampened, which means that all the
unauthenticated Invalid SPI and Check SPI messages emitted by that
peer MUST be ignored for a chosen duration.
This protection prevents a man-in-the-middle from forcing the fast
recreation of SA's and potentially depleting the entropy of systems
under attack. It also deals efficently with race conditions that may
occur after a rekey.
4.3. User controls
Because throttling at large is related to speed, the network
implementation around the security gateways has a major influence on
the pertinence of the paremeters controlling rate limiting. It is
difficult to provide good absolute values for the rate limiters,
considering that these are implementation dependent.
As such, for the sake of fitness in practical deployments, a system
implementing this memo MUST provide administrative controls over the
rate limiter parameters.
5. Negotiating IKE recovery
IKE recovery capabilities MUST be advertised through a Vendor ID
payload.
In the first two messages of the Parent SA negotiation, the Vendor ID
payload for this specification MUST be sent if supported (and it MUST
be received by both sides). The content of the payload is the
ASCII string: SECURE IKE RECOVERY, or
in HEX: 53 45 43 55 52 45 20 49 4b 45 20 52 45 43 4F 56 45 52 59
The peers' capbility for IKE Session Resumption is known implicitly
from receiving the resumption ticket.
Determining peer capability can be useful for two reasons at
least.First, this information MAY let a system decide to fallback to
another recovery mechanism, such as from Ticket based Recovery to
Stateless Safe IKE Recovery or falling back to the one embedded in
IKEv2
Knowledge of the peer's capabilities can be used by the 'live
peer'(the one that still has the SA's) in order to determine whether
it is normal or not to receive unauthenticated INVALID_SPI with or
Detienne, et al. Expires January 15, 2009 [Page 19]
Internet-Draft Safe IKE Recovery July 2008
without cookies or CHECK_SPI notifies. A peer that has lost
information about it's peer SHOULD go under the assumption that peer
does understand IKE Recovery as described in this memo. This
assumption implies that INVALI_SPI notifies with cookies and
CHECK_SPI notifies can be sent. If the remote peer does not support
IKE Recovery, it will just ignore these messages.
In general, it is useful for system administrators to monitor the
capabilities of a remote system connecting to a local security
gateway and there is an interest in advertising the IKE Recovery
capability.
6. Payload formats
For reference, the Notify Payload is defined as follow
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is the same as defined in [IKEv2].
This memo introduces a new Notify Message Type that is being
developped with a Private Use Type:
o CHECK_SPI: 32770
An official IANA assigned number MUST be assigned if this document
reaches final recommendation state.
The notification data area is formatted as such:
Detienne, et al. Expires January 15, 2009 [Page 20]
Internet-Draft Safe IKE Recovery July 2008
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Operation ! Protocol ID | RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI !
~ ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Operation (1 Octet) - This field determines the operation being
performed (Query, Reply_ACK, Reply_NACK)
o Protocol ID - Specifies the IPsec protocol identifier for the
current negotiation. Values are defined in [IKEv2].
o SPI - The SPI under investigation. The actual length of this
block depends on the type of SPI.
The list of operations and their corresponding value:
o Query: 0
o Reply_ACK: 1
o NACK: 2
7. IANA Considerations
This document requires the following notification to be registered by
IANA. The corresponding registry was established by IANA.
o CHECK_SPI Notification type (Section 6).
8. Security Considerations
IKE recovery self-protection is discussed all along the document and
contains many mechanism to thwart denial of service attacks.
IKE recovery is subject to a man-in-the-middle attack that can let
the attacker trigger a renegotiation. It has to be noticed that an
attacker able to block ESP and/or IKE packets can cause IKE itself to
also tear down and trigger a rekey of IKE SA's. With throttling and
dampening enabled, IKE recovery is able to reduce the amount of
rekeys/negotiations to as low a rate as IKEv2.
Overall, IKE Recovery is not more vulnerable than IKEv2 and even
improves on the security of IKEv2 by resynchronizing SA's more
rapidly which is important with dynamic polices.
9. References
Detienne, et al. Expires January 15, 2009 [Page 21]
Internet-Draft Safe IKE Recovery July 2008
9.1. Normative References
[Bra97] Bradner, S., "RFC 2119, Key Words for use in RFCs to
indicate Requirement Levels", March 1997.
[IKEv2] Kaufman, Ed., "RFC 4306, Internet Key Exchange (IKEv2)
Protocol", December 2005.
[NAT-T] Kivinen, "RFC 3947, Negotiation of NAT-Traversal in the
IKE", January 2005.
9.2. Informative References
[IKERESUME]
Sheffer, Y., "Stateless Session Resumption for the IKE
Protocol", July 2007.
Authors' Addresses
Frederic Detienne
Cisco
De Kleetlaan, 7
Diegem B-1831
Belgium
Phone: +32 2 704 5681
Email: fd@cisco.com
Pratima Sethi
Cisco
O'Shaugnessy Road, 11
Bangalore, Karnataka 560027
India
Phone: +91 80 4154 1654
Email: psethi@cisco.com
Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim st.
Tel Aviv 67897
Israel
Email: yir@checkpoint.com
Detienne, et al. Expires January 15, 2009 [Page 22]
Internet-Draft Safe IKE Recovery July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Detienne, et al. Expires January 15, 2009 [Page 23]