Hi Yaron, Thanks for comments. We will address them in next version.
On Thu, Oct 14, 2010 at 2:27 PM, Yaron Sheffer <yaronf.i...@gmail.com>wrote: > Hi, > > the new draft is a good realization of our discussions since the previous > version. Please see a few comments below. My main point is that if you > choose to implement *only* replay counter sync, you should not pay the price > of all the other stuff that we added because of the problems with Message ID > zero. I suggest that the protocol support the following three cases: > > - Both Msg ID and Replay Counter sync, where both must be sent in the same > IKE message (and so can have one protection mechanism). > - Only Msg ID sync. > - Only Replay Counter sync, where we use a regular Informational message. > > Detailed comments: > > 1. Abstract: failure prone -> failure-resistant (same in intro) > 2. "Standby member would initiate the SYNC Request with an > INFORMATIONAL exchange with message Id zero ." It's very important > to note that the zero message ID only applies to IKE counter sync > (or when doing both), not to implementations that only sync IPsec > counters. > 3. There's no need for a nonce in the IPsec Replay Counter > notification. Either it is sent within a regular IKE message, > which is already replay-protected, or (when the message ID is 0) > it is sent along with the other notification, whose nonce is > sufficient for this purpose. Similarly for the failover count. > 4. 6.4: the diagram should be reformatted so that it is clear which > bit ESN is (i.e. use the letter 'E' for ESN). > 5. 7: "IKEV2_MESSAGE_ID_SYNC exchange" - no, it's an Informational > exchange that contains this notification. > 6. Where is the failover count first initialized, and to what value? > The failover count is global parameter of HA and is generic across the cluster. I will add some text for it. > 7. Are there special processing rules for simultaneous failover? > Where are they described? > The current protocol which shift the to higher side on each end will take care of simultaneous failover too. We will add one example scenario for it in next version. > > Thanks, > Yaron > Best Regards, Raj > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
