--- 1/draft-ietf-ipsecme-ipsec-ha-05.txt	2010-06-10 19:13:22.000000000 +0200
+++ 2/draft-ietf-ipsecme-ipsec-ha-06.txt	2010-06-10 19:13:22.000000000 +0200
@@ -1,18 +1,18 @@
 
 Network Working Group                                             Y. Nir
 Internet-Draft                                               Check Point
 Intended status: Informational                             June 10, 2010
 Expires: December 12, 2010
 
                     IPsec Cluster Problem Statement
-                     draft-ietf-ipsecme-ipsec-ha-05
+                     draft-ietf-ipsecme-ipsec-ha-06
 
 Abstract
 
    This document defines terminology, problem statement and requirements
    for implementing IKE and IPsec on clusters.  It also describes gaps
    in existing standards and their implementation that need to be
    filled, in order to allow peers to interoperate with clusters from
    different vendors.  An agreed terminology, problem statement and
    requirements will allow the IPSECME WG to consider development of
    IPsec/IKEv2 mechanisms to simplify cluster implementations.
@@ -53,21 +53,21 @@
 
    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
    3.  The Problem Statement  . . . . . . . . . . . . . . . . . . . .  5
      3.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      3.2.  Lots of Long Lived State . . . . . . . . . . . . . . . . .  6
      3.3.  IKE Counters . . . . . . . . . . . . . . . . . . . . . . .  6
      3.4.  Outbound SA Counters . . . . . . . . . . . . . . . . . . .  6
      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
            Members  . . . . . . . . . . . . . . . . . . . . . . . . .  8
        3.7.1.  Outbound SAs using counter modes . . . . . . . . . . .  9
      3.8.  Different IP addresses for IKE and IPsec . . . . . . . . .  9
      3.9.  Allocation of SPIs . . . . . . . . . . . . . . . . . . . . 10
    4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
    7.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
    8.  Informative References . . . . . . . . . . . . . . . . . . . . 11
@@ -233,31 +233,33 @@
    gateway. [resumption] describes how new IKE and IPsec SAs can be
    recreated in such a case.
 
 3.3.  IKE Counters
 
    We can overcome the first problem described in Section 3.2, by
    synchronizing states - whenever an SA is created, we can synch this
    new state to all other members.  However, those states are not only
    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
    allowed.  So a newly-active member needs to know the last message IDs
    both received and transmitted.
 
-   In some cases, it is feasible to synchronize information about the
-   IKE message counters after every IKE exchange.  This way, the newly
+   One possible solution, is to synchronize information about the IKE
+   message counters after every IKE exchange.  This way, the newly
    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
-   leave it for future discussion to determine if it is always feasible
-   to do so.
+   message IDs to use on IKE requests, so that peers process them.  This
+   solution may be appropriate in some cases, but may be too onerous in
+   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
 
    ESP and AH have an optional anti-replay feature, where every
    protected packet carries a counter number.  Repeating counter numbers
    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
    those packets as duplicates and/or warn of an attack.
 
    Though it may be feasible to synchronize the IKE message counters, it