RADIUS Support for Proxy Mobile IPv6
draft-ietf-netext-radius-pmip6-08

[Ballot discuss]
The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern
  and several editorial suggestions.  The authors and Elwyn seem to
  agree that the following text will resolve the concern, but it is not
  in the document yet:

    When this bit is set the PMIP6_SUPPORTED flag MUST also be set,
and the IP4_HOA_SUPPORTED flag MUST NOT be set.

[Ballot discuss]
The security considerations section refers to 2865, 2866 and 3579
which do have pretty good security considerations.  However, this
spec seems to me to introduce new things, such as sending the
interface ID, which I think raises at least new privacy
considerations. The ones that I think may be relevant here are the
Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the
PMIP6-Visited-Interface-ID, Calling-Station-Id and the
Chargeable-User-Identity.  Since I'm not quite sure how these are
intended to be used, I'm also not sure what, if anything, needs to
be said about them in security considerations, so I'd like to
DISCUSS that.

(No change related to this in -07)

[Ballot discuss]
The security considerations section refers to 2865, 2866 and 3579
which do have pretty good security considerations.  However, this
spec seems to me to introduce new things, such as sending the
interface ID, which I think raises at least new privacy
considerations. The ones that I think may be relevant here are the
Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the
PMIP6-Visited-Interface-ID, Calling-Station-Id and the
Chargeable-User-Identity.  Since I'm not quite sure how these are
intended to be used, I'm also not sure what, if anything, needs to
be said about them in security considerations, so I'd like to
DISCUSS that.

Upon approval, IANA will complete the following actions:

ACTION 1:

IANA will register the following Radius Attribute Types at
http://www.iana.org/assignments/radius-types

Mobile-Node-Identifier
Service-Selection
PMIP6-Home-LMA-IPv6-Address
PMIP6-Visited-LMA-IPv6-Address
PMIP6-Home-LMA-IPv4-Address
PMIP6-Visited-LMA-IPv4-Address
PMIP6-Home-HN-Prefix
PMIP6-Visited-HN-Prefix
PMIP6-Home-Interface-ID
PMIP6-Visited-Interface-ID
PMIP6-Home-IPv4-HoA
PMIP6-Visited-IPv4-HoA
PMIP6-Home-DHCP4-Server-Address
PMIP6-Visited-DHCP4-Server-Address
PMIP6-Home-DHCP6-Server-Address
PMIP6-Visited-DHCP6-Server-Address


ACTION 2:

IANA will register the following in the Mobility Capability Registry at
http://www.iana.org/assignments/aaa-parameters

IP4_TRANSPORT_SUPPORTED
IP4_HOA_ONLY_SUPPORTED

[Ballot discuss]
The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern
  and several editorial suggestions.  The authors and Elwyn seem to
  agree that the following text will resolve the concern, but it is not
  in the document yet:

    When this bit is set the PMIP6_SUPPORTED flag MUST also be set,
and the IP4_HOA_SUPPORTED flag MUST NOT be set.

[Ballot discuss]
4.3.  Service-Selection

  The Service-Selection attribute (Type value TBD2) is of type UTF-8
  text and contains the name of the service or the external network
  that the mobility service for the particular MN SHOULD be associated
  with [RFC5149].  The identifier MUST be unique within the PMIPv6
  Domain.

I've got a question about being "unique". My understanding is that UTF-8 text is normally used in Radius for "display to the user only" text and is not compared to other pieces of text. Here you say it "MUST be unique". How "unique" does it need to be? That is, if one identifier contains an "a" followed by a combining acute accent (U+0061 U+0301), and another identifier contains the a-with-acute-accent (U+00E1), are those "unique"? I guess the main question is: What are these things being used for and will the above make a difference? I think either way, some more information is needed in this paragraph to explain.

[Ballot comment]
4.3.  Service-Selection

  The Service-Selection attribute (Type value TBD2) is of type UTF-8
  text and contains the name of the service or the external network
  that the mobility service for the particular MN SHOULD be associated
  with [RFC5149].  The identifier MUST be unique within the PMIPv6
  Domain.

I've got a question about being "unique". My understanding is that UTF-8 text is normally used in Radius for "display to the user only" text and is not compared to other pieces of text. Here you say it "MUST be unique". How "unique" does it need to be? That is, if one identifier contains an "a" followed by a combining acute accent (U+0061 U+0301), and another identifier contains the a-with-acute-accent (U+00E1), are those "unique"? I guess the main question is: What are these things being used for and will the above make a difference?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RADIUS Support for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'RADIUS Support for Proxy Mobile IPv6'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines new attributes to facilitate Proxy Mobile IPv6
  operations using the RADIUS infrastructure.  The protocol defined in
  this document uses Radius based interfaces of the mobile access
  gateway and the local mobility anchor with the AAA server for
  authentication, authorization and policy functions.  The RADIUS
  interactions between the mobile access gateway and the RADIUS-based
  AAA server take place when the Mobile Node attaches, authenticates
  and authorizes to a Proxy Mobile IPv6 domain.  Furthermore, this
  document defines the RADIUS-based interface between the local
  mobility anchor and the AAA RADIUS server for authorizing received
  Proxy Binding Update messages for the mobile node's mobility session.
  In addition to the mobility session setup related interactions, this
  document defines the baseline for the mobile access gateway and the
  local mobility anchor generated accounting.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/


