Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
draft-ietf-mip6-ikev2-ipsec-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2007-01-23
|
08 | (System) | IANA Action state changed to No IC from In Progress |
2007-01-22
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-01-16
|
08 | (System) | IANA Action state changed to In Progress |
2007-01-15
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-01-15
|
08 | Amy Vezza | IESG has approved the document |
2007-01-15
|
08 | Amy Vezza | Closed "Approve" ballot |
2007-01-11
|
08 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2007-01-11
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2007-01-11
|
08 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner |
2007-01-11
|
08 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by IESG Secretary |
2007-01-10
|
08 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-01-10
|
08 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-01-10
|
08 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-01-10
|
08 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
2007-01-10
|
08 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-01-10
|
08 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2007-01-10
|
08 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-01-10
|
08 | Sam Hartman | [Ballot comment] I really appreciate the careful PAD and SPD handling. |
2007-01-10
|
08 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2007-01-09
|
08 | Russ Housley | [Ballot discuss] Steve Bellovin's SecDir Review included: > > Section 4.1 notes that 3775 requires support for manual key > management, and … [Ballot discuss] Steve Bellovin's SecDir Review included: > > Section 4.1 notes that 3775 requires support for manual key > management, and lists IKE support as a "MAY". However, 4107 -- a > BCP which came out after 3775 -- establishes a strong presumption > that automated key management be used. Accordingly, this draft > should mandate support for IKEv2, as it does not appear to fall > under any of the exceptions. > In response Vijay Devarapalli said: > > this was discussed on the MIP6 mailing list. it was felt that this > particular draft should not update this part of RFC 3775. > draft-ietf-mip6-ikev2-ipsec only describes how IKEv2 should be used > with MIPv6.not whether MIPv6 MUST use IKEv2. that belongs in the > MIPv6 base specification. I think it is best handled when RFC 3775 > is revised. > I want to discuss this point on the telechat. |
2007-01-09
|
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2007-01-08
|
08 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
2007-01-08
|
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-01-05
|
08 | Jari Arkko | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Jari Arkko |
2007-01-05
|
08 | Jari Arkko | Reviewed last call discussion. All suggested corrections seem to be in. Initiated a discussion with the security ADs on the remaining two issues (mandatory status … Reviewed last call discussion. All suggested corrections seem to be in. Initiated a discussion with the security ADs on the remaining two issues (mandatory status of key management protocol from Steven Bellovin and mentioning MOBIKE from Tero Kivinen) |
2007-01-05
|
08 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2007-01-05
|
08 | Jari Arkko | Ballot has been issued by Jari Arkko |
2007-01-05
|
08 | Jari Arkko | Created "Approve" ballot |
2006-12-18
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-12-18
|
08 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-08.txt |
2006-12-08
|
08 | Jari Arkko | Telechat date was changed to 2007-01-11 from 2006-12-14 by Jari Arkko |
2006-11-22
|
08 | Jari Arkko | Telechat date was changed to 2006-12-14 from 2006-11-30 by Jari Arkko |
2006-11-22
|
08 | Jari Arkko | Not ready yet for a new telechat. Needs a revision. |
2006-11-15
|
08 | Yoshiko Fong | IANA Last Call Comment: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2006-11-13
|
08 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Jari Arkko |
2006-11-13
|
08 | Jari Arkko | Document pulled from this week's agenda based on reviews from Steve, Pasi, and Tero. Expecting authors to address the issues. |
2006-11-13
|
08 | Jari Arkko | Telechat date was changed to 2006-11-30 from 2006-11-16 by Jari Arkko |
2006-11-13
|
08 | Sam Hartman | I don't think this document is ready for Thursday's telechat. I cannot defer it because it's not yet in iesg evaluation. |
2006-11-10
|
08 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-11-08
|
08 | (System) | Request for Last Call review by SECDIR is assigned to Steven Bellovin |
2006-11-08
|
08 | (System) | Request for Last Call review by SECDIR is assigned to Steven Bellovin |
2006-11-01
|
08 | Dinara Suleymanova | UPDATED PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in … UPDATED PROTO Write-up (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? Basavaraj Patil. The I-D has been reviewed by the document shepherd and concluded that it is ready to be forwarded to the IESG 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? Yes. No concerns about the level and depth or breadth of the reviews exist. (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. (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. No specific concerns with this document exist. (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 strong WG consensus behind this document. Consensus is across the WG and not limited to just a few individuals. (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. (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? The I-D has passed through the ID-nits tool provided by the tools team. This document does not require review by the MIB doctor and does not specify any new media types of URIs. (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]. Yes. (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 suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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? No IANA action is required for this I-D. (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? Sections that use some form of formal specification have been verified and found to be sufficient and accurate. No concerns exist. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. The MIP6 RFCs 3775 and 3776 are based on IKE. This I-D explains MIP6 operation and establishment of the IPsec SA between the MN and HA using IKEv2. Working Group Summary The WG has been keen on ensuring a solution for MIP6 with IKEv2 is specified. There is overall consensus on the need for this specification and is widely supported. This I-D has undergone two WG last calls and has been discussed at several MIP6 WG meetings. 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? A couple of implementations exist at this time. Most vendors who implement MIP6 have expressed their intentions to implement this specification. All the key reviewers have been acknowledged in the document. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Document shepherd: Basavaraj Patil Responsible AD: Jari Arkko |
2006-10-27
|
08 | Amy Vezza | Last call sent |
2006-10-27
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-10-27
|
08 | Jari Arkko | Asked SEC ADs and the secdir to look into SPD/PAD/RFC4301 compatibility issues that I worry about. |
2006-10-27
|
08 | Jari Arkko | Placed on agenda for telechat - 2006-11-16 by Jari Arkko |
2006-10-27
|
08 | Jari Arkko | [Note]: 'PROTO Shepherd is Basavaraj Patil <basavaraj.patil@nokia.com>' added by Jari Arkko |
2006-10-27
|
08 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2006-10-27
|
08 | Jari Arkko | Last Call was requested by Jari Arkko |
2006-10-27
|
08 | (System) | Ballot writeup text was added |
2006-10-27
|
08 | (System) | Last call text was added |
2006-10-27
|
08 | (System) | Ballot approval text was added |
2006-10-27
|
08 | Jari Arkko | Proto questionnaire from the chairs: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally … Proto questionnaire from the chairs: (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? Basavaraj Patil. The I-D has been reviewed by the document shepherd and concluded that it is ready to be forwarded to the IESG 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? Yes. No concerns about the level and depth or breadth of the reviews exist. (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. (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. No specific concerns with this document exist. (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 strong WG consensus behind this document. Consensus is across the WG and not limited to just a few individuals. (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. (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? The I-D has passed through the ID-nits tool provided by the tools team. This document does not require review by the MIB doctor and does not specify any new media types of URIs. (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]. Yes. (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 suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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? No IANA action is required for this I-D. (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? Sections that use some form of formal specification have been verified and found to be sufficient and accurate. No concerns exist. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. The MIP6 RFCs 3775 and 3776 are based on IKE. This I-D explains MIP6 operation and establishment of the IPsec SA between the MN and HA using IKEv2. Working Group Summary The WG has been keen on ensuring a solution for MIP6 with IKEv2 is specified. There is overall consensus on the need for this specification and is widely supported. This I-D has undergone two WG last calls and has been discussed at several MIP6 WG meetings. 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? A couple of implementations exist at this time. Most vendors who implement MIP6 have expressed their intentions to implement this specification. All the key reviewers have been acknowledged in the document. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Document shepherd: Basavaraj Patil Responsible AD: Jari Arkko |
2006-10-27
|
08 | Jari Arkko | Waiting for proto writeup, then we can go to IETF LC. |
2006-10-25
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-10-25
|
07 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-07.txt |
2006-08-23
|
08 | Jari Arkko | State Change Notice email list have been change to mip6-chairs@tools.ietf.org,vijay.devarapalli@azairenet.com,Francis.Dupont@point6.net from mip6-chairs@tools.ietf.org |
2006-08-23
|
08 | Jari Arkko | State Change Notice email list have been change to mip6-chairs@tools.ietf.org from basavaraj.patil@nokia.com, gdommety@cisco.com, vijay.devarapalli@azairenet.com, Francis.Dupont@point6.net |
2006-08-20
|
08 | Jari Arkko | Asked Pasi Eronen if he's willing to act as an expert here. |
2006-08-20
|
08 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko |
2006-08-20
|
08 | Jari Arkko | AD reviewed posted to the mip6 list. Requires revision, and probably some help from ipsec architecture and IKEv2 experts. |
2006-08-20
|
08 | Jari Arkko | State Change Notice email list have been change to basavaraj.patil@nokia.com, gdommety@cisco.com, vijay.devarapalli@azairenet.com, Francis.Dupont@point6.net from basavaraj.patil@nokia.com, gdommety@cisco.com |
2006-08-20
|
08 | Jari Arkko | Note field has been cleared by Jari Arkko |
2006-08-20
|
08 | Jari Arkko | 1/30/06: Asked security ADs for a secdir review. Also, have a review from Jari that will require document changes (see comments). |
2006-06-16
|
08 | Dinara Suleymanova | PROTO Write-up >1) Have the chairs personally reviewed this version of the ID and do > they believe this ID is sufficiently baked to forward … PROTO Write-up >1) Have the chairs personally reviewed this version of the ID and do > they believe this ID is sufficiently baked to forward to the IESG > for publication? > >Yes. > > >2) Has the document had adequate review from both key WG members and > key non-WG members? Do you have any concerns about the depth or > breadth of the reviews that have been performed? > >The I-D has been reviewed sufficiently by WG members as well as >experts in the area of IPsec and security. > >3) Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? > >No. The document does not need further reviews. > >4) Do you have any specific concerns/issues with this document that > you believe the ADs and/or IESG should be aware of? For example, > perhaps you are uncomfortable with certain parts of the document, > or whether there really is a need for it, etc., but at the same > time these issues have been discussed in the WG and the WG has > indicated it wishes to advance the document anyway. > >There are no specific concerns with this document. > >5) 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? > >Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) specified the >use of IKE (v1) as the means to establish the IPsec SA. This I-D is >specifying the use of IKEv2 for establishing the MN-HA IPsec SA. > > >6) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize what are they upset about. > >No. > >7) Have the chairs verified that the document adheres to _all_ of the > ID nits? (see http://www.ietf.org/ID-nits.html). > >Yes. No Nits found. It has been run through the nits checker available >at the tools.ietf web site. > >8) Does the document a) split references into normative/informative, > and b) are there normative references to IDs, where the IDs are not > also ready for advancement or are otherwise in an unclear state? > (Note: the RFC editor will not publish an RFC with normative > references to IDs, it will delay publication until all such IDs are > also ready for publication as RFCs.) > >Yes. > >9) For Standards Track and BCP documents, the IESG approval > announcement includes a writeup section with the following > sections: > > - Technical Summary > > This document describes Mobile IPv6 operation with the revised > IPsec architecture and IKEv2. > > - Working Group Summary > > The document has been discussed in the WG at several IETF > meetings. It has also been reviewed sufficiently by WG members as > well as security experts. There is consensus in publishing this I-D > as a proposed standard. This specification is required in view of > IKEv2 becoming the revised mechanism for setting up IPsec SAs. > > - Protocol Quality > > > > - is the protocol already being implemented? > > Yes. > > > - have a significant number of vendors indicated they plan to > implement the spec? > > There are some vendors who have at least indicated that they > will implement this spec. > > - are there any reviewers (during the end stages) that merit > explicit mention as having done a thorough review that resulted > in important changes or a conclusion that the document was fine > (except for maybe some nits?) > > The acknowledgement section captures this adequately. > >-Basavaraj > |
2006-04-12
|
06 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-06.txt |
2006-03-25
|
08 | Margaret Cullen | [Note]: '1/30/06: Asked security ADs for a secdir review. Also, have a review from Jari that will require document changes (see comments).' added by Margaret … [Note]: '1/30/06: Asked security ADs for a secdir review. Also, have a review from Jari that will require document changes (see comments).' added by Margaret Wasserman |
2006-03-25
|
08 | Margaret Cullen | Shepherding AD has been changed to Jari Arkko from Margaret Wasserman |
2006-03-06
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-03-06
|
05 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-05.txt |
2006-01-30
|
08 | Margaret Cullen | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Margaret Wasserman |
2006-01-30
|
08 | Margaret Cullen | [Note]: '1/30/06: Asked security ADs for a secdir review. Also, have a review from Jari that will require document changes (see comments).' added by Margaret … [Note]: '1/30/06: Asked security ADs for a secdir review. Also, have a review from Jari that will require document changes (see comments).' added by Margaret Wasserman |
2006-01-30
|
08 | Margaret Cullen | Jari Arkko wrote: > > Per request, I'm reviewing this a second time now that its going to > the AD and the IESG. > … Jari Arkko wrote: > > Per request, I'm reviewing this a second time now that its going to > the AD and the IESG. > > Overall: > > I liked this document, particularly the home address allocation that > becomes much, much easier with this. > And the ability to employ in practise any type of existing AAA via > EAP. > > The spec does still have some issues. My main concern is that it tries > to do perhaps a bit too much, there are parts we should and others > that we could delete -- likely resulting in more readable and easily > implementable spec. > > Technical: > >> The IKEv2 specification [4] requires that public key based mechanism >> be used to authenticate the home agent to the mobile node, when EAP >> is used. This should be used by default by the mobile node and the >> home agent. If the EAP method that is used, supports mutual >> authentication and key generation, then the mobile node MAY use EAP >> itself to authenticate the home agent. The mobile node can request >> this by including the EAP_ONLY_AUTHENTICATION notification payload >> [8] in message 3. If the home agent supports the >> EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, >> it omits the public key based AUTH and CERT payloads in message 4. >> If the home agent does not support this mechanism, it rejects it by >> including an AUTH payload in message 4. More details can be found in >> [8]. >> > (snip) > >> The use of EAP for authenticating the mobile node to the home agent >> is described in Section 8. This document recommends that if the EAP >> method used, supports mutual authentication, then EAP itself be used >> for authenticating the home agent to the mobile node also. This runs >> contrary to the recommendation in [4]. The home agent can ignore the >> recommendation in this document and implement EAP authentication as >> described in the IKEv2 specification. Security considerations >> related to the use of EAP with IKEv2 are described in [4] and [8]. >> >> > I think that EAP-only auth mode in IKEv2 makes a lot of sense. But I'm > very concerned that a document from MIP6 WG overrides a MUST in > another WG's main document. > Here's what RFC 4306 says: > > In addition to authentication using public key signatures and shared > secrets, IKE supports authentication using methods defined in RFC > 3748 [EAP]. Typically, these methods are asymmetric (designed for a > user authenticating to a server), and they may not be mutual. For > this reason, these protocols are typically used to authenticate the > initiator to the responder and MUST be used in conjunction with a > public key signature based authentication of the responder to the > initiator. > > My suggestion would be to take the specific extension of > IKEv2 out of the draft and pursue that separately. Obviously, this > extension is also very useful in non-MIPv6 scenarios, so this is also > logical from the point of view of keeping our specs modular. > > In any case, I think the above text would make [8] normative > dependency, which I don't think you want... > >> o If the mobile node has used IKEv2 to establish security >> associations with its home agent, it should follow the procedures >> discussed in Section 11.7.1 and 11.7.3 of the base specification >> [2] to determine whether the IKE endpoints can be moved or if the >> IKE SA has to be re-established. >> >> o If the home agent has used IKEv2 to establish security >> associations with the mobile node, it should follow the procedures >> discussed in Section 10.3.1 and 10.3.2 of the base specification >> [2] to determine whether the IKE endpoints can be moved or if the >> IKE SA has to be re-established. >> >> > Hmm... I wonder if we really want to carry the K bit scheme forward. I > saw that as an intermediate solution. There's no requirement for you > to handle everything in this spec, you can also streamline & simplify. > Also, I would prefer the above text to allow IKEv2-specific address > changes. In particular, there seems to be no reason to disallow > automatic NAT-T address changes or even MOBIKE. None of that has any > effect on Mobile IPv6, as long as the client still sends a correct > Mobile IPv6 Binding Update inside. And MOBIKE is already referenced > from elsewhere of the spec, so this is also a consistency issue. > > Same issue in Section 7.3. > >> MIP6 Working Group V. Devarapalli >> Internet-Draft Nokia >> Expires: April 26, 2006 F. Dupont >> Point6 >> October 23, >> 2005 >> >> >> >> > The header says nothing about the relationship to RFC 3776. > Updates? Obsoletes? Personally, I think "updates" would make more > sense, but this is related to the issue of whether you want to carry > the manual SA stuff from 3776 here. Its quite a lot to carry, and > everyone who uses manual SAs can still use 3776, so no one would > actually lose anything. But YMMV, maybe you wanted to show how you get > rid of per-interface policies with the new architecture. > > Editorial: > >> The IPsec architecture has been revised [5]. Among the many >> changes, >> > Maybe "RFC 3776 was, however, defined for the first revision of the > IPsec architecture. The second revision [5] has introduced..." > And change "revised IPsec architecture" later in the document to "the > second revision of the IPsec architecture". (Or is the 2nd? Was the > something before 2401? Anyway, my point is that when someone reads > this 10 years from now, it may no longer be obvious what "revised > ipsec architecture" means.) > >> If the >> home address of the mobile node changes, the SPD and SAD entries need >> to re-created or updated for the new home address. >> > s/need to/need to be/ > >> The author would like to thank Mika Joutsenvirta, Pasi Eronen, >> Francis Dupont, Jari Arkko, Gerardo Giaretta and Shinta Sugimoto for >> reviewing the draft. >> >> > Francis is thanking himself :-) > > --Jari > > |
2005-11-23
|
08 | Margaret Cullen | State Changes to AD Evaluation from Publication Requested by Margaret Wasserman |
2005-11-09
|
08 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2005-10-26
|
04 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-04.txt |
2005-09-13
|
03 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-03.txt |
2005-07-19
|
02 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-02.txt |
2005-02-22
|
01 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-01.txt |
2004-10-19
|
00 | (System) | New version available: draft-ietf-mip6-ikev2-ipsec-00.txt |