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 |