Done in -06 On Jun 10, 2010, at 7:17 PM, Sean Turner wrote:
> 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 > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
