Skip to main content

Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5685

Revision differences

Document history

Date Rev. By Action
2015-10-14
13 (System) Notify list changed from ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ikev2-redirect@ietf.org to (None)
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2009-11-06
13 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-11-06
13 Cindy Morgan [Note]: 'RFC 5685' added by Cindy Morgan
2009-11-05
13 (System) RFC published
2009-09-22
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-09-21
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-09-21
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-09-18
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-09-17
13 (System) IANA Action state changed to In Progress
2009-09-17
13 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-09-17
13 Cindy Morgan IESG state changed to Approved-announcement sent
2009-09-17
13 Cindy Morgan IESG has approved the document
2009-09-17
13 Cindy Morgan Closed "Approve" ballot
2009-09-10
13 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Charlie Kaufman.
2009-09-03
13 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2009-08-04
13 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-13.txt
2009-08-02
13 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-07-30
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-07-30
12 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-12.txt
2009-07-21
13 Pasi Eronen [Ballot Position Update] New position, Recuse, has been recorded by Pasi Eronen
2009-07-17
13 (System) Removed from agenda for telechat - 2009-07-16
2009-07-16
13 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2009-07-16
13 Cullen Jennings
[Ballot discuss]
Is there a problem with redirect loops. Where A redirects to B that redirects to C then back to A? Is this a …
[Ballot discuss]
Is there a problem with redirect loops. Where A redirects to B that redirects to C then back to A? Is this a problem.
2009-07-16
13 Cullen Jennings [Ballot discuss]
Is there a problem with redirect loops. Where A redirects to B that redirects to C? Is this a problem.
2009-07-16
13 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-07-16
13 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-07-16
13 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-07-16
13 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-07-16
13 Adrian Farrel
[Ballot comment]
VPN should be expanded on first use in the Abstract and the main text.
===
IPsec should be referenced on its first use. …
[Ballot comment]
VPN should be expanded on first use in the Abstract and the main text.
===
IPsec should be referenced on its first use.
===
Abstract says:
  Currently there is no standard mechanism
  specified that allows an overloaded VPN gateway or a VPN gateway that
  is being shut down for maintenance to redirect the VPN client to
  attach to another gateway.  This document proposes a redirect
  mechanism for IKEv2.  The proposed mechanism can also be used in
  Mobile IPv6 to enable the home agent to redirect the mobile node to
  another home agent.
Would prefer this to be reworded since this I-D creates such a
mechanism. How about...
  This document defines an IKEv2 mechanism
  that allows an overloaded VPN gateway or a VPN gateway that
  is being shut down for maintenance to redirect the VPN client to
  attach to another gateway.  The mechanism can also be used in
  Mobile IPv6 to enable the home agent to redirect the mobile node to
  another home agent.
===
Section 3
  The gateway MUST keep track of those clients that
  indicated support for the redirect mechanism and those that didn't.
Surely it only has to keep track for those clients for which it may
want to perform a redirect?
===
Rename section 5 to:
"Redirect during an active session"
since *all* redirects are gateway initiated.
===
Bit numbers on the figures are out of alignment
2009-07-16
13 Adrian Farrel
[Ballot discuss]
This is a fine document and only needs a few tweaks to address these issues and possibly the comments I have also raised. …
[Ballot discuss]
This is a fine document and only needs a few tweaks to address these issues and possibly the comments I have also raised.

===
I don't see any description of prevention of redirect bouncing except
a count described in non-2119 language in the security considerations.
I think you need...
1. A VPN gateway MUST NOT redirect to the VPN gateway indicated in the
  Redirected-From field.
2. A client MUST track redirects and SHOULD give up if it is ever
  redirected back to a VPN gateway that has already performed a
  redirect.
This certainly applies to IKE_SA_INIT and IKE_AUTH redirects, but I am
not sure about redirect of an active session. Presumably this could
legitimately be moved back and forth between gateways. You would need
a different mechanisms (including a timer?) to prevent thrashing.
===
In the anycast case you need to state whether the Redirected-From
should indicate the anycase address or the VPN gateway doing the
redirect. In either case, there are some subtle interactions with
the redirect bounce prevention mechanisms.
2009-07-16
13 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-07-15
13 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-07-15
13 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-07-15
13 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2009-07-13
13 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-07-09
13 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2009-07-09
13 Tim Polk Ballot has been issued by Tim Polk
2009-07-09
13 Tim Polk Created "Approve" ballot
2009-07-09
13 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk
2009-07-09
13 Tim Polk Placed on agenda for telechat - 2009-07-16 by Tim Polk
2009-06-30
13 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-06-25
13 Michelle Cotton
IANA Last Call comments:

Upon approval of this document, the IANA will update the
"Internet Key Exchange Version 2 (IKEv2) Parameters" registry located at
http://www.iana.org/assignments/ikev2-parameters …
IANA Last Call comments:

Upon approval of this document, the IANA will update the
"Internet Key Exchange Version 2 (IKEv2) Parameters" registry located at
http://www.iana.org/assignments/ikev2-parameters
by making new assignments to the "IKEv2 Notify Message Types - Status Types"
sub-registry and by creating a new sub-registry named "IKEv2 Gateway
Identity Type",
as described below.

=======================================================
=======================================================
sub-registry: IKEv2 Notify Message Types - Status Types

OLD:

Value NOTIFY MESSAGES - STATUS TYPES Reference
------------ -------------------------------- ---------
16405 ANOTHER_AUTH_FOLLOWS [RFC4739]
16406-40959 Unassigned [RFC4306]


NEW:

Value NOTIFY MESSAGES - STATUS TYPES Reference
------------ -------------------------------- ---------
16405 ANOTHER_AUTH_FOLLOWS [RFC4739]
16406 REDIRECT_SUPPORTED
[RFC-ipsecme-ikev2-redirect-11]
16407 REDIRECT
[RFC-ipsecme-ikev2-redirect-11]
16408 REDIRECTED_FROM
[RFC-ipsecme-ikev2-redirect-11]
16409-40959 Unassigned [RFC4306]


=======================================================
=======================================================
NEW sub-registry: IKEv2 Gateway Identity Type
Reference: [RFC-ipsecme-ikev2-redirect-11]
Registration Procedures: Expert Review for values 0-240

Value datatype: unsigned integer, 8 bits
Description: string
Notification payload: token strings

Value Description Notification Payload
Reference
------ ---------------------------------- -----------------------
----------
0 Reserved
[RFC-ipsecme-ikev2-redirect-11]
1 IPv4 address of the VPN gateway REDIRECT, REDIRECT_FROM
[RFC-ipsecme-ikev2-redirect-11]
2 IPv6 address of the VPN gateway REDIRECT, REDIRECT_FROM
[RFC-ipsecme-ikev2-redirect-11]
3 FQDN of the VPN gateway REDIRECT, REDIRECT_FROM
[RFC-ipsecme-ikev2-redirect-11]
4-240 Unassigned
[RFC-ipsecme-ikev2-redirect-11]
241-255 Private use
[RFC-ipsecme-ikev2-redirect-11]
2009-06-22
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2009-06-22
13 Samuel Weiler Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2009-06-16
13 Cindy Morgan Last call sent
2009-06-16
13 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-06-16
13 Tim Polk Last Call was requested by Tim Polk
2009-06-16
13 Tim Polk State Changes to Last Call Requested from Publication Requested::AD Followup by Tim Polk
2009-06-16
13 (System) Ballot writeup text was added
2009-06-16
13 (System) Last call text was added
2009-06-16
13 (System) Ballot approval text was added
2009-06-16
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-06-16
11 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-11.txt
2009-06-09
13 Tim Polk State Changes to Publication Requested::Revised ID Needed from Publication Requested by Tim Polk
2009-06-09
13 Tim Polk Note field has been cleared by Tim Polk
2009-05-25
13 Pasi Eronen Responsible AD has been changed to Tim Polk from Pasi Eronen
2009-05-21
13 Cindy Morgan
Document name: Redirect Mechanism for IKEv2,
draft-ietf-ipsecme-ikev2-redirect-10

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of …
Document name: Redirect Mechanism for IKEv2,
draft-ietf-ipsecme-ikev2-redirect-10

(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?

The document shepherd is Yaron Sheffer, co-chair of the ipsecme WG. I have
reviewed it 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 in-depth review within the ipsecme WG. I am not aware
of any non-WG reviews. I do not have any such concerns.

(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?

No concerns, the document lies fully within the ipsecme WG's area of
expertise.

(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.

I have no such concerns. There have been no IPR disclosures.

(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 wide WG consensus.

(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.)

There have not been any such conflicts.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html 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?

Yes, I have personally verified that.

(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].

No issues identified.

(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 new code points in existing registries, and one
new IANA registry. There are no issues with any of them. I expect the
Responsible AD to request the existing IKE/IPsec IANA expert to extend his
services to the current draft.

(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.

This document defines a redirect mechanism for IKEv2. The main use case is
scalability of large deployments of remote access VPN gateways. The proposed
mechanism can also be used in Mobile IPv6, where signaling is protected by
IKE/IPsec, to support the home agent in redirecting the mobile node to
another home agent.

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?

The document represents the consensus opinion of the ipsecme WG.

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 any implementations. Neither do we know of relevant
vendor plans.
2009-05-21
13 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-05-19
10 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-10.txt
2009-05-11
09 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-09.txt
2009-04-13
08 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-08.txt
2009-04-08
07 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-07.txt
2009-03-24
06 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-06.txt
2009-03-09
05 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-05.txt
2009-02-09
04 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-04.txt
2009-02-02
03 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-03.txt
2008-12-11
02 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-02.txt
2008-11-04
01 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-01.txt
2008-10-20
00 (System) New version available: draft-ietf-ipsecme-ikev2-redirect-00.txt