Re: [Mip6] WG LC: Yoshihiro Ohba's review
Julien Bournelle <julien.bournelle@int-evry.fr> Tue, 10 October 2006 13:36 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHmM-0004pd-V0; Tue, 10 Oct 2006 09:36:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHmL-0004oi-8S for mip6@ietf.org; Tue, 10 Oct 2006 09:36:17 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHmJ-0005w0-W0 for mip6@ietf.org; Tue, 10 Oct 2006 09:36:17 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id E40982FD6E; Tue, 10 Oct 2006 15:36:08 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1GXHoA-0000Jr-Oe; Tue, 10 Oct 2006 15:38:10 +0200
Date: Tue, 10 Oct 2006 15:38:10 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review
Message-ID: <20061010133810.GA1208@ipv6-3.int-evry.fr>
References: <C147E294.257AE%basavaraj.patil@nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C147E294.257AE%basavaraj.patil@nokia.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck:
X-INT-MailScanner-SpamCheck:
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a6ea8837e8866a83aa68ed7cf9155ec9
Cc: mip6@ietf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Errors-To: mip6-bounces@ietf.org
Hi all, please find below a review of Yoshihiro Obha for the document draft-ietf-mip6-aaa-ha-goals-03.txt. Thanks a lot yoshi for this review. Mobile IPv6 WG G. Giaretta Internet-Draft I. Guardini Intended status: Standards Track E. Demaria Expires: March 16, 2007 Telecom Italia J. Bournelle GET/INT R. Lopez Univ. of Murcia September 12, 2006 AAA Goals for Mobile IPv6 draft-ietf-mip6-aaa-ha-goals-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In commercial deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol YO: Why just for commercial deployments? I think it is also useful for other AAA deployments such as enterprise usage. operations may need to be explicitly authorized and traced, requiring Giaretta, et al. Expires March 16, 2007 [Page 1] Internet-Draft AAA Goals for Mobile IPv6 September 2006 the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping in integrated and split scenarios. YO: I believe readers do not understand the above sentence without explaining what integrated and split scenarios are. Can we simply remove the above sentence from Abstract? This document describes various scenarios where a AAA interface for Mobile IPv6 is actually required. Additionally, it lists design goals and requirements for such an interface. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4 4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5 5. Goals for the Split Scenario . . . . . . . . . . . . . . . . . 6 5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Service Authorization . . . . . . . . . . . . . . . . . . 7 5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8 5.5. Provisioning of Configuration Parameters . . . . . . . . . 8 6. Goals for the Integrated Scenario . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Giaretta, et al. Expires March 16, 2007 [Page 2] Internet-Draft AAA Goals for Mobile IPv6 September 2006 1. Introduction Mobile IPv6 [1] was originally designed as a protocol without any integration with the AAA infrastructure. Nonetheless, in some environments it might be desirable to authenticate the user based on existing credentials stored at the AAA server to authorize protocol operations, to enable accounting and credit control. Due to this requirement, Mobile IPv6 might require the interaction with the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping [2] in split [3] and integrated [4] scenarios. YO: The first sentence may give an impression that we are going to modifiy Mobile IPv6 protocol to interface with AAA, which is not true. I think what we should probably convey here is something like: " Mobile IPv6 [1] provides the basic IP mobility functionality for IPv6. When Mobile IPv6 is used in tightly managed environments with the use of the AAA (Authentication, Authorization and Accounting) infrastructure, an interface between Mobile IPv6 and AAA protocols needs to be defined. Also, two scenarios for bootstrapping Mobile IPv6 service [2], i.e., split [3] and integrated [4] scenarios, must be supported by such an interface. " This document describes various scenarios where a AAA interface is required. Additionally, it lists design goals and requirements for such an interface. This document only describes requirements, goals and scenarios. It does not provide solutions. Notice that this document builds on the security model of the AAA infrastructure. As such, the end host/user shares credentials with the home AAA server and the communication between the AAA server and the AAA client may be protected. If the AAA server and the AAA client are not part of the same administrative domain, then some sort of contractual relationship between the involved administrative domains is typically in place in form of roaming agreements. YO: This document seems to assume the use of IPsec between MN and HA for securing Mobile IPv6 signaling. But the AAA interface could also be used for RFC 4285. So I think it might be good to mention in this section that the document may not preclude the use of alternative methods for securing Mobile IPv6 signaling between MN and HA while this document focuses on the use of IPsec between MN and HA. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. Some of the terms are also extracted from [2]. 3. Motivation YO: I think that most of the contents of this section is already described in RFC 4680. Can we simply remove this section and just refer to RFC 4680 in the Introduction? Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are provisioned with a set of configuration parameters, namely the Home Address and the Home Agent Address, in order to accomplish a home registration. Moreover, MNs and Home Agents (HAs) must share the cryptographic material needed in order to setup IPsec security associations to protect Mobile IPv6 signaling (e.g. shared keys or certificates). One approach is to statically provision the necessary configuration Giaretta, et al. Expires March 16, 2007 [Page 3] Internet-Draft AAA Goals for Mobile IPv6 September 2006 parameters at MNs and HAs. This solution is sub-optimal from a deployment perspective, especially in large networks with a lot of users (e.g., a mobile operator network). For this reason the Mobile IPv6 bootstrapping problem was investigated and is described in [2]. Based on the analysed scenarios, two solutions were developed. The solution for the split scenario is described in [3] and the one for the integrated scenario can be found at [4]. A key point behind these scenarios is that, whenever static provisioning is not feasible, the AAA infrastructure of the MSP can be used as the central element to enable dynamic Mobile IPv6 bootstrapping. In this case the AAA infrastructure can be exploited to offload the end host's authentication to the AAA server as well as to deliver the necessary configuration parameters to the HA. Moreover, in case Mobile IPv6 is a service offered by a Mobility Service Provider (MSP), all protocol operations (e.g., home registrations) may need to be explicitly authorized and monitored (e.g., for accounting purposes). This can be accomplished relying on the AAA infrastructure of the MSP that stores user profiles and credentials. In the split scenario, the deployment of this service model requires the availability of an interface between the Home Agent and the AAA infrastructure. The core capabilities that should be supported by this interface include Mobile IPv6 service authorization and maintenance (e.g. asynchronous service termination) as well as the exchange of accounting data. This basic set of features is needed in any Mobile IPv6 bootstrapping scenario. In the integrated scenario, the AAA server also delivers some Mobile IPv6 parameters to the NAS. 4. Bootstrapping Scenarios This section describes some bootstrapping scenarios in which a communication between the AAA infrastructure of the Mobility Service Provider and the Home Agent is needed. YO: Section 4.2 also discusses communication between NAS and the AAA infrastructure of ASP. 4.1. Split Scenario In the split scenario [3], there is the assumption that the mobility service and network access service are not provided by the same administrative entity. This implies that the mobility service can be authorized by a different entity deploying its own AAA infrastructure. The entity offering the mobility service is called Mobility Service Provider (MSP) while the entity authorizing the service is the Mobility Service Authorizer (MSA). YO: Can we define MSP, MSA, ASP and ASP in Section 2? I know those terms are defined in [2], but we can reiterate the definition in this document. Once the terms are defined, we can remove the last sentence. In this scenario, the Mobile Node discovers the Home Agent Address Giaretta, et al. Expires March 16, 2007 [Page 4] Internet-Draft AAA Goals for Mobile IPv6 September 2006 using the Domain Name Service (DNS). It queries the address based on the Home Agent name or by service name. In the former case, the Mobile Node is configured with the Fully Qualified Domain Name (FDQN) of the Home Agent. In the latter case, [3] defines a new service resource record (SRV RR). Then the Mobile Node performs an IKEv2 [6] exchange with the HA to setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure its Home Address (HoA). The IKEv2 Mobile Node to Home Agent authentication can be done using either public key signatures or the Extensible Authentication Protocol (EAP). YO: I think this authentication must be mutually done, not one one-way. Also public key may be used within EAP methods as described in the next paragraph. So I think the above sentence can be revised as follows: " Mutual authentication for IKEv2 between Mobile Node and Home Agent can be done with or without use of Extensible Authentication Protocol (EAP). " If EAP is used for authentication, the operator can choose any available EAP methods. Note that even if EAP is used, the MN authenticates the HA using public key based authentication. Based on YO: I don't see a significance of mentioning public key based authentication in this section. This note can be removed. IKEv2, the HA may rely on a remote EAP server. In this case, a AAA protocol such as RADIUS EAP [7]/Diameter EAP [8] must be used between the HA and the home EAP server. This allows a pool of HAs to rely on the same EAP server to authenticate Mobile Nodes. In this case, a AAA protocol such as RADIUS EAP [7]/Diameter EAP [8] must be used between the HA and the home EAP server. This allows a pool of HAs to rely on the same EAP server to authenticate Mobile Nodes. It also allows the roaming mobility case in which the Mobile Node obtains the mobility service in a different administrative domain (MSP != MSA). Probably the above paragraph can be simplified something like: " If EAP is used for authentication, the operator can choose any available EAP methods. Use of EAP with the AAA infrastructure allows the HA for not necessarily maintaining authentication credentials for each Mobile Node by itself. It also allows roaming in terms of Mobile IPv6 service where MSP and MSA belong to different administrative domains. " The Mobile Node may also want to update its FQDN in the DNS with the newly allocated Home Address. [3] recommends that the HA performs the DNS entry update on behalf of the Mobile Node. For that purpose, the Mobile Node indicates its FDQN in the IKEv2 exchange (IDii field in IKE_AUTH) and adds a DNS Update Option in the Binding Update message sent to the HA. When the Mobile Node uses a Home Agent belonging to a different administrative domain (MSP != MSA), the local HA may not share a security association with the home DNS server. In this case, [3] suggests that the home AAA server is responsible for the update. Thus, the HA should send to the home AAA server the (FDQN, HoA) pair. Note that the AAA exchange between the HA and the AAA server is normally terminated before the HA receives the Binding Update message. The reason is that the authentication has succeeded if the Mobile Node is able to send the BU. YO: What is the siginificance of having this note in this section? Can we simply remove this note? 4.2. Integrated Scenario In the integrated scenario [4], the assumption is that the user is authenticated and authorized by the same authorizer than network access service. The Mobility Service Authorizer (MSA) and the Access Service Authorizer (ASA) are the same entity. YO: The above text may be changed to: " In the integrated scenario [4], the user is authenticated and authorized for both network access service and mobility service by the same administrative domain. In this case, the Mobility Service Authorizer (MSA) and the Access Service Authorizer (ASA) are the same entity. " Two scenarios are possible. In the first case, the Home Agent is allocated by the user's home domain. In the second case it is Giaretta, et al. Expires March 16, 2007 [Page 5] Internet-Draft AAA Goals for Mobile IPv6 September 2006 allocated by an entity in the visited domain. In both cases, it is s/by an entity in the visited domain/by the visited domain/. assumed that the AAA server in the home domain (AAAH) authorizes both network access service and mobility service. YO: The context of the last sentence is already covered in the first paragraph and can be removed. In this scenario, Mobile Node discovers the Home Agent Address using DHCPv6. During network access service authentication and authorization, AAAH also verifies if authenticating user is authorized to use mobility service. In affirmative case, the AAAH sends the information about the assigned home agent to the Network Access Server (NAS) where the Mobile Node is currently attached. Then, the NAS stores the received information. To request home agent data, the Mobile Node sends a DHCPv6 Information Request to the All_DHCP_Relay_Agents_and_Servers multicast address. With this request, the Mobile Node can specify if it wants a home agent provided by the visited domain (ASP/MSP) or by the home domain (ASA/ MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS receives the DHCPv6 Information Request then it sends home agent information received from AAAH in a new DHC Relay Agent Option as defined in [9]. In case the Mobile Node cannot acquire home agent information via DHCPv6, it can try the default mechanism based on DNS described in [3]. After the Mobile Node has acquired the home agent information, the mechanism used to bootstrap the HoA, IPsec Security Association, and Authentication and Authorization with the MSA is the same described in the bootstrapping solution for split scenario [3]. 5. Goals for the Split Scenario Section 4 raises the need to define extensions for the AAA protocol used between the AAAH server and the HA. The following sections list a set of goals. 5.1. General goals YO: If the intent is to describe general AAA goals in this document, the current set of goals described in this section is insufficient. You may take a look at Section 2.1 of RFC 2989 for more detailed list. G1.1 The AAAH server and the HA MUST be able to authenticate each other (mutual authentication) in order to prevent the installation of unauthorized state on the HA. In some deployment scenarios, it may not be feasible for HA and AAAH to mutually authenticate each other. For example, let us consider the case where MSP is not the MSA. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information back and forth between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be trustworthy>/ Giaretta, et al. Expires March 16, 2007 [Page 6] Internet-Draft AAA Goals for Mobile IPv6 September 2006 G1.2 The AAA-HA interface MUST provide integrity protection in order to prevent any alteration of exchanged data (e.g., Mobile IPv6 configuration parameters). G1.3 The AAA-HA interface MUST provide replay protection. G1.4 The AAA-HA interface SHOULD provide confidentiality since it may be used to transfer keying material (e.g., shared key generated during EAP method authentication). G1.5 The AAA-HA interface SHOULD support inactive peer detection. This functionality can be used by the AAAH server to maintain a list of active HAs. YO: This can be done outside of AAA protocols. AAAH server can just ping to HAs. I don't think this requiremet is a AAA requirement. 5.2. Service Authorization G2.1 The AAA-HA interface SHOULD allow the use of Network Access Identifier (NAI) to identify the user. YO: Why this is not "MUST allow"? G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile IPv6 service authorization for the mobile node. YO: I don't understand what "verify Mobile IPv6 service authorization for the mobile node " means. Please elaborate more on this goal. G2.3 The AAAH server MAY assign explicit operational limitations and authorization restrictions on the HA (e.g., packet filters, QoS parameters). G2.4 The AAAH server MUST be able to send an authorization lifetime to the HA to limit Mobile IPv6 session duration for the MN. G2.5 The HA MUST be able to request to the AAAH server an extension of the authorization lifetime granted to the MN. G2.6 The AAAH server MUST be able to force the HA to terminate an active Mobile IPv6 session for authorization policy reasons (e.g., credit exhaustion). 5.3. Accounting G3.1 The AAA-HA interface MUST support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the mobile node in bi- directional tunneling, etc. Giaretta, et al. Expires March 16, 2007 [Page 7] Internet-Draft AAA Goals for Mobile IPv6 September 2006 5.4. Mobile Node Authentication G4.1 The AAA-HA interface MUST support pass-through EAP authentication with the HA working as EAP authenticator operating in pass-through mode and the AAAH server working as back-end authentication server. YO: We can simplify the text something like: " G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator. " 5.5. Provisioning of Configuration Parameters G5.1 The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN). YO: FQDN is missing here. YO: Also, I am wondering if there is an option in which AAAH assigns a home address or a home address prefix and communicate the assignment to the HA. G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. YO: Why this is not "MUST be able to"? 6. Goals for the Integrated Scenario In the integrated scenario, the AAA server provides the HA information to the NAS as part of the whole AAA operations for network access. Next goals are considered in addition to those described in section Section 5. G6.1 The AAAH server MUST be able to communicate the Home Agent Information (IP Address or FQDN) to the NAS. G6.2 The NAS SHOULD be able to notify that it supports the functionalities described in [4]. YO: The NAS notifies to whom? I guess the NAS notifies AAAH server of the functionalities. If so, please explicitly mention it. Also why this is not "MUST be able to"? G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can allocate a Home Agent to the MN. YO: Why MSP is mentioned here? Also why this is not "MUST be able to"? G6.4 The AAA server of the MSA MUST be able to indicate to the NAS whether the MN is authorized to use a local Home Agent (i.e. a Home Agent in the ASP/MSP) YO: "MSA" should read "ASA/MSA". Also "ASP/MSP" should read "MSP". YO: Also, I would like to see the following discussions in this section: - Whether the AAA-HA interface as well as AAA-NAS interface allow authentication and authorization messages to be processed by different AAA servers. - In the integrated case, whether the AAA server for the AAA-HA interface and the AAA server for the AAA-NAS interface can be different. 7. IANA Considerations This document does not require actions by IANA. Giaretta, et al. Expires March 16, 2007 [Page 8] Internet-Draft AAA Goals for Mobile IPv6 September 2006 8. Security Considerations As stated in Section 5.1 the AAA-HA interface must provide mutual authentication, integrity and replay protection. Furthermore, if security parameters (e.g., IKE pre-shared key) are transferred through this interface, confidentiality is strongly recommended to be supported. However note that AAA protocols does not support this unless it exists a direct connection between corresponding entities. YO: Is there any scenario in which security parameters are not transferred through this interface? 9. Acknowledgements The authors would like to thank James Kempf, Alper Yegin, Vijay Devarapalli, Basavaraj Patil, Gopal Dommety and Madjid Nakhjiri for their comments and feedback. Moreover the authors would like to thank Hannes Tschofenig for his deep technical and editorial review of the draft. 10. References 10.1. Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in progress), May 2006. YO: Replace the reference with RFC 4640. [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-02 (work in progress), March 2006. YO: The draft seems to be expired. [4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in progress), June 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [7] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial Giaretta, et al. Expires March 16, 2007 [Page 9] Internet-Draft AAA Goals for Mobile IPv6 September 2006 In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [8] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [9] Yegin, A., "DHCP Option for Home Agent Discovery in MIPv6", draft-jang-dhc-haopt-02 (work in progress), March 2006. [10] Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work in progress), November 2004. YO: This draft seems to be expired. [11] Giaretta, G., "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-03 (work in progress), March 2006. YO: This draft seems to be expired. (snip) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6
- [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goal… Basavaraj Patil
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Julien Bournelle
- [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6… Madjid Nakhjiri
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Gerardo Giaretta
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Yoshihiro Ohba
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Vijay Devarapalli
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Yoshihiro Ohba
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Vijay Devarapalli
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Gerardo Giaretta
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Gerardo Giaretta
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Gerardo Giaretta
- Re: [Mip6] WG LC: Yoshihiro Ohba's review Yoshihiro Ohba
- Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-… Gerardo Giaretta
- RE: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-… Madjid Nakhjiri
- [Mip6] Some comments on draft-ietf-mip6-aaa-ha-go… Narayanan, Vidya
- Re: [Mip6] Some comments on draft-ietf-mip6-aaa-h… Gerardo Giaretta
- Re: [Mip6] Some comments on draft-ietf-mip6-aaa-h… Vijay Devarapalli
- Re: [Mip6] Some comments on draft-ietf-mip6-aaa-h… Lakshminath Dondeti
- Re: [Mip6] Some comments on draft-ietf-mip6-aaa-h… Vijay Devarapalli
- Re: [Mip6] Some comments on draft-ietf-mip6-aaa-h… Lakshminath Dondeti
- Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-… Gerardo Giaretta
- RE: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-… Madjid Nakhjiri