Yoav Nir wrote:
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.
This is fine.
#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")
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)?
Yoav
On Jun 8, 2010, at 2:23 PM, Sean Turner wrote:
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
