One document matched: draft-xia-netlmm-radius-01.txt
Differences from draft-xia-netlmm-radius-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 05:30:29 |