< draft-lior-radius-prepaid-extensions-00.txt   draft-lior-radius-prepaid-extensions-01.txt >
Network Working Group A. Lior Network Working Group A. Lior
INTERNET-DRAFT Bridgewater Systems INTERNET-DRAFT Bridgewater Systems
Category: Informational Category: Informational P. Yegani
draft-lior-radius-prepaid-extensions-00.txt P. Yegani draft-lior-radius-prepaid-extensions-01.txt Cisco
Expires: 25 August 2003 Cisco Expires: 30 December 2003 K. Chowdhury
Nortel
L. Madour
Ericsson Canada
Y. Li Y. Li
Bridgewater Systems Bridgewater Systems
24 February 2003 June 30, 2003
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 This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
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-
skipping to change at page 1, line 43 skipping to change at page 1, line 45
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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
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.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1 Terminology................................................4 1.1 Terminology................................................4
1.2 Requirements language......................................4 1.2 Requirements language......................................4
2. Use-cases......................................................4 2. Use-cases......................................................4
2.1 Simple use-case............................................5 2.1 Simple use-case............................................5
2.2 Support for concurrent Prepaid sessions....................7 2.2 Quota Recovery.............................................6
2.3 Support for Roaming........................................7 2.3 Support for concurrent PrePaid sessions....................7
2.4 Prepaid termination........................................8 2.4 Support for Roaming........................................7
2.5 PrePaid termination........................................8
3. Architecture...................................................8 3. Architecture...................................................8
4. Operations....................................................12 4. Operations....................................................12
4.1 General Requirements......................................12 4.1 General Requirements......................................12
4.1.1 Broker AAA Requirements..............................12 4.1.1 Broker AAA Requirements..............................12
4.2 Authentication and Authorization..........................13 4.2 Authentication and Authorization..........................12
4.3 Session Start Operation...................................15 4.3 Session Start Operation...................................15
4.4 Mid-Session Operation.....................................16 4.4 Mid-Session Operation.....................................15
4.4.1 Accounting Operation.................................16 4.5 Dynamic Operations........................................17
4.4.2 Quota Replenishing Operation.........................16 4.5.1 Unsolicited Session Termination Operation............17
4.5 Dynamic Operations........................................18 4.5.2 Unsolicited Change of Authorization Operation........18
4.5.1 Unsolicited Session Termination Operation............19 4.6 Termination Operation.....................................19
4.5.2 Unsolicited Change Filter Operation..................19 4.7 Mobile IP Operations......................................20
4.6 Termination Operation.....................................20 4.8 Accounting Considerations.................................20
4.7 Mobile IP Operations......................................21 4.9 Interoperability with Diameter............................21
5. Attributes....................................................22 5. Attributes....................................................21
5.1 PPCC attribute............................................22 5.1 PPCC attribute............................................21
5.2 Dynamic-Capabilities attribute............................23 5.2 Dynamic-Capabilities attribute............................22
5.3 PPQ-Response attribute....................................24 5.3 PPAQ Attribute............................................23
5.4 PPQ Attribute.............................................25 5.4 Table of Attributes.......................................26
5.5 Service Type..............................................26
5.6 Table of Attributes.......................................26
6. Security Considerations.......................................26 6. Security Considerations.......................................26
6.1 Authentication and Authorization..........................26 6.1 Authentication and Authorization..........................26
6.2 Accounting Messages.......................................27 6.2 Replenishing Procedure....................................27
6.3 Replenishing Procedure....................................27 7. IANA Considerations...........................................27
7. IANA Considerations...........................................28 8. Normative References..........................................27
8. Normative References..........................................28 Acknowledgments..................................................28
9. Acknowledgments...............................................28 Author's Addresses...............................................28
10. Author's Addresses...........................................29 Intellectual Property Statement..................................28
11. Intellectual Property Statement..............................29 Full Copyright Statement.........................................29
12. Full Copyright Statement.....................................30 Expiration Date..................................................29
Expiration Date..................................................30
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 deliver a data service for either a period
of time, or a quantity of data. The subscriber purchases the Data of time, or a quantity of data. The subscriber purchases the Data
Service using various means such as buying a Prepaid Card, or Service using various means such as buying a PrePaid Card, or
online. How the subscriber purchases his Prepaid Data Service online. How the subscriber purchases his PrePaid Data Service
depends on the deployment and is not in scope for this document. depends on the deployment and is not in scope for this document.
In some deployments, the Prepaid data service will be combined with
a prepaid voice service. This is not an issue for this document
other than the fact that the Prepaid Data Services described in this
paper should work with other prepaid data services.
The fundamental business driver for a carrier to provide prepaid
data services is to increase participation (subscriber base) and
therefore to increase revenues.
Therefore, it makes sense that prepaid services meet the following In some deployments, the PrePaid data service will be combined with
goals: a PrePaid voice service. This is not an issue for this document
other than the fact that the PrePaid Data Services described in this
paper should work with other PrePaid data services.
- Leverage existing infrastructure, hence reducing capital The fundamental business driver for a carrier to provide PrePaid
expenditures typically required when rolling a new service; data services is to increase participation (subscriber base) and
- Protect against revenue loss; thus to increase revenues. Therefore, it makes sense that PrePaid
- Protect against fraud; services meet the following goals:
- Be as widely deployable over Dialup, Wireless and WLAN
networks. - Leverage existing infrastructure, hence reducing capital
expenditures typically required when rolling a new service;
- Protect against revenue loss;
- Protect against fraud;
- Be as widely deployable over Dialup, Wireless and WLAN networks.
The protocol described in this document maximizes existing The protocol described in this document maximizes existing
infrastructure as much as possible - hence the use of the RADIUS infrastructure as much as possible û hence the use of the RADIUS
protocol. The protocol is used in ways to protect against revenue protocol. The protocol is used in ways to protect against revenue
loss or revenue leakage. This is achieved by allocating small loss or revenue leakage. This is achieved by allocating small
quotas to each data session and having the ability to update the quotas to each data session and having the ability to update the
quotas dynamically during the lifetime of a prepaid data session. quotas dynamically during the lifetime of the PrePaid data session.
As well, mechanisms have been designed to be able to recover from As well, mechanisms have been designed to be able to recover from
errors that occur from time to time. errors that occur from time to time.
Protection against fraud is provided by recording of accounting Protection against fraud is provided by recording of accounting
records, by providing mechanisms to thwart replay attacks. As well, records, by providing mechanisms to thwart replay attacks. As well,
mechanisms have been provided to terminate data sessions when fraud mechanisms have been provided to terminate data sessions when fraud
is detected. is detected.
Prepaid System will become more prevalent and sophisticated as the PrePaid System will become more prevalent and sophisticated as the
various networks such as Dialup, Wireless and WLAN converge. This various networks such as Dialup, Wireless and WLAN converge. This
protocol extension is designed to meet the challenges of converged protocol extension is designed to meet the challenges of converged
networks. networks.
The draft mainly addresses how to use the RADIUS protocol to achieve The draft mainly addresses how to use the RADIUS protocol to achieve
a Prepaid Data Service. The details of the Prepaid System, such as a PrePaid Data Service. The details of the PrePaid System, such as
its persistent store, its rating capabilities, how it maintains its its persistent store, its rating capabilities, 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.
1.1 Terminology 1.1 Terminology
Access Device Access Device
Prepaid Client PrePaid Client
Prepaid Server PrePaid Server
Home agent (HA) Home agent (HA)
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
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. Use-cases 2. Use-cases
In this section we present a set of use case that will help In this section we present a set of use cases that will help
establish the requirements needed to deliver a prepaid data service. 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 with a provider. obtained a valid account from a service provider such as a wireless
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 Access Device and not from the UserÆs Device.
The connection between the UserÆs Device, which typically involves The connection between the UserÆs Device, which typically involves
setting up a PPP session is specific to a given network technology setting up a PPP session is specific to a given network technology
and the details are not required to deliver a Prepaid service. and the details are not required to deliver a PrePaid service.
2.1 Simple use-case 2.1 Simple 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 authorize the subscriber. infrastructure to authenticate and authorize the subscriber.
The Access Device sends an Access Request to the AAA system to The Access Device sends a RADIUS Access-Request to the AAA system to
authenticate the subscriber, and identify and authorize the service. authenticate the subscriber, and identify and authorize the service.
The Access Request includes the subscriberÆs credentials and may The Access-Request includes the subscriberÆs credentials and may
include the Prepaid capabilities of the Access Device. Prepaid include the PrePaid capabilities of the Access Device. PrePaid
capabilities will be included if the Access Device has Prepaid capabilities will be included if the Access Device supports PrePaid
Client capabilities. 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. Once the subscriber
has been validated, the AAA system determines that the subscriber is has been validated, the AAA system determines that the subscriber is
a Prepaid subscriber and makes a request of the Prepaid System to a PrePaid subscriber and requests that the PrePaid System authorize
authorize the prepaid subscriber. The request may include the the PrePaid subscriber. The request may include the PrePaid
Prepaid Capabilities of the serving Access Device. Capabilities of the serving 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 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
will include attributes for the Prepaid Client such as, the initial includes attributes such as, an allocation of a portion of the
quota (time or volume) and maybe a threshold value. subscriberÆs account called the initial quota (in units of time or
volume) and optionally a threshold value.
The Prepaid System allocates a portion of the subscribers account so In order to support concurrent PrePaid sessions, at any time, the
that we can support concurrent prepaid sessions. For example, the PrePaid System allocates a portion of the subscribers account to a
subscriber may be on a prepaid voice call and may also have a given PrePaid session. For example, the subscriber may be on a
concurrent prepaid data session. Throughout the life of a session PrePaid voice call and may also have a concurrent PrePaid data
the Access Device will request quota updates from the Prepaid session. Throughout the lifetime of a session the Access Device
System. will request quota updates from the PrePaid System.
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 Response PrePaid System with the service attributes into an Access Response
message that it sends back to the Access Device. Note, the AAA message that it sends back to the Access Device. Note the AAA
System determines the type of service whereas the Prepaid System is System is responsible for authorizing the service whereas the
only responsible for prepaid authorization. PrePaid System is responsible for PrePaid authorization.
Upon receiving the Access Response, the Access Device allows the Upon receiving the Access Response, the Access Device allows the
prepaid data session to start and it starts to meter the session PrePaid data session to start and it starts to meter the session
based on time or volume. based on time or volume.
Once the usage for the session approaches the allotted quota, the Once the usage for the session approaches the allotted quota (as
Access Device will, as instructed by the Prepaid System, request for expressed by the threshold), the Access Device will, as instructed
additional quotas. The re-authorization for additional quota flows by the PrePaid System, request an additional quota. The re-
through the AAA system to the Prepaid System. The Prepaid System authorization for additional quota flows through the AAA system to
revalidates the subscriberÆs account and if there is still a balance the PrePaid System. The PrePaid System revalidates the subscriberÆs
it will reauthorize the request with an additional quota allotment. account; it will subtract the previous quota allocation from the
Otherwise, the Prepaid System will reject the request. Note the userÆs balance and if there is a balance remaining it will
replenishing of the quotas is not a re-authentication procedure but reauthorize the request with an additional quota allotment.
rather a re-authorization procedure. Otherwise, the PrePaid System will reject the request. 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 It is important to note that the PrePaid System is maintaining
session state for the subscriber. In this case the state is how session state for the subscriber. This state includes how much was
much was allocated for the session and how much is left in the allocated during the last quota allocation for a particular session
account. It is required that all subsequent messages about the and how much is left in the account. Therefore, it is required that
prepaid session reach the correct Prepaid System. all subsequent messages about the PrePaid session reach the correct
PrePaid System.
Upon receiving a re-allotment of the quota, the Access Device will, Upon receiving a re-allotment of the quota, the Access Device will,
continue to service until the new threshold is reached. If the continue the data service session until the new threshold is
Access Device receives a rejection, then it will let the subscriber reached. If the Access Device receives a rejection, then it will
use up the remaining quota and then terminate the session. let the subscriber use up the remaining quota and then terminate the
session.
Alternatively, instead of terminating the session, the Access Device Alternatively, instead of terminating the session, the Access Device
may restrict the data session such that the subscriber can only may restrict the data session such that the subscriber can only
reach a particular web server. This web server maybe used to allow reach a particular web server. This web server maybe used to allow
the subscriber to replenish their account. This restriction can the subscriber to replenish their account. This restriction can
also be used to allow new subscribers to purchase a Prepaid Service. also be used to allow new subscribers to purchase a PrePaid Service.
Quota Recovery
2.2 Quota Recovery
In the above scenario, should the subscriber terminate the session In the above scenario, should the subscriber terminate the session
before the session is terminated the remaining balance allotted to before the session the quota is used up, the remaining balance
the session must be credited back to the subscriberÆs account. 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.
2.2 Support for concurrent Prepaid sessions 2.3 Support for concurrent PrePaid sessions
The subscriber at any given time may initiate more than one session. The subscriber at any given time may initiate more than one session.
To support concurrent sessions the Prepaid System allocates a To support concurrent sessions the PrePaid System allocates a
portion of the account to any given session at any given time. portion of the account to any given session at any given time.
Each session is treated independently. Each session is treated independently.
2.3 Support for Roaming 2.4 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 some 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 around and maintain a Dynamic roaming allows to subscriber to move between foreign
connection with the home network seamlessly. As the subscriber networks while maintaining a connection with the home network
moves between networks, the data session is handed off between the seamlessly. As the subscriber moves between networks, the data
networks. 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. As well, subsequent messaging for the session the home network. PrePaid authorization and quota replenishing for
need to be received at the home network and more specifically at the the session need to be received at the home network and more
Prepaid System where state is being maintained. This behavior is specifically at the PrePaid System where state is being maintained.
particularly challenging for dynamic roaming. To illustrate this,
supposing a subscriber establishes a prepaid session and is then
handed off to an Access Device that does not support prepaid
capabilities.
Static roaming is handled by proxy chains of broker AAA servers.
Static roaming or Dynamic roaming is handled by mobile-ip. Note Dynamic roaming is particularly challenging. A subscriber that
mobile-ip may also involve proxy chains. established a PrePaid Data Session may roam to another Access Device
that doesnÆt not support PrePaid functionality. The system should
be capable to continue the PrePaid session.
2.4 Prepaid termination 2.5 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
the PrePaid system explicitly terminate the subscribers PrePaid data
session at an Access Device. For example, if time based PrePaid
service is being used and the mobile subscriber performs a dormant
handoff, the PrePaid System needs to explicitly terminate the
PrePaid session at the old Access Device.
3. Architecture 3. Architecture
A Prepaid Data Service deployment consists of Access Devices, AAA A PrePaid Data Service deployment consists of Access Devices, AAA
servers, and Prepaid Servers. The subscriber device is not servers, and PrePaid Servers. The subscriber device is not
implicated in the delivery of Prepaid Data Services. In mobile-ip, implicated in the delivery of PrePaid Data Services. In mobile-ip,
the Home Agent may also be implicated in delivering a Prepaid Data the Home Agent may also be implicated in delivering a PrePaid Data
Service. Service.
In order to be have as general a solution as possible, in this paper In order to be have as general a solution as possible, in this paper
we generalize the Access Devices, which in reality may be a NAS from we generalize the Access Devices, which in reality may be a NAS from
in Dialup deployments, PDSN in CDMA2000 deployments or an 802.11 in Dialup deployments, PDSN in CDMA2000 deployments or an 802.11
WLAN Access Points. To actively participate in Prepaid procedures WLAN Access Point. To actively participate in PrePaid procedures
outlined here, the Access Device MUST have Prepaid Client outlined here, the Access Device MUST have PrePaid Client
capabilities. Prepaid Client Capabilities include the ability to capabilities. PrePaid Client Capabilities include the ability to
meter the usage for a prepaid data session; this usage includes time meter the usage for a PrePaid data session; this usage includes time
or volume usage. An exception to this rule is during dynamic or volume usage. An exception to this rule is during dynamic
roaming scenarios, where the Access Device can relegate its Prepaid roaming scenarios, where the Access Device can relegate its PrePaid
Client Capabilities to the Home Agent (HA). Furthermore, the Access Client Capabilities to the Home Agent (HA). Furthermore, the Access
Device may also have Dynamic Session Capabilities that include the Device may also have Dynamic Session Capabilities that include the
ability to terminate a data session and/or change the filters ability to terminate a data session and/or change authorization
associated with a specific data session by processing Disconnect attributes associated with a specific data session by processing
Messages and Change of Filter messages as per [CHIBA]. Disconnect Messages and Change of Authorization messages as per
[CHIBA].
In this document RADIUS is used as the AAA server. There are three In this document the AAA server uses the RADIUS protocol. There are
kinds or categories of AAA servers. The AAA server in the home three kinds or categories of AAA servers. The AAA server in the
network, the HAAA, is responsible for authentication of the home 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 roaming deployments the AAA to authorize PrePaid subscribers. In roaming deployments the AAA
server in the visited network, the VAAA, is responsible for 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 and hence donÆt play an responsible for the routing of the RADIUS message to the HAAA.
active roll in the Prepaid Data Service delivery.
In this document the Prepaid Server are described in functional The PrePaid Server is described in functional terms related to itÆs
terms related to their interface with the HAAA. The Prepaid Server interface with the HAAA. The PrePaid Server maintains the
maintains the accounting state of the prepaid subscribers. As well, accounting state of the PrePaid subscribers. As well, the PrePaid
the Prepaid Server maintains state for each active prepaid data Server maintains state for each active PrePaid data service session.
service session. This state includes, allocated quotas, the last This state includes, allocated quotas, the last known activity
known activity counters (time or volume) for the prepaid counters (time or volume) for the PrePaid subscriberÆs data session
subscriberÆs data session. These counters are continuously being and the servicing Access Device. These counters are continuously
updated during the lifetime of the Prepaid data service. being updated during the lifetime of the PrePaid data service.
The various deployments for Prepaid are presented in the remainder The various deployments scenarios for PrePaid are presented in the
of this section. The first deployment is the basic Prepaid data remainder of this section. The first deployment is the basic
service and is depicted in figure 1. Here the Access Device and the PrePaid data service and is depicted in figure 1. Here the Access
HAAA and the Prepaid Server are collocated in the same provider Device and the HAAA and the PrePaid Server are collocated in the
network. same operator 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 Access Device communicates with
one or more HAAA servers in the network. To provide redundancy more one or more HAAA servers in the network. To provide redundancy more
then one HAAA is available to use by an Access Device. then one HAAA is available to use by an 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 will 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 the RADIUS protocol in
this specification. However, in cases where the PPS does not this specification. However, in cases where the PPS does not
implement the RADIUS protocol, the implementation would have to map implement the RADIUS protocol, the implementation would have to map
the requirements defined in this document to whatever protocol is the requirements defined in this document to whatever protocol is
used between the HAAA and the PPS. used between the HAAA and the PPS.
+------+ +-----+ +------+ +-----+
| | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | | | | | | | | | | | |
| Sub | | Access | | +------+ | +-----+ | Sub | | Access | | +------+ | +-----+
| |---| |--+ | | |---| |--+ |
| Device | | Device | | +------+ | +-----+ | Device | | Device | | +------+ | +-----+
| | | | | | | | | | | | | | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | |
+------+ +-----+ +------+ +-----+
Figure 1 Basic Prepaid Architecture Figure 1 Basic PrePaid Architecture
The following figure shows a static roaming prepaid architecture The following figure shows a static roaming PrePaid architecture
that is typical of a wholesale scenario for Dial-Up users or a that is typical of a wholesale scenario for Dial-Up users or a
broker scenario used in Dial-Up or WLAN roaming scenarios. broker scenario used in Dial-Up or WLAN roaming scenarios.
+----+ +----+ +----+ +-----+ +----+ +----+ +----+ +-----+
| | | | | | | | | | | | | | | |
+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Sub | |Access| | +----+ | +----+ | +----+ | +-----+ |Sub | |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 2 Static Roaming Prepaid Architecture Figure 2 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 Access Device (NAS, WLAN Access
Point). The Access Device communicates with the Visiting AAA server Point). The Access Device communicates with the Visiting AAA server
(VAAA) using the RADIUS protocol. Again for redundancy there maybe (VAAA) using the RADIUS protocol. Again for redundancy there maybe
more then one VAAA. The VAAA communicate using the RADIUS protocol more then one VAAA. The VAAA communicate using the RADIUS protocol
with AAA servers in the broker network (BAAA). There maybe more with AAA servers in the broker network (BAAA). There maybe more
then one Broker Network between the Visited Network and the Home then one Broker Network between the Visited Network and the Home
Network. The Home Network is the same as in the simple Network. The Home Network is the same as in the simple
architecture. architecture.
To support dynamic roaming the network will utilize mobile-ip. To support dynamic roaming the network will most likely utilize
Figure 3 illustrates a typical mobile-ip deployment. Note that mobile-ip. Figure 3 illustrates a typical mobile-ip deployment.
typically the mobile device would be moving between networks that Note that typically the mobile device would be moving between
use the same technology such as Wireless or WLAN. Increasingly, networks that use the same technology such as Wireless or WLAN.
device will be able to roam between networks that use different Increasingly, device will be able to roam between networks that use
technology such as between WLAN and Wireless and Broadband. different technology such as between WLAN and Wireless and
Fortunately, mobile-ip can address this type of roaming and Broadband. Fortunately, mobile-ip can address this type of roaming
therefore we need not be concerned with the underlying network and therefore we need not be concerned with the underlying network
technology. technology.
+------+ +------+ +----+ +----+ +----+ +-----+ +------+ +------+ +----+ +----+ +----+ +-----+
| | | | | | | | | | | | | | | | | | | | | | | |
|Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS | |Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS |
| |--|Device| | | | | | | | | | |--|Device| | | | | | | | |
|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
| | | | | | | | | | | |
+------+ +------+ | | +------+ +------+ | |
| | | +----+ | | | +----+
skipping to change at page 11, line 39 skipping to change at page 11, line 39
+------+ +------+ | | | | +------+ +------+ | | | |
| | | | +-|VAAA+------+ | | | | | +-|VAAA+------+ |
|Sub | |Access| | | | | |Sub | |Access| | | | |
| |--|Device+-+ +----+ | | |--|Device+-+ +----+ |
|Device| | (FA) | | |Device| | (FA) | |
| | | +------------------------+ | | | +------------------------+
+------+ +------+ +------+ +------+
Figure 3 Roaming using mobile-ip Figure 3 Roaming using mobile-ip
In the figure 3, the Subscriber device establishes a prepaid session In the figure 3, the Subscriber device establishes a PrePaid session
between the Access Device in the foreign network, which has prepaid between the Access Device in the foreign network, which has PrePaid
capabilities and the Home Agent (HA). The setup for this service is capabilities and the Home Agent (HA). The setup for this service is
identical to the cases covered above. Notice that the Access Device identical to the cases covered above. Notice that the Access Device
is known as the Foreign Agent (FA). As the subscriber device moves is known as the Foreign Agent (FA). As the subscriber device moves
to another network it establishes a connection with another Access to another network it establishes a connection with another Access
Device in another foreign network. The prepaid data service should Device in another foreign network. The PrePaid data service should
continue to be available. When a device associates to another continue to be available. When a device associates to another
Access Device it MUST re-authenticate at the new Access Device and Access Device it MUST re-authenticate at the new Access Device and
de-associate or logoff the old Access Device. Furthermore, any de-associate or logoff the old Access Device. Furthermore, any
unused quota at the old Access Device MUST be promptly credited back unused quota at the old Access Device MUST be promptly credited back
to the subscribers account. The reason we say promptly, is because to the subscribers account. The reason we say promptly, is because
if the subscriber is very low on resources to start with, the if the subscriber is very low on resources to start with, the
subscriber may not have enough resources to log on to the new Access subscriber may not have enough resources to log on to the new 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: dormant handoff vs. active
handoff vs. fast handoff. handoff vs. fast handoff.
skipping to change at page 12, line 31 skipping to change at page 12, line 31
Unfortunately, standards are evolving with each network technology Unfortunately, standards are evolving with each network technology
creating their own scheme to make the handoff procedures more creating their own scheme to make the handoff procedures more
efficient. efficient.
4. Operations 4. Operations
4.1 General Requirements 4.1 General Requirements
4.1.1 Broker AAA Requirements 4.1.1 Broker AAA Requirements
The intent of this document is to minimize the requirement impacts Broker AAA servers MUST support the Message-Authenticator(80)
on the Broker AAA servers. The BAAA servers function is to forward attribute as defined in [RFC2869]. If BAAA servers are used, the
the RADIUS packets as usual to the appropriate RADIUS servers with BAAA servers function is to forward the RADIUS packets as usual to
the following considerations. the appropriate RADIUS servers.
Accounting messages are used to keep the Prepaid Server current as
to what is happening with the prepaid data session. Therefore,
Broker AAA servers SHOULD perform their forwarding function of
accounting packets associated with prepaid data sessions in a pass
through fashion as described in [RFC2866] section 2.1.
In addition, if the BAAA server fails to forward the prepaid data
session accounting packets, it MAY store them locally but it SHOULD
NOT generated an Accounting Response packet back to its client.
The BAAA MUST be capable of supporting the encryption procedures Accounting messages are not needed to deliver a PrePaid service.
specified in [RFC2868] section 3.5. However, accounting messages can be used to keep the PrePaid Server
current as to what is happening with the PrePaid data session.
Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the
pass through mode described in [RFC2866].
4.2 Authentication and Authorization 4.2 Authentication and Authorization
The Access Device initiates the authentication and authorization The Access Device initiates the authentication and authorization
procedure by sending a RADIUS Access Request as usual. procedure by sending a RADIUS Access-Request as usual.
If the Access Device has Prepaid Client capabilities, it MUST If the Access Device has PrePaid Client capabilities, it MUST
include the PPCC attribute in the RADIUS Access Request. The PPCC include the PPCC attribute in the RADIUS Access-Request. The PPCC
attribute indicates to the Prepaid server the prepaid capabilities attribute indicates to the PrePaid server the PrePaid capabilities
possessed by the Access Device. These are required in order to possessed by the Access Device. These are required in order to
complete the prepaid authorization procedures. complete the PrePaid authorization procedures.
The PPCC is encrypted using the same procedure as in [RFC2868]
Section 3.5 and includes the Event-Timestamp(55) which protects
against replay attacks.
If the Access Device supports the Disconnect Message capabilities or If the Access Device supports the Disconnect-Message or the Change-
the Change of Filter Message capabilities, then it SHOULD include of-Auhtorization capabilities, then it SHOULD include the Dynamic-
the Dynamic-Capabilities attribute. The Dynamic-Capabilities Capabilities attribute.
attribute will indicate to the PPS if the Access Device will support
the Disconnect Message or the Change of Filter Message.
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 the filter id on an Access terminate a data session, or change authorization of an active
device. For example, some Access Devices provide a session session. For example, some 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. Request.
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 PPCC attribute and (as in EAP), the Access Device MUST include the PPCC attribute and
the Dynamic-Capabilities attribute (if used) in at least the last the Dynamic-Capabilities attribute (if used) in at least the last
Access Request during the authentication procedure. Access-Request of the authentication procedure.
The Access Request will be sent as usual to the HAAA. The packet
may be proxied through zero or more BAAA. The BAAA SHALL treat the
PPCC as a undistinguished octets and re-encrypt the PPCC as it
forwards the Access Request to the HAAA. No interpretation by the
BAAA should be made.
Once the Access Request arrives at the HAAA, the HAAA will The Access-Request will be sent as usual to the HAAA. The packet
may be proxied through zero or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA will
authenticate the subscriber. If the subscriber is not authenticate the subscriber. If the subscriber is not
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
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 Access subscriber is a PrePaid Subscriber the HAAA SHALL forward the
Request to a Prepaid server for further authorization. Access-Request to a PrePaid server for further authorization.
The Access Request will contain the PPCC attribute, the Dynamic- The Access-Request will contain the PPCC attribute, the Dynamic-
Capabilities attribute if one was included; the User-Name(1) Capabilities attribute if one was included; the User-Name(1)
attribute would be set to a value that would represent the attribute MAY be set to a value that would represent the
SubscriberÆs Prepaid Identity. This attribute will be 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 will validate the Access Request by decrypting
the PPCC and checking the Event-Timestamp(55). The Prepaid server
will lookup the subscriberÆs prepaid account and authorize the
subscriber taking into consideration the Access Device Prepaid
Client Capabilities.
Upon successful authorization, the Prepaid server will generate an The PrePaid server lookups the subscriberÆs PrePaid account and will
Access Accept containing the initial PPQ-Response attribute which authorize the subscriber taking into consideration the Access Device
contains the following sub-attributes: PrePaid Client Capabilities.
-The QUOTA-Id which is set by the Prepaid server to a unique Upon successful authorization, the PrePaid server will generate an
value that is used to correlate subsequent quota updates; Access-Accept containing the PPAQ attribute, which contains the
following sub-attributes:
-Volume and Time Quotas, one of which is set to a value - The QUOTA-Id which is set by the PrePaid server to a unique value
representing a portion of the subscribers account; that is used to correlate subsequent quota requests;
-The Time of Volume Threshold that the Prepaid server MAY set to - Volume and/or Time Quotas, one of which is set to a value
control when the Access Device requests additional quota. representing a portion of the subscribers account;
The Prepaid Referral the first one is set to the IP address of the - MAY contain a Time or Volume Threshold that controls when the
Serving Prepaid Server, the second one is set to an alternate Access Device requests additional quota;
Prepaid Server. This way the HAAA will be able to route subsequent
packets to the serving Prepaid Server or its alternate.
Additionally, the Prepaid server MAY set the Terminate-Action(29) to - The IP address of the Serving PrePaid Server and one or more
RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control alternative PrePaid Servers. This is used by the HAAA to route
how often interim Accounting Requests are generated. subsequent quota replenishing messages to the appropriate PrePaid
server(s).
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, upon unsuccessful authorization, the
Prepaid server will generate an Access Reject or an Access Accept PrePaid server will generate an Access-Reject or an Access-Accept
and set the Filter-Id(11) or the Ascend-Data-Filter (if supported) and set the Filter-Id(11) or the Ascend-Data-Filter (if supported)
attribute and the Session-Timeout(27) attribute such that the attribute and the Session-Timeout(27) attribute such that the
Prepaid subscriber could get access to a restricted set of locations PrePaid subscriber could get access to a restricted set of locations
for a short duration to allow them to replenish their account, or for a short duration to allow them to replenish their account, or
create an account; or to browse free content. create 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
will append the usual service attributes and forward the packet. will append the usual service attributes and forward the packet to
The HAAA SHALL NOT append any attributes already set by the Prepaid the Access Device. The HAAA SHALL NOT append or overwrite any
server. If the HAAA, receives an Access Reject message, it will attributes already set by the PrePaid server. If the HAAA, receives
simply forward the packet to its client. Depending on site an Access-Reject message, it will simply forward the packet to its
policies, if the HAAA fails to receive an Access Response message client. Depending on site policies, if the HAAA fails to receive an
from the Prepaid server it MAY do nothing or send an Access Reject Access-Accept or Access-Reject message from the PrePaid server it
or an Access Accept message back to its client. MAY do nothing or send an Access-Reject or an Access-Accept message
back to its client.
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)
MUST 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.
In addition to the usual attributes, the Accounting Request(Start) Note that the PrePaid Server role is not to record accounting
message MUST contain the PPQ attribute. messages and therefore it SHOULD not respond with an Accounting
Response packet.
HAAA receives the Accounting Request(Start) packet and MAY record
it. If the packet is associated with a prepaid subscriber (it
contains a PPQ attribute) it SHALL forward the packet to the serving
Prepaid server or its secondary if any.
The Prepaid server SHALL respond with an Accounting Response packet
as usual.
The HAAA server SHALL respond with an Accounting Response packet if
it forwarded the Accounting Request(Start) packet to the Prepaid
server and it received the Accounting Response packet; and if it was
responsible for recording the Accounting Request(Start) packet, it
did so successfully.
4.4 Mid-Session Operation 4.4 Mid-Session Operation
During the lifetime of a session the Access Device will generate During the lifetime of a PrePaid data session the Access Device
accounting messages as usual and request to replenish the quotas. SHOULD be configured to generate Accounting-Request (Interim) and
will request to replenish the quotas using Authorize Only Access-
4.4.1 Accounting Operation Request messages.
During the normal data session the Access Device will generate
Accounting Requests(start), Accounting Requests(stop) and Accounting
Request(Interim).
These Accounting records are needed by the Prepaid server to keep an
accurate running usage record for each data session and to be able
to correctly credit the accounts of a prepaid subscriber during
faults.
If these Accounting messages are associated with a Prepaid data
service, then the Access Device MUST include the PPQ attribute.
The HAAA will forward any accounting packets received to the primary
Prepaid server and failing that the secondary Prepaid server
identified in the PPQ attribute.
The HAAA may record the accounting packets locally as well.
The Prepaid Server MUST respond with an Accounting Response packet.
The HAAA server MUST respond with an Accounting Response packet if
it forwarded the Accounting Request packet to the Prepaid server and
it received the Accounting Response packet; and if it was
responsible for recording the Accounting Request packet, it did so
successfully.
4.4.2 Quota Replenishing Operation
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 Access Device MUST send an Access-Request with Service-
Type(6) set to a value of Prepaid and it MUST contain the PPQ Type(6) set to a value of ôAuthorize Onlyö and the PPAQ attribute.
attribute.
The other attributes should be the same as were used in the Access The Access Device MUST also include NAS identifiers, and Session
Request during the Authentication and Authorization phase except for identifier attributes in the Authorize Only Access-Request. The
the User Password or Chap Password, which should be left out. This Session Identifier should be the same as those used during the
Access Request is only used for reauthorization and not re- Access-Request. For example, if the User-Name(1) attribute was used
authentication and the passwords are not required. The encrypted in the Access-Request it MUST be included in the Authorize Only
PPQ attribute acts as the credential for the Access Request. Access-Request especially if the User-Name(1) attribute is used to
route the Access-Request to the Home AAA server.
As during the Authentication and Authorization phase, the BAAA SHALL The Authorize Only Access-Request MUST not include either User
forward the Access Request message to the HAAA validating decrypting Password or Chap Password. In order to authenticate the message,
and re-encrypting the PPQ attribute. Note that the BAAA will treat the Access Device must include the Message-Authenticator(80)
the PPQ as non-distinguished octets. attribute. The Access Device will compute the value for the
Message-Authenticator based on [RFC2869].
The HAAA SHALL receive the Access Request, decrypt the PPQ, validate When the HAAA receives the Authorize-Only Access-Request that
it and use the PPS-referral attributes to route the Access Request contains a PPAQ, it SHALL validate the message using the Message-
to the correct Prepaid server. The HAAA MAY modify the User-Name(1) Authenticator(80) as per [RFC2869]. If the HAAA receives an
attribute as it has done during the initial Access Request. Note Authorize Only Access-Request that contains a PPAQ but not a
the Prepaid server will use the Quota-ID sub-attribute contained Message-Authenticator(80) it SHALL silently discard the message. An
within the PPQ to locate the user account. The HAAA MAY add the Authorize Only Access-Request message that does not contain a PPAQ
Username-Password(2) attribute and set itÆs value to the password it is either in error or belongs to another application (for example, a
shares with the Prepaid server. The HAAA will re-encrypt the PPQ. Change of Authorization message [CHIBA]). In this case the
Authorize Only Access-Request will either be silently discarded or
handled by another application (not in scope of this document).
The Prepaid server will validate the Access Request by decrypting Once the Authorize Only Access-Request message is validated, the
the PPQ and checking the Event-Timestamp. If the User-Password(2) HAAA SHALL forward the Authorize Only Access-Request to the
is specified, the Prepaid server will use it to ensure that the HAAA appropriate PrePaid Server. The HAAA MUST forward the Authorize
is valid. Only Access-Request to the PrePaid server specified in the PPAQ.
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) attribute to a value
that represents the userÆs internal PrePaid account in the PrePaid
server. Note the PrePaid server could use the Quota-ID sub-
attribute contained within the PPAQ to locate the user account.
The Prepaid server will lookup the prepaid session by using the Upon receiving the Authorize Only Access-Request containing a PPAQ
Prepaid Quota Id contained within the PPQ. The Prepaid Server would attribute, the PrePaid server MUST validate the Message-
then re-authorize the subscriber by allotting it a new quota. The Authenticator(80) as prescribed in [RFC2869]. If the message is
Prepaid Server may want to calculate a different threshold values as invalid, the PrePaid server MUST silently discard the message. If
well. it received an Authorize Only Access-Request message that does not
contain a PPAQ it MUST silently discard the message.
Note: At the Prepaid server, the PPQ and the QUOTA-ID is acting as The PrePaid server will lookup the PrePaid session by using the
the credential for the subscriber. The User-Name(1) attribute is PrePaid Quota Id contained within the PPAQ. The PrePaid Server
used to route the Access Request to the correct HAAA. The User- would, take the last allocated quota and subtract that from the
Password if supplied, is used to authenticate the HAAA at the UserÆs balance. If there is remaining balance, the PrePaid server
Prepaid server. re-authorizes the PrePaid session by allocate an additional quota.
The PrePaid server may want to calculate a different threshold
values as well.
Upon successful re-authorization, the Prepaid server will generate Upon successful re-authorization, the PrePaid server will generate
an Access Accept containing the PPQ-Response attribute. an Access-Accept containing the PPAQ attribute. The Access-Accept
message MAY contain Service-Type(6) set to Authorize-Only and MAY
contain the Message-Authenticator(80).
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, upon unsuccessful authorization, the
Prepaid server will generate an Access Reject or an Access Accept PrePaid server will generate an Access-Reject or an Access-Accept
with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute
and the Session Timeout attribute such that the Prepaid subscriber and the Session-Timeout(27) attribute such that the PrePaid
could get access to a restricted set of locations for a short subscriber could get access to a restricted set of locations for a
duration to allow them to replenish their account, or create an short duration to allow them to replenish their account, or create
account. Or to browse free content. The Prepaid server MAY add the an account; or to browse free content.
Terminate-Action(29) attribute with the value of RADIUS-Request, to
allow the Access Device to try to get a new quota allocated before
booting the subscriber off.
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 Response site policies, if the HAAA fails to receive an Access-Accept or an
message from the Prepaid server it MAY do nothing or send an Access Access-Reject message from the PrePaid server it MAY do nothing or
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 Upon receiving an Access-Accept, the Access Device SHALL update its
quotas and threshold parameters with the values contained in the quotas and threshold parameters with the values contained in the
PPQ-Response packet. Note that the Prepaid server MAY update the PPAQ attribute. Note that the PrePaid server MAY update the
PPS-referral attributes and these may have to be saved as well. 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 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 PPClient as advertised in the capabilities that are supported by the Access Device as advertised
Dynamic-Capabilities attribute during Access Request. in the Dynamic-Capabilities attribute during the initial Access-
Request.
There are two type 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 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 the Accounting-Session-Id(44) -MUST provide at least one session identifier such as User-Name(1),
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
Prepaid server send a Disconnect Request packet that MUST contain This capability is described in detail in [CHIBA]. The PrePaid
server send 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 holding that session. the Access Device holding that session.
The HAAA upon receiving the Disconnect Request packet 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 a AAA that can process the Disconnection Request packet. received by the a AAA that is in the same network as the serving
Access Device.
Each AAA MUST have the knowledge to route the packet. How the Each AAA MUST route the Disconnect Request packet. How the routing
routing decision is made is an implementation detail. decision is made is an implementation detail.
Once the Disconnect Request packet reaches a AAA that can act on it. Once the Disconnect Request packet reaches AAA that is in the same
The AAA will either send the Disconnect Request packet to the Access network as the serving Access Device, if the Access Device supports
Device directly or it may have to use SNMP or Telnet to command the Disconnect-Request (as per [CHIBA]), it sends the message directly
Access Device to terminate the session. to the Access Device; otherwise it uses other mechanisms such as
SNMP or Telnet to command the Access Device to terminate the
session.
If the Access Device receives a Disconnect Request packet, it will If the Access Device receives a Disconnect-Request packet, it will
respond with either a Disconnect-ACK packet if it was able to respond with either a Disconnect-ACK packet if it was able to
terminate the session or else it will respond with a Disconnect-NAK terminate the session or else it will respond with a Disconnect-NAK
packet. 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. the session.
If a AAA server was 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. respond with a Disconnect-NAK packet.
Issue: A reason code in the NAK message should be provided so that 4.5.2 Unsolicited Change of Authorization Operation
the prepaid server knows why the Disconnect failed. This may be
under consideration now by Chiba et al.
4.5.2 Unsolicited Change Filter Operation The PrePaid Server MAY send a Change-of-Authorization message as
described in [CHIBA] to restrict internet access when the subscriber
has no more balance.
The Prepaid server sends a Change of Filter packet it MUST contain The PrePaid server sends a Change-of-Authorization packet it MUST
identifiers that will uniquely identify the subscriber session and contain identifiers that will uniquely identify the subscriber
the Access Device serving that session. session and the Access Device serving that session.
The HAAA upon receiving the Change of Filter packet will either act Upon receiving the Change-of-Authorization packet the HAAA will
on it or will proxy it to another AAA server until it is received by either act on it or proxy it to another AAA server until it is
a AAA that can process the Change of Filter packet. received by a AAA server that is in the same network as the serving
Access Device.
Each AAA MUST have the knowledge to route the packet. 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 Filter packet reaches a AAA that can act on it. Once the Change-of-Authorization packet reaches a AAA that is in the
The AAA will either send the Change of Filter packet to the Access same network as the serving Access Device, if the Access Device
Device directly or it may have to use SNMP or Telnet to command the supports Change-of-Authorization message, it will forward the
Access Device to change its filters. message to the Access Device; otherwise, it will use other
mechanisms such as SNMP or Telnet to command the Access Device to
change its filters.
If the Access Device receives a Change of Filter packet, it will If the Access Device receives a Change-of-Authorization packet, it
respond with either a Change of Filter-ACK packet if it was able to will respond with either a Change-of-Authorization-ACK packet if it
change the filter or else it will respond with a Change of Filter - was able to change the filter or else it will respond with a Change-
NAK packet of-Authorization-NAK packet.
If the AAA server is performing the change of filter operation, it If the AAA server is performing the change of filter operation, it
MUST respond with a Change of Filter-ACK message if it successfully MUST respond with a Change-of-Authorization-ACK message if it
or a Change of Filter-NAK packet if it failed to change the filter. successfully or a Change-of-Authorization-NAK packet if it failed to
If a AAA server was unable to route the Change of Filter request it change the filter.
MUST respond with a Change of Filter-NAK packet.
Issue: A reason code in the NAK message should be provided so that If a AAA server was unable to route the Change-of-Authorization it
the prepaid server knows why the Change of Filter failed. MUST respond with a Change-of-Authorization-NAK packet.
4.6 Termination Operation 4.6 Termination Operation
The termination phase is initiated when the Subscriber logs off, the The termination phase is initiated when either: the Subscriber logs
quotas have been consumed, or when the Access Device receives a off; the quotas have been consumed, or when the Access Device
Disconnect Message. In all of these instances, if the session is a receives a Disconnect Message. In all of these instances, if the
prepaid data session, the Access Device will generate and Accounting session is a PrePaid data session, the Access Device will send an
Request (stop) packet that MUST contain the PPQ attribute with Authorize-Only Access-Request message with a PPAQ Update-Reason
Reason set to Terminate. attribute set to either ôClient Service terminationö 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 use the referral information in the PPQ to forward the The HAAA MUST validate the Authorize Only Access-Request using the
Accounting Request(stop) packet to the serving Prepaid Server or its Message-Authenticator(80) as per [RFC2869] and if valid, use the
alternate if needed. The HAAA MAY record the Accounting PrePaidServer subtype in the PPAQ to forward the Authorize Only
Request(stop) packet. Access-Request packet to the serving PrePaid Server or if needed,
its alternate.
The Prepaid Server SHALL use the information contained in the PPQ
attribute of the Accounting Request(stop) packet to adjust the
subscriberÆs balance and to close the session. The Prepaid Server
SHALL respond back with an Accounting Response.
The HAAA SHALL respond with an Access Response packet if it has
received the Access Response from the Prepaid Server, and if it was
responsible for recording the Accounting message, it did so
successfully.
In addition to getting the Accounting Request(stop) packet, at the
end of the data session. In more robust deployments, the Access
Device MAY have been instructed by the Prepaid Server to generate an
Access Request message by the inclusion of the Terminate-Action(29)
attribute with a value of RADIUS-Request in the Access Accept
message. In this case, if the session is prepaid, the Access Device
generates an Access Request that MUST containing the PPQ attribute
with a Service-Type(6) set to Prepaid. The Reason sub-attribute of
the PPQ attribute SHALL be set to Terminate.
The BAAA SHALL forward the Access Request to the next BAAA or the
HAAA.
Upon receiving an Access Request message with Service-Type(6) set to
Prepaid, the HAAA SHALL use the referral information contained in
the PPQ attribute to route the Access Request to the serving Prepaid
Server or its alternate. The HAAA MAY add the User-Password(2)
attribute with the password shared between it and the Prepaid
Server.
Upon the receiving the Access Request, the Prepaid server will The PrePaid Server MUST validate the Authorize Only Access Request
examine the PPQ attribute and use the Quota-ID to locate the session and use the information contained in the PPAQ attribute to adjust
and adjust the subscriberÆs account accordingly and close the the subscriberÆs balance and to close the session. The PrePaid
session. The Prepaid Server SHALL reply with an Access Accept Server SHALL respond back with an Access-Accept message.
message.
4.7 Mobile IP Operations 4.7 Mobile IP Operations
In roaming scenarios using mobile-ip, as the mobile subscriber roams In roaming scenarios using mobile-ip, as the mobile subscriber roams
between networks, or between different types of networks such as between networks, or between different types of networks such as
between WLAN and CDMA2000 networks, the prepaid data session is between WLAN and CDMA2000 networks, the PrePaid data session is
maintained transparently. maintained transparently.
As the subscriber device associates with the new Access Device, the As the subscriber device associates with the new Access Device, the
Access Device sends a RADIUS Access Request and the subscriber is Access Device sends a RADIUS Access-Request and the subscriber is
re-authenticated and reauthorized. If the Access Device has Prepaid re-authenticated and reauthorized. If the Access Device has PrePaid
Client capabilities, it MUST include the PPCC attribute in the Client capabilities, it MUST include the PPCC attribute in the
RADIUS Access Request. In this manner the procedure follows the RADIUS Access-Request. In this manner the procedure follows the
Authentication and Authorization procedure described earlier. Authentication and Authorization procedure described earlier.
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 Access Device will be
returned to the Prepaid system due to the usual mobile-ip handoff returned to the PrePaid system due to the usual mobile-ip handoff
procedures. Specifically, the quota will be returned when the procedures. Specifically, the quota will be returned when the
Access Device sends the Accounting Request (stop) message. The Access Device sends the Authorize Only Access-Request with PPAQ
Prepaid system may issue a Disconnect Message to the Access Device Update-Reason subtype set to either ôRemote Forced disconnectö or
as well. ôClient Service terminationö. In order to trigger the sending of
this last Authorize Only Access-Request, the PrePaid system may
issue a Disconnect Message [CHIBA] to the Access Device.
If the subscriber has roamed to an Access Device that does not have If the subscriber has roamed to an Access Device that does not have
any Prepaid Capabilities, prepaid data service may still be possible any PrePaid Capabilities, PrePaid data service may still be possible
by requesting the Home Agent (providing it has Prepaid Capabilities) by requesting the Home Agent (providing it has PrePaid Capabilities)
to assume responsibilities for metering the service. The procedure to assume responsibilities for metering the service. The procedure
for this scenario will be given in the next release of this draft. for this scenario will be given in the next release of this draft.
4.8 Accounting Considerations
Accounting messages are not required to deliver PrePaid Data
Service. Accounting message will typically be generated for PrePaid
Data Service. This because accounting message are used for auditing
purposes as well as for bill generation.
Accounting messages associated with PrePaid Data Sessions should
include the PPAQ attribute.
4.9 Interoperability with Diameter
RADIUS PrePaid solutions need to interoperate with Diameter
protocol. Two possibilities exist: The AAA infrastructure is
Diameter based and the Access Device are RADIUS based; or the Access
Device is Diameter based and the AAA infrastructure is RADIUS based.
The Diameter Credit Control Application [DIAMETERCC] describes how
to implement a PrePaid using an all Diameter based infrastructure.
<This section to be completed.>
5. Attributes 5. Attributes
As currently written, this draft is using the RADIUS [RFC2865] As currently written, this draft is using the RADIUS [RFC2865]
namespace. namespace.
Subsequent version will probably be written to use VSAs. However, Subsequent version will probably be written to use VSAs. However,
the Vendor Identifier that would be proposed would be Prepaid the Vendor Identifier that would be proposed would be PrePaid
Application. Application.
Note as currently written, this draft proposes to use container Note: as currently written, this draft proposes to use container
types, or attributes that contain sub-attributes, that will have types, or attributes that contain sub-attributes, that will have
attributes from the prepaid space and also attributes belonging to attributes from the PrePaid space and also attributes belonging to
RADIUS space. The technique for encoding such a structure will be RADIUS space. The technique for encoding such a structure will be
identified in future release of this document. identified in future release of this document.
5.1 PPCC attribute Note: The attributes presented in this version of the draft,
represent the bare minimum attributes required to implement a
PrePaid solution. The use of the ôAuthorize Onlyö Pattern allows
the ability to extend PrePaid by adding additional PrePaid VSA in
the future.
The PPCC at tribute is sent in the Access Request message and is 5.1 PPCC attribute
used to describe the Access Devices prepaid capabilities. The The PPCC at tribute is sent in the Access-Request message and is
used to describe the Access Devices PrePaid capabilities. The
attribute is encrypted using the procedures defined in [RFC2868 ] attribute is encrypted using the procedures defined in [RFC2868 ]
section 3.5. section 3.5.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE (Event-Timestamp) | | VALUE (Event-Timestamp) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 37 skipping to change at page 22, line 39
SUB-TYPE 2: value of PP-capabilities SUB-TYPE 2: value of PP-capabilities
LENGTH: 4 LENGTH: 4
DESCRIPTION: DESCRIPTION:
BIT-MAP with the following values: BIT-MAP with the following values:
1 Time metering 1 Time metering
2 Volume metering 2 Volume metering
>2 Reserved >2 Reserved
5.2 Dynamic-Capabilities attribute 5.2 Dynamic-Capabilities attribute
The Dynamic Capabilities attribute is sent in the Access Request and The Dynamic Capabilities attribute is sent in the Access-Request and
describes the capabilities of the Access Device. Mainly it describes the capabilities of the Access Device. Mainly it
describes the method for support for unsolicited session termination describes the method for support for unsolicited session termination
and the method for support of unsolicited change of filters. and the method for support of unsolicited change of filters.
Subtype: Session-Termination-Methods 1 Subtype: Session-Termination-Methods 1
-None -None
-Disconnect-Message [CHIBA] -Disconnect-Message [CHIBA]
-Telnet -Telnet
-SNMP -SNMP
Subtype: Dynamic-Filter-Capabilities 1 Subtype: Dynamic-Authorization-Capabilities 1
-None -None
-CoF [CHIBA] -CoA [CHIBA]
-Telenet -Telenet
-SNMP -SNMP
5.3 PPQ-Response attribute 5.3 PPAQ Attribute
The PPQ-Response attribute is sent in the Access Response and
describes the current quota for a given prepaid data session.
Subtype Quota ID 1
Assigned by the Prepaid server at the start of the session. It is
used to correlate all other transactions for the given prepaid data
session.
Subtype Volume-Quota 0-1
Optional. The maximum number of octets that are allowed for this
session since the beginning of the session.
Subtype Volume-Threshold 0-1
Optional. Defines when to trigger quota replenishment. Current
Octets >= Volume-Threshold.
Subtype Time-Quota 0-1
Optional. The maximum number of seconds that are allowed for this
session as measured from the beginning of the session.
Subtype Time-Threshold 0-1
Optional. Defines when to trigger quota replenishment. Current
Octets >= Time-Threshold
Subtype Action 1 The PPAQ attribute is sent in Authorize Only Access-Request and
Access-Accept messages. In Authorize Only Access-Request messages
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
subsequent quotas).
Defines what to do when the quota has been reached. The attribute consists of a number of subtypes. Subtypes not used
are omitted in the message.
-Drop the session Type: 26
-Replenish Length: variable, greater than 8
Vendor-ID: 5535
Vendor-Type: 90
Vendor-Length: variable, greater than 2
Subtype PPS-Referral 1..2 Sub-Type (=1): Sub-Type for QuotaIDentifier attribute
Length: length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID):
The first PPS-Referral attribute MUST be included and contains the The QuotaIDentifier Sub-Type is generated by the PrePaid server
IP address of the primary serving Prepaid server. The second PPS- at allocation of a Volume and/or Duration Quota. The on-line
Referral attributes MAY be included and contains the IP address of quota update RADIUS Access-Request message sent from the Access
the secondary serving Prepaid server. Device to the PPS shall include a previously received
QuotaIDentifier.
NOTES: Sub-Type (=2): Sub-Type for VolumeQuota attribute
Length: length of VolumeQuota attribute (= 6 octets)
VolumeQuota (VQ):
Either Volume-Quota or Time-Quota MUST appear in the attribute. The optional VolumeQuota Sub-Type is only present if Volume Based
Volume Threshold may only appear if Volume Quota appears charging is used. In RADIUS Access-Accept message (PPS to Access
If the Access Device can measure time, and if Time-Threshold appears Device direction), it indicates the Volume (in octets) allocated
with Volume Quota, then the Access device should trigger a quota for the session by the PrePaid server. In RADIUS Authorize Only
replenishment when the Current Time >= Time-Threshold. Access-Request message (Access Device to PPS direction), it
indicates the total used volume (in octets) for both forward and
reverse traffic applicable to PrePaid accounting.
5.4 PPQ Attribute Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
Length: length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO):
This attribute reports the current prepaid usage at the access The optional VolumeQuotaOverflow Sub-Type is used to indicate how
device. It is contained in both the Access Request messages and many times the VolumeQuota counter has wrapped around 2^32 over
Accounting Requests message. the course of the service being provided.
Subtype Quota ID 1 Sub-Type (=4): Sub-Type for VolumeThreshold attribute
Length: length of VolumeThreshold attribute (= 6 octets)
VolumeThreshold (VT):
The Quota-ID assigned by the Prepaid server during the Access The VolumeThreshold Sub-Type shall always be present if
Response. 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
requesting quota update. This threshold should not be larger than
the VolumeQuota.
Subtype Event-Timestamp(55) 1 Sub-Type (=5): Sub-Type for VolumeThresholdOverflow
Length: length of VolumeThresholdOverflow attribute (= 4 octets)
VolumeThresholdOverflow (VTO):
Used to protect against replay attacks The optional VolumeThresholdOverflow Sub-Type is used to indicate
how many times the VolumeThreshold counter has wrapped around
2^32 over the course of the service being provided.
Subtype Current-Volume 0-1 Sub-Type (=6): Sub-Type for DurationQuota attribute
Length: length of DurationQuota attribute (= 6 octets)
DurationQuota (DQ):
Optional. The current volume in octets since the session started. The optional DurationQuota Sub-Type is only present if Duration
Based charging is used. In RADIUS Access-Accept message (PPS to
Access Device direction), it indicates the Duration (in seconds)
allocated for the session by the PrePaid server. In on-line
RADIUS Access-Accept message (PPC to PPS direction), it indicates
the total Duration (in seconds) since the start of the accounting
session related to the QuotaID.
Subtype Current-Time 0-1 Sub-Type (=7): Sub-Type for DurationThreshold attribute
Length: length of DurationThreshold attribute (= 6 octets)
DurationThreshold (DT):
Optional. The number of seconds since the session started. The DurationThreshold Sub-Type shall always be present if
DurationQuota is present in a RADIUS Access-Accept message (PPS
to Access Device direction). It represents the duration (in
seconds) that shall be used by the session before requesting
quota update. This threshold should not be larger than the
DurationQuota and shall always be sent with the DurationQuota.
Subtype Reason 1 Sub-Type (=8): Sub-Type for Update-Reason attribute
The reason for sending this attribute: Length: length of Update-Reason attribute (= 4 octets)
Update-Reason attribute (UR):
-Interim, The Update-Reason Sub-Type shall be present in the on-line RADIUS
-QuotaReplenish, Access-Request message (Access Device to PPS direction). It
-Terminate indicates the reason for initiating the on-line quota update
operation. Update reasons 4, 5, 6, 7 and 8 indicate that the
associated resources are released at the client side, and
therefore the PPS shall not allocate a new quota in the RADIUS
Access_Accept message.
Subtype PPS-Referral 1..2 1. Pre-initialization
2. Initial request
3. Threshold reached
4. Quota reached
5. Remote Forced disconnect
6. Client Service termination
7. Main SI released
8. Service Instance not established
The IP address of the primary serving Prepaid Server and optionally Sub-Type (=9): Sub-Type for PrePaidServer attribute
the IP address of the secondary serving Prepaid server. Length: Length of PrePaidServer (IPv4 = 6 octets, IPv6= 18 octets
PrePaidServer:
5.5 Service Type The optional, multi-value PrePaidServer indicates the address of
the serving PrePaid System. If present, the Home RADIUS server
uses this address to route the message to the serving PrePaid
Server. The attribute may be sent by the Home RADIUS server. If
present in the incoming RADIUS Access-Accept message, the PDSN
shall send this attribute back without modifying it in the
subsequent RADIUS Access-Request message, except for the first
one. If multiple values are present, the PDSN shall not change
the order of the attributes.
The following is a new value for the Service-Type(6) attribute. NOTES:
12 Prepaid Either Volume-Quota or Time-Quota MUST appear in the attribute.
Volume Threshold may only appear if Volume Quota appears
If the Access Device can measure time, and if Time-Threshold appears
with Volume Quota, then the Access device should trigger a quota
replenishment when the Current Time >= Time-Threshold.
5.6 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
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.
6.1 Authentication and Authorization 6.1 Authentication and Authorization
RADIUS is susceptible to replay attacks during the Authentication RADIUS is susceptible to replay attacks during the Authentication
and Authorization procedures. The protocol given in this draft and Authorization procedures. A successful replay of the initial
prevents replay attacks that can cause havoc such as the depletition Access-Request could result in an allocation of an initial quota.
the subscribers prepaid account.
The Access Request originating at a Prepaid Capable access device
include the PPCC attribute which contains the Event-Timestamp(55)
attribute and the PPCC is encrypted. Therefore the Prepaid System
can use the attribute to detect replay attacks.
6.2 Accounting Messages
Accounting messages are signed by the RADIUS protocol but they are
also susceptible to replay attacks. However, since accounting
messages are designed for recording purposes, no harm come by a
replay attack. The accounting subsystem should be able to detect
and remove duplicate records. Accounting records associated with
prepaid data session contain the PPQ attribute with contains the
Event-Timestamp(55) attribute. Even though Accounting messages are
still only used for record keeping, replay attacks can be detected
and prevented.
6.3 Replenishing Procedure
The Access Request message used in the Replenishing procedure To thwart such an attack...
contains the User-Name(1) attribute but does not contain User-
Password or Chap-Password. This is because this message is used for
Re-authorizing additional quotas. Never-the-less security is a
concern.
The subscriber password is not used because it is only available 6.2 Replenishing Procedure
during subscriber authentication. The Access Device should not keep
the subscriber's password. Furthermore, the password may not have
been available in the first place since the EAP type of
authentication may have been used. EAP only exists during
authentication.
The User-Name(1) attribute contains the NAI of the subscriber. The A successful replay attacks of the Authorize Only Access-Request
purpose of this attribute is to route the Access Request message to could deplete the subscribers prepaid account.
the home network.
The Access Request contains the PPQ attribute which contains the To be completed.
Event-Timestamp(55) and the Quota-ID sub-attributes. This attribute
is encrypted and provides the following security mechanisms. The
inclusion of the Event-Timestamp(55) is used to prevent replay
attacks. The Quota-ID was allocated by the Prepaid server and
uniquely identifies the subscriber. Therefore the Prepaid Server
uses the PPQ attribute as the credential of the subscriber. Since
this attribute is encrypted it forms a very reliable credential for
the prepaid subscriber at the Prepaid server.
7. IANA Considerations 7. IANA Considerations
This draft does create RADIUS attributes nor any new To be completed.
number spaces for IANA administration. 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, is 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.
This draft requires assignment of new values to existing RADIUS
attributes. These include:
Attribute Values Required
========= ===============
Service-Type Prepaid(12)
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,
"Remote Authentication Dial In User Server (RADIUS)", "Remote Authentication Dial In User Server
RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
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.
[CHIBA] Chiba, M., Dommety, G., Eklund, M., Mitton, D., [CHIBA] 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 (RADIUS)", Remote Authentication Dial-In User Service
Internet Draft (work in progress), draft-chiba- (RADIUS)", Internet Draft (work in progress), draft-
radius-dynamic-authorization-07.txt, February 2003. chiba-radius-dynamic-authorization-07.txt, February
2003.
[DIAMETERCC] Work in Progress.
Acknowledgments Acknowledgments
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
Nortel Networks Ericsson Canada
2221, Lakeside Blvd, 5400 Decarie, TMR
Richardson, TX-75082 Quebec, Canada
chowdury@nortelnetworks.com Lila.madour@ericsson.ca
Yong Li Yong Li
Bridgewater Systems Bridgewater Systems
303 Terry Fox Drive 303 Terry Fox Drive
Suite 100 Suite 100
Ottawa Ontario Ottawa Ontario
Canada Canada
Yong.li@bridgewatersystems.com Yong.li@bridgewatersystems.com
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 30, line 32 skipping to change at page 29, line 40
assigns. This document and the information contained herein is assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."
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-
00.txt>, and will expire 25th August, 2003. 01.txt>, and will expire 30th December, 2003.
 End of changes. 197 change blocks. 
636 lines changed or deleted 613 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/