One document matched: draft-xia-netlmm-radius-02.txt
Differences from draft-xia-netlmm-radius-01.txt
Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Standards Track Huawei USA
Expires: August 28, 2008 J. Korhonen
TeliaSonera
S. Gundavelli
Cisco
February 25, 2008
RADIUS Proxy Mobile IPv6
draft-xia-netlmm-radius-02
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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Xia, et al. Expires August 28, 2008 [Page 1]
Internet-Draft RADIUS-PMIPv6 February 2008
Abstract
Proxy Mobile IPv6 (PMIPv6) 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 August 28, 2008 [Page 2]
Internet-Draft RADIUS-PMIPv6 February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Mobile IPv6 Bootstrapping Overview . . . . . . . . . . . . 5
3.2. Proxy Mobile IPv6 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.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Accounting at LMA . . . . . . . . . . . . . . . . . . 10
3.3.2. Accounting at MAG . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . 12
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. Chargeable User Id . . . . . . . . . . . . . . . . . . 13
4.2.9. Calling-Station-Id . . . . . . . . . . . . . . . . . . 13
4.2.10. Callback-Id . . . . . . . . . . . . . . . . . . . . . 13
4.2.11. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Xia, et al. Expires August 28, 2008 [Page 3]
Internet-Draft RADIUS-PMIPv6 February 2008
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 a MN roams into a PMIPv6 domain and 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 policy profile from AAA server using RADIUS
protocol. The policy profile contains for example the following
information: LMAA, Home Network Prefix (MN-HNP) and an AAA
assigned MN's temporary identity.
Security Association Establishment:
After a successful access authentication and authorization, the
MAG MUST send a Proxy Binding Update (PBU) message to the LMA
assigned to the MN. The signaling messages, Proxy Binding Update
and Proxy Binding Acknowledgement SHOULD be protected using IPSec.
In PMIPv6, a security association (SA) between a LMA and a MAG are
shared by multiple MNs. Before sending a PBU message, the MAG
checks if there is an existing SA established between the MAG and
the LMA. The MAG initiates a SA establishment procedure if there
is no existing SA. IKEv2 [RFC4306] SHOULD be used for a dynamic
SA setup between the MAG and the LMA. The MAG and the LMA can use
any available mechanisms for a mutual authentication (i.e., shared
secret/certificate/EAP) and IKEv2 initiator identity used during
the SA setup is the MAG's identity. The MAG and LMA message
exchange in SA setup is outside of scope of this document. In
this specification, only AAA interfaces related to the SA setup
are discussed.
MN home address configuration:
An important function of PMIPv6 is the emulation of the MN's home
link on the access link. 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
Xia, et al. Expires August 28, 2008 [Page 4]
Internet-Draft RADIUS-PMIPv6 February 2008
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 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. Mobile IPv6 Bootstrapping Overview
[RFC4640] is problem statement for bootstrapping Mobile IPv6 (MIPv6).
In MIPv6 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 to obtain this information is
called bootstrapping. [RFC4640] discusses issues involved in how the
MN can be bootstrapped and various potential deployment scenarios for
the 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 for the split
scenario, while [I-D.ietf-mip6-bootstrapping-integrated-dhc]
describes the solution for the 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.
Xia, et al. Expires August 28, 2008 [Page 5]
Internet-Draft RADIUS-PMIPv6 February 2008
[I-D.ietf-mip6-radius] defines new RADIUS attributes to facilitate
Mobile IPv6 bootstrapping in both integrated and split scenarios.
[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 for PMIPv6 because the
bootstrapping is a part of the access authentication procedure.
Therefore, we will not present all details of PMIPv6 bootstrapping
but instead we will only highlight special considerations that apply
to PMIPv6.
3.2. Proxy Mobile IPv6 Bootstrapping Procedure
PMIPv6 offloads mobility management to the network. The MAG needs at
least the following information during the PMIPv6 bootstrapping: the
LMAA , a MN-HNP or a MN-HoA, a MN-Identifier, and a MAG to LMA SA.
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 LMA MUST allow only authorized MAGs to create binding cache
entries on behalf of the mobile nodes. Security Associations should
be setup before sending the first PBU. 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, a MAG inspects destination address of each packet, and
initiates a SA setup process if the destination address matches an
entry in the PAD.
Xia, et al. Expires August 28, 2008 [Page 6]
Internet-Draft RADIUS-PMIPv6 February 2008
IKEv2 SHOULD be used to setup a SA between the MAG and the LMA to
protect the PBU and PBA messages, and user plane traffic. These SAs
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 [RFC4306] 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
session key material from the RADIUS server through RADIUS Access-
Accept message. The key material is used for further SA
establishment between the MAG and the LMA.
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, PMIPv4 or PMIPv6. AAA
servers may provide support for IPv4, IPv6, MIPv4, MIPv6, PMIPv4 and
PMIPv6 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 MIP6-Feature-Vector AVP is used for
the negotiation. Same attribute is also available for RADIUS
[I-D.ietf-mip6-radius] that can be reused for PMIPv6 purposes. The
assigned values are defined in [I-D.korhonen-dime-pmip6]. The MAG
sends Access-Request message with MIP6-Feature-Vector attribute to
announce its capabilities and the AAA server returns mutually
supported capabilities in the MIP6-Feature-Vector attribute in the
Access-Accept reply message. The mutually agreed on capability set
may also be affected by the MN subscription and 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 August 28, 2008 [Page 7]
Internet-Draft RADIUS-PMIPv6 February 2008
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 further details, 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 August 28, 2008 [Page 8]
Internet-Draft RADIUS-PMIPv6 February 2008
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 PMIPv6, 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 August 28, 2008 [Page 9]
Internet-Draft RADIUS-PMIPv6 February 2008
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.3. Accounting
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
Xia, et al. Expires August 28, 2008 [Page 10]
Internet-Draft RADIUS-PMIPv6 February 2008
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
This section describes the RADIUS Proxy Mobile IPv6 support
attributes.
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 August 28, 2008 [Page 11]
Internet-Draft RADIUS-PMIPv6 February 2008
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
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
This specification reuses RADIUS Mobile IPv6 support attributes
defined in [I-D.ietf-mip6-radius] for PMIPv6 purposes.
4.2.1. MIP6-HA Attribute
The RADIUS server may dynamically assign a LMA to the MN based on the
LMA location, current load or a local policy.
4.2.2. MIP6-HA-FQDN Attribute
The RADIUS server may assign an FQDN of the LMA to the MAG. The MAG
can perform DNS query or DHCP request with the FQDN to discover the
Xia, et al. Expires August 28, 2008 [Page 12]
Internet-Draft RADIUS-PMIPv6 February 2008
LMA IP 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 this prefix to configure a 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. 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.9. Calling-Station-Id
This attribute MAY be present in Access-Request message and contains
the MN Interface identifier.
4.2.10. Callback-Id
This attribute MAY be present in Access-Accept message and contains
the MN interface identifies assigned by the AAA server.
Xia, et al. Expires August 28, 2008 [Page 13]
Internet-Draft RADIUS-PMIPv6 February 2008
4.2.11. 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 TBD MIP6-Feature-Vector
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
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 MIP6-Feature-Vector
0-1 0-1 0-1 Chargeable-User-Id
Xia, et al. Expires August 28, 2008 [Page 14]
Internet-Draft RADIUS-PMIPv6 February 2008
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). Diameter PMIPv6 support is defined
in [I-D.korhonen-dime-pmip6].
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.
8. References
8.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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[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.
Xia, et al. Expires August 28, 2008 [Page 15]
Internet-Draft RADIUS-PMIPv6 February 2008
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006.
[I-D.ietf-mip6-radius]
Chowdhury, K., "RADIUS Mobile IPv6 Support",
draft-ietf-mip6-radius-04 (work in progress),
February 2008.
8.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-11 (work in progress),
February 2008.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02
(work in progress), November 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-07 (work in progress),
February 2008.
[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-08 (work in progress),
February 2008.
Xia, et al. Expires August 28, 2008 [Page 16]
Internet-Draft RADIUS-PMIPv6 February 2008
[I-D.ietf-mip6-hiopt]
Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
Options for Home Information Discovery in MIPv6",
draft-ietf-mip6-hiopt-11 (work in progress),
February 2008.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[I-D.korhonen-dime-pmip6]
Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Support For
Mobility Access Gateway and Local Mobility Anchor to
Diameter Server Interaction", draft-korhonen-dime-pmip6-03
(work in progress), February 2008.
[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 August 28, 2008 [Page 17]
Internet-Draft RADIUS-PMIPv6 February 2008
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
P.O.Box 970
FI-00051 Sonera, FINLAND
Email: Jouni.korhonen@teliasonera.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
Email: sgundave@cisco.com
Xia, et al. Expires August 28, 2008 [Page 18]
Internet-Draft RADIUS-PMIPv6 February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 August 28, 2008 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 05:30:27 |