[netext] Review of I-D: draft-ietf-netext-radius-pmip6-03

<Basavaraj.Patil@nokia.com> Tue, 19 July 2011 17:00 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB9C21F85B1 for <netext@ietfa.amsl.com>; Tue, 19 Jul 2011 10:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nebM98VLsdEb for <netext@ietfa.amsl.com>; Tue, 19 Jul 2011 10:00:54 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 220F721F85A7 for <netext@ietf.org>; Tue, 19 Jul 2011 10:00:54 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p6JH0qHk023248 for <netext@ietf.org>; Tue, 19 Jul 2011 20:00:53 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 20:00:22 +0300
Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 19 Jul 2011 19:00:21 +0200
Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.61]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.002; Tue, 19 Jul 2011 19:00:21 +0200
From: Basavaraj.Patil@nokia.com
To: netext@ietf.org
Thread-Topic: Review of I-D: draft-ietf-netext-radius-pmip6-03
Thread-Index: AQHMRjVXy0SYlqxXokmPTmE1GR+eFQ==
Date: Tue, 19 Jul 2011 17:00:21 +0000
Message-ID: <CA4B2252.1BD2B%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
x-originating-ip: [172.19.59.133]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E251681B15E45C4F85CE05EF6C4CB3BA@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jul 2011 17:00:22.0217 (UTC) FILETIME=[58B1F390:01CC4635]
X-Nokia-AV: Clean
Subject: [netext] Review of I-D: draft-ietf-netext-radius-pmip6-03
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 17:00:55 -0000

A few comments on the I-D:

1. I-D states:

>The AAA procedures
>   defined in this document cover the following two deployment models:
>
>   o  a mobile node connects to the Proxy Mobile IPv6 domain from the
>      home network
>
>   o  a mobile node connects to the Proxy Mobile IPv6 domain from a
>      visitor network


The above bullet points are not deployment models. Its just
illustrative of the type of networks from which an MN may
attach. Suggest rephrasing it.

2. You could reference the definition of NAS as per one of the RADIUS
   RFCs instead of redefining it here

3. 
 >  Any time a mobile node attaches to a PMIPv6 Domain, the NAS on that
 >  access network activates the network access authentication
 >  procedure."
   
   is not entirely correct. An access network may require
   authentication by a host attaching to it. And that access network
   may be part of a PMIP6 domain. The statement above implies that
   PMIP6 domains and access networks within those require a NAS and
   access authentication... which is not true.

4. 
> The NAS performs the network access authentication and queries the
> HAAA using RADIUS protocol.

NAS could use Diameter as well. Rephrase the above.

5. 
> If the network access authentication succeeds, the MN is
>  authorized for PMIPv6 service and its Policy Profile is obtained as
>  part of the RADIUS message exchange with the AAA server.

Access network authentication does not imply PMIP6 service
authorization. 

6. 
s/unambiguous indication of the type of address to be
assigned/unambiguous indication of the type of address(es) to be
assigned 

7. 
>IP4_TRANSPORT_SUPPORTED (0x0000080000000000)
>
>      This capability bit is used for negotiation of the IPv4 transport
>      support between the MAG and AAA.

Why does the MAG need to indicate support for IPv4 transport?  Why
would the MAG not support v4? I dont see the need for this.

8. 
> 4.2.  Mobile-Node-Identifier

Is the MN Identifier used in the PMIP6 PBU/PBA messages the same as
the identity used for access authentication? If it is not, how does
the NAS get the PMIP6 MN identifier? It would be maybe useful to even
rename this as the PMIP6-MN-Identifier to avoid ambiguity

9. 
>   The Service-Selection attribute (AVP Code TBD) contains the name of
>   the service or the external network that the mobility service for the
>   particular MN SHOULD be associated with.

Can you give an example of what the service name can be? I am trying
to understand what exactly would the service attribute be.

>     This field is of type UTF8String and contains the Service
>      Identifier the MN is associated with.

I dont understand what is implied by the term "Service Identifier the
MN is associated with".

10. Sec 4.14:
>4.14.  PMIP6-Home-DHCP4-Server-Address
>
>   The PMIP6-Home-DHCP4-Server-Address (AVP Code TBD) contains the IPv4
>   address of the DHCPv4 server in the home network.

Is this attribute needed? Is it not the case that the MAG is already
confgured with the address of the DHCP servers that it interacts with?

Please address these comments before the chairs can forward the I-D to the
IESG.

-Basavaraj