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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