No IPR declarations have been submitted directly on this I-D.

I have reviewed this specification.

The draft is well written. Thanks for that. I only found a couple of minor editorial issues, and one technical issue. I would like to talk about the technical issue before we send the draft forward. Please reply to this e-mail and/or revise the draft accordingly so that I can start an IETF Last Call.

Section 4.9: Shouldn't this section include some text about not including this attribute, if MIP6-Home-HN-Prefix is already present? (Like Section 4.7 had for its corresponding attribute pair.) The same problem may appear in Section 4.13 and elsewhere as well. Please check.

Section 4.10 & 4.11: This is the technical issue that worries me. While RFC 5213 does say that there are cases where MN-HoA is known, this is certainly an exception rather than the rule:

  Mobile Node's Home Address (MN-HoA)

      MN-HoA is an address from a mobile node's home network prefix.
      The mobile node will be able to use this address as long as it is
      attached to the access network that is in the scope of that Proxy
      Mobile IPv6 domain.  If the mobile node uses more than one address
      from its home network prefix(es), any one of these addresses is
      referred to as mobile node's home address.  Unlike in Mobile IPv6
      where the home agent is aware of the home address of the mobile
      node, in Proxy Mobile IPv6, the mobility entities are only aware
      of the mobile node's home network prefix(es) and are not always
      aware of the exact address(es) that the mobile node configured on
      its interface from its home network prefix(es).  However, in some
      configurations and based on the enabled address configuration
      modes on the access link, the mobility entities in the network can
      be certain about the exact address(es) configured by the mobile
      node.

Sections 4.10 and 4.11 talk about IIDs without any context on how they should be derived, used, and whether they can even exist on a given deployment.

One approach to fix this would be to delete the subsections. Another one would be explain how the IID values are determined, when they can be determined, and how they should be used. Yet another approach is to point me (and the reader) to another RFC that describes this (as I could of course have missed something).

> 4.18.  Calling-Station-Id
>
>    The Calling-Station-Id attribute (Type value 31) is of type String
>    and when used for PMIPv6 it contains the link-layer identifier of the
>    MN as defined in [RFC5213], Sections 2.2 and 8.6.

You should refer to the RFC that originally defined Calling-Station-Id.

>    The User-Name attribute MUST be present in the Access-Request.  It
>    SHOULD carry a valid MN identity unless the identity is being
>    suppressed for policy reasons, for example, when identity hiding is
>    in effect.  The MN identity, if available, MUST be in Network Access
>    Identifier (NAI) [RFC4282] format.

I think there is always an identifier that is of the valid form. It just may not reveal the identity of the user (at least not in an 1-1 and stable fashion). Consider making this change:

... MUST carry a correctly formed identifier that SHOULD correspond to a MN identity unless ...

Jari

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

I (Basavaraj Patil) am the document shepherd for this I-D. I have
reviewed this version of the document and believe 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?

The document has been reviewed by RADIUS experts as well as a few key WG
members. It has been reviewed adequately. I do not have any concerns
about the depth or breadth of the reviews w.r.t this I-D.

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

The document has been reviewed by RADIUS experts. There is also some
implementation experience of the specification. Hence additional
reviews from a specific group or broader community is not
essential. However a review by the Ops area directorate on the various
RADIUS attributes being specified would be useful.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I do not have any specific concerns with the document. The I-D
specifies several new attributes (RADIUS) which are summarized in Sec
5.2 and the AD may want to pay attention to it. There have been no IPR
disclosures related to this I-D.

