Protocol Support for High Availability of IKEv2/IPsec
RFC 6311

Received changes through RFC Editor sync (changed abstract to '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 Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.

This document defines 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 solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]')

[Ballot comment]
I also have a few minor suggestions you might consider to help polish the document

---

I missed a reference to RFC 6027 in Section 1.

---

Please consider whether a reference figure showing a "cluster" would
help the reader.   

---

Section 1

  This document proposes an extension to the IKEv2 protocol to solve
  the main issues of IKE Message ID synchronization and IPsec SA replay
  counter synchronization and gives implementation advice for others.
  Following is a summary of the solutions provided in this document:

This is a Standards Track document, so you "define" not "propose".

Ditto Section 5

Additionally could you clarify "for others"? I think this is "to
address other issues."

---

It would be helpful if this document made a distinction between 2119
langauge for behavior that is defined in this document and behavior
defined in another document (such as the based spec.) Perhaps use
lower case for behavior defined elsewhere, and include an explicit
reference to where the behavior is defined.

---                                 

I think:

10.  Interaction with other drafts

...should s/drafts/specifications/

[Ballot discuss]
I have two concerns with this document that I would be happy to discuss.

---

I had some difficulty understanding that Section 7 says:

  The standby member can initiate the synchronization of IKEv2 Message
  ID's under different circumstances.
  o  When it receives a problematic IKEv2/IPsec packet, i.e. a packet
      outside its expected receive window.

This seems to conflict with the DoS avoidance described in Section 11.
It seemed to me that this trigger is not needed since the standby
member since whenever a failure (or forced) take-over has happened the
new active member will know that it has taken over as in the third
bullet in the list.

Your trade-off here seems to be that you would like to not have to
resynch when the new active member is already in synch, and the only
way you can find out that you are out of synch is by waiting for a
message.

Similarly the second trigger:

  o  When it has to send the first IKEv2/IPsec packet after a failover
      event.

...can only serve to spread the load of resynch, and is really just a
sub-case of the third trigger in the list.

Yet the third trigger:

  o  When it has just received control from the active member and
      wishes to update the values proactively, so that it need not start
      this exchange later, when sending or receiving the request.

...is rather vague with "just received control" and, in the case of
a very large number of peers, such behavior might very well cripple the
new active member.

So I think you should look again at the tirggers:
- in the light of DoS protection (perhaps the first case can only be
  applied once per peer per take-over)
- in order to take load distribution more explicitly into account.

---

Section 8.2 says:

  For IPsec, there is often a trade-off between security and
  reliability of the protected protocols.  Here again there is some
  leeway for local policy.  Some implementations might accept incoming
  traffic that is outside the replay window for some time after the
  failover event.  Strict implementations will only accept traffic
  that's inside the "safe" window.

Shouldn't you at least be recommending against this behavior? Isn't
this like saying tat an IPsec implementation can sometimes ignore
the fact that it is a security implementation? You should at least
draw out this case in Section 11 if itis really something that is
considered as an option.

[Ballot comment]
Please insert in section 6, just before 6.1.

  All multi-octet fields representing integers are laid out in big
  endian order (also known as "most significant byte first", or
  "network byte order").

(This should have appeared at the top of section 3 of RFC 5996, but unfortunately it only appears in section 3.1. Just trying to avoid confusion.)

[Ballot comment]
Please add a little more detail to the examples on page 22 (explain what the tuples represent), and verify that the examples are correct.

[Ballot comment]
- I guess there's a 4th case for the list on the end of p10 - that
the newly active member does neither if the peer didn't support this
spec. Maybe worth a mention.

- 5.2 says a "rekey SHOULD follow shortly..." is that really 2119
language or just what's going to happen when you add a large
increment? If the latter, then maybe s/SHOULD/is likely to/

- 6.4: The sentence "Note that this solution requires that
all these Child SAs either use or do not use Extended Sequence
Numbers" seems odd - I guess you mean "requires that either all
Child SAs use Extended Sequence Numbers or else that no Child SA
uses Extended Sequence Numbers," which is different.

- a nit, 5.1, 1st sentence; s/two counter value/two counter/values/

IANA understands that, upon approval of this document, there is a single
IANA Action that needs to be completed.

In the IKEv2 Notify Message Types - Status Types subregistry of the
Internet Key Exchange Version 2 (IKEv2) Parameters located at:

http://www.iana.org/assignments/ikev2-parameters

four new registrations are to be made. Each of new Notify Message Types
must be assigned values between 16396 and 40959.

The four new registrations are as follows:

Value NOTIFY MESSAGES - STATUS TYPES Reference
---------- ------------------------------- ---------
TBD1 IKEV2_MESSAGE_ID_SYNC_SUPPORTED [RFC-to-be]
TBD2 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED [RFC-to-be]
TBD3 IKEV2_MESSAGE_ID_SYNC [RFC-to-be]
TBD4 IPSEC_REPLAY_COUNTER_SYNC [RFC-to-be]

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Protocol Support for High Availability of IKEv2/IPsec) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Protocol Support for High Availability of IKEv2/IPsec'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipsecha-protocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipsecha-protocol/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

        Yaron Sheffer, co-chair of the IPsecME WG, is Shepherd for this document. I am also a coauthor on the latest version. I have reviewed this version and believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

        The document has had a significant amount of review during F2F meetings and on the list. The WG raised issues which were tracked and closed. I have no concerns regarding the quality of review.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The document is within the core focus area of the IPsecME WG. I am not aware of any particular additional community that needs to review it.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The is general consensus in the group that the document deals with issues that need to be solved. In fact, it follows an earlier Problem Statement (RFC 6027). An IPR disclosure was recently submitted (https://datatracker.ietf.org/ipr/1515/). There was no WG discussion of this disclosure.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

        There is solid consensus behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No extreme discontent.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

        I have verified ID nits. Out of the issues reported by the nits checker, only one is real (a normative ref to the Problem Statement), and should be fixed for the next revision. There are no formal criteria to be met.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split. As mentioned above, there is one normative reference to an Informational RFC.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The document defines a few extensions (IKEv2 notification types), and the IANA considerations are appropriate.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

  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 and IKEv2 HA clustering. This document proposes an extension to the IKEv2 protocol to solve the main issues raised in the "IPsec Cluster Problem Statement" for 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.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

        There were no notable issues with the WG process. The initial document review was more than satisfactory. More recently the WG has had a lower level of energy, and consequently fewer reviews of ongoing work.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

We are not aware of implementations of this protocol. However this protocol is solving a set of well-known issues, so we expect vendors to implement it as IKEv2 becomes mainstream.