Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction
draft-ietf-dime-mip6-integrated-12

[Ballot discuss]
(updated discuss on 2008-11-26)

I have reviewed draft-ietf-dime-mip6-integrated-11, and I have a
major concern about the document:

Whenever we need to add couple of new attributes to existing AAA
messages, we have basically three choices: (1) define one solution,
with attributes in the 0-255 range, or (2) define two very similar
solutions (one in the 0-255 range, another in the >255 range) and
a translation between them, and occasionally (3) define one solution
with attributes in the >255 range.

(The third approach is realistic only when the functionality is not
needed on the RADIUS side, and clearly does not apply to this
situation.)

In the second approach, the Diameter-only solution (in the >255 range)
has some advantages: it can use nice Diameter features (such as
grouped AVPs), so it's somewhat "cleaner" and more elegant.

Its disadvantage is that defining two solutions plus the translation
functionality is more *complexity* and *work* than just a single
solution. It also requires updating the RADIUS/Diameter translation
agents.

In this particular case, this draft has taken approach #2, but it
seems the main reason has been organizational: there have been two
WGs (DIME and MEXT) working on this, and the WG that got to IESG
evaluation first (DIME) chose the local optimum that made their draft
slightly simpler (but the overall solution more complex).
Interestingly enough, the other WG chose approach #1 -- so if MEXT
had finished their draft first, this draft wouldn't be needed at all.

I want to repeat the last point, since it's quite important: if the
MEXT WG document (with a RADIUS+Diameter solution -- it's not
RADIUS-only, despite the file name) would already be in IESG
evaluation stage, it's IMHO highly unlikely that we would publish
draft-ietf-dime-mip6-integrated. So far, it seems the only plausible
reason for publishing this document is that 3GPP needs it soon,
and we're in a hurry. Is this really a good enough reason?

---

Other, more minor comments:

If there are multiple MIP6-Agent-Info AVPs, there's no way to find
out which home agent a MIP6-Home-Link-Prefix belongs to. Should
the MIP6-Home-Link-Prefix AVP be inside the MIP6-Agent-Info group?

Is MIP6-Home-Link-Prefix applicable to request messages? If it is,
what are the semantics?

The concept of "realm of a home agent" isn't defined anywhere (since
realm in this AVP is a Diameter concept); should the text say it's the
Diameter realm of the Diameter entity (NAS/LAAA/VAAA/HAAA) that added
the AVP?

[Ballot discuss]
(updated discuss on 2008-11-26)

I have reviewed draft-ietf-dime-mip6-integrated-11, and I have a
major concern about the document:

Whenever we need to add couple of new attributes to existing AAA
messages, we have basically three choices: (1) define one solution,
with attributes in the 0-255 range, or (2) define two very similar
solutions (one in the 0-255 range, another in the >255 range) and
a translation between them, and occasionally (3) define one solution
with attributes in the >255 range.

(The third approach is realistic only when the functionality is not
needed on the RADIUS side, and clearly does not apply to this
situation.)

In the second approach, the Diameter-only solution (in the >255 range)
has some advantages: it can use nice Diameter features (such as
grouped AVPs), so it's somewhat "cleaner" and more elegant.

Its disadvantage is that defining two solutions plus the translation
functionality is more *complexity* and *work* than just a single
solution. It also requires updating the RADIUS/Diameter translation
agents.

In this particular case, this draft has taken approach #2, but it
seems the main reason has been organizational: there have been two
WGs (DIME and MEXT) working on this, and the WG that got to IESG
evaluation first (DIME) chose the local optimum that made their draft
slightly simpler (but the overall solution more complex).
Interestingly enough, the other WG chose approach #1 -- so if MEXT
had finished their draft first, this draft wouldn't be needed at all.

I *strongly* suggest reconsidering this approach. The current DIME WG
approach means extra complexity and work that needs to be justified
by better arguments than "we're the Diameter WG, so we don't care
about RADIUS".

---

Other, more minor comments:

If there are multiple MIP6-Agent-Info AVPs, there's no way to find
out which home agent a MIP6-Home-Link-Prefix belongs to. Should
the MIP6-Home-Link-Prefix AVP be inside the MIP6-Agent-Info group?

Is MIP6-Home-Link-Prefix applicable to request messages? If it is,
what are the semantics?

The concept of "realm of a home agent" isn't defined anywhere (since
realm in this AVP is a Diameter concept); should the text say it's the
Diameter realm of the Diameter entity (NAS/LAAA/VAAA/HAAA) that added
the AVP?

[Ballot discuss]
In addition, the AVP specification(s) need
to be clear that it is delivering *Mobile IPv6* home agent information.
(The name of the AVP is somewhat misleading, but I don't mind that
as long as the section describing the AVP is clear about this).

This does not appear to be clear for the reuse of the RFC4004 attribute, which was specified for MIP4.

[Ballot comment]
The small detail that I complained about in my Discuss has been fixed. However, I still support Pasi in his Discuss. From an initial look it was not clear how it was addressed in the new version.

