Hi Pekka,
I agree with both of your comments, we should look at them for -04.
Thanks,
Yaron
On 02/11/2011 07:32 AM, Pekka Riikonen wrote:
On Tue, 8 Feb 2011, Yaron Sheffer wrote:
: Date: Tue, 08 Feb 2011 22:15:15 +0200
: From: Yaron Sheffer<[email protected]>
: To: [email protected]
: Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt
:
: Hi,
:
: this version attempts to address all the open issues that were raised in
: the last few months. In particular, it clarifies the behavior of the IKE
: Message ID during failover while reducing some of the complexity.
: Another significant change is the semantics of the IPsec replay counter
: sync message.
:
: Pleas review the document. We would like to close the issues in the next
: week or so, and move to WGLC. The currently open issues are here:
:
http://tools.ietf.org/wg/ipsecme/trac/query?status=new&status=assigned&status=reopened&component=ipsecha-protocol
:
Looks good to me, I have no major gripes. Ignoring the corner cases
described in section 8.3 is one way to go and is fine with me. Perhaps
I'd make the language of using the INVALID_SPI "SHOULD" (or "MAY") from
"would" as in RFC 5996 use of INVALID_SPI is only MAY and other crash
recovery mechanisms doesn't exist. Developers may face the issues we
discussed on the mailing list and that discussion provides a nice
reference on how to solve those issues if they are important to the
developer.
I'd also perhaps look the way the word "reject" has been used, sometimes
used as is, sometimes written as "reject/drop", and sometimes replaced
with phrase "be silently dropped". Example in section 5.1:
o The peer MUST reject any received synchronization message if M1 is
lower than or equal to the highest value it has seen from the
cluster. This includes any previous received synchronization
messages.
Later in same section:
o The request contains a Nonce field. This field MUST be returned
in the response, unchanged. A response MUST be silently dropped
if the received Nonce does not match the one that was sent.
I'd assume the reject here would also result into silently dropping. RFC
5996 often uses word reject but almost always followed by what to do after
the rejection.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
