draft-ietf-ipsecme-ipsec-ha-05.txt   draft-ietf-ipsecme-ipsec-ha-06.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Informational June 10, 2010 Intended status: Informational June 10, 2010
Expires: December 12, 2010 Expires: December 12, 2010
IPsec Cluster Problem Statement IPsec Cluster Problem Statement
draft-ietf-ipsecme-ipsec-ha-05 draft-ietf-ipsecme-ipsec-ha-06
Abstract Abstract
This document defines terminology, problem statement and requirements This document defines terminology, problem statement and requirements
for implementing IKE and IPsec on clusters. It also describes gaps for implementing IKE and IPsec on clusters. It also describes gaps
in existing standards and their implementation that need to be in existing standards and their implementation that need to be
filled, in order to allow peers to interoperate with clusters from filled, in order to allow peers to interoperate with clusters from
different vendors. An agreed terminology, problem statement and different vendors. An agreed terminology, problem statement and
requirements will allow the IPSECME WG to consider development of requirements will allow the IPSECME WG to consider development of
IPsec/IKEv2 mechanisms to simplify cluster implementations. IPsec/IKEv2 mechanisms to simplify cluster implementations.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 5 3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 5
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Lots of Long Lived State . . . . . . . . . . . . . . . . . 6 3.2. Lots of Long Lived State . . . . . . . . . . . . . . . . . 6
3.3. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 6 3.4. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 6
3.5. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.5. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7
3.6. Missing Synch Messages . . . . . . . . . . . . . . . . . . 7 3.6. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8
3.7. Simultaneous use of IKE and IPsec SAs by Different 3.7. Simultaneous use of IKE and IPsec SAs by Different
Members . . . . . . . . . . . . . . . . . . . . . . . . . 8 Members . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7.1. Outbound SAs using counter modes . . . . . . . . . . . 9 3.7.1. Outbound SAs using counter modes . . . . . . . . . . . 9
3.8. Different IP addresses for IKE and IPsec . . . . . . . . . 9 3.8. Different IP addresses for IKE and IPsec . . . . . . . . . 9
3.9. Allocation of SPIs . . . . . . . . . . . . . . . . . . . . 10 3.9. Allocation of SPIs . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . . 11 8. Informative References . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 6, line 31 skipping to change at page 6, line 31
gateway. [resumption] describes how new IKE and IPsec SAs can be gateway. [resumption] describes how new IKE and IPsec SAs can be
recreated in such a case. recreated in such a case.
3.3. IKE Counters 3.3. IKE Counters
We can overcome the first problem described in Section 3.2, by We can overcome the first problem described in Section 3.2, by
synchronizing states - whenever an SA is created, we can synch this synchronizing states - whenever an SA is created, we can synch this
new state to all other members. However, those states are not only new state to all other members. However, those states are not only
long-lived, they are also ever changing. long-lived, they are also ever changing.
IKE has message counters. A peer may not process message n until IKE has message counters. A peer MUST NOT process message n until
after it has processed message n-1. Skipping message IDs is not after it has processed message n-1. Skipping message IDs is not
allowed. So a newly-active member needs to know the last message IDs allowed. So a newly-active member needs to know the last message IDs
both received and transmitted. both received and transmitted.
In some cases, it is feasible to synchronize information about the One possible solution, is to synchronize information about the IKE
IKE message counters after every IKE exchange. This way, the newly message counters after every IKE exchange. This way, the newly
active member knows what messages it is allowed to process, and what active member knows what messages it is allowed to process, and what
message IDs to use on IKE requests, so that peers process them. We message IDs to use on IKE requests, so that peers process them. This
leave it for future discussion to determine if it is always feasible solution may be appropriate in some cases, but may be too onerous in
to do so. systems with lots of SAs. It also has the drawback, that it never
recovers from the missing synch message problem, which is described
in Section 3.6.
3.4. Outbound SA Counters 3.4. Outbound SA Counters
ESP and AH have an optional anti-replay feature, where every ESP and AH have an optional anti-replay feature, where every
protected packet carries a counter number. Repeating counter numbers protected packet carries a counter number. Repeating counter numbers
is considered an attack, so the newly-active member MUST NOT use a is considered an attack, so the newly-active member MUST NOT use a
replay counter number that has already been used. The peer will drop replay counter number that has already been used. The peer will drop
those packets as duplicates and/or warn of an attack. those packets as duplicates and/or warn of an attack.
Though it may be feasible to synchronize the IKE message counters, it Though it may be feasible to synchronize the IKE message counters, it
 End of changes. 5 change blocks. 
8 lines changed or deleted 10 lines changed or added

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