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/ |