Network Working Group F. Xia Internet-Draft B. Sarikaya Expires: May 18, 2008 Huawei USA J. Korhonen TeliaSonera Corporation November 15, 2007 RADIUS Proxy Mobile IPv6 draft-xia-netlmm-radius-01 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 May 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Xia, et al. Expires May 18, 2008 [Page 1] Internet-Draft RADIUS-PMIP6 November 2007 Abstract Proxy Mobile IPv6 (PMIP6) is network based mobility management protocol which allows IP session continuity for a mobile node (MN) without its involvement in mobility management. A mobile access gateway (MAG) is authorized to send Mobile IPv6 signaling messages on behalf of mobile nodes. The MAG requires a local mobility anchor address(LMAA), mobile node's identifier (MN-Identifier),and IPsec security association (SA) with it's LMA before it sends signaling messages. Interworking with existing authentication, authorization and accounting (AAA) infrastructure, MAG acquires the LMAA (directly or indirectly) and MN-Identifier. Local mobility anchor (LMA) also uses AAA infrastructure to authenticate MAG and build SA between MAG when IKEv2 IPSec is used for security between MAG and LMA . This document defines new RADIUS attributes and reasonably reuses existing attributes to serve the purpose. This information exchange takes place as part of the initial network access authentication procedure. Address configuration modes and others can also be obtained from AAA infrastructure to emulate MN's home link on access links. Xia, et al. Expires May 18, 2008 [Page 2] Internet-Draft RADIUS-PMIP6 November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. MIP6 Bootstrapping Overview . . . . . . . . . . . . . . . 5 3.2. PMIP6 Bootstrapping Procedure . . . . . . . . . . . . . . 6 3.2.1. Security Association Setup . . . . . . . . . . . . . . 6 3.2.2. Mobility Capability Negotiation . . . . . . . . . . . 7 3.2.3. Dynamic LMA Assignment . . . . . . . . . . . . . . . . 7 3.2.4. DNS Update . . . . . . . . . . . . . . . . . . . . . . 8 3.2.5. Home Link Emulation . . . . . . . . . . . . . . . . . 9 3.2.6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10 3.2.7. Mobile Node Identity . . . . . . . . . . . . . . . . . 10 3.2.8. Mobile Node Interface Identifier . . . . . . . . . . . 10 3.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Accounting at LMA . . . . . . . . . . . . . . . . . . 11 3.3.2. Accounting at MAG . . . . . . . . . . . . . . . . . . 11 4. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 11 4.1. PMIPv6 MN-HoA configuration mode . . . . . . . . . . . . . 11 4.2. Use of existing RADIUS Attributes . . . . . . . . . . . . 12 4.2.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . 12 4.2.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . 13 4.2.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . 13 4.2.4. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . 13 4.2.5. MIP-MN-HoA Attribute . . . . . . . . . . . . . . . . . 13 4.2.6. MIP-HA-IP Attribute . . . . . . . . . . . . . . . . . 13 4.2.7. Service-Type . . . . . . . . . . . . . . . . . . . . . 13 4.2.8. Framed-Protocol . . . . . . . . . . . . . . . . . . . 13 4.2.9. Chargeable User Id . . . . . . . . . . . . . . . . . . 14 4.2.10. Calling-Station-Id . . . . . . . . . . . . . . . . . . 14 4.2.11. Callback-Id . . . . . . . . . . . . . . . . . . . . . 14 4.2.12. MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . . . . 14 4.3. Table of Attributes . . . . . . . . . . . . . . . . . . . 14 5. Diameter Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative references . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Xia, et al. Expires May 18, 2008 [Page 3] Internet-Draft RADIUS-PMIP6 November 2007 1. Introduction It is possible to support mobility for IPv6 nodes by extending Mobile IPv6 [RFC3775] signaling and reusing the home agent via a proxy mobility agent in the network. [I-D.ietf-netlmm-proxymip6] describes the approach to supporting mobility without requiring the mobile node to be involved in mobility management signaling. The proxy mobility agent in the network performs the signaling and does the mobility management on behalf of the mobile node. From AAA perspective, the operation of Proxy Mobile IPv6 includes the following parts: Access Authentication. When MN attaches to an access link connected to the MAG, the MN may present its identity and home realm, as part of the access authentication procedure. Upon a successful access authentication, MAG acting as an RADIUS client obtains the MN's profile from AAA servers through RADIUS protocol. The profile probably contains the following information: LMA Address, Home Network Prefix (MN-HNP), AAA assigned MN identity, AAA assigned Interface identifier and so on. Security Association Establishment. After a successful access authentication and authorization, the MAG MUST send a Proxy Binding Update(PBU) message to the MN's LMA. The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement SHOULD be protected using IPsec. In PMIP6 scenario, a pair of security associations (SA) between LMA and MAG are shared by multiple MNs. Before sending Proxy Binding Update message, MAG checks if there is a SA ready between the MAG and the LMA. MAG initiates SA establishment procedure if there is no existing SA. IKEv2 is used to setup security associations between the MAG and the LMA. The MAG and the LMA can use any of the authentication mechanisms (shared secret/certificate/EAP), as described in [RFC4877], for mutual authentication. The MAG and LMA message exchange in SA setup is outside of scope of this document. In this memo, only AAA interfaces related to the SA setup is discussed. It should be noted that the SA is between the MAG and LMA, and the IKEv2 initiator identity used during the SA setup is the MAG identity. MN home address configuration . An important function of PMIPv6 is emulation of the MN's home link on the access link. Home address configuration is an important characteristics of links. The MN can operate in an IPv4-only mode, IPv6-only mode or in dual IPv4/ IPv6 mode. The MN can obtain IPv6 address through DHCPv6 or stateless auto-configuration. In the DHCPv6 case, the MAG can have DHCPv6 relay functionality and relay DHCPv6 messages between the MN and a DHCPv6 server. Alternatively the MAG may act as a DHCPv6 server. In the latter case, the MAG can obtain MN-HoA from Xia, et al. Expires May 18, 2008 [Page 4] Internet-Draft RADIUS-PMIP6 November 2007 AAA server, or from LMA through PBU/PBA exchange. In the stateless address auto-configuration case, the MN can also use the prefix advertised in a Router Advertisement sent by the MAG to configure an IPv6 address. The MN-HNP can be obtained from the AAA server or from the LMA. Once the MN-HoA configuration is finished, the MAG may send Access-Request to trigger a dynamic DNS update for MN-HoA. 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 [RFC2119]. The terminology in this document is based on the definitions in [I-D.ietf-netlmm-proxymip6]. 3. Solution Overview 3.1. MIP6 Bootstrapping Overview [RFC4640] is problem statement for bootstrapping Mobile IPv6. In MIP6 scenario, a MN needs at least the following information: a home address, a home agent address, and a security association with home agent to register. The process of obtaining this information is called bootstrapping. [RFC4640] discusses issues involved with how MN can be bootstrapped and various potential deployment scenarios for MN's bootstrapping. Two deployments scenarios are defined in [RFC4640]: a split scenario and an integrated scenario. The essential difference between the two scenarios is that in the split scenario, the mobility service and the network access service are authorized by different entities while in integrated scenario, the two services are authorized by the same entity. [RFC5026] details bootstrapping solution in split scenario, while [I-D.ietf-mip6-bootstrapping-integrated-dhc] describes the solution for integrated scenario. Furthermore, [I-D.ietf-mip6-hiopt] defines new DHCP options to be used for dynamic home information discovery in the integrated scenario. To facilitate these solutions, the AAA functionality for the integrated and the split scenarios need to be defined. [I-D.ietf-mip6-radius] defines new RADIUS attributes to facilitate Mobile IPv6 bootstrapping in both integrated and split scenarios. Xia, et al. Expires May 18, 2008 [Page 5] Internet-Draft RADIUS-PMIP6 November 2007 [I-D.ietf-dime-mip6-integrated] describes Diameter interface between a network access server and a home AAA server in the integrated scenario. [I-D.ietf-dime-mip6-split] specifies Diameter interface between a home agent and a home AAA server in the split scenario. The integrated scenario seems more suitable to PMIPv6 because the access authentication is a part of the bootstrapping. So, in the following, we will not present all the details of PMIPv6 bootstrapping but instead we will only highlight special considerations that apply. 3.2. PMIP6 Bootstrapping Procedure Proxy Mobile IPv6 offloads mobility management to the network. The MAG needs at least the following information during the PMIP6 bootstrapping: the LMA address , a MN-HNP or a MN-HoA, and MN- Identifier, a security association with LMA to register the MN with the LMA. The MN-Identifier may also be the MN-HoA. The process of obtaining this information is called PMIPv6 bootstrapping in this document. 3.2.1. Security Association Setup The local mobility anchor MUST allow only authorized mobile access gateways to create binding cache entries on behalf of the mobile nodes. Security Associations should be setup before sending the first Proxy Binding Update. There MAY be a separate security association for each different Realm mobile nodes have. However, this is up to the deployment and operators to decide. In [I-D.ietf-netlmm-proxymip6], the example Peer Authorization Database (PAD) entries are illustrated as following. mobile access gateway PAD: - IF remote_identity = lma_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SA for remote address lma_addres_1 local mobility anchor PAD: - IF remote_identity = mag_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address mag_address_1 For example, the MAG inspects destination address of each packet, and initiates SA setup process if the destination address matches an entry in the PAD. Xia, et al. Expires May 18, 2008 [Page 6] Internet-Draft RADIUS-PMIP6 November 2007 IKEv2 is used to setup security associations between the MAG and the LMA to protect the Proxy Binding Update, Proxy Binding Acknowledgment messages and user plane traffic. These security associations are shared by multiple MNs between the MAG and LMA pair . The MAG and the LMA can use any of the authentication mechanisms (shared secret/ certificate/EAP) described in [RFC4877] for mutual authentication and the security association setup. When EAP is used, the MAG acts as a supplicant and the LMA as an authenticator. The LMA must follow the procedures defined in [RFC3579]. The LMA gets AAA-key from the RADIUS server through RADIUS Access-Accept message. The AAA-Key is used for further SA establishment between MAG and LMA. If mutual authentication is needed, LMA acts as a supplicant and the MAG as an authenticator. The MAG must follow the procedures defined in [RFC3579]. 3.2.2. Mobility Capability Negotiation Different network entities may have different mobility management capabilities. A MN may support IPv6 or IPv4, MIPv4 or MIPv6. A MAG may support IPv4 or IPv6, MIPv4, MIPv6, Proxy MIPv4 or Proxy MIPv6. AAA servers may provide support for IPv4, IPv6, MIPv4, MIPv6, Proxy MIPv4 and Proxy MIPv6 subscriptions. Negotiation mechanism may be necessary among MN, MAG, and AAA servers. In this document, only mobility capability negotiation between a MAG and an AAA server is dealt with. In [I-D.korhonen-dime-pmip6], the attribute Mobility- Capability is used for the negotiation. Due the limited RADIUS attribute space, the Framed-Protocol attribute is reused to convey capability information. See Section 4.2.8 for new reserved values. The MAG sends Access-Request message with Framed-Protocol attribute to announce its capabilities and the AAA server returns mutually supported capabilities in the Framed-Protocol attribute in the Access-Accept reply message. The mutually agreed on capability set may also be affected by the MN subscription or operator policy. 3.2.3. Dynamic LMA Assignment [I-D.ietf-mip6-hiopt] defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home agent FQDN and home network prefix. Similarly, a MAG can act as a DHCP client to dynamically request a LMAA, or a LMA FQDN. A MAG may also receive the LMAA or the LMA FQDN as a part of the MN access authentication. Xia, et al. Expires May 18, 2008 [Page 7] Internet-Draft RADIUS-PMIP6 November 2007 MN MAG AAA DHCP-S or DHCP-R | | | | | 1 Access Authentication | | |<----------->|<----------------->| | | | | | | | 2 Access-Accept | | | |<------------------| | | | | | | | | | | | 3 DHCP Information-Request | | |----------------------------------->| | | | | | | 4 DHCP reply | | |<---------------------------------- | | | | | Figure 2: Dynamic LMA Using DHCP 1. An MN initiates authentication when the MN accesses the networks. 2. After successful authentication, the LMAA or the LMA's FQDN can be included in RADIUS Access-Accept message. The LMAA MUST be used if it is present. The LMA's FQDN can be used to retrieve LMAA from either a DHCP server or a DNS server if the LMAA is not present in a RADIUS Access-Accept message. It is out of the scope for the MAG to get a LMAA from a DHCP server or a DNS server. The following DHCP exchanges are listed as an example. 3. The MAG as a DHCP client sends Information-Request for LMAA information according to [I-D.ietf-mip6-hiopt]. In the referred document, even there isn't any LMA's information in RADIUS Access-Accept, MAG can still dynamically find a LMAA from it's a DHCP server. 4. A DHCP relay or a DHCP server sends LMAA information through a DHCP Reply message. For detail, please refer to [I-D.ietf-mip6-hiopt]. 3.2.4. DNS Update In order that the MN is reachable through its dynamically assigned Home Address, the DNS needs to be updated with the new Home Address. Since the DNS update must be performed securely in order to prevent attacks or modifications from malicious nodes, the node performing this update must share a security association with the DNS server. In this case the MAG may not share a security association with the DNS server and the DNS entry update can be performed by the AAA server. In order to accomplish this, the MAG sends to the AAA server the FQDN-HoA pair using the RADIUS protocol. Xia, et al. Expires May 18, 2008 [Page 8] Internet-Draft RADIUS-PMIP6 November 2007 LMA MAG AAA DNS server | | | | | 1 PBU | | | |<------------| | | | | | | | 2 PBA | | | |------------>| | | | | | | | Address Configuration | | | | | | | | 3 Access-Request | | | |------------------>| | | | | 4 DNS Update | | | |<-------------->| | | | | | | 5 Access-Accept | | | |<------------------| | | | | | Figure 3: DNS Update through AAA Figure 3 illustrates a typical MN-HoA DNS Update procedure 1. After successful access authentication and authorization, the MAG MUST send a Proxy Binding Update message to the LMA. The Proxy Binding Update message MUST have the Home Network Prefix option. MAG can learn the prefix from AAA server or from other means, and include the prefix in the Home Network Prefix option for requesting it from the local mobility anchor. If the specified value is 0::/0, then the LMA will allocate a prefix to the mobile node. 2. Successful PBA includes confirmed prefix which is advertised in Router Advertisement message by MAG to MN for stateless address auto-configuration. 3. Once address configuration finishes, the MAG sends Access-Request with MIP6-DNS-MO Attribute defined in [I-D.ietf-mip6-radius]. 4. The AAA server performs the DNS update based on [RFC2136]. 5. MIP6-DNS-MO attribute SHOULD be included in Access-Accept to confirm the DNS update. 3.2.5. Home Link Emulation In PMIP6, MAG is also responsible for emulating the MN's home link on the access link. The characteristics of links are prefix, address configuration mode, MTU, link layer address of the default address and so on. To keep the consistency of link characteristics, MN's prefix is allocated from LMA or AAA server. MN's address configuration mode SHOULD be conveyed in Access-Accept in PMIP6-HL- Xia, et al. Expires May 18, 2008 [Page 9] Internet-Draft RADIUS-PMIP6 November 2007 Feature attribute defined in Section 4.1 . The other parameters have limited impact on MN's behavior, so we offer no further discussion. 3.2.6. IPv4 Support [I-D.ietf-netlmm-pmip6-ipv4-support] specifies extensions to the Proxy Mobile IPv6 protocol for supporting IPv4. IPv4 support in Proxy Mobile IPv6 includes the support for the mobile node's IPv4 home address mobility and for supporting the scenario where the local mobility anchor and the mobile access gateway are separated by an IPv4 transport network. The IPv4 Local Mobility Anchor Address and MN's IPv4 Home Address SHOULD be included in RADIUS Access-Accept message. 3.2.7. Mobile Node Identity During the access authentication the MN needs to provide at least its home realm to the MAG. The MAG uses the realm information to route the subsequent RADIUS requests to MN's home AAA server. Furthermore, the MAG needs to know the MN Identity when sending a Proxy binding update to the LMA. However, depending on the used authentication mechanism the MAG may not be able to learn the MN identity. For example various EAP-methods provide identity hiding functionality. In this case the home AAA server MUST provide a temporary identity to the MAG to be used in subsequent proxy binding updates. The Chargeable User Id attribute [RFC4372] should be used to for conveying the temporary MN Identity from the AAA server to the MAG. The MAG announces its capability to handle identities provided by the Chargeable User Identity using the capability negotiation as defined in [RFC4372]. 3.2.8. Mobile Node Interface Identifier The MAG provides the AAA server with MN interface identifier in the RADIUS request message. The interface identifier may be the layer-2 identifier of the MN or a MAG generated identifier for the MN. The MN interface identifier MUST be unique at least within the PMIP6 domain. The MAG provides the MN interface identifier in the Calling- Station-Id Attribute. In a case the MAG wants the AAA server to assign the used MN interface identifier, the MAG MUST NOT include the Calling-Station-Id in the RADIUS request. In the corresponding RADIUS reply the AAA server includes the assigned MN interface identifier in the Callback-Id attribute. 3.3. Accounting Xia, et al. Expires May 18, 2008 [Page 10] Internet-Draft RADIUS-PMIP6 November 2007 3.3.1. Accounting at LMA The accounting at the LMA to AAA server interface is based on [RFC2865] and [RFC2866]. The 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 MN in bi- directional tunneling, etc. 3.3.2. Accounting at MAG The accounting at the MAG to AAA server interface is based on [RFC2865] and [RFC2866]. The interface must also support the transfer of accounting records which include: time of binding cache entry creation and deletion, octets sent and received by the MN in bi-directional tunneling, etc. If there is data traffic between a visiting mobile node and a correspondent node that is locally attached to an access link connected to the mobile access gateway, the mobile access gateway MAY optimize on the delivery efforts by locally routing the packets and by not reverse tunneling them to the mobile node's local mobility anchor. In this case, local data traffic MUST be reported to AAA servers through RADIUS protocol. 4. RADIUS Attributes We define a new attribute and then describe the existing attributes in [I-D.ietf-mip6-radius] that are reused in PMIPv6. 4.1. PMIPv6 MN-HoA configuration mode The new defined attribute (MN-HoA configuration) is included in Access-Accept message for MAG to emulate MN's home link. Xia, et al. Expires May 18, 2008 [Page 11] Internet-Draft RADIUS-PMIP6 November 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | DHCP server address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: to be defined by IANA. Length: The length of the attribute. M bit: 1-bit "Managed address configuration" flag. When set, MN uses stateful protocol (that is, DHCP) for address auto-configuration, and DHCP server's address is included in the attribute. When M bit is not set, MN uses stateless address configuration. Reserved: Reserved for future use. DHCP server address: When M bit is set, the field holds DHCP server's address. 4.2. Use of existing RADIUS Attributes 4.2.1. MIP6-HA Attribute The attribute and the following are defined in [I-D.ietf-mip6-radius] . In this document, these attributes are properly reused in PMIPv6 scenario. The RADIUS server may dynamically assign a LMA to the MN based on LMA location and current load. Xia, et al. Expires May 18, 2008 [Page 12] Internet-Draft RADIUS-PMIP6 November 2007 4.2.2. MIP6-HA-FQDN Attribute The RADIUS server may assign an FQDN of the LMA to the MN. MAG can perform DNS query or DHCP request with the FQDN to derive the LMA address. 4.2.3. MIP6-HL-Prefix Attribute The RADIUS server may assign a Home Link that is in close proximity to the MAG. The MN can use the prefix to formulate MN-HoA. 4.2.4. MIP6-DNS-MO Attribute By using this payload the MAG as a RADIUS client instructs the RADIUS server to perform a dynamic DNS update. 4.2.5. MIP-MN-HoA Attribute The attribute and the following are defined in [I-D.nakhjiri-radius-mip4] . In this document, these attributes are properly reused in PMIPv6 scenario. By using this payload a RADIUS server deliver MN's MIPv4 Home Address. 4.2.6. MIP-HA-IP Attribute By using this payload a RADIUS server deliver MN's Home Agent Address. 4.2.7. Service-Type The attribute and the following are defined in [RFC2865] . In this document, these attributes are properly reused in PMIPv6 scenario. Service-Type (6) SHALL set its value to "Framed" (2). 4.2.8. Framed-Protocol This attribute MAY be used in both Access-Request and Access-Accept packets. The values of the attribute are extended as follows. PMIPv6 16 IPv4: 32 IPv6: 64 MAG_DIRECT_ROUTING: 128 DNS_UPDATE_SUPPORT: 256 Xia, et al. Expires May 18, 2008 [Page 13] Internet-Draft RADIUS-PMIP6 November 2007 The values are handled as a bit field. For example value 336 (16+64+ 256) means that PMIPv6 with IPv6 only and DNS update is supported. 4.2.9. Chargeable User Id This attribute MAY be used to convey a temporary MN Identifier that was assigned by the AAA server. The use of this attribute is defined in [RFC4372]. 4.2.10. Calling-Station-Id This attribute MAY be present in Access-Request message and contains the MN Interface identifier. 4.2.11. Callback-Id This attribute MAY be present in Access-Accept message and contains the MN interface identifies assigned by the AAA server. 4.2.12. MS-MPPE-Recv-Key and MS-MPPE-Send-Key When EAP is used in IKEv2 SA establishment, the RADIUS server SHOULD transport the MSK from to LMA or MAG. The MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [RFC2548] are used for the transportation. The first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, and the next up to 32 octets are stored into the MS-MPPE-Send-Key. The encryption of these attributes is described in [RFC2548]. 4.3. Table of Attributes The following table provides a guide to which attributes may be found in authentication and authorization process. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 TBD MN-HoA configuration 0-1 0-1 0 0 TBD MIP6-HA 0-1 0-1 0 0 TBD MIP6-HA-FQDN 0-1 0-1 0 0 TBD MIP6-HL-Prefix 0-1 0-1 0 0 TBD MIP6-DNS-MO 0-1 0-1 0 0 TBD MIP-MN-HoA 0-1 0-1 0 0 TBD MIP-HA-IP 0-1 0-1 0 0 7 Framed-Protocol 0-1 0-1 0 0 89 Chargeable User Id 0-1 0 0 0 31 Calling-Station-Id 0 0-1 0 0 20 Callback-Id 0 0-1 0 0 VSA MS-MPPE-Recv-Key Xia, et al. Expires May 18, 2008 [Page 14] Internet-Draft RADIUS-PMIP6 November 2007 0 0-1 0 0 VSA MS-MPPE-Send-Key The following table provides a guide to which attributes may be found in accounting process. Request Interim Stop Attribute 0 0 0 MN-HoA configuration 0-1 0-1 0 MIP6-HA 0 0 0 MIP6-HA-FQDN 0-1 0-1 0 MIP6-HL-Prefix 0 0 0 MIP6-DNS-MO 0-1 0-1 0 MIP-MN-HoA 0-1 0-1 0 MIP-HA-IP 0-1 0-1 0 Service-Type 0-1 0-1 0 Framed-Protocol 0-1 0-1 0-1 Chargeable User Id 5. Diameter Considerations When used in Diameter, the attributes defined in this specification can be used as Diameter AVPs from the Code space 1-255 (RADIUS attribute compatibility space). No additional Diameter Code values need be therefore allocated. 6. Security Considerations The MAG and the LMA to the RADIUS server transactions must be adequately secured. Otherwise there is a possibility that fraudulent values are received from a rogue RADIUS server. The new attributes defined in this document do not introduce additional security considerations. 7. IANA consideration The type of attribute PMIPv6 MN-HoA configuration mode MUST be assigned by IANA. The value of the attribute Framed-Protocol MUST also be assigned by IANA. 8. Acknowledgements Xia, et al. Expires May 18, 2008 [Page 15] Internet-Draft RADIUS-PMIP6 November 2007 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006. 9.2. Informative references [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 (work in progress), November 2007. [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Xia, et al. Expires May 18, 2008 [Page 16] Internet-Draft RADIUS-PMIP6 November 2007 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01 (work in progress), July 2007. [I-D.ietf-mip6-bootstrapping-integrated-dhc] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in progress), July 2007. [I-D.ietf-dime-mip6-split] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", draft-ietf-dime-mip6-split-05 (work in progress), September 2007. [I-D.ietf-dime-mip6-integrated] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", draft-ietf-dime-mip6-integrated-06 (work in progress), November 2007. [I-D.ietf-mip6-hiopt] Jang, H., "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-08 (work in progress), November 2007. [I-D.ietf-mip6-radius] Chowdhury, K., "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-02 (work in progress), March 2007. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [I-D.korhonen-dime-pmip6] Korhonen, J., Bournelle, J., and K. Chowdhury, "Diameter Proxy Mobile IPv6: Support For Mobility Access Gateway and Local Mobility Anchor to Diameter Server Interaction", draft-korhonen-dime-pmip6-01 (work in progress), November 2007. [I-D.nakhjiri-radius-mip4] Nakhjiri, M., "RADIUS Mobile IPv4 extensions", draft-nakhjiri-radius-mip4-02 (work in progress), October 2005. Xia, et al. Expires May 18, 2008 [Page 17] Internet-Draft RADIUS-PMIP6 November 2007 Authors' Addresses Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Jouni Korhonen TeliaSonera Corporation P.O.Box 970 FI-00051 Sonera, FINLAND Email: Jouni.korhonen@teliasonera.com Xia, et al. Expires May 18, 2008 [Page 18] Internet-Draft RADIUS-PMIP6 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xia, et al. Expires May 18, 2008 [Page 19]