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

[Yoav Nir <[e-mail]>]

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.