< draft-lior-radius-prepaid-extensions-03.txt   draft-lior-radius-prepaid-extensions-04.txt >
Network Working Group A. Lior Network Working Group A. Lior
INTERNET-DRAFT Bridgewater Systems INTERNET-DRAFT Bridgewater Systems
Category: Informational P. Yegani Category: Informational P. Yegani
draft-lior-radius-prepaid-extensions-03.txt Cisco draft-lior-radius-prepaid-extensions-04.txt Cisco
Expires: 16 July, 2004 K. Chowdhury Expires: 14 January, 2005 K. Chowdhury
Nortel Nortel
L. Madour
Ericsson Canada
Y. Li Y. Li
Bridgewater Systems Bridgewater Systems
February 16, 2003 July 14, 2004
PrePaid Extensions to Remote Authentication Dial-In User Service PrePaid Extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of [RFC2026]. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2005
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
RADIUS Extensions for PrePaid February 2004
The draft presents an extension to the Remote Authentication Dial-In The draft presents an extension to the Remote Authentication Dial-In
User Service (RADIUS) protocol to support PrePaid data services for User Service (RADIUS) protocol to support PrePaid data services for
a wide range of deployments such as Dial, Wireless, WLAN. a wide range of deployments such as Dial, Wireless, WLAN.
Consideration for roaming using mobile-ip is also given. Consideration for roaming using mobile-ip is also given.
RADIUS Extensions for PrePaid February 2004
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1 Terminology................................................6 1.1 Terminology................................................6
1.2 Requirements language......................................6 1.2 Requirements language......................................6
2. Architectural Model............................................6 2. Architectural Model............................................6
2.1 Why not existing RADIUS attributes?.......................14 2.1 Why not existing RADIUS attributes?.......................12
3. Use-cases.....................................................16 3. Use-cases.....................................................14
3.1 Simple pre-paid access use-case...........................17 3.1 Simple pre-paid access use-case...........................15
3.2 Simple Service Device use-case............................20 3.2 Support for concurrent PrePaid sessions...................17
3.3 Support for concurrent PrePaid sessions...................20 3.3 Support for Roaming.......................................18
3.4 Support for Roaming.......................................21 3.4 PrePaid termination.......................................19
3.5 PrePaid termination.......................................22 4. Operations....................................................19
4. Operations....................................................22 4.1 General Requirements......................................19
4.1 General Requirements......................................22 4.1.1 Broker AAA Requirements..............................19
4.1.1 Broker AAA Requirements..............................22 4.2 Authentication and Authorization for Prepaid Enabled Service
4.2 Authentication and Authorization for Prepaid Enabled Access Access Devices................................................20
Devices.......................................................23 4.2.1 Multiple-Session Pre-paid............................22
4.2.1 Single Service Pre-paid..............................24 4.3 Session Start Operation...................................22
4.2.2 Multiple-Session Pre-paid............................25 4.4 Mid-Session Operation.....................................23
4.3 Session Start Operation...................................27 4.5 Dynamic Operations........................................25
4.4 Mid-Session Operation.....................................28 4.5.1 Unsolicited Session Termination Operation............25
4.5 Dynamic Operations........................................30 4.5.2 Unsolicited Change of Authorization Operation........26
4.5.1 Unsolicited Session Termination Operation............30 4.6 Termination Operation.....................................27
4.5.2 Unsolicited Change of Authorization Operation........31 4.7 Mobile IP Operations......................................27
4.6 Termination Operation.....................................32 4.8 Accounting Considerations.................................28
4.7 Mobile IP Operations......................................32 4.9 Service Device Operation..................................29
4.8 Accounting Considerations.................................33 4.10 Interoperability with Diameter Credit Control Application29
4.9 Service Device Operation..................................33 5. Attributes....................................................29
4.10 Interoperability with Diameter Credit Control Application34 5.1 PPAC Attribute............................................29
5. Attributes....................................................34 5.2 Session Termination Capability............................31
5.1 PPAC Attribute............................................34 5.3 PPAQ Attribute............................................31
5.2 Session Termination Capability............................36 5.4 Table of Attributes.......................................36
5.3 PPAQ Attribute............................................36 6. Security Considerations.......................................36
5.4 Table of Attributes.......................................40 6.1 Authentication and Authorization..........................36
6. Security Considerations.......................................41 6.2 Replenishing Procedure....................................36
6.1 Authentication and Authorization..........................41 7. IANA Considerations...........................................36
6.2 Replenishing Procedure....................................41 8. Normative References..........................................37
7. IANA Considerations...........................................41
8. Normative References..........................................41
Acknowledgments..................................................42
Author's Addresses...............................................42
Intellectual Property Statement..................................43
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
Full Copyright Statement.........................................43 Acknowledgments..................................................37
Expiration Date..................................................44 Author's Addresses...............................................38
Intellectual Property Statement..................................38
Disclaimer of Validity...........................................39
Copyright Statement..............................................39
Expiration Date..................................................39
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
1. Introduction 1. Introduction
This draft describes RADIUS protocol extensions supporting PrePaid This draft describes RADIUS protocol extensions supporting PrePaid
Data Services. Data Services.
PrePaid data services are cropping up in many wireless and wireline PrePaid data services are cropping up in many wireless and wireline
based networks. A PrePaid Data Service subscriber is one that based networks. A PrePaid Data Service subscriber is one that
purchases a contract to deliver a data service for either a period purchases a contract to receive a data service for either a period
of time, or a quantity of data. Before providing a prepaid data of time, or a quantity of data. Before providing a prepaid data
service, the service provider checks that the prepaid subscriber has service, the service provider checks that the prepaid subscriber has
sufficient funds to cover the particular service request. Only after sufficient funds to cover the particular service request. Only after
confirmation that funds are available is the service provided to the confirmation that funds are available is the service provided to the
user. user.
The subscriber purchases the Data Service using various means such The subscriber purchases the Data Service using various means such
as buying a PrePaid Card, or online. How the subscriber purchases as buying a PrePaid Card, or online. How the subscriber purchases
their PrePaid Data Service depends on the deployment and is not in their PrePaid Data Service depends on the deployment and is not in
scope for this document. scope for this document.
In some deployments, the PrePaid data service will be combined with In some deployments, the PrePaid data service will be combined with
other Prepaid services such as PrePaid voice service. This is not other Prepaid services such as PrePaid circuit voice service. This
an issue for this document other than the fact that the PrePaid Data is not an issue for this document other than the fact that the
Services described in this paper should work with other PrePaid data PrePaid Data Services described in this paper should work with other
and or voice services. PrePaid data and or circuit voice services.
The fundamental business driver for a carrier to provide PrePaid The fundamental business driver for a carrier to provide PrePaid
data services is to increase participation (subscriber base) and data services is to increase participation (subscriber base) and
thus to increase revenues. Therefore, it makes sense that PrePaid thus to increase revenues. Therefore, it makes sense that PrePaid
services meet the following goals: services meet the following goals:
- Leverage existing infrastructure, hence reducing capital - Leverage existing infrastructure, hence reducing capital
expenditures typically required when rolling a new service; expenditures typically required when rolling out a new service;
- Ability to rate service requests in real-time; - Ability to rate service requests in real-time;
- Ability to check that the end userÆs account for coverage for the - Ability to check that the end userÆs account for coverage for the
requested service charge prior to execution of that service; requested service charge prior to execution of that service;
- Protect against revenue loss, i.e., prevent an end user from - Protect against revenue loss, i.e., prevent an end user from
generating chargeable events when the credit of that account is generating chargeable events when the credit of that account is
exhausted or expired; exhausted or expired;
- Protect against fraud; - Protect against fraud;
- Be as widely deployable over Dialup, Wireless and WLAN networks. - Be as widely deployable over Dialup, Wireless and WLAN networks.
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
skipping to change at page 6, line 9 skipping to change at page 6, line 9
an entity behind this AAA server. Finally, the details of the an entity behind this AAA server. Finally, the details of the
PrePaid System, such as its persistent store, how it maintains its PrePaid System, such as its persistent store, how it maintains its
accounts are not covered at all. However, in order to define the accounts are not covered at all. However, in order to define the
RADIUS protocol extensions it is necessary to discuss the functional RADIUS protocol extensions it is necessary to discuss the functional
behavior of the PrePaid System. behavior of the PrePaid System.
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
1.1 Terminology 1.1 Terminology
Access Device Service Access Device
PrePaid Client PrePaid Client
PrePaid Server PrePaid Server
Home agent (HA) Home agent (HA)
Home network Home network
Home AAA (HAAA) Home AAA (HAAA)
Broker AAA (BAAA) Broker AAA (BAAA)
Visited AAA (VAAA) Visited AAA (VAAA)
Foreign Agent (FA) Foreign Agent (FA)
WLAN WLAN
Service Device Service Device
Service Event
1.2 Requirements language 1.2 Requirements language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
2. Architectural Model 2. Architectural Model
The architectural model supports prepaid clients on either an access The architectural model supports prepaid clients on a service access
device or a service device. An access device (e.g. a NAS) typically device. A service access device (e.g. a NAS) typically provides a
provides a single service to end-users, corresponding to network access to data service to end-users. A service access device in an
access. The service device enables finer grain services to be entity on the data path that includes a RADIUS client.
defined. For example, a service may be defined for access to a
particular destination network, which enables further segmentation
of services within the network. An access device and service device
may be combined into a single physical entity.
When pre-paid service is used the access or service device collects When pre-paid service is used the service access device collects
service event information and reports it while and/or after services service event information and reports it while and/or after services
are provided to the prepaid user. This event information is sent to are provided to the prepaid user. This event information is sent to
a prepaid server by using the prepaid RADIUS extensions. a prepaid server by using the prepaid RADIUS extensions.
If real-time credit control is required, the access or service If real-time credit control is required, the service access device
device (prepaid client) contacts the prepaid server with service (prepaid client) contacts the prepaid server with service event
event information included before the service is provided. The information included before the service is provided. The prepaid
prepaid server, depending on the service event information, performs server, depending on the service event information, performs credit
credit check and allocates a portion of available credit to the check and allocates a portion of available credit to the service
event. The rating entity converts this credit value into a time
and/or volume amount, which is then returned to the requesting
service access device. The rating entity may determine that during
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
service event. The rating entity converts this credit value into a the allocated quota, a tariff switch will occur in which case the
time and/or volume amount, which is then returned to the requesting rating entity will include details of the quota allocated prior to
device. The rating entity may determine that during the allocated the tariff switch, details of the quota allocated after the tariff
quota, a tariff switch will occur in which case the rating entity switch together with details of when the tariff switch will occur.
will include details of the quota allocated prior to the tariff
switch, details of the quota allocated after the tariff switch
together with details of when the tariff switch will occur.
The requesting device (either access or service device) then The requesting service access device then monitors service execution
monitors service execution according to the instructions returned by according to the instructions returned by the prepaid server. After
the prepaid server. After service completion or on a subsequent service completion or on a subsequent request for service, the
request for service, the prepaid server deducts the reserved prepaid server deducts the reserved allocation of credit from the
allocation of credit from the prepaid userÆs account. prepaid userÆs account.
Similarly, when a user terminates an on-going prepaid service, the Similarly, when a user terminates an on-going prepaid service, the
prepaid client signals the prepaid server with the a value prepaid client signals the prepaid server with the a value
corresponding to the unused portion of the allocated quota. The corresponding to the unused portion of the allocated quota. The
prepaid server is then able to refund unused allocated funds into a prepaid server is then able to refund unused allocated funds into a
userÆs prepaid account. userÆs prepaid account.
There MAY be multiple prepaid servers in the system for reasons of There MAY be multiple prepaid servers in the system for reasons of
redundancy and load balancing. The system MAY also contain separate redundancy and load balancing. The system MAY also contain separate
rating server(s) and accounts MAY locate in a centralized database. rating server(s) and accounts MAY be located in a centralized
System internal interfaces can exist to relay messages between database. System internal interfaces can exist to relay messages
servers and an account manager. However the detailed architecture between servers and an account manager. However the detailed
of prepaid system and its interfaces are implementation specific and architecture of prepaid system and its interfaces are implementation
are out of scope of this specification. specific and are out of scope of this specification.
accounting accounting
+------------+ +-----------+ protocol +--------------+ +------------+ +-----------+ protocol +--------------+
| Access |<----->| Service |<------------>| Accounting | | Subscriber |<----->| Service | | |
| Device | +-->| Device |<-----+ | Server | | | | Access |<------------>| Accounting |
+------------+ | +-----------+ | +--------------+ | Device | | Device |<-----+ | Server |
| | +------------+ +-----------+ | +--------------+
+------------+ | | |
| Access |<--+ | +--------------+ |
| Device | +------>| PrePaid | | +--------------+
+------------+ prepaid | Server | +------>| PrePaid |
prepaid | Server |
protocol +--------------+ protocol +--------------+
Figure 1 Basic Prepaid Architecture Figure 1 Basic Prepaid Architecture
RADIUS Extensions for PrePaid February 2004
The prepaid server and accounting server in this architecture model The prepaid server and accounting server in this architecture model
are logical entities. The real configuration MAY combine them into a are logical entities. The real configuration MAY combine them into a
single host. single host.
RADIUS Extensions for PrePaid February 2004
There MAY exist protocol transparent RADIUS Proxies between prepaid There MAY exist protocol transparent RADIUS Proxies between prepaid
client and prepaid server. These proxies transparently support the client and prepaid server. These proxies transparently support the
prepaid RADIUS extensions. prepaid RADIUS extensions.
In order to generalize the solution, in this paper we generalize the In order to generalize the solution, in this paper we generalize the
Access Devices, which in reality may be a NAS from in Dialup Service Access Devices, which in reality may be a NAS in Dialup
deployments, PDSN in CDMA2000 deployments,an 802.11 WLAN Access deployments, PDSN (Packet Data Serving Node) or HA (Home Agent) in
Points or GGSN in GSM deployments. To actively participate in CDMA2000 deployments, an 802.11 WLAN Access Points or GGSN (Gateway
Prepaid procedures outlined here, the Access Device MUST have GPRS Serving Node) in GPRS/UMTS deployments. To actively participate
Prepaid Client capabilities. Prepaid Client Capabilities include in Prepaid procedures outlined here, the Service Access Device MUST
the ability to meter the usage for a prepaid data session; this have the Prepaid Client capabilities. Prepaid Client Capabilities
usage includes time or volume usage. include the ability to meter the usage for a prepaid data session;
this usage includes time or volume (e.g. number of bytes) usage.
In circumstances when the Access Device does not support the Prepaid In the case of roaming scenarios using mobile IP (in a wireless or
client capabilities, prepaid client functionality may be provided wireline network), the prepaid client functionality may be delegated
using either a stand alone service device or, in the case of roaming to the Home Agent. It may also be possible to deliver limited
scenarios using mobile IP, the prepaid client functionality may be prepaid services using RADIUS capabilities specified in RFC2865 and
delegated to the Home Agent. It may also be possible to deliver RFC2866.
limited prepaid services using RADIUS capabilities specified in
RFC2865 and RFC2866.
Furthermore, the device including the prepaid client functionality Furthermore, the device including the prepaid client functionality
may also have Dynamic Session Capabilities that include the ability may also have Dynamic Session Capabilities that include the ability
to terminate a data session and/or change the filters associated to terminate a data session and/or change the filters associated
with a specific data session by processing Disconnect Messages and with a specific data session by processing Disconnect Messages and
Change of Filter messages as per [RFC3576]. Change of Authorization messages as per [RFC3576].
In this document RADIUS is used as the AAA server. There are three In this document RADIUS is used as the AAA server. There are three
kinds or categories of AAA servers. The AAA server in the home kinds or categories of AAA servers. The AAA server in the home
network, the HAAA, is responsible for authentication of the network, the HAAA, is responsible for authentication of the
subscriber and also authorization of the service. In addition, the subscriber and also authorization of the service. In addition, the
HAAA communicates with the Prepaid servers using the RADIUS protocol HAAA communicates with the Prepaid servers using the RADIUS protocol
to authorize prepaid subscribers. In AAA based roaming deployments to authorize prepaid subscribers. In AAA based roaming deployments
the AAA server in the visited network, the VAAA, is responsible for the AAA server in the visited network, the VAAA, is responsible for
forwarding the RADIUS messages to the HAAA. The VAAA may also forwarding the RADIUS messages to the HAAA. The VAAA may also
modify the messages. In roaming deployments, the visited network modify the messages. In roaming deployments, the visited network
may be separated from the home network by one or more broker may be separated from the home network by one or more broker
networks. The AAA servers in the broker networks, BAAA are networks. The AAA servers in the broker networks, BAAA are
responsible to route the RADIUS packets transparently and hence
donÆt play an active roll in the Prepaid Data Service delivery.
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
responsible to route the RADIUS packets and hence donÆt play an
active roll in the Prepaid Data Service delivery.
In this document the Prepaid Server is described in functional terms In this document the Prepaid Server is described in functional terms
related to their interface with the HAAA. The Prepaid Server related to their interface with the HAAA. The Prepaid Server
interfaces to entities which: interfaces to entities which:
i) Keep the accounting state of the prepaid subscribers (balance i) Keep the accounting state of the prepaid subscribers (balance
manager); manager);
ii) Allow service requests to be rated in real-time (Rating Engine); ii) Allow access service requests to be rated in real-time (Rating
and Engine); and
iii) Allow quota to be managed for a particular pre-paid service iii) Allow quota to be managed for a particular pre-paid service
(Quota Server). (Quota Server).
The various deployments for Prepaid are presented in the remainder The various deployments for Prepaid are presented in the remainder
of this section. The first deployment is the basic Prepaid data of this section. The first deployment is the basic Prepaid data
service and is depicted in figure 2. Here the Access Device which service and is depicted in figure 2. Here the Service Access Device
supports the prepaid client functionality, the HAAA and the Prepaid which supports the prepaid client functionality, the HAAA and the
Server are collocated in the same provider network. Prepaid Server are collocated in the same provider network.
The Subscriber Device establishes a connection with one of several The Subscriber Device establishes a connection with one of several
Access Devices in the network. The Access Device communicates with Access Devices in the network. The Service Access Device
one or more HAAA servers in the network. To provide redundancy more communicates with one or more HAAA servers in the network. To
then one HAAA is available to use by an Access Device. provide redundancy more than one HAAA may be available to use by a
Service Access Device.
The network will have one or more Prepaid Servers. Multiple Prepaid The network will have one or more Prepaid Servers. Multiple Prepaid
Servers will be used to provide redundancy and load sharing. The Servers may be used to provide redundancy and load sharing. The
interface between the HAAA and the PPS is the RADIUS protocol in interface between the HAAA and the PPS is implemented using the
this specification. However, in cases where the PPS does not RADIUS protocol in this specification. However, in cases where the
implement the RADIUS protocol, the implementation would have to map PPS does not implement the RADIUS protocol, the implementation would
the requirements defined in this document to whatever protocol is have to map the requirements defined in this document to whatever
used between the HAAA and the PPS. protocol is used between the HAAA and the PPS.
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
+------+ +-----+ +------+ +-----+
| | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | | | | | | | | | | | |
| Sub | | Access | | +------+ | +-----+ | Sub | | Service| | +------+ | +-----+
| |---| |--+ | | |---| Access |--+ |
| Device | | Device | | +------+ | +-----+ | Device | | Device | | +------+ | +-----+
| | | | | | | | | | | | | | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | |
+------+ +-----+ +------+ +-----+
Figure 2 Basic Prepaid Access Architecture Figure 2 Basic Prepaid Access Architecture
In the second deployment scenario, the Access Device does not Figure 3 shows a static roaming prepaid architecture that is typical
support the prepaid client functionality. Instead an independent of a wholesale scenario for Dial-Up users or a broker scenario used
Service Device provides prepaid client functionality as depicted in in Dial-Up or WLAN roaming scenarios.
figure 3. Here the Access Device which dose not supports the
prepaid client functionality is configured as AAA client to the AAA
proxy functionality in the Service Device. The Service device, which
supports the prepaid client functionality then appends prepaid
extensions in the AAA requests proxied to the HAAA.
The Subscriber Device establishes a connection with one of several
Access Devices in the network. The Authentication and Authorization
requests from the Access Device are proxied through the Service
Device which then appends prepaid extensions on to the requests. The
Service Device communicates with one or more HAAA servers in the
network. The Service Device is responsible for removing prepaid
extensions from messages received from the HAAA before proxying them
on to the Access Device. To provide redundancy more then one
Service Devices are available to use by an Access Device and more
than one HAAA is available for use by the Service Device. The
Service Device is configured to be default gateway to the Access
Device, enabling all traffic to be correctly metered.
RADIUS Extensions for PrePaid February 2004
(AAA) +---------+ +------+ +-----+
+------------| Service | | | | |
+--------+ | | |--+--| HAAA |--+--| PPS |
| | +--------+ +--| Device | | | | | | |
| Sub | | Access | (IP)| +---------+ | +------+ | +-----+
| |---| |-----+ | |
| Device | | Device | | +---------+ | +------+ | +-----+
| | +--------+ +--| Service | | | | | | |
+--------+ | | |--+--| HAAA |--+--| PPS |
+------------| Device | | | | |
AAA) +---------+ +------+ +-----+
Figure 3 Prepaid Service Architecture
The following figure 4 shows a static roaming prepaid architecture
that is typical of a wholesale scenario for Dial-Up users or a
broker scenario used in Dial-Up or WLAN roaming scenarios.
+----+ +----+ +----+ +-----+ +----+ +----+ +----+ +-----+
| | | | | | | | | | | | | | | |
+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Sub | |Access| | +----+ | +----+ | +----+ | +-----+ |Sub | |Service| | +----+ | +----+ | +----+ | +-----+
| |--| |-+ | | | | |--|Access |-+ | | |
|Device| |Device| | +----+ | +----+ | +----+ | +-----+ |Device| |Device | | +----+ | +----+ | +----+ | +-----+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | |
+----+ +----+ +----+ +-----+ +----+ +----+ +----+ +-----+
| Visited | |Broker | | Home | | Visited | |Broker | | Home |
| Network | |Network| | Network | | Network | |Network| | Network |
Figure 4 Static Roaming Prepaid Architecture Figure 3 Static Roaming Prepaid Architecture
As in the basic prepaid architecture the subscriberÆs device As in the basic prepaid architecture the subscriberÆs device
establishes a connection with the Access Device (NAS, WLAN Access establishes a connection with the Service Access Device (NAS, WLAN
Point). The Access Device communicates with the Visiting AAA server Access Point). The Service Access Device communicates with the
(VAAA) using the RADIUS protocol. Again for redundancy there maybe Visiting AAA server (VAAA) using the RADIUS protocol. Again for
more then one VAAA. The VAAA communicate using the RADIUS protocol redundancy there maybe more then one VAAA. The VAAA communicate
with AAA servers in the broker network (BAAA). There maybe more using the RADIUS protocol with AAA servers in the broker network
then one Broker Network between the Visited Network and the Home (BAAA). There maybe more then one Broker Network between the
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
Network. The Home Network is the same as in the simple Visited Network and the Home Network. The Home Network is the same
architecture. as in the simple architecture.
To support dynamic roaming the network will utilize mobile-ip. To support dynamic roaming the network will utilize Mobile-Ip as
Figure 5 illustrates a typical mobile-ip deployment. Note that illustrated in Figure 4. Note that typically the mobile device
typically the mobile device would be moving between networks that would be moving between networks that use the same technology such
use the same technology such as Wireless or WLAN. Increasingly, as Wireless or WLAN. Increasingly, device will be able to roam
device will be able to roam between networks that use different between networks that use different technology such as between WLAN
technology such as between WLAN and Wireless and Broadband. and Wireless and Broadband. Fortunately, Mobile-Ip can address this
Fortunately, mobile-ip can address this type of roaming and type of roaming and therefore we need not be concerned with the
therefore we need not be concerned with the underlying network underlying network technology.
technology.
+------+ +------+ +----+ +----+ +----+ +-----+ +------+ +-------+ +----+ +----+ +----+ +-----+
| | | | | | | | | | | | | | |Service| | | | | | | | |
|Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS | |Sub | |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS |
| |--|Device| | | | | | | | | | |--|Device | | | | | | | | |
|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
| | | | | | | | | | | |
+------+ +------+ | | +------+ +------ + | |
| | | +----+ | | | +----+
| | | | | | | | | |
|ROAMS +------------------+ HA | |ROAMS +------------------+ HA |
| | | | | | | |
V +----+ | +----+ V +----+ | +----+
+------+ +------+ | | | | +------+ +-------+ | | | |
| | | | +-|VAAA+------+ | | | |Service| +-|VAAA+------+ |
|Sub | |Access| | | | | |Sub | |Access | | | | |
| |--|Device+-+ +----+ | | |--|Device +-+ +----+ |
|Device| | (FA) | | |Device| | (FA) | |
| | | +------------------------+ | | | +------------------------+
+------+ +------+ +------+ +-------+
Figure 5 Roaming using mobile-ip and pre-paid enabled Access Figure 4 Roaming using Mobile-IP and pre-paid enabled Service
Devices Access Devices
In figure 5, the Subscriber device establishes a prepaid session In figure 4, the Subscriber device establishes a prepaid session
between the Access Device in the foreign network, which has prepaid between the Service Access Device in the foreign network, which has
capabilities and the Home Agent (HA). The setup for this service is prepaid capabilities. The subscriberÆs home address will be
identical to the cases covered above. Notice that the Access Device anchored at the Home Agent (HA) in the home network. The setup for
is known as the Foreign Agent (FA). As the subscriber device moves this access service is identical to the cases covered above. Notice
that the Service Access Device may be collocated with the Foreign
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
to another network it establishes a connection with another Access Agent (FA) in case of Mobile-IPv4. As the subscriber device moves
Device in another foreign network. The prepaid data service should it establishes a connection with another Service Access Device in
continue to be available. When a device associates to another the same foreign network or in another foreign network. The prepaid
Access Device it MUST re-authenticate at the new Access Device and data service should continue to be available. When a device
de-associate or logoff the old Access Device. Furthermore, any associates to another Service Access Device it MUST re-authenticate
unused quota at the old Access Device MUST be promptly credited back at the new Service Access Device and de-associate or logoff from the
to the subscribers account. The reason we say promptly, is because old Service Access Device. Furthermore, any unused quota at the old
if the subscriber is very low on resources to start with, the Service Access Device MUST be promptly credited back to the
subscriber may not have enough resources to log on to the new Access subscribers account. The reason we say promptly, is because if the
subscriber is very low on resources to start with, the subscriber
may not have enough resources to log on to the new Service Access
Device. The speed at which resources can be returned depend on the Device. The speed at which resources can be returned depend on the
type of handoff procedure that is used: dormant handoff vs. active type of handoff procedure that is used. Some of the example of
handoff vs. fast handoff. handoffs in wireless networks are dormant handoff, active handoff
and fast handoff.
As well, notice that if the Access Devices could communicate with
each other then there could be a way to accelerate a faster handoff
procedure. In particular, it could accelerate the return of the
unused portion of the quotas from the old Access Device.
Unfortunately, standards are evolving with each network technology
creating their own scheme to make the handoff procedures more
efficient.
Finally, pre-paid service may be provided in a roaming scenario
where the Access Devices do not support the prepaid client
capabilities. In such a scenario, a Service Device is configured as
AAA proxy to the Home Agent and also as default gateway for the home
agent, see Figure 6.
RADIUS Extensions for PrePaid February 2004
+------+ +------+ +----+ +----+ +----+ As well, notice that if the Service Access Devices could communicate
| | | | | | | | | | with each other then there could be a way to accelerate a faster
|Sub | |Access+---|VAAA|-|BAAA|----------------| | handoff procedure. In particular, it could accelerate the return of
| |-|Device| | | | | | | the unused portion of the quotas from the old Access Device.
|Device| | (FA) +-+ +----+ +-+--+ (AAA) | |
| | | | | | +---------+ |HAAA|
+------+ +------+ | | | | | |
| | | +----+ +---+ | | +-----+
| | (IP) | | |(IP)|Ser| | | | |
|ROAMS +-------------+ HA |----| |--| |--| PPS |
| | | | |Dev| | | | |
V +----+ | +----+ +---+ +----+ +-----+
+------+ +------+ | | | |
| | | | +-|VAAA+---+ |
|Sub | |Access| | | | |
| |-|Device+-+ +----+ |
|Device| | (FA) | (IP) |
| | | +-----------------+
+------+ +------+
Figure 6 Roaming using mobile-ip and prepaid enabled Service Unfortunately, standards with regards to handoff are evolving with
Device behind the Home Agent. each network technology creating their own scheme to make the
handoff procedures more efficient.
2.1 Why not existing RADIUS attributes? 2.1 Why not existing RADIUS attributes?
It has been asked ôWhy not use existing RADIUS attributes to build a It has been asked ôWhy not use existing RADIUS attributes to build a
prepaid solution? This will allow us to have a solution with prepaid solution? This will allow us to have a solution with
existing devices without code modification.ö existing devices without code modification.ö
It is possible to build a prepaid solution using existing RADIUS It is possible to build a prepaid solution using existing RADIUS
attributes. The RADIUS server can simply send an Access-Accept attributes. The RADIUS server can simply send an Access-Accept
message containing Session-Timeout(27) and set Termination- message containing Session-Timeout(27) and set Termination-
Action(29) to RADIUS-request. Upon receiving the Access-Accept Action(29) to RADIUS-request. Upon receiving the Access-Accept
message, the NAS will time the session and upon termination of the message, the NAS will meter the duration of the session and upon
session the NAS generate an Access-Request message again. The termination of the session the NAS generate an Access-Request
RADIUS server would re-authenticate the session and reply with an message again. The RADIUS server would re-authenticate the session
Access-Accept message with additional time in Session-Timeout(27) or and reply with an Access-Accept message with additional time in
an Access-Reject message if there were no more resources in the Session-Timeout(27) or an Access-Reject message if there were no
userÆs account. more resources in the userÆs account.
RADIUS Extensions for PrePaid February 2004
If the user terminates the session before the time expressed in If the user terminates the session before the time expressed in
Session-Timeout(27). The NAS will recover any unused time from the Session-Timeout(27). The NAS will recover any unused time from the
accounting stream. accounting stream.
RADIUS Extensions for PrePaid February 2004
There are several problems with such a solution: There are several problems with such a solution:
-It only allows for time-based prepaid. The solution presented in -It only allows for time-based prepaid. The solution presented in
this document allows for both time and volume based prepaid. As this document allows for both time and volume based prepaid. As
well as extensibility for other features such as tarified based well as extensibility for other features such as tarified based
solutions. solutions.
-This solution only allows for prepaid based on Access. The
solution presented in this document allows the use of this protocol
to support prepaid solutions for other services not just Access.
-Using accounting messages to recoup unused time may be problematic -Using accounting messages to recoup unused time may be problematic
because RADIUS accounting messages are not real-time. A RADIUS because RADIUS accounting messages are not real-time. A RADIUS
server may store-and-forward accounting messages in batches. The server may store-and-forward accounting messages in batches. The
solution presented in this paper does not rely on Accounting Packets solution presented in this paper does not rely on Accounting Packets
at all. It uses Access-Request, messages which do flow through any at all. It uses Access-Request, messages which do flow through any
network in real-time. Delaying accounting messages may cause network in real-time. Delaying accounting messages may cause
revenue leakage. revenue leakage.
-Session-Timeout(27) is not a mandatory attribute. If a prepaid -Session-Timeout(27) is not a mandatory attribute. If a prepaid
subscriber is being serviced by a NAS that does not adhere to subscriber is being serviced by a NAS that does not adhere to
Session-Timeout then that subscriber will obtain unlimited service. Session-Timeout then that subscriber will obtain unlimited service.
-Termination-Action(29) presents its own issues. First the -Termination-Action(29) presents its own issues. First the
behaviour of Termination-Action(29) is not mandatory. Second, behaviour of Termination-Action(29) is not mandatory. Second,
according to RFC2865 Termination-Action fires when the Service is according to RFC2865 Termination-Action fires when the Service is
complete. But we should not be terminating the service we really complete. But we should not be terminating the service while
should only be terminating a session when we are negotiating negotiating additional quota. The refreshing of the time quota
additional quota. The refreshing of the time quota should be should be transparent to the user. Because Termination-Action
transparent to the user. Because Termination-Action occurs when the occurs when the Service is complete it is unclear whether or not the
Service is complete it is unclear whether or not the user experience user experience would be transparent. For example, will the RADIUS
would be transparent. For example, will the RADIUS server allocate server allocate the subscriber a new IP address? Furthermore, the
the subscriber a new IP address? Furthermore, the RADIUS server has RADIUS server has no way of telling why the Access-Request message
no way of telling why the Access-Request message was generated. The was generated. The RADIUS server will have to wait for the
RADIUS server will have to wait for the corresponding accounting corresponding accounting packet to determine the reason for this
packet to determine the reason for this Access-Request message. Access-Request message. Lastly re-authenticating the subscriber may
Lastly re-authenticating the subscriber may take far too long. The take far too long. The solution presented in this document allows
solution presented in this document allows quota replenishing to quota replenishing to occur in an undisruptive manner from the
occur in an undisruptive manner from the perspective of the user. perspective of the user. No re-authentication is required and
No re-authentication is required and quotas can be negotiated prior quotas can be negotiated prior to the quotas running out.
to the quotas running out.
RADIUS Extensions for PrePaid February 2004
-Prepaid ambiguity. Implementing prepaid using existing RADIUS -Prepaid ambiguity. Implementing prepaid using existing RADIUS
attributes presents another problem. Due to the fact that the attributes presents another problem. Due to the fact that the
RADIUS Extensions for PrePaid February 2004
standard RADIUS attributes are not mandatory, then the correct standard RADIUS attributes are not mandatory, then the correct
prepaid operation is really an act of faith on the part of the prepaid operation is really an act of faith on the part of the
RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) RADIUS server. If Session-Timeout(27) and/or Termination-Action(29)
are not supported, the prepaid subscriber will get free access. The are not supported, the prepaid subscriber will get free access. The
solution described in this document, requires that a prepaid capable solution described in this document, requires that a prepaid capable
NAS inform the RADIUS server whether or not it supports prepaid Service Access Device inform the RADIUS server whether or not it
capabilities. The RADIUS server can now determine whether service supports prepaid capabilities. The RADIUS server can now determine
should be granted or not. For example, if a prepaid subscriber is whether service should be granted or not. For example, if a prepaid
connected to a NAS that does not support prepaid, the RADIUS server subscriber is connected to a NAS that does not support prepaid, the
can either instruct the NAS to tunnel the traffic to a gateway that RADIUS server can either instruct the NAS to tunnel the traffic to
does support prepaid metering, or it may allow the subscriber on but another entity in the home network that does support prepaid client
restrict their traffic. function (e.g. Home Agent) or it may allow the subscriber to get
access but restrict the traffic.
The prepaid solution we present is a robust carrier grade prepaid The prepaid solution we present is a robust carrier grade prepaid
solution. It only requires the support of 2 mandatory attributes solution. It only requires the support of 2 mandatory attributes
and one optional attribute. Furthermore, it does not really and one optional attribute. Furthermore, it does not really
require much code support at the NAS. NASes already support require much code support at the NAS. NASes already support
measurement of time and volume. This solution requires that they measurement of time and volume. This solution requires that they
advertise their prepaid capabilities in an Access-Request; that they advertise their prepaid capabilities in an Access-Request; that they
generate an Access-Request Authorize-Only packet to obtain more generate an Access-Request Authorize-Only packet to obtain more
quota at or before the quota is used up. It also requires that the quota at or before the quota is used up. It also requires that the
NAS send an Access-Request with Authorize-Only when the session NAS send an Access-Request with Authorize-Only when the session
skipping to change at page 16, line 48 skipping to change at page 14, line 47
3. Use-cases 3. Use-cases
In this section we present a set of use cases that will help In this section we present a set of use cases that will help
establish the requirements needed to deliver PrePaid data services. establish the requirements needed to deliver PrePaid data services.
These use cases donÆt address how the PrePaid account is established These use cases donÆt address how the PrePaid account is established
or maintained. It is assumed that the PrePaid subscriber has or maintained. It is assumed that the PrePaid subscriber has
obtained a valid account from a service provider such as a wireless obtained a valid account from a service provider such as a wireless
operator or a WLAN operator. operator or a WLAN operator.
To make the document as general as possible, the use cases cover the To make the document as general as possible, the use cases cover the
experience from the Access Device and not from the UserÆs Device. experience from the Service Access Device and not from the UserÆs
The connection between the UserÆs Device, which typically involves Device. The connection between the UserÆs Device, which typically
involves setting up a layer 2 session, e.g., PPP session or GPRS PDP
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
setting up a layer 2 session, e.g., PPP session or GPRS PDP Context, Context, is specific to a given network technology and the details
is specific to a given network technology and the details are not are not required to deliver a PrePaid service.
required to deliver a PrePaid service.
3.1 Simple pre-paid access use-case 3.1 Simple pre-paid access use-case
A PrePaid subscriber connects to his home network. As usual, the A PrePaid subscriber connects to his home network. As usual, the
Access Device that is servicing the subscriber will use the AAA Access Device that is servicing the subscriber will use the AAA
infrastructure to authenticate and authorize the subscriber. infrastructure to authenticate and authorize the subscriber.
The Access Device sends a RADIUS Access-Request to the AAA system to The Service Access Device sends a RADIUS Access-Request to the AAA
authenticate the subscriber, and identify and authorize the service. system to authenticate the subscriber, and identify and authorize
The Access-Request includes the subscriberÆs credentials and may the service. The Access-Request includes the subscriberÆs
include the PrePaid capabilities of the Access Device. PrePaid credentials and may include the PrePaid capabilities of the Service
capabilities MUST be included if the Access Device supports PrePaid Access Device. PrePaid capabilities MUST be included if the Service
functionality. Access Device supports PrePaid functionality.
The AAA System proceeds with the authentication procedure. This may The AAA System proceeds with the authentication procedure. This may
involve several transactions such as in EAP. Once the subscriber involve several transactions such as in EAP [RFC2284]. Once the
has been validated, the AAA system determines that the subscriber is subscriber has been authenticated, the AAA system determines that
a PrePaid subscriber and requests that the PrePaid System authorize the subscriber is a PrePaid subscriber and requests that the PrePaid
the PrePaid subscriber. The request MUST include the PrePaid System authorize the PrePaid subscriber. The request MUST include
Capabilities of the serving Access Device. These capabilities will the PrePaid Capabilities of the serving Service Access Device.
include whether the Access Device support optional granular prepaid
service. Granular prepaid service allows an Access Device to offer
service differentiation above plain network access, for example
discriminating between a prepaid service request for access to the
public Internet from access to a particular application server
hosted in the private domain of the home provider network. In the
simple prepaid access scenario, such capabilities are not required
to be supported by the Access Device.
The PrePaid System will validate that the subscriber has a PrePaid The PrePaid System will validate that the subscriber has a PrePaid
Account; it will validate that the account is active; and will Account; it will validate that the account is active; and will
validate that the Access Device has the appropriate PrePaid validate that the Service Access Device has the appropriate PrePaid
capabilities. If all is in order, the PrePaid System will authorize capabilities. If all is in order, the PrePaid System will authorize
the subscriber to use the network. Otherwise it will reject the the subscriber to use the network. Otherwise it will reject the
request. The response is sent back to the AAA System. The response request. The response is sent back to the AAA System. The response
includes attributes such as, definition of what services are includes attributes to indicate the allocation of a portion of the
RADIUS Extensions for PrePaid February 2004
authorized. The exact definition of the service may define vanilla
network access or more granular service definition. The exact
definition of these services is not the focus of this draft. This
definition MAY include a ôservice keyö which can be used to
correlate prepaid requests for access to a service with the service
definition in the prepaid system. Such service key information MUST
be included when the prepaid user has subscribed to more than one
prepaid service. If a user has subscribed to only a single service,
the response MAY also include an allocation of a portion of the
subscriberÆs account called the initial quota (in units of time or subscriberÆs account called the initial quota (in units of time or
volume) and optionally a threshold value. volume) and optionally a threshold value.
[Editor comments: we should leave tariff switch issues to another [Editor comments: we should leave tariff switch issues to another
document. One way to deal with a tariff switch is to set the document. One way to deal with a tariff switch is to set the
threshold or quota such that a new allocation is requested just threshold or quota such that a new allocation is requested just
before or at the tariff switch period.] before or at the tariff switch period.]
When the rating engine has determined that a tariff switch will When the rating engine has determined that a tariff switch will
shortly occur, the initial quota may be segmented into that which shortly occur, the initial quota may be segmented into that which
SHOULD be used before the tariff switch, that which SHOULD be used SHOULD be used before the tariff switch, that which SHOULD be used
RADIUS Extensions for PrePaid February 2004
after the tariff switch together with details describing the tariff after the tariff switch together with details describing the tariff
switching instant. switching instant.
The Access Device is responsible for requesting quota to be allocate The Access Device is responsible for requesting quota to be allocate
for a particular prepaid user. for a particular prepaid user.
[NEED A USE CASE FOR CONCURTENT PREPAID SESSIONS]
In order to support concurrent PrePaid sessions, at any time, the In order to support concurrent PrePaid sessions, at any time, the
PrePaid System allocates a portion of the subscribers account to a PrePaid System allocates a portion of the subscribers account to a
given PrePaid session. For example, in a multi-service environment given PrePaid session. For example, in a multi-service environment
it might happen that an end user with an already ongoing service it might happen that an end user with an already ongoing service
(e.g., browsing the Internet) issues a new service request (e.g., (e.g., browsing the Internet) issues a new service request (e.g.,
for downloading a ring-tone) towards the same account. Throughout for downloading a ring-tone) towards the same account. Throughout
the lifetime of a session the Access Device will monitor usage the lifetime of a session the Access Device will monitor usage
according to the quota(s) returned from the prepaid server and will according to the quota(s) returned from the prepaid server and will
request further quota updates from the PrePaid System as previously request further quota updates from the PrePaid System as previously
allocated quotas are consumed. Conditions may be included with allocated quotas are consumed. Conditions may be included with
quotas, which indicate when an allocated quota should be returned to quotas, which indicate when an allocated quota should be returned to
the prepaid system. These conditions can include an Idle-Timeout(28) the prepaid system. These conditions can include an Idle-Timeout(28)
associated with the provided quota. In this case, the Access device associated with the provided quota. In this case, the Access device
monitors the service for activity. When a single inactivity period monitors the service for activity. When a single inactivity period
exceeds that provided in the quota conditions, the unused quota is exceeds that provided in the quota conditions, the unused quota is
returned to the prepaid server. returned to the prepaid server.
RADIUS Extensions for PrePaid February 2004
The AAA system incorporates the PrePaid attributes received from the The AAA system incorporates the PrePaid attributes received from the
PrePaid System with the service attributes into an Access-Accept PrePaid System into an Access-Accept message that it sends back to
message that it sends back to the Access Device. Note the AAA the Service Access Device. Note the AAA System is responsible for
System is responsible for authorizing the service whereas the authorizing the service whereas the PrePaid System is responsible
PrePaid System is responsible for PrePaid authorization. for PrePaid authorization.
Upon receiving the Access-Response, the Access Device allows the Upon receiving the Access-Response, the Service Access Device allows
PrePaid data session to start and it starts to meter the session the PrePaid data session to start and it starts to meter the session
based on time or volume, as indicated in the returned Quota based on time or volume, as indicated in the returned Quota
Once the usage for the session approaches the allotted quota (as Once the usage for the session approaches the allotted quota (as
expressed by the threshold), the Access Device will request an expressed by the threshold), the Service Access Device will request
additional quota. The re-authorization for additional quota flows an additional quota. The re-authorization for additional quota
through the AAA system to the PrePaid System. The PrePaid System flows through the AAA system to the PrePaid System. The PrePaid
revalidates the subscriberÆs account; it will subtract the previous System revalidates the subscriberÆs account; it will subtract the
quota allocation from the userÆs balance and if there is a balance previous quota allocation from the userÆs balance and if there is a
remaining it will reauthorize the request with an additional quota balance remaining it will reauthorize the request with an additional
allotment. Otherwise, the PrePaid System will reject the request. quota allotment. Otherwise, the PrePaid System will reject the
Note the replenishing of the quotas is a re-authorization procedure
and does not involve re-authentication of the subscriber.
It is important to note that the PrePaid System is maintaining RADIUS Extensions for PrePaid February 2004
session state for the subscriber. This state includes how much was
allocated during the last quota allocation for a particular session
and how much is left in the account. Therefore, it is required that
all subsequent messages about the PrePaid session reach the correct
PrePaid System.
Upon receiving a re-allotment of the quota, the Access Device will, request. Note the replenishing of the quotas is a re-authorization
continue the data service session until the new threshold is procedure and does not involve re-authentication of the subscriber.
reached. If the request for additional quota cannot be fulfilled
then the Access Device will let the subscriber use up the remaining
quota and terminate the session.
Alternatively, instead of terminating the session, the Access Device It is important to note that the PrePaid System is maintaining
may restrict the data session such that the subscriber can only session state for the subscriber. This state includes how much
reach a particular web server. This web server maybe used to allow account balance was allocated during the last quota allocation for a
the subscriber to replenish their account. This restriction can particular session and how much is left in the account. Therefore,
also be used to allow new subscribers to purchase their initial it is required that all subsequent messages about the PrePaid
PrePaid Service. session reach the correct PrePaid System.
RADIUS Extensions for PrePaid February 2004 Upon receiving a re-allotment of the quota, the Service Access
Device will, continue the data service session until the new
threshold is reached. If the request for additional quota cannot be
fulfilled then the Service Access Device will let the subscriber use
up the remaining quota and terminate the session.
Should the subscriber terminate the session before the session the Alternatively, instead of terminating the session, the Service
quota is used up, the remaining balance allotted to the session must Access Device may restrict the data session such that the subscriber
be credited back to the subscriberÆs account. can only reach a particular web server. This web server maybe used
to allow the subscriber to replenish their account. This
restriction can also be used to allow new subscribers to purchase
their initial PrePaid Service.
Should the subscriber terminate the session before the quota is used
up, the remaining balance allotted to the session must be credited
back to the subscriberÆs account.
As well, while the Access Device is waiting for the initial quota, As well, while the Access Device is waiting for the initial quota,
the subscriber may have dropped the session. The initial quota must the subscriber may have dropped the session. The initial quota must
be credited back to the subscribers account. be credited back to the subscribers account.
3.2 Simple Service Device use-case 3.2 Support for concurrent PrePaid sessions
When the Access Device does not support the prepaid extensions, an
operator may still offer prepaid services to subscribers by using a
service device configured as default IP gateway to the Access
device.
A Prepaid subscriber connects to his home network in the usual way.
The non-prepaid enabled Access Device that is servicing the
subscriber will use the AAA infrastructure to authenticate and
authorize the subscriber. The Service device will be configured as
AAA proxy to the Access Device.
The Access Device sends an Access Request to the Service Device
acting as AAA proxy to authenticate the subscriber, and identify and
authorize the service. The Service Device will proxy the Access
Request and append its own Prepaid capabilities to the Access
Request message. These prepaid capabilities are defined identically
to the simple access device user-case.
The prepaid system performs functions as with prepaid support in the
Access Device, e.g., the AAA system incorporates the prepaid
attributes received from the Prepaid System with the service
attributes into an Access-Accept message that it sends back to the
Service Device. The Service device removes these attributes before
forwarding the Access-Accept message to the Access Device.
Upon receiving the Access-Accept with allocated quota, the Service
Device allows the prepaid data service session to start and since it
is configured as default gateway to the access device, it starts to
meter the session based on time and/or volume.
3.3 Support for concurrent PrePaid sessions
RADIUS Extensions for PrePaid February 2004 [REPLACE THIS TEXT WITH TOKEN BASED PREPAID]
Both prepaid support using Access Devices and prepaid support using Both prepaid support using Access Devices and prepaid support using
Service Devices can be configured to support a prepaid multi-service Service Devices can be configured to support a prepaid multi-service
environment. In such circumstances, the prepaid client capabilities environment. In such circumstances, the prepaid client capabilities
will indicate that the Access or Service Device supports a multi- will indicate that the Access or Service Device supports a multi-
service environment [Editor: need to add this to the PPAC]. [Editor: service environment [Editor: need to add this to the PPAC]. [Editor:
This needs to be reworked. DonÆt believe that this step is required. This needs to be reworked. DonÆt believe that this step is required.
The Service Ids should be known a priori ¡ the Access Request should The Service Ids should be known a priori ¡ the Access Request should
RADIUS Extensions for PrePaid February 2004
include the Service Key being requested.] In such circumstances, include the Service Key being requested.] In such circumstances,
instead of returning a quota, the prepaid service provides a list of instead of returning a quota, the prepaid service provides a list of
authorized services corresponding to a list of service keys to the authorized services corresponding to a list of service keys to the
prepaid client. The Access/Service device then uses these service prepaid client. The Access/Service device then uses these service
keys to request prepaid authorization to the corresponding services. keys to request prepaid authorization to the corresponding services.
The prepaid server responds with an individual quota for the The prepaid server responds with an individual quota for the
requested service key [Editor: add service key to PPAQ]. The requested service key [Editor: add service key to PPAQ]. The
Access/Service Device may in parallel request prepaid authorization Access/Service Device may in parallel request prepaid authorization
to a second service key. In which case a separate authorization to a second service key. In which case a separate authorization
exchange is used to provide an independent quota for this second exchange is used to provide an independent quota for this second
service. service.
Each session is treated independently. Each session is treated independently.
The method by which a prepaid user activates a service and the The method by which a prepaid user activates a service and the
method for signaling this information to the Access/Service Device method for signalling this information to the Access/Service Device
is out of scope of this draft. is out of scope of this draft.
The method by which a granular service is defined is out of scope of The method by which a granular service is defined is out of scope of
this draft. Only service key correlation information is required to this draft. Only service key correlation information is required to
enable the prepaid server to authorize and rate a particular enable the prepaid server to authorize and rate a particular
request. request.
3.4 Support for Roaming 3.3 Support for Roaming
For some networks it is essential that PrePaid Data Services be For some networks it is essential that PrePaid Data Services be
offered to roaming subscribers. Support for static and dynamic offered to roaming subscribers. Support for static and dynamic
roaming models are needed. Static roaming is where the subscriber roaming models are needed. Static roaming is where the subscriber
logs onto a foreign network. The foreign network has a roaming logs onto a foreign network. The foreign network has a roaming
agreement directly with the home network or through a broker network agreement directly with the home network or through a broker network
or networks. The subscriber remains logged into the network until or networks. The subscriber remains logged into the network until
the subscriber changes location. When changing location a new the subscriber changes location. When changing location a new
connection and a new login procedure is required. connection and a new login procedure is required.
Dynamic roaming allows to subscriber to move between foreign Dynamic roaming allows to subscriber to move between networks while
networks while maintaining a connection with the home network maintaining a connection with the home network seamlessly. As the
subscriber moves between networks, the data session is handed off
RADIUS Extensions for PrePaid February 2004 between the networks.
seamlessly. As the subscriber moves between networks, the data
session is handed off between the networks.
In both roaming scenarios, the subscriber always authenticates with In both roaming scenarios, the subscriber always authenticates with
the home network. PrePaid authorization and quota replenishing for the home network. PrePaid authorization and quota replenishing for
the session need to be received at the home network and more the session need to be received at the home network and more
specifically at the PrePaid System where state is being maintained. specifically at the PrePaid System where state is being maintained.
RADIUS Extensions for PrePaid February 2004
Dynamic roaming is particularly challenging. A subscriber that Dynamic roaming is particularly challenging. A subscriber that
established a PrePaid Data Session may roam to another Access Device established a PrePaid Data Session may roam to another Access Device
that doesnÆt not support PrePaid functionality. The system should that doesnÆt not support PrePaid functionality. The system should
be capable to continue the PrePaid session. be capable to continue the PrePaid session.
3.5 PrePaid termination 3.4 PrePaid termination
When fraud is detected by the PrePaid System, or when an error is When fraud is detected by the PrePaid System, or when an error is
detected, it may be beneficial for the PrePaid system to terminate a detected, it may be beneficial for the PrePaid system to terminate a
specific session for the subscriber or all the sessions of a specific session for the subscriber or all the sessions of a
subscriber. subscriber.
Some errors can occur such that the PrePaid System is in a state Some errors can occur such that the PrePaid System is in a state
where it is not sure whether the session is in progress or not. where it is not sure whether the session is in progress or not.
Under conditions such as this, the PrePaid system may wish to Under conditions such as this, the PrePaid system may wish to
terminate the PrePaid data session to make sure that resources are terminate the PrePaid data session to make sure that resources are
not being utilized for which it canÆt charge for reliably. not being utilized for which it canÆt charge for reliably.
Some handoff procedure used during dynamic roaming may require that Some handoff procedure used during dynamic roaming may require that
the PrePaid system explicitly terminate the subscribers PrePaid data the PrePaid system explicitly terminate the subscribers PrePaid data
session at an Access Device. For example, if time based PrePaid session at an Service Access Device. For example, if time based
service is being used and the mobile subscriber performs a dormant PrePaid service is being used and the mobile subscriber performs a
handoff, the PrePaid System needs to explicitly terminate the dormant handoff, the PrePaid System needs to explicitly terminate
PrePaid session at the old Access Device. the PrePaid session at the old Service Access Device.
4. Operations 4. Operations
4.1 General Requirements 4.1 General Requirements
4.1.1 Broker AAA Requirements 4.1.1 Broker AAA Requirements
Broker AAA servers MUST support the Message-Authenticator(80) Broker AAA servers MUST support the Message-Authenticator(80)
attribute as defined in [RFC2869]. If BAAA servers are used, the attribute as defined in [RFC2869]. If BAAA servers are used, the
RADIUS Extensions for PrePaid February 2004
BAAA servers function is to forward the RADIUS packets as usual to BAAA servers function is to forward the RADIUS packets as usual to
the appropriate RADIUS servers. the appropriate RADIUS servers.
Accounting messages are not needed to deliver a PrePaid service. Accounting messages are not needed to deliver a PrePaid service.
However, accounting messages can be used to keep the PrePaid Server However, accounting messages can be used to keep the PrePaid Server
current as to what is happening with the PrePaid data session. current as to what is happening with the PrePaid data session.
Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the
pass through mode described in [RFC2866]. pass through mode described in [RFC2866].
4.2 Authentication and Authorization for Prepaid Enabled Access Devices RADIUS Extensions for PrePaid February 2004
The Access Device initiates the authentication and authorization 4.2 Authentication and Authorization for Prepaid Enabled Service Access
procedure by sending a RADIUS Access-Request as usual. Devices
If the Access Device has PrePaid Client capabilities, it MUST The Service Access Device initiates the authentication and
include the PPAC(TBD) attribute in the RADIUS Access-Request. The authorization procedure by sending a RADIUS Access-Request to the
PPAC(TBD) attribute indicates to the PrePaid server the PrePaid HAAA.
capabilities possessed by the Access Device. These are required in
order to complete the PrePaid authorization procedures.
[Editor: add support for the MultiSession-Capabilities attribute] If the Service Access Device has PrePaid Client capabilities, it
If the Access Device supports multiple sessions-keys capabilities, MUST include the PPAC(TBD) attribute in the RADIUS Access-Request.
then it SHOULD include the MultiSession-Capabilities attribute. The The PPAC(TBD) attribute indicates to the PrePaid server the PrePaid
presence of the MultiSession-Capabilities attribute will indicate to capabilities possessed by the Service Access Device. These are
the PPS that the Access Device support prepaid service required in order to complete the PrePaid authorization procedures.
differentiation above simple prepaid access.
If the Access Device supports the Disconnect-Message or the Change- If the Service Access Device supports the Disconnect-Message or the
of-Authorization capabilities, then it SHOULD include the Dynamic- Change-of-Authorization capabilities, then it SHOULD include the
Capabilities attribute. Dynamic-Capabilities attribute.
In certain deployments, there may be other ways in which to In certain deployments, there may be other ways in which to
terminate a data session, or change authorization of an active terminate a data session, or change authorization of an active
session. For example, some Access Devices provide a session session. For example, some Service Access Devices provide a session
termination service via Telnet or SNMP. In these cases, the AAA termination service via Telnet or SNMP. In these cases, the AAA
server MAY add the Dynamic-Capabilities message to the Access- server MAY add the Dynamic-Capabilities message to the Access-
Request. Upon receiving the Change-of-Authorization message, the Request. Upon receiving the Change-of-Authorization message, the
AAA server would then be responsible for terminating the session AAA server would then be responsible for terminating the session
using whatever means that are supported by the device. using whatever means that are supported by the device.
If the authentication procedure involves multiple Access-Requests If the authentication procedure involves multiple Access-Requests
(as in EAP), the Access Device MUST include the PPAC(TBD) attribute (as in EAP), the Service Access Device MUST include the PPAC(TBD)
attribute and the Dynamic-Capabilities attribute (if used) in at
RADIUS Extensions for PrePaid February 2004 least the last Access-Request of the authentication procedure.
and the Dynamic-Capabilities attribute (if used) in at least the
last Access-Request of the authentication procedure.
The Access-Request will be sent as usual to the HAAA. The packet The Access-Request will be sent as usual to the HAAA. The packet
may be proxied through zero or more BAAA. may be proxied through zero or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA will Once the Access-Request arrives at the HAAA, the HAAA will
authenticate the subscriber. If the subscriber is cannot be authenticate the subscriber. If the subscriber is cannot be
authenticated, the HAAA will send an Access-Reject message back to authenticated, the HAAA will send an Access-Reject message back to
the client. If the subscriber is authenticated, the HAAA will the client. If the subscriber is authenticated, the HAAA will
determine whether or not the subscriber is a PrePaid subscriber. determine whether or not the subscriber is a PrePaid subscriber.
The techniques used to determine whether or not a subscriber is a The techniques used to determine whether or not a subscriber is a
PrePaid subscriber is beyond the scope of this document. If the PrePaid subscriber is beyond the scope of this document. If the
subscriber is not a PrePaid subscriber, then the HAAA will respond subscriber is not a PrePaid subscriber, then the HAAA will respond
RADIUS Extensions for PrePaid February 2004
as usual with an Access-Accept or Access-Reject message. If the as usual with an Access-Accept or Access-Reject message. If the
subscriber is a PrePaid Subscriber the HAAA SHALL forward the subscriber is a PrePaid Subscriber the HAAA SHALL forward the
Access-Request to a PrePaid server for further authorization. Access-Request to a PrePaid server for further authorization.
The Access-Request will contain the PPAC(TBD) attribute, the The Access-Request will contain the PPAC(TBD) attribute, the
Dynamic-Capabilities attribute if one was included; and the Dynamic-Capabilities attribute if one was included; the User-Name(1)
MultiSession-Capabilities attribute if one was included, the User- attribute MAY be set to a value that would represent the
Name(1) attribute MAY be set to a value that would represent the
SubscriberÆs PrePaid Identity. This attribute is used by the SubscriberÆs PrePaid Identity. This attribute is used by the
PrePaid server to locate the PrePaid SubscriberÆs account. For PrePaid server to locate the PrePaid SubscriberÆs account. For
added security, the HAAA MAY also set the User-Password(2) attribute added security, the HAAA MAY also set the User-Password(2) attribute
to the password used between the HAAA and the PrePaid server. to the password used between the HAAA and the PrePaid server.
The PrePaid server lookups the subscriberÆs PrePaid account and will The PrePaid server lookups the subscriberÆs PrePaid account and will
authorize the subscriber taking into consideration the Access Device authorize the subscriber taking into consideration the Service
PrePaid Client Capabilities. The Prepaid Server will decide whether Access Device PrePaid Client Capabilities.
single service prepaid access will be provided or a multiple session
pre-paid access will be provided.
4.2.1 Single Service Pre-paid
If a single service prepaid access is provided, upon successful Upon successful authorization, the PrePaid server will generate an
authorization, the PrePaid server will generate an Access-Accept Access-Accept containing the PPAC(TBD) attribute and the PPAQ(TBD)
containing the PPAC(TBD) attribute and the PPAQ(TBD) attribute. attribute.
The PPAC attribute returned to the client indicates the type of The PPAC attribute returned to the client indicates the type of
prepaid service to be provided for the session. prepaid service to be provided for the session. The PPAQ(TBD)
which contains the following sub-attributes: attribute includes:
RADIUS Extensions for PrePaid February 2004
- The QUOTA-Id which is set by the PrePaid server to a unique value - The QUOTA-Id, which is set by the PrePaid server to a unique
that is used to correlate subsequent quota requests; value that is used to correlate subsequent quota requests;
- Volume and/or Time Quotas, one of which is set to a value - Volume and/or Time quotas, which are set to a value representing a
representing a portion of the subscribers account; portion of the subscribers account;
- MAY contain a Time or Volume Threshold that controls when the - MAY contain a Time or Volume Threshold that controls when the
Access Device requests additional quota; Service Access Device requests additional quota;
- The IP address of the Serving PrePaid Server and one or more - The IP address of the Serving PrePaid Server and one or more
alternative PrePaid Servers. This is used by the HAAA to route alternative PrePaid Servers. This is used by the HAAA to route
subsequent quota replenishing messages to the appropriate PrePaid subsequent quota replenishing messages to the appropriate PrePaid
server(s). server(s).
Note: Idle-Timeout(28) can be used to trigger the premature Note: Idle-Timeout(28) can be used to trigger the premature
termination of a pre-paid service following subscriber inactivity. termination of a pre-paid service following subscriber inactivity.
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, upon unsuccessful authorization, the
PrePaid server will generate an Access-Reject to terminate the PrePaid server will generate an Access-Reject to terminate the
RADIUS Extensions for PrePaid February 2004
session immediately. Alternatively, the PrePaid server may generate session immediately. Alternatively, the PrePaid server may generate
an Access-Accept blocking some or all of the traffic and/or redirect an Access-Accept blocking some or all of the traffic and/or redirect
some or all of the traffic to a location where the subscriber can some or all of the traffic to a location where the subscriber can
replenish their account for a period of time. Blocking of traffic replenish their account for a period of time. Blocking of traffic
is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect
I-d). Redirection is achieved by sending Redirect-Id or Redirect- I-d). Redirection is achieved by sending Redirect-Id or Redirect-
Rule defined in the Redirect I-d. The period of time before the Rule defined in the Redirect I-d. The period of time before the
blocked/redirected session last can be specified by Session- blocked/redirected session last can be specified by Session-
Timeout(27) attribute. Timeout(27) attribute.
Upon receiving the Access-Accept from the PrePaid Server, the HAAA Upon receiving the Access-Accept from the PrePaid Server, the HAAA
will append the usual service attributes and forward the packet to will append the usual service attributes and forward the packet to
the Access Device. The HAAA SHALL NOT append or overwrite any the Service Access Device. The HAAA SHALL NOT append or overwrite
attributes already set by the PrePaid server. If the HAAA, receives any attributes already set by the PrePaid server. If the HAAA,
an Access-Reject message, it will simply forward the packet to its receives an Access-Reject message, it will simply forward the packet
client. Depending on site policies, if the HAAA fails to receive an to its client. Depending on site policies, if the HAAA fails to
Access-Accept or Access-Reject message from the PrePaid server it receive an Access-Accept or Access-Reject message from the PrePaid
MAY do nothing or send an Access-Reject or an Access-Accept message server it MAY do nothing or send an Access-Reject or an Access-
back to its client. Accept message back to its client.
4.2.2 Multiple-Session Pre-paid
RADIUS Extensions for PrePaid February 2004
If the prepaid server decides that multiple-session prepaid service
is to be provided, upon successful authorization, the Prepaid server
will generate an Access-Accept containing the PPAQ attribute which
contains the following sub-attributes:
- a list of the service keys which the Access Device can subsequently
use in pre-paid service authorization request.
[Editor: if this stands (see earlier comments) then instead of
issuing an access-accept the PPS should issue a Challenge that
contains the service-keys]
The first PrepaidServer subtype is set to the IP address of the
Serving Prepaid Server, the second one is set to an alternate
Prepaid Server if any. This way the HAAA will be able to route
subsequent packets to the serving Prepaid Server or its alternate.
[Editor: this should only be done on the Access Accept that deliver
the quota for the specific service.]
Additionally, the Prepaid server MAY set the Terminate-Action(29) to
RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control
how often interim Accounting Requests are generated.
Upon receiving the Access-Accept from the Prepaid Server, the HAAA
will append the usual service attributes and forward the packet.
The HAAA SHALL NOT append any attributes already set by the Prepaid
server. If the HAAA, receives an Access-Reject message, it will
simply forward the packet to its client. Depending on site
policies, if the HAAA fails to receive an Access-Accept message from
the Prepaid server it MAY do nothing or send an Access-Reject or an
Access-Accept message back to its client.
Upon receiving the Access-Accept with a list of service keys, the
Access Device can trigger the authorization request for a particular
service corresponding to a service key. The technique for triggering
an authorization request for a particular service is out of scope of
this draft.
The Access Device initiates authorization for a particular service
by sending a RADIUS Access Request including a single service-key
reference.
RADIUS Extensions for PrePaid February 2004
For the specific service-key reference, the prepaid server will
check whether funds are available and will, following successful
allocation of funds, the Prepaid server will generate an Access-
Accept containing the PPQ-Response attribute which contains the
following sub-attributes:
- The QUOTA-Id which is set by the Prepaid server to a unique value
that is used to correlate subsequent quota updates;
- The ServiceKey-Id which is set by the Prepaid server to the
service key requested by the Access Device;
- Volume and Time Quotas, one of which is set to a value
representing a portion of the subscribers account;
- The Time of Volume Threshold that the Prepaid server MAY set to 4.2.1 Multiple-Session Pre-paid
control when the Access Device requests additional quota.
Note: Idle-Timeout(28) can be used to trigger the premature To be completed in the next release.
termination of a pre-paid service following subscriber inactivity.
4.3 Session Start Operation 4.3 Session Start Operation
The real start of the session is indicated by the arrival of The real start of the session is indicated by the arrival of
Accounting-Request(Start) packet. The Accounting-Request (Start) Accounting-Request(Start) packet. The Accounting-Request (Start)
MAY be routed to the PrePaid Server so that it can confirm the MAY be routed to the PrePaid Server so that it can confirm the
initial quota allocation. initial quota allocation.
Note that the PrePaid Server role is not to record accounting Note that the PrePaid Server role is not to record accounting
messages and therefore it SHOULD not respond with an Accounting messages and therefore it SHOULD not respond with an Accounting
Response packet. Response packet.
If the Prepaid server does not receive the Accounting-Request(start) If the Prepaid server does not receive the Accounting-Request(start)
message it will only know that the session has started upon the message it will only know that the session has started upon the
first reception of a quota replenishment operation. first reception of a quota replenishment operation.
If the Prepaid server does not receive indication directly (via If the Prepaid server does not receive indication directly (via
Accounting-Request(start)) or indirectly, it SHOULD after some Accounting-Request(start)) or indirectly, it SHOULD after some
configurable time, deduce that the Session has not started. If the configurable time, deduce that the Session has not started. If the
Access Device supports termination capabilities, the PPS SHOULD send
a Disconnect Message to the Access Device to ensure that the session
is indeed dead.
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
Service Access Device supports termination capabilities, the PPS
SHOULD send a Disconnect Message to the Service Access Device to
ensure that the session is indeed dead.
4.4 Mid-Session Operation 4.4 Mid-Session Operation
During the lifetime of a PrePaid data session the Access Device will During the lifetime of a PrePaid data session the Service Access
request to replenish the quotas using Authorize-Only Access-Request Device will request to replenish the quotas using Authorize-Only
messages. Access-Request messages.
Once the allocated quota has been reached or the threshold has been Once the allocated quota has been reached or the threshold has been
reached, the Access Device MUST send an Access-Request with Service- reached, the Service Access Device MUST send an Access-Request with
Type(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD) Service-Type(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD)
attribute. attribute.
The Access Device MUST also include NAS identifiers, and Session The Service Access Device MUST also include NAS identifiers, and
identifier attributes in the Authorize Only Access-Request. The Session identifier attributes in the Authorize Only Access-Request.
Session Identifier should be the same as those used during the The Session Identifier should be the same as those used during the
Access-Request. For example, if the User-Name(1) attribute was used Access-Request. For example, if the User-Name(1) attribute was used
in the Access-Request it MUST be included in the Authorize Only in the Access-Request it MUST be included in the Authorize Only
Access-Request especially if the User-Name(1) attribute is used to Access-Request especially if the User-Name(1) attribute is used to
route the Access-Request to the Home AAA server. route the Access-Request to the Home AAA server.
The Authorize Only Access-Request MUST not include either User The Authorize Only Access-Request MUST not include either User
Password or Chap Password. In order to authenticate the message, Password or Chap Password. In order to authenticate the message,
the Access Device MUST include the Message-Authenticator(80) the Service Access Device MUST include the Message-Authenticator(80)
attribute. The Access Device will compute the value for the attribute. The Service Access Device will compute the value for the
Message-Authenticator based on [RFC2869]. Message-Authenticator based on [RFC2869].
When the HAAA receives the Authorize-Only Access-Request that When the HAAA receives the Authorize-Only Access-Request that
contains a PPAQ(TBD), it SHALL validate the message using the contains a PPAQ(TBD), it SHALL validate the message using the
Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an
Authorize Only Access-Request that contains a PPAQ(TBD) but not a Authorize Only Access-Request that contains a PPAQ(TBD) but not a
Message-Authenticator(80) it SHALL silently discard the message. An Message-Authenticator(80) it SHALL silently discard the message. An
Authorize Only Access-Request message that does not contain a Authorize Only Access-Request message that does not contain a
PPAQ(TBD) is either in error or belongs to another application (for PPAQ(TBD) is either in error or belongs to another application (for
example, a Change of Authorization message [RFC3576]). In this case example, a Change of Authorization message [RFC3576]). In this case
the Authorize Only Access-Request will either be silently discarded the Authorize Only Access-Request will either be silently discarded
or handled by another application (not in scope of this document). or handled by another application (not in scope of this document).
Once the Authorize Only Access-Request message is validated, the Once the Authorize Only Access-Request message is validated, the
HAAA SHALL forward the Authorize Only Access-Request to the HAAA SHALL forward the Authorize Only Access-Request to the
appropriate PrePaid Server. The HAAA MUST forward the Authorize appropriate PrePaid Server. The HAAA MUST forward the Authorize
Only Access-Request to the PrePaid server specified in the
PPAQ(TBD). The HAAA MUST sign the message using the Message-
Authenticator(80) and the procedures in [RFC2869]. As with the
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
Only Access-Request to the PrePaid server specified in the
PPAQ(TBD). The HAAA MUST sign the message using the Message-
Authenticator(80) and the procedures in [RFC2869]. As with the
Access-Request message, the HAAA MAY modify the User-Name(1) Access-Request message, the HAAA MAY modify the User-Name(1)
attribute to a value that represents the userÆs internal PrePaid attribute to a value that represents the userÆs internal PrePaid
account in the PrePaid server. Note the PrePaid server could use account in the PrePaid server. Note the PrePaid server could use
the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate
the user account. the user account.
Upon receiving the Authorize Only Access-Request containing a Upon receiving the Authorize Only Access-Request containing a
PPAQ(TBD) attribute, the PrePaid server MUST validate the Message- PPAQ(TBD) attribute, the PrePaid server MUST validate the Message-
Authenticator(80) as prescribed in [RFC2869]. If the message is Authenticator(80) as prescribed in [RFC2869]. If the message is
invalid, the PrePaid server MUST silently discard the message. If invalid, the PrePaid server MUST silently discard the message. If
skipping to change at page 29, line 48 skipping to change at page 25, line 5
short duration to allow them to replenish their account, or create short duration to allow them to replenish their account, or create
an account; or to browse free content. an account; or to browse free content.
Upon receiving the Access-Accept from the PrePaid server, the HAAA Upon receiving the Access-Accept from the PrePaid server, the HAAA
SHALL return the packet to its client. If the HAAA, receives an SHALL return the packet to its client. If the HAAA, receives an
Access-Reject message, it will forward the packet. Depending on Access-Reject message, it will forward the packet. Depending on
site policies, if the HAAA fails to receive an Access-Accept or an site policies, if the HAAA fails to receive an Access-Accept or an
Access-Reject message from the PrePaid server it MAY do nothing or Access-Reject message from the PrePaid server it MAY do nothing or
it MAY send an Access-Reject message back to its client. it MAY send an Access-Reject message back to its client.
Upon receiving an Access-Accept, the Access Device SHALL update its
quotas and threshold parameters with the values contained in the
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
PPAQ(TBD) attribute. Note that the PrePaid server MAY update the Upon receiving an Access-Accept, the Service Access Device SHALL
PrePaidServer attribute(s) and these may have to be saved as well. update its quotas and threshold parameters with the values contained
in the PPAQ(TBD) attribute. Note that the PrePaid server MAY update
the PrePaidServer attribute(s) and these may have to be saved as
well.
Upon receiving an Access-Accept message containing either Filter- Upon receiving an Access-Accept message containing either Filter-
Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27).
The Access Device SHALL restrict the subscriber session accordingly. The Service Access Device SHALL restrict the subscriber session
accordingly.
4.5 Dynamic Operations 4.5 Dynamic Operations
The PrePaid server may want to take advantage of the dynamic The PrePaid server may want to take advantage of the dynamic
capabilities that are supported by the Access Device as advertised capabilities that are supported by the Service Access Device as
in the Dynamic-Capabilities attribute during the initial Access- advertised in the Dynamic-Capabilities attribute during the initial
Request. Access-Request.
There are two types of actions that the PrePaid server can perform: There are two types of actions that the PrePaid server can perform:
it can request that the session be terminated; or it can request it can request that the session be terminated; or it can request
that the filters associated with the session be modified. that the filters associated with the session be modified.
Both of these actions require that the session be uniquely Both of these actions require that the session be uniquely
identified at the Access Device. As a minimum the PrePaid server: identified at the Service Access Device. As a minimum the PrePaid
server:
-MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32)
-MUST provide at least one session identifier such as User-Name(1), -MUST provide at least one session identifier such as User-Name(1),
Framed-IP-Address(), the Accounting-Session-Id(44). Framed-IP-Address(), the Accounting-Session-Id(44).
Other attributes could be used to uniquely identify a PrePaid data Other attributes could be used to uniquely identify a PrePaid data
session. session.
4.5.1 Unsolicited Session Termination Operation 4.5.1 Unsolicited Session Termination Operation
This capability is described in detail in [RFC3576]. The PrePaid This capability is described in detail in [RFC3576]. The PrePaid
server sends a Disconnect Request packet that MUST contain server sends a Disconnect Request packet that MUST contain
identifiers that uniquely identify the subscriberÆs data session and identifiers that uniquely identify the subscriberÆs data session and
the Access Device servicing that session. the Service Access Device servicing that session.
Upon receiving the Disconnect Request packet the HAAA will either Upon receiving the Disconnect Request packet the HAAA will either
act on it or will proxy it to another AAA server until it is act on it or will proxy it to another AAA server until it is
received by the a AAA that is in the same network as the serving
Access Device.
Each AAA MUST route the Disconnect Request packet. How the routing
decision is made is an implementation detail.
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
Once the Disconnect Request packet reaches AAA that is in the same received by the a AAA that is in the same network as the serving
network as the serving Access Device, if the Access Device supports Service Access Device.
Disconnect-Request (as per [RFC3576]), it sends the message directly
to the Access Device; otherwise it uses other mechanisms such as
SNMP or Telnet to command the Access Device to terminate the session
(this is an implementation detail).
If the Access Device receives a Disconnect-Request packet, it will Each AAA MUST route the Disconnect Request packet to the AAA that is
respond with either a Disconnect-ACK packet if it was able to in the same network as the serving Service Access Device (as per
terminate the session or else it will respond with a Disconnect-NAK [RFC3576]).
packet.
If the Service Access Device receives a Disconnect-Request packet,
it will respond with either a Disconnect-ACK packet if it was able
to terminate the session or else it will respond with a Disconnect-
NAK packet.
If the AAA server is performing the disconnect operation, it MUST If the AAA server is performing the disconnect operation, it MUST
respond with a Disconnect-ACK message if it successfully terminated respond with a Disconnect-ACK message if it successfully terminated
the session or a Disconnect-NAK message if it failed to terminate the session or a Disconnect-NAK message if it failed to terminate
the session with the appropriate Error-Cause(101) set. the session with the appropriate Error-Cause(101) set.
If any AAA server is unable to route the Disconnect-Request it MUST If any AAA server is unable to route the Disconnect-Request it MUST
respond with a Disconnect-NAK packet with Error-Cause(101) set to respond with a Disconnect-NAK packet with Error-Cause(101) set to
ôRequest Not Routableö(502). ôRequest Not Routableö(502).
4.5.2 Unsolicited Change of Authorization Operation 4.5.2 Unsolicited Change of Authorization Operation
The PrePaid Server MAY send a Change-of-Authorization message as The PrePaid Server MAY send a Change-of-Authorization message as
described in [RFC3576] to restrict Internet access when the described in [RFC3576] to restrict Internet access when the
subscriber has no more balance. The COA packet may contain Filter- subscriber has no more balance. The COA packet may contain Filter-
Id(11) and or attributes defined in Redirect I-d. Id(11) and or attributes defined in Redirect I-d.
The PrePaid server sends a Change-of-Authorization packet it MUST The PrePaid server sends a Change-of-Authorization packet it MUST
contain identifiers that will uniquely identify the subscriber contain identifiers that will uniquely identify the subscriber
session and the Access Device serving that session. session and the Service Access Device serving that session.
Upon receiving the Change-of-Authorization packet the HAAA will Upon receiving the Change-of-Authorization packet the HAAA will
either act on it or proxy it to another AAA server until it is either act on it or proxy it to another AAA server until it is
received by a AAA server that is in the same network as the serving received by a AAA server that is in the same network as the serving
Access Device. Service Access Device.
Each AAA must route the packet to the serving network. How the Each AAA must route the packet to the serving network. How the
routing decision is made is an implementation detail. routing decision is made is an implementation detail.
Once the Change-of-Authorization packet reaches a AAA that is in the Once the Change-of-Authorization packet reaches a AAA that is in the
same network as the serving Access Device, if the Access Device same network as the serving Service Access Device, if the Service
supports Change-of-Authorization message, it will forward the
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
message to the Access Device; otherwise, it will use other Access Device supports Change-of-Authorization message, it will
mechanisms such as SNMP or Telnet to command the Access Device to forward the message to the Service Access Device.
change its filters.
If the Access Device receives a Change-of-Authorization packet, it
will respond with either a Change-of-Authorization-ACK packet if it
was able to change the filter or else it will respond with a Change-
of-Authorization-NAK packet.
If the AAA server is performing the change of filter operation, it
MUST respond with a Change-of-Authorization-ACK message if it
successfully or a Change-of-Authorization-NAK packet if it failed to
change the filter.
If a AAA server was unable to route the Change-of-Authorization it If the Service Access Device receives a Change-of-Authorization
MUST respond with a Change-of-Authorization-NAK packet. packet, it will respond with either a Change-of-Authorization-ACK
packet if it was able to change the filter or else it will respond
with a Change-of-Authorization-NAK packet.
4.6 Termination Operation 4.6 Termination Operation
The termination phase is initiated when either: the Subscriber logs The termination phase is initiated when either: the Subscriber logs
off; the quotas have been consumed, or when the Access Device off; the quotas have been consumed, or when the Service Access
receives a Disconnect Message. In all of these instances, if the Device receives a Disconnect Message. In all of these instances, if
session is a PrePaid data session, the Access Device will send an the session is a PrePaid data session, the Service Access Device
Authorize-Only Access-Request message with a PPAQ(TBD) Update-Reason will send an Authorize-Only Access-Request message with a PPAQ(TBD)
attribute set to either ôClient Service terminationö or ôRemote Update-Reason attribute set to either ôClient Service terminationö
Forced disconnectö and the currently used quota. or ôRemote Forced disconnectö and the currently used quota.
The BAAA MUST forward this packet to the next BAAA or the HAAA. The BAAA MUST forward this packet to the next BAAA or the HAAA.
The HAAA MUST validate the Authorize Only Access-Request using the The HAAA MUST validate the Authorize Only Access-Request using the
Message-Authenticator(80) as per [RFC2869] and if valid, use the Message-Authenticator(80) as per [RFC2869] and if valid, use the
PrePaidServer subtype in the PPAQ(TBD) to forward the Authorize Only PrePaidServer subtype in the PPAQ(TBD) to forward the Authorize Only
Access-Request packet to the serving PrePaid Server or if needed, Access-Request packet to the serving PrePaid Server or if needed,
its alternate. its alternate.
The PrePaid Server MUST validate the Authorize Only Access Request The PrePaid Server MUST validate the Authorize Only Access Request
and use the information contained in the PPAQ(TBD) attribute to and use the information contained in the PPAQ(TBD) attribute to
adjust the subscriberÆs balance and to close the session. The adjust the subscriberÆs balance and to close the session. The
PrePaid Server SHALL respond back with an Access-Accept message. PrePaid Server SHALL respond back with an Access-Accept message.
4.7 Mobile IP Operations 4.7 Mobile IP Operations
In roaming scenarios using Mobile-IP, as the mobile subscriber roams
between networks, or between different types of networks such as
between WLAN and CDMA2000 networks, the PrePaid data session should
be maintained transparently if the HA is acting as the Service
Access Device.
As the subscriber device associates with the new Service Access
Device (AP or PDSN that supports prepaid client capability), the
Service Access Device sends a RADIUS Access-Request and the
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
In roaming scenarios using mobile-ip, as the mobile subscriber roams subscriber is re-authenticated and reauthorized. The Service Access
between networks, or between different types of networks such as Device MUST include the PPAC(TBD) attribute in the RADIUS Access-
between WLAN and CDMA2000 networks, the PrePaid data session is Request. In this manner the procedure follows the Authentication
maintained transparently. and Authorization procedure described earlier.
As the subscriber device associates with the new Access Device, the If the HA was acting as the Service Access Device before handoff,
Access Device sends a RADIUS Access-Request and the subscriber is the userÆs prepaid session does not undergo any change after the
re-authenticated and reauthorized. If the Access Device has PrePaid handoff because the Mobile IP session is anchored at the HA and the
Client capabilities, it MUST include the PPAC(TBD) attribute in the userÆs Home IP address remains the same.
RADIUS Access-Request. In this manner the procedure follows the
Authentication and Authorization procedure described earlier.
In the case of AP or PDSN acting as the Service Access Device it is
likely that the userÆs IP address will change (Care of Address).
Therefore, the ongoing prepaid session will have some impact. In the
case the Service Access Device shall send an Access-Request.
The Access-Request message is routed to the home network and MUST The Access-Request message is routed to the home network and MUST
reach the PrePaid System that is serving the PrePaid session. The reach the PrePaid System that is serving the PrePaid session. The
PrePaid system will then correlate the new authorization request PrePaid system will then correlate the new authorization request
with the existing active session and will assign a quota to the new with the existing active session and will assign a quota to the new
request. Any outstanding quota at the old Access Device will be request. Any outstanding quota at the old Service Access Device
returned to the PrePaid system due to the usual mobile-ip handoff MUST be returned to the PrePaid system. If the Mobile-IP nodes (HA
procedures. Specifically, the quota will be returned when the and FA) supports registration revocation (Mobile IPv4 only).
Access Device sends the Authorize Only Access-Request with PPAQ(TBD) Specifically, the quota SHOULD be returned when the Service Access
Update-Reason subtype set to either ôRemote Forced disconnectö or Device sends the Authorize Only Access-Request with PPAQ(TBD)
ôClient Service terminationö. In order to trigger the sending of Update-Reason set to either ôRemote Forced disconnectö or ôClient
this last Authorize Only Access-Request, the PrePaid system may Service terminationö. In order to trigger the sending of this last
issue a Disconnect Message [CHIBA] to the Access Device. Authorize Only Access-Request, the PrePaid system may issue a
Disconnect Message [CHIBA] to the Service Access Device.
If the subscriber has roamed to an Access Device that does not have If the subscriber has roamed to a Service Access Device that does
any PrePaid Capabilities, PrePaid data service may still be possible not have any PrePaid Capabilities, PrePaid data service may still be
by requesting the Home Agent (providing it has PrePaid Capabilities) possible by requesting the Home Agent (providing it has PrePaid
to assume responsibilities for metering the service. The procedure Capabilities) to assume responsibilities for metering the service.
for this scenario will be given in the next release of this draft. The procedure for this scenario will be given in the next release of
this draft.
4.8 Accounting Considerations 4.8 Accounting Considerations
Accounting messages are not required to deliver PrePaid Data Accounting messages are not required to deliver PrePaid Data
Service. Accounting message will typically be generated for PrePaid Service. Accounting message will typically be generated for PrePaid
Data Service. This because accounting message are used for auditing Data Service. This because accounting message are used for auditing
purposes as well as for bill generation. purposes as well as for bill generation.
RADIUS Extensions for PrePaid February 2004
Accounting messages associated with PrePaid Data Sessions should Accounting messages associated with PrePaid Data Sessions should
include the PPAQ(TBD) attribute. include the PPAQ(TBD) attribute.
4.9 Service Device Operation 4.9 Service Device Operation
RADIUS Extensions for PrePaid February 2004
To be completed To be completed
4.10 Interoperability with Diameter Credit Control Application 4.10 Interoperability with Diameter Credit Control Application
RADIUS PrePaid solutions need to interoperate with Diameter RADIUS PrePaid solutions need to interoperate with Diameter
protocol. Two possibilities exist: The AAA infrastructure is protocol. Two possibilities exist: The AAA infrastructure is
Diameter based and the Access Device are RADIUS based; or the Access Diameter based and the Service Access Device are RADIUS based; or
Device is Diameter based and the AAA infrastructure is RADIUS based. the Service Access Device is Diameter based and the AAA
infrastructure is RADIUS based.
The Diameter Credit Control Application [DIAMETERCC] describes how The Diameter Credit Control Application [DIAMETERCC] describes how
to implement a PrePaid using an all Diameter based infrastructure. to implement a PrePaid using an all Diameter based infrastructure.
<This section to be completed.> <This section to be completed.>
5. Attributes 5. Attributes
This draft is using the RADIUS [RFC2865] namespace. This draft is using the RADIUS [RFC2865] namespace.
5.1 PPAC Attribute 5.1 PPAC Attribute
The PrepaidAccountingCapability (PPAC) attribute is sent in the The PrepaidAccountingCapability (PPAC) attribute is sent in the
Access-Request message by a Prepaid Capable NAS and is used to Access-Request message by a Prepaid Capable NAS and is used to
describe the PrePaid capabilities of the NAS. The PPAC is available describe the PrePaid capabilities of the NAS. The PPAC is available
to be sent in an Access-Accept message by the Prepaid server to to be sent in an Access-Accept message by the Prepaid server to
indicate the type of prepaid metering that is to be applied to this indicate the type of prepaid metering that is to be applied to this
session. session.
RADIUS Extensions for PrePaid February 2004
0 1 2 3 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 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 | SUB-TYPE 1 | LENGTH | | TYPE | LENGTH | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) | | AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | SelectedForSession (SFS) | | SUB-TYPE 2 | LENGTH | SelectedForSession (SFS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : value of PPAC TYPE : value of PPAC
RADIUS Extensions for PrePaid February 2004
LENGTH: 14 LENGTH: 14
VALUE : String VALUE : String
The value MUST be encoded as follows: The value MUST be encoded as follows:
Sub-Type (=1) : Sub-Type for AvailableInClient attribute Sub-Type (=1) : Sub-Type for AvailableInClient attribute
Length : Length of AvailableInClient attribute Length : Length of AvailableInClient attribute
(= 6 octets) (= 6 octets)
AvailableInClient (AiC): AvailableInClient (AiC):
skipping to change at page 35, line 33 skipping to change at page 31, line 5
0x00000011 PrePaid Accounting for Volume and Duration supported 0x00000011 PrePaid Accounting for Volume and Duration supported
(non concurrently) (non concurrently)
Others Reserved, treat like Not Capable of PrePaid Others Reserved, treat like Not Capable of PrePaid
Accounting (=0). Accounting (=0).
Sub-Type (=2) : Sub-Type for SelectedForSession attribute Sub-Type (=2) : Sub-Type for SelectedForSession attribute
Length : Length of SelectedForSession attribute Length : Length of SelectedForSession attribute
(= 6 octets) (= 6 octets)
SelectedForSession (SfS): SelectedForSession (SfS):
RADIUS Extensions for PrePaid February 2004
The optional SelectedForSession Sub-Type, generated by the PrePaid The optional SelectedForSession Sub-Type, generated by the PrePaid
server, indicates the PrePaid Accounting capability to be used for a server, indicates the PrePaid Accounting capability to be used for a
given session. The possible values are: given session. The possible values are:
0x00000000 PrePaid Accounting not used 0x00000000 PrePaid Accounting not used
0x00000001 Usage of PrePaid Accounting for Volume. 0x00000001 Usage of PrePaid Accounting for Volume.
(only possible if the AvailableInClient supports (only possible if the AvailableInClient supports
PrePaid Accounting for Volume) PrePaid Accounting for Volume)
0x00000010 Usage of PrePaid Accounting for Duration. 0x00000010 Usage of PrePaid Accounting for Duration.
(only possible if the AvailableInClient supports (only possible if the AvailableInClient supports
PrePaid Accounting for Duration) PrePaid Accounting for Duration)
0x00000011 Usage of PrePaid Accounting for Volume and Duration 0x00000011 Usage of PrePaid Accounting for Volume and Duration
(non concurrent) (only possible if the (non concurrent) (only possible if the
AvailableInClient supports PrePaid Accounting for AvailableInClient supports PrePaid Accounting for
Volume and duration) Volume and duration)
Others Reserved, treat like PrePaid Accounting not used(=0). Others Reserved, treat like PrePaid Accounting not used(=0).
RADIUS Extensions for PrePaid February 2004
5.2 Session Termination Capability 5.2 Session Termination Capability
The value shall be bitmap encoded rather than a raw integer. This The value shall be bitmap encoded rather than a raw integer. This
attribute shall be included RADIUS Access-Request message to the attribute shall be included RADIUS Access-Request message to the
RADIUS server and indicates whether or not the NAS supports Dynamic RADIUS server and indicates whether or not the NAS supports Dynamic
Authorization. Authorization.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 29 skipping to change at page 32, line 5
Type : value of Session Termination Capability Type : value of Session Termination Capability
Length: = 4 Length: = 4
String encoded as follows: String encoded as follows:
0x00000001 Dynamic Authorization Extensions (rrfc3576) is 0x00000001 Dynamic Authorization Extensions (rrfc3576) is
supported. supported.
5.3 PPAQ Attribute 5.3 PPAQ Attribute
RADIUS Extensions for PrePaid February 2004
The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and
Access-Accept messages. In Authorize Only Access-Request messages Access-Accept messages. In Authorize Only Access-Request messages
it is used to report usage and request further quota; in an Access- it is used to report usage and request further quota; in an Access-
Accept message it is used to allocate the quota (initial quota and Accept message it is used to allocate the quota (initial quota and
subsequent quotas). subsequent quotas).
The attribute consists of a number of subtypes. Subtypes not used The attribute consists of a number of subtypes. Subtypes not used
are omitted in the message. are omitted in the message.
RADIUS Extensions for PrePaid February 2004
0 1 2 3 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 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 | SUB-TYPE 1 | LENGTH | | TYPE | LENGTH | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIdentifier (QID) | | QuotaIdentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Volume Quota | | SUB-TYPE 2 | LENGTH | Volume Quota |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Volume Quota | SUB-TYPE 3 | LENGTH | | Volume Quota | SUB-TYPE 3 | LENGTH |
skipping to change at page 37, line 40 skipping to change at page 33, line 5
| SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 9 | LENGTH | PrePaidServer | | SUB-TYPE 9 | LENGTH | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrePaidServer | | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PPAQ Type : Value of PPAQ
Length: variable, greater than 8 Length: variable, greater than 8
RADIUS Extensions for PrePaid February 2004
String: The String value MUST be encoded as follows: String: The String value MUST be encoded as follows:
Sub-Type (=1): Sub-Type for QuotaIDentifier attribute Sub-Type (=1): Sub-Type for QuotaIDentifier attribute
Length : Length of QuotaIDentifier attribute (= 6 octets) Length : Length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID): QuotaIDentifier (QID):
The QuotaIDentifier Sub-Type is generated by the PrePaid server The QuotaIDentifier Sub-Type is generated by the PrePaid server
at allocation of a Volume and/or Duration Quota. The on-line at allocation of a Volume and/or Duration Quota. The on-line
quota update RADIUS Access-Request message sent from the Service
RADIUS Extensions for PrePaid February 2004 Access Device to the PPS shall include a previously received
quota update RADIUS Access-Request message sent from the Access
Device to the PPS shall include a previously received
QuotaIDentifier. QuotaIDentifier.
Sub-Type (=2): Sub-Type for VolumeQuota attribute Sub-Type (=2): Sub-Type for VolumeQuota attribute
Length : length of VolumeQuota attribute (= 6 octets) Length : length of VolumeQuota attribute (= 6 octets)
VolumeQuota (VQ): VolumeQuota (VQ):
The optional VolumeQuota Sub-Type is only present if Volume Based The optional VolumeQuota Sub-Type is only present if Volume Based
charging is used. In RADIUS Access-Accept message (PPS to Access charging is used. In RADIUS Access-Accept message (PPS to Service
Device direction), it indicates the Volume (in octets) allocated Access Device direction), it indicates the Volume (in octets)
for the session by the PrePaid server. In RADIUS Authorize Only allocated for the session by the PrePaid server. In RADIUS
Access-Request message (Access Device to PPS direction), it Authorize Only Access-Request message (Service Access Device to
indicates the total used volume (in octets) for both forward and PPS direction), it indicates the total used volume (in octets)
reverse traffic applicable to PrePaid accounting. for both forward and reverse traffic applicable to PrePaid
accounting.
Sub-Type (=3): Sub-Type for VolumeQuotaOverflow Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
Length : length of VolumeQuotaOverflow attribute (= 4 octets) Length : length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO): VolumeQuotaOverflow (VQO):
The optional VolumeQuotaOverflow Sub-Type is used to indicate how The optional VolumeQuotaOverflow Sub-Type is used to indicate how
many times the VolumeQuota counter has wrapped around 2^32 over many times the VolumeQuota counter has wrapped around 2^32 over
the course of the service being provided. the course of the service being provided.
Sub-Type (=4): Sub-Type for VolumeThreshold attribute Sub-Type (=4): Sub-Type for VolumeThreshold attribute
Length : length of VolumeThreshold attribute (= 6 octets) Length : length of VolumeThreshold attribute (= 6 octets)
VolumeThreshold (VT): VolumeThreshold (VT):
The VolumeThreshold Sub-Type shall always be present if The VolumeThreshold Sub-Type shall always be present if
VolumeQuota is present in a RADIUS Access-Accept message (PPS to VolumeQuota is present in a RADIUS Access-Accept message (PPS to
Access Device direction). It is generated by the PrePaid server
and indicates the volume (in octets) that shall be used before RADIUS Extensions for PrePaid February 2004
requesting quota update. This threshold should not be larger than
the VolumeQuota. Service Access Device direction). It is generated by the PrePaid
server and indicates the volume (in octets) that shall be used
before requesting quota update. This threshold should not be
larger than the VolumeQuota.
Sub-Type (=5): Sub-Type for VolumeThresholdOverflow Sub-Type (=5): Sub-Type for VolumeThresholdOverflow
Length : Length of VolumeThresholdOverflow attribute Length : Length of VolumeThresholdOverflow attribute
(= 4 octets) (= 4 octets)
VolumeThresholdOverflow (VTO): VolumeThresholdOverflow (VTO):
RADIUS Extensions for PrePaid February 2004
The optional VolumeThresholdOverflow Sub-Type is used to indicate The optional VolumeThresholdOverflow Sub-Type is used to indicate
how many times the VolumeThreshold counter has wrapped around how many times the VolumeThreshold counter has wrapped around
2^32 over the course of the service being provided. 2^32 over the course of the service being provided.
Sub-Type (=6): Sub-Type for DurationQuota attribute Sub-Type (=6): Sub-Type for DurationQuota attribute
Length : length of DurationQuota attribute (= 6 octets) Length : length of DurationQuota attribute (= 6 octets)
DurationQuota (DQ): DurationQuota (DQ):
The optional DurationQuota Sub-Type is only present if Duration The optional DurationQuota Sub-Type is only present if Duration
Based charging is used. In RADIUS Access-Accept message (PPS to Based charging is used. In RADIUS Access-Accept message (PPS to
Access Device direction), it indicates the Duration (in seconds) Service Access Device direction), it indicates the Duration (in
allocated for the session by the PrePaid server. In on-line seconds) allocated for the session by the PrePaid server. In on-
RADIUS Access-Accept message (PPC to PPS direction), it indicates line RADIUS Access-Accept message (PPC to PPS direction), it
the total Duration (in seconds) since the start of the accounting indicates the total Duration (in seconds) since the start of the
session related to the QuotaID. accounting session related to the QuotaID.
Sub-Type (=7): Sub-Type for DurationThreshold attribute Sub-Type (=7): Sub-Type for DurationThreshold attribute
Length : length of DurationThreshold attribute (= 6 octets) Length : length of DurationThreshold attribute (= 6 octets)
DurationThreshold (DT): DurationThreshold (DT):
The DurationThreshold Sub-Type shall always be present if The DurationThreshold Sub-Type shall always be present if
DurationQuota is present in a RADIUS Access-Accept message (PPS DurationQuota is present in a RADIUS Access-Accept message (PPS
to Access Device direction). It represents the duration (in to Service Access Device direction). It represents the duration
seconds) that shall be used by the session before requesting (in seconds) that shall be used by the session before requesting
quota update. This threshold should not be larger than the quota update. This threshold should not be larger than the
DurationQuota and shall always be sent with the DurationQuota. DurationQuota and shall always be sent with the DurationQuota.
Sub-Type (=8): Sub-Type for Update-Reason attribute Sub-Type (=8): Sub-Type for Update-Reason attribute
Length : length of Update-Reason attribute (= 4 octets) Length : length of Update-Reason attribute (= 4 octets)
RADIUS Extensions for PrePaid February 2004
Update-Reason attribute (UR): Update-Reason attribute (UR):
The Update-Reason Sub-Type shall be present in the on-line RADIUS The Update-Reason Sub-Type shall be present in the on-line RADIUS
Access-Request message (Access Device to PPS direction). It Access-Request message (Service Access Device to PPS direction).
indicates the reason for initiating the on-line quota update It indicates the reason for initiating the on-line quota update
operation. Update reasons 4, 5, 6, 7 and 8 indicate that the operation. Update reasons 4, 5, 6, 7 and 8 indicate that the
associated resources are released at the client side, and associated resources are released at the client side, and
therefore the PPS shall not allocate a new quota in the RADIUS therefore the PPS shall not allocate a new quota in the RADIUS
Access_Accept message. Access_Accept message.
RADIUS Extensions for PrePaid February 2004
1. Pre-initialization 1. Pre-initialization
2. Initial request 2. Initial request
3. Threshold reached 3. Threshold reached
4. Quota reached 4. Quota reached
5. Remote Forced disconnect 5. Remote Forced disconnect
6. Client Service termination 6. Client Service termination
7. Main SI released 7. Main SI released
8. Service Instance not established 8. Service Instance not established
Sub-Type (=9) : Sub-Type for PrePaidServer attribute Sub-Type (=9) : Sub-Type for PrePaidServer attribute
skipping to change at page 40, line 36 skipping to change at page 35, line 46
present in the incoming RADIUS Access-Accept message, the PDSN present in the incoming RADIUS Access-Accept message, the PDSN
shall send this attribute back without modifying it in the shall send this attribute back without modifying it in the
subsequent RADIUS Access-Request message, except for the first subsequent RADIUS Access-Request message, except for the first
one. If multiple values are present, the PDSN shall not change one. If multiple values are present, the PDSN shall not change
the order of the attributes. the order of the attributes.
NOTES: NOTES:
Either Volume-Quota or Time-Quota MUST appear in the attribute. Either Volume-Quota or Time-Quota MUST appear in the attribute.
Volume Threshold may only appear if Volume Quota appears Volume Threshold may only appear if Volume Quota appears
If the Access Device can measure time, and if Time-Threshold appears If the Service Access Device can measure time, and if Time-Threshold
with Volume Quota, then the Access device should trigger a quota appears with Volume Quota, then the Service Access Device should
replenishment when the Current Time >= Time-Threshold. trigger a quota replenishment when the Current Time >= Time-
Threshold.
RADIUS Extensions for PrePaid February 2004
5.4 Table of Attributes 5.4 Table of Attributes
TO BE COMPLETED. TO BE COMPLETED.
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
Authorize_Only Request Accept Reject Authorize_Only Request Accept Reject
RADIUS Extensions for PrePaid February 2004
6. Security Considerations 6. Security Considerations
The protocol exchanges described are susceptible to the same The protocol exchanges described are susceptible to the same
vulnerabilities as RADIUS and it is recommended that IPsec be vulnerabilities as RADIUS and it is recommended that IPsec be
employed to afford better security. employed to afford better security.
If IPsec is not available the protocol in this draft improves the If IPsec is not available the protocol in this draft improves the
security of RADIUS. The various security enhancements are explained security of RADIUS. The various security enhancements are explained
in the following sections. in the following sections.
skipping to change at page 41, line 36 skipping to change at page 37, line 5
A successful replay attacks of the Authorize Only Access-Request A successful replay attacks of the Authorize Only Access-Request
could deplete the subscribers prepaid account. could deplete the subscribers prepaid account.
To be completed. To be completed.
7. IANA Considerations 7. IANA Considerations
To be completed. To be completed.
RADIUS Extensions for PrePaid February 2004
This draft does create RADIUS attributes. However, the authors This draft does create RADIUS attributes. However, the authors
recognize that it may not be possible to obtain such attributes. recognize that it may not be possible to obtain such attributes.
Therefore, in subsequent drafts it will be proposed to use a Vendor Therefore, in subsequent drafts it will be proposed to use a Vendor
space as an Application Space. space as an Application Space.
8. Normative References 8. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996. Revision 3", RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
RADIUS Extensions for PrePaid February 2004
"Remote Authentication Dial In User Server "Remote Authentication Dial In User Server
(RADIUS)", RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
2000. 2000.
[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS
Extensions", RFC 2869, June 2000. Extensions", RFC 2869, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
Holdrege, M., Goyret, I., "RADIUS Attributes for Holdrege, M., Goyret, I., "RADIUS Attributes for
Tunnel Protocol Support" , RFC 2868, June 2000. Tunnel Protocol Support" , RFC 2868, June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D.,
Aboba, B., "Dynamic Authorization Extensions to Aboba, B., "Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service Remote Authentication Dial-In User Service
(RADIUS)", RFC 3576, February 2003. (RADIUS)", RFC 3576, February 2003.
[DIAMETERCC] Work in Progress. [DIAMETERCC] Work in Progress.
[REDIRECT] RADIUS Redirection Internet Draft. Work in progress. [REDIRECT] RADIUS Redirection Internet Draft. Work in progress.
RFC 2284 EAP
Acknowledgments Acknowledgments
The authors would like to thank Mark Grayson (Cisco) and Nagi The authors would like to thank Mark Grayson, Nagi Jonnala and Joel
Jonnala for their contribution to this draft. Halpern, for their contribution to this draft.
RADIUS Extensions for PrePaid February 2004
Author's Addresses Author's Addresses
Avi Lior Parviz Yegani, Ph.D. Avi Lior Parviz Yegani, Ph.D.
Bridgewater Systems Mobile Wireless Group Bridgewater Systems Mobile Wireless Group
303 Terry Fox Drive Cisco Systems 303 Terry Fox Drive Cisco Systems
Suite 100 3625 Cisco Way Suite 100 3625 Cisco Way
Ottawa Ontario San Jose, CA 95134 Ottawa Ontario San Jose, CA 95134
Canada USA Canada USA
avi@bridgewatersystems.com pyegani@cisco.com avi@bridgewatersystems.com pyegani@cisco.com
Kuntal Chowdhury Lila Madour Kuntal Chowdhury Yong Li
Nortel Networks Ericsson Canada Nortel Networks Bridgewater Systems
2221, Lakeside Blvd, 5400 Decarie, TMR 2221, Lakeside Blvd, 303 Terry Fox Drive
Richardson, TX-75082 Quebec, Canada Richardson, TX-75082 Suite 100
chowdury@nortelnetworks.com Lila.madour@ericsson.ca chowdury@nortelnetworks.com Ottawa Ontario
Canada
Yong Li Yong.li@bridgewatersystems.com
Bridgewater Systems
RADIUS Extensions for PrePaid February 2004
303 Terry Fox Drive
Suite 100
Ottawa Ontario
Canada
Yong.li@bridgewatersystems.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; neither does it represent that it rights might or might not be available; nor does it represent that
has made any effort to identify any such rights. Information on the it has made any independent effort to identify any such rights.
IETF's procedures with respect to rights in standards-track and Information on the IETF's procedures with respect to rights in IETF
standards-related documentation can be found in BCP-11. Copies of Documents can be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementers or users of this specification attempt made to obtain a general license or permission for the use
can be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
RADIUS Extensions for PrePaid February 2004 RADIUS Extensions for PrePaid February 2004
copyrights defined in the Internet Standards process must be Disclaimer of Validity
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and This document and the information contained herein are provided on
will not be revoked by the Internet Society or its successors or an ôAS ISö basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
assigns. This document and the information contained herein is REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright ¨ The Internet Society (2004). 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.
Expiration Date Expiration Date
This memo is filed as draft-lior-radius-extensions-for-prepaid- This memo is filed as draft-lior-radius-extensions-for-prepaid-
03.txt, and will expire 16th July, 2004. 04.txt, and will expire 14 January, 2005.
 End of changes. 163 change blocks. 
758 lines changed or deleted 554 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/