--- 1/draft-ietf-ipsecme-failure-detection-06.txt 2011-03-28 10:16:59.000000000 +0200 +++ 2/draft-ietf-ipsecme-failure-detection-07.txt 2011-03-28 10:16:59.000000000 +0200 @@ -1,28 +1,28 @@ IPsecME Working Group Y. Nir, Ed. Internet-Draft Check Point Intended status: Standards Track D. Wierbowski -Expires: September 11, 2011 IBM +Expires: September 29, 2011 IBM F. Detienne P. Sethi Cisco - March 10, 2011 + March 28, 2011 A Quick Crash Detection Method for IKE - draft-ietf-ipsecme-failure-detection-06 + draft-ietf-ipsecme-failure-detection-07 Abstract This document describes an extension to the IKEv2 protocol that - allows for faster detection of SA desynchronization using a saved - token. + allows for faster detection of Security Association (SA) + desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 11, 2011. + This Internet-Draft will expire on September 29, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,52 +64,52 @@ 4. Formats and Exchanges . . . . . . . . . . . . . . . . . . . . 7 4.1. Notification Format . . . . . . . . . . . . . . . . . . . 7 4.2. Passing a Token in the AUTH Exchange . . . . . . . . . . 8 4.3. Replacing Tokens After Rekey or Resumption . . . . . . . 9 4.4. Replacing the Token for an Existing SA . . . . . . . . . 10 4.5. Presenting the Token in an Unprotected Message . . . . . 10 5. Token Generation and Verification . . . . . . . . . . . . . . 11 5.1. A Stateless Method of Token Generation . . . . . . . . . 11 5.2. A Stateless Method with IP addresses . . . . . . . . . . 12 5.3. Token Lifetime . . . . . . . . . . . . . . . . . . . . . 12 - 6. Backup Gateways . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Backup Gateways . . . . . . . . . . . . . . . . . . . . . . . 13 7. Interaction with Session Resumption . . . . . . . . . . . . . 13 - 8. Operational Considerations . . . . . . . . . . . . . . . . . . 14 - 8.1. Who should implement this specification . . . . . . . . . 14 - 8.2. Response to unknown child SPI . . . . . . . . . . . . . . 15 + 8. Operational Considerations . . . . . . . . . . . . . . . . . . 15 + 8.1. Who should implement this specification . . . . . . . . . 15 + 8.2. Response to unknown child SPI . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9.1. QCD Token Generation and Handling . . . . . . . . . . . . 16 9.2. QCD Token Transmission . . . . . . . . . . . . . . . . . 17 - 9.3. QCD Token Enumeration . . . . . . . . . . . . . . . . . . 17 + 9.3. QCD Token Enumeration . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 - 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 12.1. Changes from draft-ietf-ipsecme-failure-detection-05 . . 18 + 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 12.1. Changes from draft-ietf-ipsecme-failure-detection-05 . . 19 12.2. Changes from draft-ietf-ipsecme-failure-detection-04 . . 19 12.3. Changes from draft-ietf-ipsecme-failure-detection-03 . . 19 12.4. Changes from draft-ietf-ipsecme-failure-detection-02 . . 19 12.5. Changes from draft-ietf-ipsecme-failure-detection-01 . . 19 12.6. Changes from draft-ietf-ipsecme-failure-detection-00 . . 19 - 12.7. Changes from draft-nir-ike-qcd-07 . . . . . . . . . . . . 19 + 12.7. Changes from draft-nir-ike-qcd-07 . . . . . . . . . . . . 20 12.8. Changes from draft-nir-ike-qcd-03 and -04 . . . . . . . . 20 12.9. Changes from draft-nir-ike-qcd-02 . . . . . . . . . . . . 20 12.10. Changes from draft-nir-ike-qcd-01 . . . . . . . . . . . . 20 12.11. Changes from draft-nir-ike-qcd-00 . . . . . . . . . . . . 20 - 12.12. Changes from draft-nir-qcr-00 . . . . . . . . . . . . . . 20 + 12.12. Changes from draft-nir-qcr-00 . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. The Path Not Taken . . . . . . . . . . . . . . . . . 21 A.1. Initiating a new IKE SA . . . . . . . . . . . . . . . . . 21 A.2. SIR . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Birth Certificates . . . . . . . . . . . . . . . . . . . 22 - A.4. Reducing Liveness Check Length . . . . . . . . . . . . . 22 + A.4. Reducing Liveness Check Length . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction IKEv2, as described in [RFC5996] and its predecessor RFC 4306, has a method for recovering from a reboot of one peer. As long as traffic flows in both directions, the rebooted peer should re-establish the tunnels immediately. However, in many cases the rebooted peer is a VPN gateway that protects only servers, so all traffic is inbound. In other cases, the non-rebooted peer has a dynamic IP address, so @@ -505,20 +505,33 @@ See Section 9.2 for a discussion of a use-case for this method. When using this method, the TOKEN_SECRET_DATA field is calculated as follows: TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T) The IPaddr-T field specifies the IP address of the token taker. Secret rollover considerations are similar to those in the previous section. + Note that with a multi-homed token taker, the QCD token matches just + one of the token taker IP addresses. Usually this is not a problem, + as packets sent to the token maker come out the same IP address. If + for some reason this changes, then the token maker can replace the + token as described in section 4.4. + + There is a corner case where the token taker begins using a different + IP address (because of multi-homing, roaming or normal network + operations) and the token maker loses state before replacing the + token. In that case, it will send a correct QCD token, but the token + taker will still have the old token. In that case the extension will + not work, and the peers will revert to RFC 5996 recovery. + 5.3. Token Lifetime The token is associated with a single IKE SA, and SHOULD be deleted by the token taker when the SA is deleted or expires. More formally, the token is associated with the pair (SPI-I, SPI-R). 6. Backup Gateways Making crash detection and recovery quick is a worthy goal, but since rebooting a gateway takes a non-zero amount of time, many @@ -642,20 +655,27 @@ several roles. In order to limit the effects of DoS attacks, a token taker SHOULD limit the rate of QCD_TOKENs verified from a particular source. If excessive amounts of IKE requests protected with unknown IKE SPIs arrive at a token maker, the IKE module SHOULD revert to the behavior described in section 2.21 of [RFC5996] and either send an INVALID_IKE_SPI notification, or ignore it entirely. + Section 9.2 requires that token makers never send a QCD token in the + clear for a valid IKE SA, and describes some configurations where + this could occur. Implementations that may be installed in such + configurations SHOULD automatically detect this and disable this + extension in unsafe configurations, and MUST allow the user to + control whether the extension is enabled or disabled. + 8.2. Response to unknown child SPI After a reboot, it is more likely that an implementation receives IPsec packets than IKE packets. In that case, the rebooted implementation will send an INVALID_SPI notification, triggering a liveness check. The token will only be sent in a response to the liveness check, thus requiring an extra round-trip. To avoid this, an implementation that has access to enough non- volatile storage MAY store a mapping of child SPIs to owning IKE @@ -685,21 +705,21 @@ introducing significant delays. This requirement is especially significant, because this document introduces a new way to reset an IKE SA. The mechanism need not be similarly secure against an active MITM, since this type of attacker is already able to disrupt IKE sessions. 9.1. QCD Token Generation and Handling Tokens MUST be hard to guess. This is critical, because if an - attacker can guess the token associated with an IKE SA, she can tear + attacker can guess the token associated with an IKE SA, they can tear down the IKE SA and associated tunnels at will. When the token is delivered in the IKE_AUTH exchange, it is encrypted. When it is sent again in an unprotected notification, it is not, but that is the last time this token is ever used. An aggregation of some tokens generated by one maker together with the related IKE SPIs MUST NOT give an attacker the ability to guess other tokens. Specifically, if one taker does not properly secure the QCD tokens and an attacker gains access to them, this attacker MUST NOT be able to guess other tokens generated by the same maker. @@ -735,21 +755,21 @@ whether the attempt to trick the gateway uses the token taker's IP address or a different IP address. IPsec Failure Detection is not applicable to deployments where the QCD secret is shared by multiple gateways and the gateways cannot assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's. Load balancer configurations typically fall in this category. In order for a load balancing configuration of IPsec gateways to support this specification, all members MUST be able to tell whether a particular - IKE SA is active anywhere in the cluster. One way to do it is to + IKE SA is active anywhere in the cluster. One way to do this is to synchronize a list of active IKE SPIs among all the cluster members. Because it includes the token taker's IP address in the token generation, the method in Section 5.2 can (under certain conditions) prevent revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address, even in a load- sharing cluster without state synchronization. That method does not prevent revealing the QCD token to an active attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for