Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction
draft-ietf-dime-mip6-split-17

IANA comments:

Action 1 (Section 9.1):

Upon approval of this document, IANA will make the following
assignments in the "Command Codes" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Code Value Name Reference
--------- ----- ---------
TBD MIP6-Request [RFC-dime-mip6-split-17]
TBD MIP6-Answer [RFC-dime-mip6-split-17]


Action 2 (Section 9.2):

Upon approval of this document, IANA will make the following
assignments in the "AVP Codes" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

AVP Code Attribute Name Reference
-------- -------------- ---------
TBD MIP-Careof-Address [RFC-dime-mip6-split-17]
TBD MIP-Authenticator [RFC-dime-mip6-split-17]
TBD MIP-MAC-Mobility-Data [RFC-dime-mip6-split-17]
TBD MIP-Timestamp [RFC-dime-mip6-split-17]
TBD MIP-MN-HA-SPI [RFC-dime-mip6-split-17]
TBD MIP-MN-HA-MSA [RFC-dime-mip6-split-17]
TBD Service-Selection [RFC-dime-mip6-split-17]
TBD MIP6-Auth-Mode [RFC-dime-mip6-split-17]


Action 3 (Section 9.3):

Upon approval of this document, IANA will make the following
assignments in the "Result-Code AVP Values (code 268)" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

AVP Values Attribute Name Reference
---------- -------------- ---------
TBD DIAMETER_SUCCESS_RELOCATE_HA [RFC-dime-mip6-split-17]
TBD DIAMETER_ERROR_MIP6_AUTH_MODE [RFC-dime-mip6-split-17]


Action 4 (Section 9.4):

Upon approval of this document, IANA will make the following
assignments in the "Application IDs" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

ID values Name Reference
--------- ----- ----------
TBD Diameter Mobile IPv6 IKE (MIP6I) [RFC-dime-mip6-split-17]
TBD Diameter Mobile IPv6 Auth (MIP6A) [RFC-dime-mip6-split-17]


Action 5 (Section 9.5):

Upon approval of this document, IANA will create the following
registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode AVP)
Registration Procedure: Specification Required
Initial contents of this sub-registry will be:

Value Token Reference
---- ----- ---------
0 Reserved [RFC-dime-mip6-split-17]
1 MIP6_AUTH_MN_AAA [RFC-dime-mip6-split-17]
2-4294967295 Unassigned

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
Figure 2 could be much better explained and referenced.  It's clear there are conventions for such diagrams but the conventions are slightly mixed  --  different for IKE and for EAP so different for left and right side of the same diagram!
- On the left side, every message contains an HDR but that's just part of the list of what the message contains
- on the right side, every message begins with its type (DER/DEA)
- SK{xxx} indicates signing?
- (xxx) indicates payload in DER and DEA messages
- CP(xxx) indicates an IKE config payload?
- is the order of messages required -- must the HA wait for a DEA before sending the next message to the MN

An explicit reference that the abbreviations and conventions in the left side come from RFC4306 would be good.  There is a reference to 4306 shortly after the diagram but it is worded as if it explains only a small point.  Better would be  "Conventions and abbreviations for the MN/HA interactions in this diagram are from RFC4306" (plus an explanation for SK(xxx) which is not there.)

I'm not sure what the reference for the right side would be.

Similar, for the tables in section 6, it's unclear that the conventions and meaning of the columns comes from, for example, RFC3588 (though the specifics differ -- in RFC3588, the last column is not considered an AVP Flag Rule)

[Ballot comment]
Use of EAP methods that do not establish a shared key is discouraged but permitted
(a SHOULD NOT in section 4.1). 

That seems to conflict with goal G4.3 from ietf-mext-aaa-ha-goals...

[Ballot comment]
Couple of editorial suggestions/nits:

The abstract gives the impression that this document supports IKEv2
with certificates and pre-shared secrets. This is probably left over
from older draft versions, which did support them?

Section 4.3, 2nd paragraph: The text should be clearer that for IPsec,
it means IKE SAs (not CHILD SAs/IPsec SAs).

Section 6.7: what about an IPv4 care-of address? (with DSMIPv6)

Sections 8: The symbol "*0" isn't defined -- does this mean "0+"
or something else?

[Ballot discuss]
I have reviewed draft-ietf-dime-mip6-split-16, and have couple of
questions/concerns that I'd like to discuss before recommending
approval of the document:

1) This document specifies only the MIP6_AUTH_MN_AAA authentication
mode, but seems to have lot of text that doesn't make sense for this
authentication mode -- but would make sense for the (somewhat
controversial) MN-HA authentication mode (where HA just asks the AAA
server for a key, without proving that the user is "live" -- violating
various AAA design rules).

