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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/