Skip to main content

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