The MN-HA parts include e.g. Section 4.2, 5th paragraph ("In some
architectures..."), and many of the AVP definitions (such as including
MIP-MN-HA-SPI in MIP6-Request message -- as far as I can tell, with
MIP6_AUTH_MN_AAA mode, it's included only in MIP6-Answers).

Could you clarify what is the situation here? Is there a second draft
which defines the MN-HA authentication mode? Or is the intent to
specify the final missing piece for MN-HA mode (the enumerated value)
in some non-IETF spec (which is allowed by the "Specification
Required" IANA rule)?

(My preference would be to either omit the MN-HA authentication mode
completely, or include it fully -- including 90% of it doesn't seem
like a terribly good idea.)

2) Section 4.1, paragraph beginning with "In some deployment
scenarios.."  seems to suggest using the MIP6I Diameter application
for non-Mobile IPv6 purposes (IPsec VPNs). Could you clarify
what is the intent here?

3) Section 6.14, "The replay modes, defined in RFC 4004 [RFC4004], are
supported".  The replay modes in RFC 4004 are for Mobile IPv4, not
Mobile IPv6.  It seems not all of them are actually supported by
MIPv6?

4) Section 6.16: The MIP-Timestamp AVP is 32 bits, but the timestamp
in the BU/BAck is 64 bits -- is the HA supposed to truncate/expand
this?

5) Section 6.15: What are the expected semantics of the MIP6_SPLIT
bit? A NAS that sends a message with MIP6I/MIP6A application
identifier already supports this specification -- so what additional
information is communicated by setting or not setting this bit?

6) The security considerations (or some place) should explicitly
mention that this spec expects that the AAA Server derives the MN-HA
security association (including MN-HA shared key) somehow (probably
based on the MN-AAA shared key), but there is no IETF document
specifying how that is done, and the security properties of the system
depend on how this is done. (For example, the simplest possible way,
just using MN-AAA key as the MN-HA key, would probably have
implications on how you would want to deploy your AAA nodes.)

(This is one big difference from RFC 4004 and related Mobile IPv4
specs -- in MIPv4 case, there is an RFC (3957) that specifies how to
derive the MN-HA shared key from the MN-AAA key, in a way that's
reasonably OK to transport over AAA.)

7) To me both RFC 4285 and 5149 look like they should be normative.
What was the reason for moving RFC 4285 from a Normative Reference
(like it was in version -15) to Informative?

[Ballot comment]
Section 6., paragraph 2:
>                    AVP  Defined            |    |    |SHLD| MUST|MAY |

  I'd prefer SHLD->SHOULD. (Here and elsewhere.)

[Ballot comment]
Section 6., paragraph 2:
>                    AVP  Defined            |    |    |SHLD| MUST|MAY |
>    Attribute Name  Code in      Value Type |MUST| MAY| NOT|  NOT|Encr|

  I'd prefer SHLD->SHOULD. (Here and elsewhere.)

Security Directorate Review by Donald Eastlake:

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.

This document primarily specifies the interaction between a Mobile IP Home Agent and a Diameter server when an IPv6 Mobile Mode wants to bootstrap its operations dynamically through interaction between its Home Agent and the Diameter server of a Mobile Service Provider.

General: I'm always a bit suspicious of draft that include several options and alternatives. These at least make the document more complex and increase the probability that some security flaw in one of the options/alternatives will be overlooked.

Security: The Security Considerations section of this draft is pretty short and primarily refers to the Security Considerations of three other RFCs. It appears that the referenced documents, particularly RFC
5026 and the RFCs referenced by the Securities Considerations section of RFC 5026, are adequate.

Nits:

Given that the first two messages in the Figure 2 message flow diagram are annotated "(1)" and "(2)", it would seem like a good idea to add those annotations at an appropriate place in the subsequent text.

"a IKEv2" -> "an IKEv2".

First paragraph of 5.1: "a number AVPs" -> "a number of AVPs".

Second paragraph of 5.2.1: "with a replay protection related information" -> "with replay protection related information".

9.5: "values" -> "value".

10: "in in" -> "in".

IANA Last Call questions/comments:

- In the "MIP6 Authentication Mode (MIP6-Auth-Mode AVP)" registry, is
0 reserved or available for assignment? Also, does this registry have
an upper limit?

Action 1 (Section 9.1):

Upon approval of this document, IANA will make the following
assignments in the "Command Codes" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Code Value Name Reference
--------- ----- ---------
TBD MIP6-Request [RFC-dime-mip6-split-16]
TBD MIP6-Answer [RFC-dime-mip6-split-16]


Action 2 (Section 9.2):

Upon approval of this document, IANA will make the following
assignments in the "AVP Codes" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

AVP Code Attribute Name Reference
-------- -------------- ---------
TBD MIP-Careof-Address [RFC-dime-mip6-split-16]
TBD MIP-Authenticator [RFC-dime-mip6-split-16]
TBD MIP-MAC-Mobility-Data [RFC-dime-mip6-split-16]
TBD MIP-Timestamp [RFC-dime-mip6-split-16]
TBD MIP-MN-HA-SPI [RFC-dime-mip6-split-16]
TBD MIP-MN-HA-MSA [RFC-dime-mip6-split-16]
TBD Service-Selection [RFC-dime-mip6-split-16]
TBD MIP6-Auth-Mode [RFC-dime-mip6-split-16]