(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. It is essential for
enabling the deployment of PMIP6 (RFC5213) protocol. The WG as a whole
does understand the relevance of this I-D and agrees with it.

(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 the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. I have run the I-D throigh the tool and it has passed.

(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 split references into normative and informative
ones. All normative references are RFCs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, the I-D does include an IANA considerations section which lists
the set of attributes that need IANA action. The document does not
recommend any new registry to be created. New RADIUS attributes (PMIP6
specific) are specified by this I-D and IANA assignments handled
accordingly.

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

I-D does not contain any XML code, BNF rules or MIB definitions.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up?

Technical summary:
This document defines new attributes to facilitate Proxy Mobile IPv6
operations using the RADIUS infrastructure. The protocol specified
here uses RADIUS based interfaces of the mobile access
gateway and the local mobility anchor with the AAA server for
authentication, authorization and policy functions. The RADIUS
interactions between the mobile access gateway and the RADIUS-based
AAA server take place when the Mobile Node attaches to the network,
authenticates and authorizes within a Proxy Mobile IPv6 domain.
Furthermore, this document defines the RADIUS-based interface
between the local mobility anchor and the AAA RADIUS server for
authorizing received Proxy Binding Update messages for the mobile
node's mobility session.
Additionally, this document specifies the baseline for the mobile
access gateway and the local mobility anchor generated accounting.

Working group summary:
The document has been reviewed by several RADIUS protocol experts
as well as key members within the working group. It has undergone
two working group last calls and has been revised based on
feedback from reviewers as well as implementation experience.
There is strong WG consensus behind this document.

Document quality:
There is at least one known implementation of the
protocol. Multiple vendors have indicated plans to implement this
specification.
All the key people who have reviewed this I-D are acknowledged in
the document.

The I-D has been submitted to the IESG for publication.

Proto writeup:



The Netext WG I-D: "RADIUS Support for Proxy Mobile IPv6",
has completed working group last
call and is ready to be progressed for IESG review and approval.

The I-D is a standards track document. The proto writeup for this I-D
is below.

-Basavaraj



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

I (Basavaraj Patil) am the document shepherd for this I-D. I have
reviewed this version of the document and believe 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?   

The document has been reviewed by RADIUS experts as well as a few key WG
members. It has been reviewed adequately. I do not have any concerns
about the depth or breadth of the reviews w.r.t this I-D.

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

The document has been reviewed by RADIUS experts. There is also some
implementation experience of the specification. Hence additional
reviews from a specific group or broader community is not
essential. However a review by the Ops area directorate on the various
RADIUS attributes being specified would be useful.

(1.d) Does the Document Shepherd have any specific concerns or 
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue. 

I do not have any specific concerns with the document. The I-D
specifies several new attributes (RADIUS) which are summarized in Sec
5.2 and the AD may want to pay attention to it. There have been no IPR
disclosures related to this I-D.

(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. It is essential for
enabling the deployment of PMIP6 (RFC5213) protocol. The WG as a whole
does understand the relevance of this I-D and agrees with it.

(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 the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews? 

Yes. I have run the I-D throigh the tool and it has passed.

(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 split references into normative and informative
ones. All normative references are RFCs.
 
(1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation? 

Yes, the I-D does include an IANA considerations section which lists
the set of attributes that need IANA action. The document does not
recommend any new registry to be created. New RADIUS attributes (PMIP6
specific) are specified by this I-D and IANA assignments handled
accordingly.

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

I-D does not contain any XML code, BNF rules or MIB definitions.


(1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up?

Technical summary:
  This document defines new attributes to facilitate Proxy Mobile IPv6
  operations using the RADIUS infrastructure.  The protocol specified
  here uses RADIUS based interfaces of the mobile access
  gateway and the local mobility anchor with the AAA server for
  authentication, authorization and policy functions.  The RADIUS
  interactions between the mobile access gateway and the RADIUS-based
  AAA server take place when the Mobile Node attaches to the network,
  authenticates and authorizes within a Proxy Mobile IPv6 domain.
  Furthermore, this document defines the RADIUS-based interface
  between the local mobility anchor and the AAA RADIUS server for
  authorizing received Proxy Binding Update messages for the mobile
  node's mobility session.   
  Additionally, this document specifies the baseline for the mobile
  access gateway and the local mobility anchor generated accounting.

Working group summary:
    The document has been reviewed by several RADIUS protocol experts
    as well as key members within the working group. It has undergone
    two working group last calls and has been revised based on
    feedback from reviewers as well as implementation experience.
    There is strong WG consensus behind this document.

Document quality:
    There is at least one known implementation of the
    protocol. Multiple vendors have indicated plans to implement this
    specification.
    All the key people who have reviewed this I-D are acknowledged in
    the document.

June 27, 2011
This is the working group last call for the I-D:
RADIUS Support for Proxy Mobile IPv6


The I-D has been updated by the authors following reviews by Avi Lior
and Pete McCann.

Abstract:
  This document defines new attributes to facilitate Proxy Mobile IPv6
  operations using the RADIUS infrastructure.  The RADIUS interactions
  between the mobile access gateway and the RADIUS-based AAA server
  take place when the Mobile Node attaches, authenticates and
  authorizes to a Proxy Mobile IPv6 domain.  Furthermore, this document
  defines the RADIUS-based interface between the local mobility anchor
  and the AAA RADIUS server for authorizing received Proxy Binding
  Update messages for the mobile node's mobility session.  In addition
  to the mobility session setup related interactions, this document
  defines the baseline for the mobile access gateway and the local
  mobility anchor generated accounting.

The I-D is intended for publication as a proposed standard.
The deadline for receiving comments (i.e end of WG LC) is July 12th,
2011.
Please send your review comments to the mailing list or authors.

-Chairs