Re: [netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)

Behcet Sarikaya <behcetsarikaya@yahoo.com> Wed, 07 September 2011 19:49 UTC

Return-Path: <behcetsarikaya@yahoo.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 7FE7E21F8C18 for <netext@ietfa.amsl.com>; Wed, 7 Sep 2011 12:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level:
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8A8LpRdheIC for <netext@ietfa.amsl.com>; Wed, 7 Sep 2011 12:49:19 -0700 (PDT)
Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by ietfa.amsl.com (Postfix) with SMTP id B973A21F8C42 for <netext@ietf.org>; Wed, 7 Sep 2011 12:49:19 -0700 (PDT)
Received: from [98.139.91.65] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 07 Sep 2011 19:51:07 -0000
Received: from [98.139.91.23] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 07 Sep 2011 19:51:07 -0000
Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 07 Sep 2011 19:51:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 451826.2665.bm@omp1023.mail.sp2.yahoo.com
Received: (qmail 54246 invoked by uid 60001); 7 Sep 2011 19:51:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315425066; bh=Y2cZsGDuZCEzBXt3270MPmgkZGq8V9gmp/Qw9LBkeJY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XP25rn0c3g4L899rlQDHB3wCKwgt+m5OZqtIOUJ4E/IrZr6oGnacT9Pnh8Fhd16O4pCPrXFu+ov5gL7Z5zWYeOSAacTxjqO3Vp0f5CkP+waK8ac9mvaqIWc8mc0dik9yoOpROj1vxTz3qgf9lCqrMM6/QkISn/dVzfYlhgB42t8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RK/0fwDfgX9E26PaPcrNrxqJ6vBaDnVEiq8G5nktqlYB3zEGYOp5F6mKarf2/bHVpK3lbYMsnMq6pdHDPeyZeCxpep9uzyxDrB+Ei1i1sel+IVvuq/L3LcMrXpvZgJcQb6EPcbGTfMpP7RRZvmvHdDFPrEvF8kDSy6QxcJhT46w=;
X-YMail-OSG: c1AgEjYVM1mdmU2t63amM6hhfzEehKZLlVBEGFlbK7Ztp1V VIY3pTyJn995hrVha2exiwbghPFqGTX2J.DXUw.K1J1l46R9E1GoOYMUMrE9 f..vR6iSCKw0H6R1RIYM37dDfS4PshaDCZE.ywyfRJpFoTgtwapKRn63NuE8 KEEBb6MUwU4nQY8loOMvj_wnxSaDhm3u4YdIBWhsdqebo1uti6AGBGpivFCS STysrZH9Hd7UGyFy_wiwOetPMO8y5S1oHMGMKJFSXS_5cgmlQE1bKiBhN6iK 6sJ8GKtIFNRgHA9cq1_GusTgBwj_GDGz48rVYkZyyy2mPydXDs_SCAbIGseB LINw6FXcff818vO9OdAaOVDy9nsNiBcB_7ByAJB5.HJ8KJOEO1iMsf52bQz2 nALEq.Xk0gSlX6fp5tr1K1GWu.3DtGgQHL6M4jNwkJmIKhwTGsfCkb0DTj0v 9dahZguE-
Received: from [50.58.7.243] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 07 Sep 2011 12:51:06 PDT
X-Mailer: YahooMailWebService/0.8.113.315625
References: <CA8BFC07.1027C%basavaraj.patil@nokia.com>
Message-ID: <1315425066.78916.YahooMailNeo@web111416.mail.gq1.yahoo.com>
Date: Wed, 7 Sep 2011 12:51:06 -0700 (PDT)
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>, "draft-ietf-netext-radius-pmip6@tools.ietf.org" <draft-ietf-netext-radius-pmip6@tools.ietf.org>
In-Reply-To: <CA8BFC07.1027C%basavaraj.patil@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
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: Wed, 07 Sep 2011 19:49:20 -0000

Hi Basavaraj,

Thank you for your comments. We revised the draft accordingly. 

However there is only one issue which is given below.

Regards,

Behcet


