Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: January 7, 2009 Huawei USA
July 6, 2008
Problem Statement and Requirements for Diameter/Radius Prefix
Authorization Application
draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
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 January 7, 2009.
Sarikaya & Xia Expires January 7, 2009 [Page 1]
Internet-Draft PS:Diameter Prefix Authorization July 2008
Abstract
This document provides problem statement for AAA prefix authorization
application. The document also identifies application scenarios and
requirements on AAA prefix authorization application.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4
4.1. Prefix Management in Access Routers . . . . . . . . . . . 4
4.2. Prefix Management in Local Mobility Anchors . . . . . . . 5
4.3. Prefix Management for Mobile Routers . . . . . . . . . . . 6
5. Requirements on AAA-based Prefix Authorization Application . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative references . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Sarikaya & Xia Expires January 7, 2009 [Page 2]
Internet-Draft PS:Diameter Prefix Authorization July 2008
1. Introduction and Motivation
Prefix assignment for an IPv6 node (host or router) is essential to
IPv6 address formulation. Even though IPv6 address space is large
enough, it still makes sense for operators to manage addresses in a
central way, e.g. using central DHCPv6 servers or AAA servers.
Authorizing the use of a prefix that a central server has by a prefix
user needs communication between different network entities.
Prefix usage and per-MN prefixes are widely discussed in IETF 16NG,
NEMO, and NETLMM Working Groups. Corresponding solutions are also
introduced. But these solutions only solve a part of the problem.
In 16NG, an Access Router allocates a mobile node's prefix using
Router Advertisement message defined in [RFC4861]. There is no
discussion about how the Access Router acquires prefixes from
external entity. NEMO deals with synchronization of Mobile Network
prefixes between a Mobile Router and a Home Agent, while the method
is agnostic to the way that a Home Agent gets prefixes from back end
servers. In Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6], Proxy
Binding Update and Proxy Binding Acknowledgement messages are used to
allocate prefixes from a Local Mobile Anchor to a mobile node, but
how the Local Mobile Anchor gets prefixes from external server is
left out of the scope.
[RFC3633] defines Prefix Delegation options and procedures to provide
a mechanism for automated delegation of IPv6 prefixes using the
Dynamic Host Configuration Protocol (DHCP). In [RFC3633], the
requesting router (RR) as DHCP client requests the prefixes for the
prefix users from the delegating router (DR) as DHCP server. When RR
and DR are not located on the same subnet RR needs to have a Relay
agent as well as DHCP client in order to communicate with DHCP server
in the network.
Making use of AAA infrastructure for prefix management can solve the
aforementioned problems in a uniform way.
2. Terminology
Prefix Authorization (PA): The process by which a network access
server (NAS) (as AAA client) obtains a prefix dynamically from AAA
server.
3. Problem Statement
AAA servers managing IP addresses is a convention. [RFC2865] defines
attribute Framed-IP-Address for allocating IPv4 address for a host.
Sarikaya & Xia Expires January 7, 2009 [Page 3]
Internet-Draft PS:Diameter Prefix Authorization July 2008
AAA servers statically configuring IPv6 prefixes is also a
convention. [RFC3162] introduces Framed-IPv6-Prefix attribute for
configuring IPv6 prefixes for a host. This configuration is static
because Framed-IPv6-Prefix carries a number of prefixes only.
Lifetime values for each prefix can not be carried.
Existing AAA (RADIUS and Diameter) mechanisms can't accomodate prefix
authorization. [RFC4818] designs Delegated-IPv6-Prefix attribute.
The protocol defined in [RFC4818] is in fact used for the AAA server
to authorize prefix(es) to NAS for use in the user's network.
However in [RFC4818], the recommended usage scenario is that the AAA
server configures the delegating server acting as NAS with the
prefix(es) and then DHCP Prefix Delegation [RFC3633] can be used to
delegate these prefixes to the requesting router. Also Delegated-
IPv6-Prefix carries a number of prefixes only. Lifetime values for
each prefix can not be carried. The identities of the end users for
which prefixes are authorized can not be carried. AAA server is not
given any information on the end users of the prefixes. Also the NAS
could be better configured at the requesting router instead of at the
DHCP server.
In a prefix authorization application, the NAS requests prefixes from
the AAA server. In the request, the users of prefixes MUST be
identified. AAA server replies with one or more prefixes. When the
lifetime of the prefix(es) expires, the NAS renews its request for
the prefix(es).
There are many potential uses of such a prefix authorization
application which are presented in the next section. The number of
applications is growing due to the use of point-to-point link model
in cellular networks.
4. Application Scenarios
Diameter/Radius prefix authorization application has the applications
that are described in this section.
4.1. Prefix Management in Access Routers
[RFC4968] provides different IPv6 link models that are suitable for
IEEE 802.16 based networks and provides analysis of various
considerations for each link model and the applicability of each link
model under different deployment scenarios. As to IPv6 addressing,
there are two models, shared link model and point-to-point link
model. In the former model, an IPv6 prefix is shared by multiple
MNs. While in the point-to-point link model, a prefix is only
assigned to one interface of MN. Different MNs can't share a prefix
Sarikaya & Xia Expires January 7, 2009 [Page 4]
Internet-Draft PS:Diameter Prefix Authorization July 2008
and an interface can have multiple prefixes. [RFC5121] specifies the
addressing and operation of IPv6 over the IPv6 specific part of the
packet convergence sub-layer of IEEE Std 802.16e [802.16e] and point-
to-point link model is recommended.
Also, 3GPP/3GPP2 have earlier adopted the point-to-point link model
[RFC3314].
A mobile node and an Access Router are connected via a point-to-point
connection at the IPv6 layer. Hence each mobile node can be
considered to be on a separate subnet. The prefixes for the mobile
node are advertised through Router Advertisement messages [RFC4861].
When an MN attaches an Access Router(AR), the AR requests one or more
prefixes for the MN from an external server. When the MN detaches
the AR, the prefixes should be released. When an operator wants to
renumber its network, prefixes with different lifetime are advertised
to the MN.
Diameter/Radius prefix authorization application can be the mechanism
to deal with how AR acquires and manages these prefixes.
4.2. Prefix Management in Local Mobility Anchors
[I-D.ietf-netlmm-proxymip6] enables mobility support to a host
without requiring its participation in any mobility related
signaling. Currently, only point-to-point access link is supported
which assumes that the mobile node and the Mobile Access Gateway
(MAG) are the only two nodes on the access link. Figure 1 shows a
typical process for MN to request it's home network prefix(es).
MN MAG LMA Server
|------>| | | 1. RtSol
| |------->| | 2. PBU (HNP=0)
| | |<------>| 3. Prefix Exchange
| |<-------| | 4. PBA (HNPs)
|<------| | | 5. RA(HNPs)
Figure 1: Prefix Authorization in Proxy Mobile IPv6
1. An MN solicits a router advertisement (RtSol) for stateless
address configuration.
2. The Mobile Access Gateway (MAG) sends Proxy Binding Update (PBU)
message to Local Mobility Anchor (LMA) and with Home Network
Prefix (HNP) to zero.
Sarikaya & Xia Expires January 7, 2009 [Page 5]
Internet-Draft PS:Diameter Prefix Authorization July 2008
3. No details are provided in [I-D.ietf-netlmm-proxymip6] on how LMA
manages prefixes. This is one of the motivations to design a
Diameter/Radius application for prefix authorization.
4. The LMA replies PBU with Proxy Binding Acknowledgement (PBA) and
sets MN's prefixes to HNP field of PBA.
5. MAG advertises prefixes to MN with Router Advertisement (RA) for
stateless address configuration.
4.3. Prefix Management for Mobile Routers
[I-D.ietf-nemo-prefix-delegation] specifies mechanism for a Mobile
Router(MR) to synchronize its Mobile Network Prefixes with its Home
Agents and obtain new ones dynamically. Figure 2 shows the process
that a Mobile Router requests prefixes from a Home Agent.
MR HA Server
| | |
|------->| | 1. BU
| | |
| |<------>| 2. Prefix Exchange
| | |
|<-------| | 3. BA
| | |
Figure 2: Prefix Delegation in NEMO
1. Mobile Network Prefix request option defined in
[I-D.ietf-nemo-prefix-delegation] is included in the Binding
Update(BU) to indicate to the Home Agent(HA) that the MR wishes
to get new prefixes assigned to it for use as Mobile Networks
Prefixes.
2. The HA requests prefix from an external entity. There is no
further description in [I-D.ietf-nemo-prefix-delegation]. The
problem can also be solved by defining a new Diameter/Radius
application.
3. Mobile Network Prefix Confirm option defined in
[I-D.ietf-nemo-prefix-delegation] is included in the Binding
Acknowledgement to allocate prefixes to the MR.
Mobile Network Prefix Confirm option carries the prefix lifetime.
Prefixes can be refreshed either by MR sending a BU or by HA sending
a BA.
Sarikaya & Xia Expires January 7, 2009 [Page 6]
Internet-Draft PS:Diameter Prefix Authorization July 2008
5. Requirements on AAA-based Prefix Authorization Application
AAA-based prefix authorization (PA) application MUST run between a
NAS, located on AR, LMA, MR, etc. and an AAA server.
AAA-based PA application MUST support the AAA client to request
prefixes from an AAA server. AAA-based PA application MUST support
the client to give back the prefixes to the AAA server.
If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices
on the network, the certificate or the information needed to obtain a
certificate SHOULD also be sent by the AAA server to NAS.
In point-to-point link operation, the NAS MUST identify the interface
of MN in its request. The NAS MAY provide a prefix hint, e.g. of
length /48 to which the AAA server MUST reply with one or more
prefixes, e.g. of length /64.
In point-to-point operation, the AAA server MAY assign the prefix(es)
and related parameters such as the lifetime and the certificates to
MN from MN's profile.
AAA-based prefix authorization application SHOULD support prefix
release procedures.
The NAS is responsible for renewing the prefixes when the lifetime
expires. The NAS SHOULD be able to extend the lifetime of the
prefixes using messages designed for this purpose.
It SHOULD be possible to renumber the prefixes authorized by AAA
server. The AAA server SHOULD initiate prefix renumbering process.
6. Security Considerations
This document is a problem statement that does not by itself
introduce any security issues.
7. IANA Considerations
None.
8. Acknowledgements
TBD.
Sarikaya & Xia Expires January 7, 2009 [Page 7]
Internet-Draft PS:Diameter Prefix Authorization July 2008
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.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
9.2. Informative references
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
[I-D.ietf-nemo-prefix-delegation]
Kniveton, T. and P. Thubert, "Mobile Network Prefix
Delegation", draft-ietf-nemo-prefix-delegation-02 (work in
progress), August 2007.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
Sarikaya & Xia Expires January 7, 2009 [Page 8]
Internet-Draft PS:Diameter Prefix Authorization July 2008
May 2008.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
Sarikaya & Xia Expires January 7, 2009 [Page 9]
Internet-Draft PS:Diameter Prefix Authorization July 2008
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Sarikaya & Xia Expires January 7, 2009 [Page 10]
Internet-Draft PS:Diameter Prefix Authorization July 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.
Sarikaya & Xia Expires January 7, 2009 [Page 11]