Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-03.txt

From: [email-masked]
Date: Tue, 08 Feb 2011 11:45:02 -0800

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.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 08 Feb 2011 22:15:15 +0200

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, [email-masked] wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Feb 2011 10:22:44 +0200

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:

> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Feb 2011 19:56:51 -0800

On 2/8/11 12:15 PM, Yaron Sheffer wrote:
> Please review the document. We would like to close the issues in the next

+1 to "Please review the document". It would be a bummer to go into WG 
LC and then have people find things that take major revision.

--Paul Hoffman

---

From: Pekka Riikonen <[email-masked]>
Date: Fri, 11 Feb 2011 06:32:46 +0100 (CET)

On Tue, 8 Feb 2011, Yaron Sheffer wrote:

: Date: Tue, 08 Feb 2011 22:15:15 +0200
: From: Yaron Sheffer <[email-masked]>
: To: [email-masked]
: 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

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 11 Feb 2011 08:48:36 +0200

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:
> : From: Yaron Sheffer<[email-masked]>
> : To: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Feb 2011 07:18:10 -0800

> LC and then have people find things that take major revision.

It's been a week and little review has happened. It feels like we need 
to go to WG Last Call to get the review, and we should do that soon 
unless people step up soon.

--Paul Hoffman