Action 3 (Section 9.3):

Upon approval of this document, IANA will make the following
assignments in the "Result-Code AVP Values (code 268)" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

AVP Values Attribute Name Reference
---------- -------------- ---------
TBD DIAMETER_SUCCESS_RELOCATE_HA [RFC-dime-mip6-split-16]
TBD DIAMETER_ERROR_MIP6_AUTH_MODE [RFC-dime-mip6-split-16]


Action 4 (Section 9.4):

Upon approval of this document, IANA will make the following
assignments in the "Application IDs" registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

ID values Name Reference
--------- ----- ----------
TBD Diameter Mobile IPv6 IKE (MIP6I) [RFC-dime-mip6-split-16]
TBD Diameter Mobile IPv6 Auth (MIP6A) [RFC-dime-mip6-split-16]


Action 5 (Section 9.5):

Upon approval of this document, IANA will make the following
assignment in the "Mobility Capability Registry" at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Value Token Reference
---- ----- ---------
0x0000000100000000 MIP6_SPLIT [RFC-dime-mip6-split-16]


Action 6 (Section 9.5):

Upon approval of this document, IANA will create the following
registry at
http://iana.org/assignments/aaa-parameters/aaa-parameters.xhtml

Registry Name: MIP6 Authentication Mode (MIP6-Auth-Mode AVP)
Allocation Policy: Specification Required
Initial contents of this sub-registry will be:

Value Token Reference
---- ----- ---------
1 MIP6_SPLIT [RFC-dime-mip6-split-16]


We understand the above to be the only IANA Actions for this document.

PROTO WRITEUP for draft-ietf-dime-mip6-split-15.txt
===================================================

  (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 Victor Fajardo. I have personally reviewed the
document and I 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?

This document is a solutions document for the MIPv6 bootstrapping problem
for the split scenario. It has direct implications for 
authentication/authorization, provisioning and accounting of mobility 
resources to users. Therefore, the document has received extensive reviews 
by relevant WG members - under the employ of operators and parties that 
have associations with interested SDOs.

Discrepancies found during the lifetime of this doc have received a fair
amount of reviews both within and outside of the WG. All discussions
have been publicly posted in the dime mailing list. So, I do not have any
concerns with the depth or breadth of the reviews.

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

There are no concerns with this document.

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

There are no concerns with this document. An IPR disclosure has been
filed, 
see https://datatracker.ietf.org/ipr/964/, and the group has been informed 
about it. Content that may be subject of the IPR claim was moved 
into a separate document, see 
http://tools.ietf.org/id/draft-korhonen-dime-mip6-feature-bits-00.txt


  (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 consensus in the WG behind the document. The problem is
well understood and the solution is acceptable to the WG, as well
as other interested SDOs.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize 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 is no opposition to this document.

  (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?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document does not contain nits.

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

The document has been split into normative and informative references.
There normative references that are work in progress. They are as follows:

  [I-D.ietf-dime-mip6-integrated]
              Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
              and K. Chowdhury, "Diameter Mobile IPv6: Support for
              Network Access Server to Diameter Server  Interaction",
              draft-ietf-dime-mip6-integrated-11 (work in progress),
              November 2008.

  [I-D.ietf-dime-qos-attributes]
              Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
              and A. Lior, "Quality of Service Attributes for Diameter",
              draft-ietf-dime-qos-attributes-09 (work in progress),
              December 2008.

It is expected that these referenced documents will be published ahead
of draft-ietf-dime-mip6-split-15.txt.

This document requires a DOWNREF for RFC 4285. 

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations 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 [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The document has an IANA considerations section that is consistent with
the body.
The document creates a new registry for the MIP6-Auth-Mode AVP (also
defined in the
document). The document provides an initial value for this AVP and
follows BCP 26
with "Specification Required" as an allocation requirement. 

Following RFC 3588, IETF consensus is required for allocation
application ids, 
command  codes, AVP codes and values is done as part of the review and 
consensus process given by the work on it through the DIME working group. 

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

The document contains ABNF rules specified in RFC 3588. The ABNF content
has been validated.

  (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

    This document specifies the interactions between the Mobile IP Home
    Agent and the Diameter server (AAA) in the case where the network
    access service and the mobility service is not in the same
administrative
    domain. The purpose of the interactions is to bootstrap the mobile
node
    from the MSP as part of the authentication and/or authorization
process.

    The document defines new diameter applications to support IKEv2 and
    MIPv6 authentication protocol. It defines diameter messages, AVPs and
    command codes to carry the authentication, authorization and
bootstrapping 
    attributes.

  Working Group Summary

    There was consensus in the WG to publish the document.

  Document Quality

    The document has been sent for review to MEXT. This document is part
    of the solution for Mobile IPv6 bootstrapping problem defined in
    RFC 4640. It has received extensive reviews from DIME WG members.

  Personnel

    Victor Fajardo is the document shepherd for this document.