[Ballot discuss]
(updated discuss on 2008-10-30)

I have reviewed draft-ietf-dime-mip6-integrated-10, and I have a
major concern about the document:

The relationship of this document and draft-ietf-mip6-radius is very
unclear. In particular, the latter document defines RADIUS attributes
for the same purpose as this document (same contents and semantics),
and those attributes can be used in Diameter as-is (and the mip6
document says so). If this is indeed the case, why is this document
needed at all? (Having two different AVP/attribute numbers with
exactly same contents and semantics doesn't seem like a good idea.)

More detailed comments (mostly places that require some small
clarification):

MIP6-Feature-Vector: uses same name as mip6-radius document,
but with different number/contents.

The document needs to be clearer about its scope: while it
can bootstrap the home agent address, and home link prefix,
it doesn't create the security association.

The syntax allows arbitrary large number of MIP6-Agent-Info
and MIP6-Home-Link-Prefix AVPs in both request and response
messages, but doesn't say much about the semantics of having
more than 1 AVP (how exactly the AAA server and/or NAS and/or
intermediaries process them).

Semantics of MIP6-Home-Link-Prefix in request messages is not
described?

Section 4.2.1: the ABNF shows that either 0, 1, or 2
MIP-Home-Agent-Address AVPs can be present; but the text
doesn't seem to describe the case of 2 AVPs?

The document seems to support sending the IPv4 address of the DSMIPv6
HA; is there also need to send the IPv4 home address?

The document (unlike RFC 4004) doesn't seem to describe any concrete
use for the Destination-Realm part of the MIP-Home-Agent-Host AVP?
(i.e. would anyone notice if this AVP was empty or junk?)

Section 4.2.2: typo "contains IPv6 or IPv6 address"

Section 4.2.4 should say that the bits outside the
prefix-length MUST be zero.

Section 4.2.5 "No HA allowed -> no mobility" is a quite inaccurate
description: the MN can be allowed to use HA, and can do
mobility, but needs to obtain the HA address (and other
information) via some other means than this spec.

Section 4.2.5, it seems the NAS can't actually tell the
difference between the last three combinations? (Or can it?)

Section 5: it would be useful to have an example that also
included the MIP6-Home-Link-Prefix AVP to clarify how exactly
it works.

Figures 3 and 4 show a prefix length in
MIP-Home-Agent-Address AVP, but it seems it doesn't contain a
prefix length?

Section 7.2: "Specification Required" implies the use of a
Designated Expert; RFC 5226 says "the required documentation
and review criteria for use by the Designated Expert should
be provided when defining the registry".

[Ballot discuss]
This is a good spec and I will vote Yes as soon as the following small
issue is corrected:

  The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address
  and contains IPv6 or IPv6 address of the HA.

Presumably IPv4 or IPv6 was meant here? In any case, the spec needs
to be clear that both IPv4 or IPv6 address or both for the home
agent can be delivered. In addition, the AVP specification(s) need
to be clear that it is delivering *Mobile IPv6* home agent information.
(The name of the AVP is somewhat misleading, but I don't mind that
as long as the section describing the AVP is clear about this).

[Ballot discuss]
I have reviewed draft-ietf-dime-mip6-integrated-10, and I have a
major concern about the document:

The relationship of this document and draft-ietf-mip6-radius is very
unclear. In particular, the latter document defines RADIUS attributes
for the same purpose as this document (same contents and semantics),
and those attributes can be used in Diameter as-is (and the mip6
document says so). If this is indeed the case, why is this document
needed at all? (Having two different AVP/attribute numbers with
exactly same contents and semantics doesn't seem like a good idea.)

(I have also other, more detailed comments about the document text,
but those seem rather moot until this question is resolved.)

[Ballot discuss]
This is a good spec and I will vote Yes as soon as the following small
issues are corrected:

  The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address
  and contains IPv6 or IPv6 address of the HA.

Presumably IPv4 or IPv6 was meant here? In any case, the spec needs
to be clear that both IPv4 or IPv6 address or both for the home
agent can be delivered. In addition, the AVP specification(s) need
to be clear that it is delivering *Mobile IPv6* home agent information.
(The name of the AVP is somewhat misleading, but I don't mind that
as long as the section describing the AVP is clear about this).

[Ballot discuss]
4.2.1.  MIP6-Agent-Info

  The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and
  contains necessary information to assign a HA to the MN.  When the
  MIP6-Agent-Info AVP is present in a message, it MUST contain either
  the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or
  both AVPs.  The grouped AVP has the following grammar:

    ::= < AVP Header: TBD >
                      *2[ MIP-Home-Agent-Address ]
                        [ MIP-Home-Agent-Host ]
                      * [ AVP ]

In the above text there is formal notation that defines allowed behavior. However, there are no reference to the definition of this formal notation.
Please add that reference so that is clear what rules do apply.

[Ballot comment]
In email Sept. 9, Jouni indicated his intention to add the following text to
the security considerations, but it does not appear in the current RFC Editor
note.

  The Diameter messages may be transported between the HA and the
  Diameter server via one or more AAA brokers or Diameter agents.  In
  this case the HA to the Diameter server AAA communication rely on the
  security properties of the intermediate AAA brokers and Diameter
  agents (such as proxies).

IANA has questions:

The paragraph on expert review is not clear as to the actual process to be
followed. The instructions say "initiated by the O&M Area Directors in
consultation with the DIME working group chairs". Does this mean that IANA will only receive the request directly from the expert? Will requests be sent directly to the O&M ADs? In most cases the requests come directly to IANA and then IANA forwards the requests to the expert.
Clarification is needed.

Action 1 (section 7.1):

[ IESG Note: Expert Review Required ]

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

AVP Code Attribute Name Reference
------- --------------- ----------
TBD MIP6-Agent-Info [RFC-dime-mip6-integrated-09]
TBD MIP6-Feature-Vector [RFC-dime-mip6-integrated-09]
TBD MIP6-Home-Link-Prefix [RFC-dime-mip6-integrated-09]


Action 2 (section 7.2):

[ IESG Note: Expert Assignment Required ]

Upon approval of this document, the IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: Mobility Capability
Allocation rule: Only numeric values that are 2^x (power of two) are
allowed based on the allocation policy described below.

Following the policies outlined in [RFC 3775] new values with a description of their semantic for usage with the MIP6-Feature-Vector AVP together with a Token will be assigned after Expert Review initiated by the O&M Area Directors in consultation with the DIME working group chairs or the working group chairs of a designated successor working group. Updates can be provided based on expert approval only. A designated expert will be appointed by the O&M Area Directors. No mechanism to mark entries as "deprecated" is envisioned. Based on expert approval it is possible to delete entries from the registry.

Initial contents of this registry will be:

Token Value Reference
---------------------------------- ---------------------- ------------
MIP6_INTEGRATED 0x0000000000000001
[RFC-dime-mip6-integrated-09]
LOCAL_HOME_AGENT_ASSIGNMENT 0x0000000000000002
[RFC-dime-mip6-integrated-09]
Available for Assignment via IANA 2^x
[RFC-dime-mip6-integrated-09]


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

PROTO WRITEUP for draft-ietf-dime-mip6-integrated-09.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 David Frascone .
      The document is ready for publications and I have reviewed the
      document personally.


  (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 part of the work done on Mobile IPv6 bootstrapping
      in the MIP6 working group. While the MIP6 WG developed the
      overall architecture and the protocol support for the front-end
      (namely MN towards NAS and MN to HA)
      this document is one of two specifications providing the
      necessary back-end infrastructure support.
     
      A list of the related Mobile IPv6 bootstrapping documents
      can be found in the draft.
     
      Without this document the MIPv6 bootstrapping solution is incomplete.
     
      A first WGLC was started on 26. August 2007, see
      http://www1.ietf.org/mail-archive/web/dime/current/msg01940.html

      The document has received reviews from DIME and MIP6 members.
      Two further draft versions have been submitted to reflect the review
      comments. The changes can be seen here:
     
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-06.txt
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-07.txt 
     
      Due to the number of changes a second WGLC was started 3. Jan. 2008, see
      http://www1.ietf.org/mail-archive/web/dime/current/msg02290.html

The received comments were incorporated into the document:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-08.txt

The final version reflects a contact info change and simplifications regarding the example usage (only Diameter EAP usage is shown; Diameter NASREQ usage has been removed):
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-09.txt

  (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 the 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.
     
  (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 behind this document.
     


  (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.)
         
      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?  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 references split into normative and
    informative references. There are no downward references.


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

  An IANA consideration section exists and is consistent with the rest
  of the document.

  The document defines 3 new AVPs and one registry, called "Mobility
  Capability" that is used for storing flag values.


  (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 ABNF for the Diameter commands has been checked.
 
 
  (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.



Document Announcement Write-Up for "Diameter Mobile IPv6:
Support for Network Access Server to Diameter"
(draft-ietf-dime-mip6-integrated-09)

  Technical Summary

  A Mobile IPv6 node requires a Home Agent address, a home address, and
  a security association with its Home Agent before it can start
  utilizing Mobile IPv6.  RFC 3775 requires that some or all of these
  parameters are statically configured.  Mobile IPv6 bootstrapping work
  aims to make this information dynamically available to the Mobile
  Node.  An important aspect of the Mobile IPv6 bootstrapping solution
  is to support interworking with existing authentication,
  authorization and accounting infrastructure.  This document describes
  the MIPv6 bootstrapping using the Diameter Network Access Server
  (NAS) to home Authentication, Authorization and Accounting server
  (HAAA) interface.



  Working Group Summary

      There is consensus in the WG to publish this document.

  Document Quality

      The document has received extensive reviews from DIME and MIP6
      working group members. This document is a building block in the
      Mobile IPv6 bootstrapping architecture.
     
  Personnel

    David Frascone is the document shepherd for this document.