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?
7. Are there special processing rules for simultaneous failover?
Where are they described?
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