> 
> Hello,
> 
> A few comments regarding this I-D before it is ready to be sent to the
> IESG:
> 
> 1. The abstract is very poorly written. It simply says "This I-D
> defines X and Y and Z". It would be preferable to have a real abstract
> which states that the PMIP6 uses Radius based interfaces between:
> - the MAG and the AAA server
> - the LMA and the AAA server
> which are used for authentication, authorization and policy functions.
> 
> Please update the abstract. In fact part of the 1st paragraph of the
> Intro section can be used in the abstract.
> 
> 2. 
> 
> s/In the context of this document, the NAS function is logically
> coupled with the MAG./This document makes an assumption that the NAS
> function is co-located with the MAG.
> 
> s/In deployments where the NAS function and the MAG functions are
> decoupled, the specific interactions needed for that to work is
> outside the scope of this document./In scenarios where the NAS
> function and MAG are decoupled, the messaging interface needed between
> them for the operation of PMIP6 is beyond the scope of this document.
> 
> 3. 
> s/Any time a mobile node attaches to an access network/When a mobile
> node attaches to an access network
> 
> 4. In Section 3:
> Q: The I-D says: "If the network access authentication succeeds, the
> MN is identified " 
> 
> The MN identity is already known as part of access authentication. The
> above sentence implies that only of network authentication succeeds,
> MN identity is known. You may want to rephrase.
> 
> 5. 
> s/access authentication procedure SHALL provide/access authentication
> procedure SHOULD provide
> 
> (In IETF parlance, we use MUST, SHOULD and MAY)
> 
> 6. 
> "After the successful network access authentication and after
>    obtaining the mobile node's Policy Profile, the MAG sends a PBU to
>    the LMA."
> 
> Rephrase and avoid using After multiple times in the same sentence.
> 
> 7. 
> s/needed for authorizing and setting up the mobility service./which is
> required for authorizing and activating mobility service.
> 
> 8. In Section 4.2
> Q: The I-D states: "If the MAG has not acquired a valid MN-Identifier by
> other
>    means, it MUST use the received MN-Identifier."
> 
> How else would the MAG get the MN-ID?
> 
> 9. In section 4.3:
> Q: I-D states: "The MAG MUST include the Service-Selection attribute
> in the Access-Request sent to the AAA if the information was
> acquired."
> 
> How does the MAG obtain the service selection attribute? It needs to
> be explained. Because if the MAG is going to populate this attribute
> in the Access-Request message, it MUST have obtained that parameter
> somehow. 
> 
> 10. 
> s/The AAA MAY
>    return the Service-Selection to the MAG even if it was not included
>    in the Access-Request as means to indicate MN's default service to
>    the MAG./
> The AAA MAY include the Service-Selection attribute in the
> Acess-Accept response message to the MAG even if it was not included
> in the Access-Request as a means of indicating the MN's default service.
> 
> 11. In sec 4.3 I-D states:
> "On the LMA-to-AAA interface, the LMA MAY populate the Service-
>    Selection attribute in the Access-Request message using the service
>    information found in the received PBU, if such mobility option was
>    included."
> 
> In which I-D or RFC is the service-information option that can be
> carried within a PBU specified?



Here, as in RFC 5779, the assumption is that the option defined in RFC 5149 for BU can also be used in PBU.
Is this OK?


> 
> 12. 
> s/Before the MAG can engage in Proxy Mobile IPv6 signaling/Before the
> MAG can initiate Proxy Mobile IPv6 signaling
> 
> 13. 
> s/PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
>    to VAAA in the RADIUS Access-Request packet as a proposal to allocate
>    the particular LMA to the MN./
> PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
>    to the VAAA entity in the RADIUS Access-Request message. It enables
> the MAG to request an LMA in the visited network.
> 
> Q: How does the MAG decide if it is authorized to request an LMA in
> the visited network? Needs to be explained.
> 
> This comment also applies to Sec 4.7
> 
> 14. Sec 4.10:
> "For Proxy Mobile IPv6 the Home Network Prefixes assigned to the
>    mobile node have to be maintained on a per-interface basis.  When the
>    LMA is located in the home network, PMIP6-Home-Interface-ID attribute
>    conveys 64 bits interface identifier representing a particular MN's
>    interface.  The attribute is assigned by the HAAA to the MAG for
>    derivation of the MN-HoA.
> "
> 
> Is it the MNs interface ID that is being sent? The description in this
> section is not clear.
> 
> 15. Sec 4.18  
> 
> Which specific attribute defined in RFC5213 are you suggesting as the
> one to be used for the Calling-station-ID. RFC5213 itself does not
> mention any such attribute in the nomenclature.
> 
> 16. Sec 7.1/2
> 
> Does this I-D mandate the MAG and LMA entities to do metering of
> traffic associated with an MN? RFC5213 itself does not require such
> functionality. You may want to make this clear in these sections.
> 
> 17. The security section needs to be further improved. What are the
> types of threats associated with sending MN specific information
> between the MAG and AAA server; And between the LMA and AAA server.
> The current security considerations section is lacking in detail.
> 
> -Basavaraj
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>