Hi Yaron
I think this addresses the issues well. However, there is one more thing.
Section 3 is currently in skeleton form and needs to be expanded a lot.
For example, RFC 6027 says the following:
o It requires multiple parallel SAs, for which the peer has no use.
Section 2.8 of [RFC5996] specifically allows this, but some
implementation might have a policy against long-term maintenance
of redundant SAs.
And draft-ietf-ipsecme-ipsecha-protocol says:
o 3.7 is an implementation problem that needs to be solved while
building IPsec clusters. However, the peers should be required to
accept multiple parallel SAs for 3.7.1.
It's true that RFC 5996 seems to require this support already, but what it
actually says is this:
Note that IKEv2 deliberately allows parallel SAs with the same
Traffic Selectors between common endpoints. One of the purposes of
this is to support traffic quality of service (QoS) differences among
the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
[DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
and the Traffic Selectors may not uniquely identify an SA between
those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
the basis of duplicate Traffic Selectors SHOULD NOT be used.
So RFC 5996 justifies parallel SAs by QoS, not by clusters. I think Section 3
should be much clearer and contain MUST requirements for a peer to support a
reasonable amount of parallel SAs.
This is but one example. Section 3 contains a brief sentence about each problem
defined in RFC 6027 without a single RFC 2119 term in there. I think those
sentences need to be expanded to paragraphs or sub-section with requirement
levels.
And yes, I will propose text. Soon. Promise.
Yoav
On Feb 8, 2011, at 10:15 PM, Yaron Sheffer wrote:
> 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
>
> Thanks,
> Yaron
>
> On 02/08/2011 09:45 PM, internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IP Security Maintenance and Extensions
>> Working Group of the IETF.
>>
>>
>> Title : Protocol Support for High Availability of IKEv2/IPsec
>> Author(s) : R. Jenwar, et al.
>> Filename : draft-ietf-ipsecme-ipsecha-protocol-03.txt
>> Pages : 22
>> Date : 2011-02-08
>>
>> The IPsec protocol suite is widely used for business-critical network
>> traffic. In order to make IPsec deployments highly available, more
>> scalable and failure-resistant, they are often implemented as IPsec
>> High Availability (HA) clusters. However there are many issues in
>> IPsec HA clustering, and in particular in IKEv2 clustering. An
>> earlier document, "IPsec Cluster Problem Statement", enumerates the
>> issues encountered in the IKEv2/IPsec HA cluster environment. This
>> document attempts to resolve these issues with the least possible
>> change to the protocol.
>>
>> This document proposes an extension to the IKEv2 protocol to solve
>> the main issues of "IPsec Cluster Problem Statement" in the commonly
>> deployed hot-standby cluster, and provides implementation advice for
>> other issues. The main issues to be solved are the synchronization
>> of IKEv2 Message ID counters, and of IPsec Replay Counters.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-03.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>>
>> _______________________________________________
>> 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
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
