Yoav Nir wrote:
On Jun 10, 2010, at 6:39 PM, Sean Turner wrote:
Yoav Nir wrote:
#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)?
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.
That works for me.
spt
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
