Subject: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha

From: Sean Turner <[email-masked]>
Date: Tue, 08 Jun 2010 07:23:30 -0400

Yaron asked me to review draft-ietf-ipsecme-ipsec-ha on 2010-06-01. 
Here are my comments most of which are about clarifying text (so that 
readers who didn't participate in the WG discussions can understand 
this unambiguously), plus a couple of nits.

Yoav, could you post a new version that addresses my comments before 
we start IETF Last Call?

#1) Should this I-D have been called "IPsec Cluter Problem Statement" 
to more closely align with the charter?  The header also?

#2) The abstract needs to be clearer and more closely follow what's in 
the charter (I think the document does, but the abstract doesn't state 
it clearly). It states:

  This document describes a requirement from IKE and IPsec to allow for
  more scalable and available deployments for VPNs.    It defines
  terminology for high availability and load sharing clusters
  implementing IKE and IPsec, and describes gaps in the existing
  standards.

Is this a requirement "from" or "for" IKE/IPsec?  I think it's 
supposed to be for.

It's missing the "problem statement" text from the charter.  How about 
the following suggested text:

This document defines a set of terminology, a problem statement, and 
set of requirements for clusters implementing IKE and IPsec.  It also 
describes gaps in the existing standards 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.

#3) I'd like to see "cluster" introduced in the 2nd paragraph of 
Section 1.  It kind of jumps out in the 3rd para.

   by using more than one physical gateway to either share the load
   or back each other up (i.e., using a cluster).
                         ^^^^^^^^^^^^^^^^^^^^^^^

#4) Section 1: r/organizations's/organization's

#5) Section 2: In section 1, it specifically mentions that the 
gateways are physically separate.  Should this also be worked in to 
the definition of cluster in section 2:

  "Cluster" is a set of two or more physically separated gateways,
                                    ^^^^^^^^^^^^^^^^^^^^
  implementing the same
  security policy, and protecting the same domain.  Clusters exist to
  provide both high availability through redundancy, and scalability
  through load sharing.

#6) Section 2: Should this I-D explain or point (informatively) to how 
Availability is computed?

#7) Section 2: HS Cluster (there might only be one other): r/whereas 
the others are/whereas the other(s) are

#8) Section 2: LS Cluster: Can we replace: "and we don't want to even 
imply that this is a requirement" with "and this is not a requirement"?

#9) Section 2: Failover (add ,): r/In a load sharing cluster/In a load 
sharing cluster,

#10) Section 2: Loose Cluster: Is it that one address gets allocated 
to more than one member at failover, just one other, or can both 
happen?  r/In some cases, members IP addresses may be allocated to 
other members at failover./In some cases, member's IP address(es) may 
be allocated to another member or members at failover.

#11) Section 3.2: Spell out first instance of SAD (it's not in the RFC 
editor's expansion
list:http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt).

#12) Section 3.2 (last paragraph): The definition of High Availability 
states that it's not a configuration type, but in the following it 
sure does sound like it: "A naive implementation of a high 
availability cluster would have no synchronized state, and a failover 
would produce an effect similar to that of a rebooted gateway". 
Because all of the clusters in this document offer high availability 
can you just strike "high availability" from the sentence?

#13) Section 3.3: This section needs to be rephrased as a problem 
statement not a solution.  If the solution presented is a MUST 
requirement, then I'd like to see that stated clearly with a "MUST".

#14) Assuming the sections 3.4 and 3.5 are about IPsec SA: r/SA/IPsec SA

#15) Section 3.4-9: I'd like to see clear requirements language about 
what the mechanism(s) MUST/SHOULD/MAY support.

#16) Section 3.4: Shouldn't the 'must not' be "MUST NOT"?

#17) Section 3.5 (knowing people will want to verify this statement): 
Please provide a pointer to where this is: This is allowed by the 
standards, because replay counter verification is an optional feature. 
i.e., see section x of [RFCXYZ].

#18) Section 3.6: All the clusters are highly available: r/a high 
availability cluster/a cluster

#19) Section 3.7, spell out first instance of HA and add it to the 
definition in Section 2.

#20) Section 3.7: what's a "commodity load balancer"?

#21) Section 3.7 to make the two category sentence work, r/The other 
way, is to duplicate the child SAs, and have a pair of IPsec SAs for 
each active member./The second is the "duplicate" category, where the 
child SA is duplicated for each pair of IPsec SAs for each active member.

#22) Shouldn't the 'must never' be 'MUST NOT'?

spt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Jun 2010 15:35:38 +0300

Hi Sean.

I have just submitted version -05 which addresses most (but not all) of your comments. Here's a list of the exceptions (hope I didn't miss any)

#2. I've worded the abstract a little differently. Main difference is adding to "gaps in existing standards" the words "and their implementation". Some things (like tolerating skips in replay counters and multiple parallel SAs) are allowed by the RFC even now, but some vendors may perceive them as "weird" and drop the tunnels. Yes, we've had this happen with real vendors.

   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.

#13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with this. The first, is that this document is a problem statement, and intended to be INFORMATIONAL. No gateway is ever going to be said to "implement" this document. As such, I don't think it should mandate any behaviors. Some behaviors are suggested as solutions, for example "replay counter must not repeat" ==> "gateway can synchronize occasionally, and skip 10,000 numbers at failover". The charter does not allow us at this point to mandate that newly-active gateways skip 10,000 numbers. We only say this, because it is one way to solve the problem, which some vendors have already done, and other gateways should be ready for this to happen. When it comes to creating a standards-track document, we might suggest this to cluster implementers, and more important, we may mandate that all conforming IPsec implementers (whether their gateways cluster or not) MUST accept such replay counter jumps.
So I left most of sections 3.4-9 without RFC 2119 language. As an exception to this rule, where the behavior is already mandated by older RFCs (4301 and/or 4306), I did capitalize the requirement language (so "replay counter must never repeat" --> "replay counter MUST NOT repeat")

Yoav

On Jun 8, 2010, at 2:23 PM, Sean Turner wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Jun 2010 11:39:43 -0400

>    IPsec/IKEv2 mechanisms to simplify cluster implementations.

This is fine.

> So I left most of sections 3.4-9 without RFC 2119 language. As an exception to this rule, where the behavior is already mandated by older RFCs (4301 and/or 4306), I did capitalize the requirement l…

On #15, I can see that the text is proposing possible solutions.  For 
#13, it reads like counters are the only solution.  Can you tweak the 
text in such a way that it says "one possible solution, is ..." and 
that way it doesn't sound like counters is the only mechanism (even if 
it is)?

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Jun 2010 19:11:40 +0300

> that way it doesn't sound like counters is the only mechanism (even if 

How about this:
   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.  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.

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Jun 2010 12:17:49 -0400

>    recovers from the missing synch message problem, which is described

That works for me.

spt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Jun 2010 19:28:23 +0300

Done in -06