Network Working Group F. Detienne Internet-Draft P. Sethi Expires: December 22, 2008 Cisco June 20, 2008 Safe IKE Recovery draft-detienne-ikev2-recovery-00 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 December 22, 2008. 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 & Sethi Expires December 22, 2008 [Page 1] Internet-Draft Safe IKE Recovery June 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. Introducing CHECK_SPI . . . . . . . . . . . . . . . . . . 5 3.2. Recovery triggered by invalid IKE packets . . . . . . . . 5 3.3. Recovery triggered by invalid ESP packets . . . . . . . . 7 3.3.1. In the presence of an IKE_SA . . . . . . . . . . . . . 8 3.3.2. In the absence of an IKE_SA . . . . . . . . . . . . . 8 3.4. Mandatory Initiators . . . . . . . . . . . . . . . . . . . 10 3.5. Recovery closure . . . . . . . . . . . . . . . . . . . . . 12 3.6. Dealing with race conditions . . . . . . . . . . . . . . . 12 4. Cookie generation and validation . . . . . . . . . . . . . . . 12 5. Throttling and dampening . . . . . . . . . . . . . . . . . . . 13 5.1. Invalid SPI throttling . . . . . . . . . . . . . . . . . . 13 5.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. User controls . . . . . . . . . . . . . . . . . . . . . . 14 6. Negotiating IKE recovery . . . . . . . . . . . . . . . . . . . 15 7. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Detienne & Sethi Expires December 22, 2008 [Page 2] Internet-Draft Safe IKE Recovery June 2008 1. Introduction IKEv2 ([IKEv2]) relies on sending a possibly empty informational exchange to provide proof of liveness. When a peer doubts the liveness of its remote peer (e.g. it is not receiving any data or control traffic from the peer), it can send empty informational exchanges expecting a reply confirming liveness. This works as informational exchanges are supposed to be acknowledged in IKEv2. If an 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. 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 & Sethi Expires December 22, 2008 [Page 3] Internet-Draft Safe IKE Recovery June 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 [IKERESUME] 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 may not be obvious for those peers to determine which security Detienne & Sethi Expires December 22, 2008 [Page 4] Internet-Draft Safe IKE Recovery June 2008 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 remains stateless until sufficient proof of liveness is discovered. 3. IKE recovery 3.1. Introducing CHECK_SPI In order to achieve 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: 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 7. 3.2. Recovery triggered 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 Detienne & Sethi Expires December 22, 2008 [Page 5] Internet-Draft Safe IKE Recovery June 2008 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 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 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) --------------------------------------------> Detienne & Sethi Expires December 22, 2008 [Page 6] Internet-Draft Safe IKE Recovery June 2008 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: 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.3. Recovery triggered by invalid ESP packets 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. The recovery procedure will be roughly the same as for the Dangling Detienne & Sethi Expires December 22, 2008 [Page 7] Internet-Draft Safe IKE Recovery June 2008 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.3.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. 3.3.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 Detienne & Sethi Expires December 22, 2008 [Page 8] Internet-Draft Safe IKE Recovery June 2008 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. 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. Detienne & Sethi Expires December 22, 2008 [Page 9] Internet-Draft Safe IKE Recovery June 2008 The overall recovery scheme for CHILD_SA's 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.4. 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 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]. Detienne & Sethi Expires December 22, 2008 [Page 10] Internet-Draft Safe IKE Recovery June 2008 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 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 4 and proceed with the IKE exchange, according to its security policy. In any case, X SHOULD NOT retransmit the Initial Offer. The process 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): Detienne & Sethi Expires December 22, 2008 [Page 11] Internet-Draft Safe IKE Recovery June 2008 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.5. 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.6. 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. 4. Cookie generation and validation 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 X sends an unauthenticated CHECK_SPI, the cookie payload following the notify is computed as follow: Detienne & Sethi Expires December 22, 2008 [Page 12] Internet-Draft Safe IKE Recovery June 2008 Cookie = | H( | CHECK_SPI(..., Query) | ip.src | ip.dst | udp.src | udp.dst) where o is a randomly generated secret known only to the responder and periodically changed o should be changed whenever 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 7) 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 notify (ACK or NACK) 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 , messages SHOULD have a limited life time. 5. 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. 5.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. Detienne & Sethi Expires December 22, 2008 [Page 13] Internet-Draft Safe IKE Recovery June 2008 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. 5.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 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. 5.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. Detienne & Sethi Expires December 22, 2008 [Page 14] Internet-Draft Safe IKE Recovery June 2008 6. Negotiating IKE recovery IKE recovery capabilities SHOULD 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 The exact content in hex for the payload is 53454355524520494b45205245434f56455259 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 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 or CHECK_SPI notifies. A peer that lost the information about a remote gateway (i.e. that does not know whether the remote gateway supports Secure IKE Recovery) SHOULD go under the assumption that peer does understand IKE Recovery as described in this memo. This assumption implies that 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. 7. Payload formats For reference, the Notify Payload is defined as follow Detienne & Sethi Expires December 22, 2008 [Page 15] Internet-Draft Safe IKE Recovery June 2008 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: 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 Detienne & Sethi Expires December 22, 2008 [Page 16] Internet-Draft Safe IKE Recovery June 2008 o NACK: 2 8. 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 7). 9. 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. 10. References 10.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. 10.2. Informative References [IKERESUME] Sheffer, Y., "Stateless Session Resumption for the IKE Protocol", July 2007. Detienne & Sethi Expires December 22, 2008 [Page 17] Internet-Draft Safe IKE Recovery June 2008 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 Detienne & Sethi Expires December 22, 2008 [Page 18] Internet-Draft Safe IKE Recovery June 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 & Sethi Expires December 22, 2008 [Page 19]