wdiff draft-lior-radius-prepaid-extensions-00.txt draft-lior-radius-prepaid-extensions-01.txt

Network Working Group A. Lior
INTERNET-DRAFT Bridgewater Systems
Category: Informational
draft-lior-radius-prepaid-extensions-00.txt P. Yegani
draft-lior-radius-prepaid-extensions-01.txt Cisco
Expires: 25 August 30 December 2003 Cisco K. Chowdhury
Nortel
L. Madour
Ericsson Canada
Y. Li
Bridgewater Systems
24 February
June 30, 2003

Prepaid

PrePaid Extensions to Remote Authentication Dial-In User Service
(RADIUS)

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The draft presents an extension to the Remote Authentication Dial-In
User Service (RADIUS) protocol to support Prepaid PrePaid data services for
a wide range of deployments such as Dial, Wireless, WLAN.
Consideration for roaming using mobile-ip is also given.

Table of Contents

1. Introduction...................................................3
1.1 Terminology................................................4
1.2 Requirements language......................................4
2. Use-cases......................................................4
2.1 Simple use-case............................................5
2.2 Quota Recovery.............................................6
2.3 Support for concurrent Prepaid PrePaid sessions....................7
2.3
2.4 Support for Roaming........................................7
2.4 Prepaid
2.5 PrePaid termination........................................8
3. Architecture...................................................8
4. Operations....................................................12
4.1 General Requirements......................................12
4.1.1 Broker AAA Requirements..............................12
4.2 Authentication and Authorization..........................13 Authorization..........................12
4.3 Session Start Operation...................................15
4.4 Mid-Session Operation.....................................16
4.4.1 Accounting Operation.................................16
4.4.2 Quota Replenishing Operation.........................16 Operation.....................................15
4.5 Dynamic Operations........................................18 Operations........................................17
4.5.1 Unsolicited Session Termination Operation............19 Operation............17
4.5.2 Unsolicited Change Filter Operation..................19 of Authorization Operation........18
4.6 Termination Operation.....................................20 Operation.....................................19
4.7 Mobile IP Operations......................................21 Operations......................................20
4.8 Accounting Considerations.................................20
4.9 Interoperability with Diameter............................21
5. Attributes....................................................22 Attributes....................................................21
5.1 PPCC attribute............................................22 attribute............................................21
5.2 Dynamic-Capabilities attribute............................23 attribute............................22
5.3 PPQ-Response attribute....................................24 PPAQ Attribute............................................23
5.4 PPQ Attribute.............................................25
5.5 Service Type..............................................26
5.6 Table of Attributes.......................................26
6. Security Considerations.......................................26
6.1 Authentication and Authorization..........................26
6.2 Accounting Messages.......................................27
6.3 Replenishing Procedure....................................27
7. IANA Considerations...........................................28 Considerations...........................................27
8. Normative References..........................................28
9. Acknowledgments...............................................28
10. References..........................................27
Acknowledgments..................................................28
Author's Addresses...........................................29
11. Addresses...............................................28
Intellectual Property Statement..............................29
12. Statement..................................28
Full Copyright Statement.....................................30 Statement.........................................29
Expiration Date..................................................30 Date..................................................29

1. Introduction

This draft describes RADIUS protocol extensions supporting Prepaid PrePaid
Data Services.

Prepaid

PrePaid data services are cropping up in many wireless and wireline
based networks. A Prepaid PrePaid Data Service subscriber is one that
purchases a contract to deliver a data service for either a period
of time, or a quantity of data. The subscriber purchases the Data
Service using various means such as buying a Prepaid PrePaid Card, or
online. How the subscriber purchases his Prepaid PrePaid Data Service
depends on the deployment and is not in scope for this document.

In some deployments, the Prepaid PrePaid data service will be combined with
a prepaid PrePaid voice service. This is not an issue for this document
other than the fact that the Prepaid PrePaid Data Services described in this
paper should work with other prepaid PrePaid data services.

The fundamental business driver for a carrier to provide prepaid PrePaid
data services is to increase participation (subscriber base) and
therefore
thus to increase revenues. Therefore, it makes sense that prepaid PrePaid
services meet the following goals:

- 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
infrastructure as much as possible - û hence the use of the RADIUS
protocol. The protocol is used in ways to protect against revenue
loss or revenue leakage. This is achieved by allocating small
quotas to each data session and having the ability to update the
quotas dynamically during the lifetime of a prepaid the PrePaid data session.
As well, mechanisms have been designed to be able to recover from
errors that occur from time to time.

Protection against fraud is provided by recording of accounting
records, by providing mechanisms to thwart replay attacks. As well,
mechanisms have been provided to terminate data sessions when fraud
is detected.

Prepaid

PrePaid System will become more prevalent and sophisticated as the
various networks such as Dialup, Wireless and WLAN converge. This
protocol extension is designed to meet the challenges of converged
networks.

The draft mainly addresses how to use the RADIUS protocol to achieve
a Prepaid PrePaid Data Service. The details of the Prepaid PrePaid System, such as
its persistent store, its rating capabilities, how it maintains its
accounts are not covered at all. However, in order to define the
RADIUS protocol extensions it is necessary to discuss the functional
behavior of the Prepaid PrePaid System.

1.1 Terminology

Access Device
Prepaid
PrePaid Client
Prepaid
PrePaid Server
Home agent (HA)
Home network
Home AAA (HAAA)
Broker AAA (BAAA)
Visited AAA (VAAA)
Foreign Agent (FA)
WLAN

1.2 Requirements language

In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].

2. Use-cases

In this section we present a set of use case cases that will help
establish the requirements needed to deliver a prepaid PrePaid data service. services.
These use cases donÆt address how the prepaid PrePaid account is established
or maintained. It is assumed that the prepaid PrePaid subscriber has
obtained a valid account with from a service provider such as a provider. wireless
operator or a WLAN operator.

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.
The connection between the UserÆs Device, which typically involves
setting up a PPP session is specific to a given network technology
and the details are not required to deliver a Prepaid PrePaid service.

2.1 Simple use-case

A Prepaid PrePaid subscriber connects to his home network. As usual, the
Access Device that is servicing the subscriber will use the AAA
infrastructure to authenticate and authorize the subscriber.

The Access Device sends an Access Request a RADIUS Access-Request to the AAA system to
authenticate the subscriber, and identify and authorize the service.
The Access Request Access-Request includes the subscriberÆs credentials and may
include the Prepaid PrePaid capabilities of the Access Device. Prepaid PrePaid
capabilities will be included if the Access Device has Prepaid
Client capabilities. supports PrePaid
functionality..

The AAA System proceeds with the authentication procedure. This may
involve several transactions such as in EAP. Once the subscriber
has been validated, the AAA system determines that the subscriber is
a Prepaid PrePaid subscriber and makes a request of requests that the Prepaid PrePaid System to authorize
the prepaid PrePaid subscriber. The request may include the
Prepaid PrePaid
Capabilities of the serving Access Device.

The Prepaid PrePaid System will validate that the subscriber has a Prepaid PrePaid
Account; it will validate that the Account is Active; and will
validate that the Access Device has the appropriate Prepaid PrePaid
capabilities. If all is in order, the Prepaid PrePaid System will authorize
the subscriber to use the network. Otherwise it will reject the
request. The response is sent back to the AAA System. The response
will include
includes attributes for the Prepaid Client such as, an allocation of a portion of the
subscriberÆs account called the initial quota (time (in units of time or
volume) and maybe optionally a threshold value.

The Prepaid

In order to support concurrent PrePaid sessions, at any time, the
PrePaid System allocates a portion of the subscribers account so
that we can support concurrent prepaid sessions. to a
given PrePaid session. For example, the subscriber may be on a prepaid
PrePaid voice call and may also have a concurrent prepaid PrePaid data
session. Throughout the life lifetime of a session the Access Device
will request quota updates from the Prepaid PrePaid System.

The AAA system incorporates the prepaid PrePaid attributes received from the
Prepaid
PrePaid System with the service attributes into an Access Response
message that it sends back to the Access Device. Note, Note the AAA
System determines is responsible for authorizing the type of service whereas the Prepaid
PrePaid System is
only responsible for prepaid PrePaid authorization.

Upon receiving the Access Response, the Access Device allows the
prepaid
PrePaid data session to start and it starts to meter the session
based on time or volume.

Once the usage for the session approaches the allotted quota, quota (as
expressed by the threshold), the Access Device will, as instructed
by the Prepaid PrePaid System, request for an additional quotas. quota. The re-authorization re-
authorization for additional quota flows through the AAA system to
the Prepaid PrePaid System. The Prepaid PrePaid System revalidates the subscriberÆs account
account; it will subtract the previous quota allocation from the
userÆs balance and if there is still a balance remaining it will
reauthorize the request with an additional quota allotment.
Otherwise, the Prepaid PrePaid System will reject the request. Note the
replenishing of the quotas is not a re-authentication procedure but
rather a re-authorization procedure. procedure and does
not involve re-authentication of the subscriber.

It is important to note that the Prepaid PrePaid System is maintaining
session state for the subscriber. In this case the This state is includes how much was
allocated for during the last quota allocation for a particular session
and how much is left in the account. It Therefore, it is required that
all subsequent messages about the
prepaid PrePaid session reach the correct Prepaid
PrePaid System.

Upon receiving a re-allotment of the quota, the Access Device will,
continue to the data service session until the new threshold is
reached. If the Access Device receives a rejection, then it will
let the subscriber use up the remaining quota and then terminate the
session.

Alternatively, instead of terminating the session, the Access Device
may restrict the data session such that the subscriber can only
reach a particular web server. This web server maybe used to allow
the subscriber to replenish their account. This restriction can
also be used to allow new subscribers to purchase a Prepaid PrePaid Service.

2.2 Quota Recovery
In the above scenario, should the subscriber terminate the session
before the session the quota is terminated used up, the remaining balance
allotted to the session must be credited back to the subscriberÆs
account.

As well, while the Access Device is waiting for the initial quota,
the subscriber may have dropped the session. The initial quota must
be credited back to the subscribers account.

2.2

2.3 Support for concurrent Prepaid PrePaid sessions

The subscriber at any given time may initiate more than one session.
To support concurrent sessions the Prepaid PrePaid System allocates a
portion of the account to any given session at any given time.

Each session is treated independently.

2.3

2.4 Support for Roaming

For some networks it is essential that Prepaid PrePaid Data Services be
offered to roaming subscribers. Support for static and dynamic
roaming models are needed. Static roaming is where the subscriber
logs onto a foreign network. The foreign network has some a roaming
agreement directly with the Home home network or through a broker network
or networks. The subscriber remains logged into the network until
the subscriber changes location. When changing location a new
connection and a new login procedure is required.

Dynamic roaming allows to subscriber to move around and maintain between foreign
networks while maintaining a connection with the home network
seamlessly. As the subscriber moves between networks, the data
session is handed off between the networks.

In both roaming scenarios, the subscriber always authenticates with
the home network. As well, subsequent messaging PrePaid authorization and quota replenishing for
the session need to be received at the home network and more
specifically at the
Prepaid PrePaid System where state is being maintained. This behavior

Dynamic roaming is particularly challenging for dynamic roaming. To illustrate this,
supposing a challenging. A subscriber establishes that
established a prepaid session and is then
handed off PrePaid Data Session may roam to an another Access Device
that does doesnÆt 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
mobile-ip may also involve proxy chains.

2.4 Prepaid PrePaid functionality. The system should
be capable to continue the PrePaid session.

2.5 PrePaid termination

When fraud is detected by the Prepaid PrePaid System, or when an error is
detected, it may be beneficial for the Prepaid PrePaid system to terminate a
specific session for the subscriber or all the sessions of a
subscriber.

Some errors can occur such that the Prepaid PrePaid System is in a state
where it is not sure whether the session is in progress or not.
Under conditions such as this, the Prepaid PrePaid system may wish to
terminate the prepaid PrePaid data session to make sure that resources are
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

A Prepaid PrePaid Data Service deployment consists of Access Devices, AAA
servers, and Prepaid PrePaid Servers. The subscriber device is not
implicated in the delivery of Prepaid PrePaid Data Services. In mobile-ip,
the Home Agent may also be implicated in delivering a Prepaid PrePaid Data
Service.

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
in Dialup deployments, PDSN in CDMA2000 deployments or an 802.11
WLAN Access Points. Point. To actively participate in Prepaid PrePaid procedures
outlined here, the Access Device MUST have Prepaid PrePaid Client
capabilities. Prepaid PrePaid Client Capabilities include the ability to
meter the usage for a prepaid PrePaid data session; this usage includes time
or volume usage. An exception to this rule is during dynamic
roaming scenarios, where the Access Device can relegate its Prepaid PrePaid
Client Capabilities to the Home Agent (HA). Furthermore, the Access
Device may also have Dynamic Session Capabilities that include the
ability to terminate a data session and/or change the filters authorization
attributes associated with a specific data session by processing
Disconnect Messages and Change of Filter Authorization messages as per
[CHIBA].

In this document RADIUS is used as the AAA server. server uses the RADIUS protocol. There are
three kinds or categories of AAA servers. The AAA server in the
home network, the HAAA, is responsible for authentication of the
subscriber and also authorization of the service. In addition, the
HAAA communicates with the Prepaid PrePaid servers using the RADIUS protocol
to authorize prepaid PrePaid subscribers. In roaming deployments the AAA
server in the visited network, the VAAA, is responsible for
forwarding the RADIUS messages to the HAAA. The VAAA may also
modify the messages. In roaming deployments, the visited network
may be separated from the home network by one or more broker
networks. The AAA servers in the broker networks, BAAA are
responsible to route for the RADIUS packets and hence donÆt play an
active roll in routing of the Prepaid Data Service delivery.

In this document RADIUS message to the Prepaid HAAA.

The PrePaid Server are is described in functional terms related to their itÆs
interface with the HAAA. The Prepaid PrePaid Server maintains the
accounting state of the prepaid PrePaid subscribers. As well, the Prepaid PrePaid
Server maintains state for each active prepaid PrePaid data service session.
This state includes, allocated quotas, the last known activity
counters (time or volume) for the prepaid PrePaid subscriberÆs data session. session
and the servicing Access Device. These counters are continuously
being updated during the lifetime of the Prepaid PrePaid data service.

The various deployments scenarios for Prepaid PrePaid are presented in the
remainder of this section. The first deployment is the basic Prepaid
PrePaid data service and is depicted in figure 1. Here the Access
Device and the HAAA and the Prepaid PrePaid Server are collocated in the
same provider operator network.

The Subscriber Device establishes a connection with one of several
Access Devices in the network. The Access Device communicates with
one or more HAAA servers in the network. To provide redundancy more
then one HAAA is available to use by an Access Device.

The network will have one or more Prepaid PrePaid Servers. Multiple Prepaid PrePaid
Servers will be used to provide redundancy and load sharing. The
interface between the HAAA and the PPS is the RADIUS protocol in
this specification. However, in cases where the PPS does not
implement the RADIUS protocol, the implementation would have to map
the requirements defined in this document to whatever protocol is
used between the HAAA and the PPS.

+------+ +-----+
| | | |
+--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | |
| Sub | | Access | | +------+ | +-----+
| |---| |--+ |
| Device | | Device | | +------+ | +-----+
| | | | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS |
| | | |
+------+ +-----+

Figure 1 Basic Prepaid PrePaid Architecture

The following figure shows a static roaming prepaid PrePaid architecture
that is typical of a wholesale scenario for Dial-Up users or a
broker scenario used in Dial-Up or WLAN roaming scenarios.

+----+ +----+ +----+ +-----+
| | | | | | | |
+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | |
|Sub | |Access| | +----+ | +----+ | +----+ | +-----+
| |--| |-+ | | |
|Device| |Device| | +----+ | +----+ | +----+ | +-----+
| | | | | | | | | | | | | | | |
+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | |
+----+ +----+ +----+ +-----+

Figure 2 Static Roaming Prepaid PrePaid Architecture

As in the basic prepaid PrePaid architecture the subscriberÆs device
establishes a connection with the Access Device (NAS, WLAN Access
Point). The Access Device communicates with the Visiting AAA server
(VAAA) using the RADIUS protocol. Again for redundancy there maybe
more then one VAAA. The VAAA communicate using the RADIUS protocol
with AAA servers in the broker network (BAAA). There maybe more
then one Broker Network between the Visited Network and the Home
Network. The Home Network is the same as in the simple
architecture.

To support dynamic roaming the network will most likely utilize
mobile-ip. Figure 3 illustrates a typical mobile-ip deployment.
Note that typically the mobile device would be moving between
networks that use the same technology such as Wireless or WLAN.
Increasingly, device will be able to roam between networks that use
different technology such as between WLAN and Wireless and
Broadband. Fortunately, mobile-ip can address this type of roaming
and therefore we need not be concerned with the underlying network
technology.

+------+ +------+ +----+ +----+ +----+ +-----+
| | | | | | | | | | | |
|Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS |
| |--|Device| | | | | | | | |
|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
| | | | | |
+------+ +------+ | |
| | | +----+
| | | | |
|ROAMS +------------------+ HA |
| | | |
V +----+ | +----+
+------+ +------+ | | | |
| | | | +-|VAAA+------+ |
|Sub | |Access| | | | |
| |--|Device+-+ +----+ |
|Device| | (FA) | |
| | | +------------------------+
+------+ +------+

Figure 3 Roaming using mobile-ip

In the figure 3, the Subscriber device establishes a prepaid PrePaid session
between the Access Device in the foreign network, which has prepaid PrePaid
capabilities and the Home Agent (HA). The setup for this service is
identical to the cases covered above. Notice that the Access Device
is known as the Foreign Agent (FA). As the subscriber device moves
to another network it establishes a connection with another Access
Device in another foreign network. The prepaid PrePaid data service should
continue to be available. When a device associates to another
Access Device it MUST re-authenticate at the new Access Device and
de-associate or logoff the old Access Device. Furthermore, any
unused quota at the old Access Device MUST be promptly credited back
to the subscribers account. The reason we say promptly, is because
if the subscriber is very low on resources to start with, the
subscriber may not have enough resources to log on to the new Access
Device. The speed at which resources can be returned depend on the
type of handoff procedure that is used: dormant handoff vs. active
handoff vs. fast handoff.

As well, notice that if the Access Devices could communicate with
each other then there could be a way to accelerate a faster handoff
procedure. In particular, it could accelerate the return of the
unused portion of the quotas from the old Access Device.

Unfortunately, standards are evolving with each network technology
creating their own scheme to make the handoff procedures more
efficient.

4. Operations

4.1 General Requirements

4.1.1 Broker AAA Requirements

The intent of this document is to minimize the requirement impacts
on the

Broker AAA servers. The servers MUST support the Message-Authenticator(80)
attribute as defined in [RFC2869]. If BAAA servers are used, the
BAAA servers function is to forward the RADIUS packets as usual to
the appropriate RADIUS servers with
the following considerations. servers.

Accounting messages are not needed to deliver a PrePaid service.
However, accounting messages can be used to keep the Prepaid PrePaid Server
current as to what is happening with the prepaid 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 deliver RADIUS Accounting Response packet back to its client.

The BAAA MUST be capable of supporting messages using the encryption procedures
specified
pass through mode described in [RFC2868] section 3.5. [RFC2866].

4.2 Authentication and Authorization

The Access Device initiates the authentication and authorization
procedure by sending a RADIUS Access Request Access-Request as usual.

If the Access Device has Prepaid PrePaid Client capabilities, it MUST
include the PPCC attribute in the RADIUS Access Request. Access-Request. The PPCC
attribute indicates to the Prepaid PrePaid server the prepaid PrePaid capabilities
possessed by the Access Device. These are required in order to
complete the prepaid 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 Disconnect-Message or the Change of Filter Message Change-
of-Auhtorization capabilities, then it SHOULD include the Dynamic-Capabilities Dynamic-
Capabilities attribute. The Dynamic-Capabilities
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
terminate a data session, or change the filter id on authorization of an Access
device. active
session. For example, some Access Devices provide a session
termination service via Telnet or SNMP. In these cases cases, the AAA
server MAY add the Dynamic-Capabilities message to the Access Access-
Request.

If the authentication procedure involves multiple Access Requests Access-Requests
(as in EAP), the Access Device MUST include the PPCC attribute and
the Dynamic-Capabilities attribute (if used) in at least the last
Access Request during
Access-Request of the authentication procedure.

The Access Request 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 Access-Request arrives at the HAAA, the HAAA will
authenticate the subscriber. If the subscriber is not
authenticated, the HAAA will send an Access Reject Access-Reject message back to
the client. If the subscriber is authenticated, the HAAA will
determine whether or not the subscriber is a Prepaid PrePaid subscriber.
The techniques used to determine whether or not a subscriber is a
prepaid
PrePaid subscriber is beyond the scope of this document. If the
subscriber is not a prepaid PrePaid subscriber, then the HAAA will respond
as usual with an Access Accept Access-Accept or Access Reject Access-Reject message. If the
subscriber is a Prepaid PrePaid Subscriber the HAAA SHALL forward the Access
Request
Access-Request to a Prepaid PrePaid server for further authorization.

The Access Request Access-Request will contain the PPCC attribute, the Dynamic-
Capabilities attribute if one was included; the User-Name(1)
attribute would MAY be set to a value that would represent the
SubscriberÆs Prepaid PrePaid Identity. This attribute will be is used by the
Prepaid
PrePaid server to locate the Prepaid PrePaid SubscriberÆs account. For
added security, the HAAA MAY also set the User-Password(2) attribute
to the password used between the HAAA and the Prepaid PrePaid server.

The Prepaid PrePaid server will validate the Access Request by decrypting
the PPCC and checking the Event-Timestamp(55). The Prepaid server
will lookup lookups the subscriberÆs prepaid PrePaid account and will
authorize the subscriber taking into consideration the Access Device Prepaid
PrePaid Client Capabilities.

Upon successful authorization, the Prepaid PrePaid server will generate an
Access Accept
Access-Accept containing the initial PPQ-Response attribute PPAQ attribute, which contains the
following sub-attributes:

-The

- The QUOTA-Id which is set by the Prepaid PrePaid server to a unique value
that is used to correlate subsequent quota updates;

-Volume and requests;

- Volume and/or Time Quotas, one of which is set to a value
representing a portion of the subscribers account;

-The

- MAY contain a Time of or Volume Threshold that the Prepaid server MAY set to
control controls when the
Access Device requests additional quota. quota;

- The Prepaid Referral the first one is set to the IP address of the Serving Prepaid Server, the second PrePaid Server and one is set to an alternate
Prepaid Server. or more
alternative PrePaid Servers. This way is used by the HAAA will be able to route
subsequent
packets quota replenishing messages to the serving Prepaid Server or its alternate.

Additionally, the Prepaid server MAY set the Terminate-Action(29) to
RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control
how often interim Accounting Requests are generated. appropriate PrePaid
server(s).

Depending on site policies, upon unsuccessful authorization, the
Prepaid
PrePaid server will generate an Access Reject Access-Reject or an Access Accept Access-Accept
and set the Filter-Id(11) or the Ascend-Data-Filter (if supported)
attribute and the Session-Timeout(27) attribute such that the
Prepaid
PrePaid subscriber could get access to a restricted set of locations
for a short duration to allow them to replenish their account, or
create an account; or to browse free content.

Upon receiving the Access Accept Access-Accept from the Prepaid PrePaid Server, the HAAA
will append the usual service attributes and forward the packet. packet to
the Access Device. The HAAA SHALL NOT append or overwrite any
attributes already set by the Prepaid PrePaid server. If the HAAA, receives
an Access Reject Access-Reject message, it will simply forward the packet to its
client. Depending on site policies, if the HAAA fails to receive an Access Response
Access-Accept or Access-Reject message from the Prepaid PrePaid server it
MAY do nothing or send an Access Reject Access-Reject or an Access Accept Access-Accept message
back to its client.

4.3 Session Start Operation

The real start of the session is indicated by the arrival of
Accounting Request(Start)
Accounting-Request(Start) packet. The Accounting Request Accounting-Request (Start)
MUST
MAY be routed to the Prepaid PrePaid Server so that it can confirm the
initial quota allocation.

In addition to the usual attributes, the Accounting Request(Start)
message MUST contain the PPQ attribute.

HAAA receives the Accounting Request(Start) packet and MAY record
it. If

Note that the packet PrePaid Server role is associated with a prepaid subscriber (it
contains a PPQ attribute) it SHALL forward the packet not 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 record accounting
messages and therefore it SHOULD not 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. packet.

4.4 Mid-Session Operation

During the lifetime of a session the Access Device will generate
accounting messages as usual and request to replenish the quotas.

4.4.1 Accounting Operation

During the normal PrePaid 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
SHOULD be able configured 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 generate Accounting-Request (Interim) 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
will request to replenish the Prepaid server and
it received the Accounting Response packet; and if it was
responsible for recording the Accounting quotas using Authorize Only Access-
Request packet, it did so
successfully.

4.4.2 Quota Replenishing Operation messages.

Once the allocated quota has been reached or the threshold has been
reached, the Access Device MUST send an Access Request Access-Request with Service-
Type(6) set to a value of Prepaid ôAuthorize Onlyö and it MUST contain the PPQ PPAQ attribute.

The other Access Device MUST also include NAS identifiers, and Session
identifier attributes in the Authorize Only Access-Request. The
Session Identifier should be the same as were those used during the
Access-Request. For example, if the User-Name(1) attribute was used
in the Access
Request during Access-Request it MUST be included in the Authentication and Authorization phase except for Authorize Only
Access-Request especially if the User-Name(1) attribute is used to
route the Access-Request to the Home AAA server.

The Authorize Only Access-Request MUST not include either User
Password or Chap Password, which should be left out. This Password. In order to authenticate the message,
the Access Request is only used for reauthorization and not re-
authentication and Device must include the passwords are not required. Message-Authenticator(80)
attribute. The encrypted
PPQ attribute acts as Access Device will compute the credential value for the Access Request.

As during
Message-Authenticator based on [RFC2869].

When the Authentication and Authorization phase, HAAA receives the BAAA Authorize-Only Access-Request that
contains a PPAQ, it SHALL
forward validate the Access Request message to using the Message-
Authenticator(80) as per [RFC2869]. If the HAAA validating decrypting
and re-encrypting receives an
Authorize Only Access-Request that contains a PPAQ but not a
Message-Authenticator(80) it SHALL silently discard the PPQ attribute. Note message. An
Authorize Only Access-Request message that does not contain a PPAQ
is either in error or belongs to another application (for example, a
Change of Authorization message [CHIBA]). In this case the BAAA
Authorize Only Access-Request will treat either be silently discarded or
handled by another application (not in scope of this document).

Once the Authorize Only Access-Request message is validated, the PPQ as non-distinguished octets.

The
HAAA SHALL receive forward the Access Request, decrypt Authorize Only Access-Request to the PPQ, validate
it and use
appropriate PrePaid Server. The HAAA MUST forward the PPS-referral attributes Authorize
Only Access-Request to route the Access Request
to PrePaid server specified in the correct Prepaid server. 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 as it has done during to a value
that represents the initial Access Request. userÆs internal PrePaid account in the PrePaid
server. Note the Prepaid PrePaid server will could use the Quota-ID sub-attribute sub-
attribute contained within the PPQ PPAQ to locate the user account. The HAAA MAY add the
Username-Password(2) attribute and set itÆs value to the password it
shares with

Upon receiving the Prepaid server. The HAAA will re-encrypt Authorize Only Access-Request containing a PPAQ
attribute, the PPQ.

The Prepaid PrePaid server will MUST validate the Access Request by decrypting
the PPQ and checking the Event-Timestamp. Message-
Authenticator(80) as prescribed in [RFC2869]. If the User-Password(2) message is specified,
invalid, the Prepaid PrePaid server will use MUST silently discard the message. If
it to ensure received an Authorize Only Access-Request message that does not
contain a PPAQ it MUST silently discard the HAAA
is valid. message.

The Prepaid PrePaid server will lookup the prepaid PrePaid session by using the
Prepaid
PrePaid Quota Id contained within the PPQ. PPAQ. The Prepaid PrePaid Server would
then re-authorize
would, take the subscriber last allocated quota and subtract that from the
UserÆs balance. If there is remaining balance, the PrePaid server
re-authorizes the PrePaid session by allotting it a new allocate an additional quota.
The
Prepaid Server PrePaid server may want to calculate a different threshold
values as well.

Note: At the Prepaid server, the PPQ and the QUOTA-ID is acting as
the credential for the subscriber. The User-Name(1) attribute is
used to route the Access Request to the correct HAAA. The User-
Password if supplied, is used to authenticate the HAAA at the
Prepaid server.

Upon successful re-authorization, the Prepaid PrePaid server will generate
an Access Accept Access-Accept containing the PPQ-Response 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
Prepaid
PrePaid server will generate an Access Reject Access-Reject or an Access Accept Access-Accept
with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute
and the Session Timeout Session-Timeout(27) attribute such that the Prepaid PrePaid
subscriber could get access to a restricted set of locations for a
short duration to allow them to replenish their account, or create
an
account. Or account; or to browse free content. The Prepaid server MAY add the
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 Access-Accept from the Prepaid PrePaid server, the HAAA
SHALL return the packet to its client. If the HAAA, receives an
Access Reject
Access-Reject message, it will forward the packet. Depending on
site policies, if the HAAA fails to receive an Access Response Access-Accept or an
Access-Reject message from the Prepaid PrePaid server it MAY do nothing or
it MAY send an Access
Reject Access-Reject message back to its client.

Upon receiving an Access Accept, Access-Accept, the Access Device SHALL update its
quotas and threshold parameters with the values contained in the
PPQ-Response packet.
PPAQ attribute. Note that the Prepaid PrePaid server MAY update the
PPS-referral attributes
PrePaidServer attribute(s) and these may have to be saved as well.

Upon receiving an Access Accept Access-Accept message containing either Filter-
Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27).
The Access Device SHALL restrict the subscriber session accordingly.

4.5 Dynamic Operations

The Prepaid PrePaid server may want to take advantage of the dynamic
capabilities that are supported by the PPClient Access Device as advertised
in the Dynamic-Capabilities attribute during Access the initial Access-
Request.

There are two type types of actions that the Prepaid PrePaid server can perform:
it can request that the session be terminated; or it can request
that the filters associated with the session be modified.

Both of these actions require that the session be uniquely
identified at the Access Device. As a minimum the Prepaid PrePaid server:

-MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32)
-MUST provide at least one session identifier such as User-Name(1),
Framed-IP-Address(), the Accounting-Session-Id(44) Accounting-Session-Id(44).

Other attributes could be used to uniquely identify a prepaid PrePaid data
session.

4.5.1 Unsolicited Session Termination Operation

Prepaid

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
the Access Device holding that session.

The HAAA upon

Upon receiving the Disconnect Request packet the HAAA will either
act on it or will proxy it to another AAA server until it is
received by the a AAA that can process is in the Disconnection Request packet. same network as the serving
Access Device.

Each AAA MUST have the knowledge to route the Disconnect Request packet. How the routing
decision is made is an implementation detail.

Once the Disconnect Request packet reaches a AAA that can act on it.
The AAA will either send is in the Disconnect Request packet to same
network as the serving Access Device, if the Access Device directly or supports
Disconnect-Request (as per [CHIBA]), it may have sends the message directly
to use 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 Disconnect-Request packet, it will
respond with either a Disconnect-ACK packet if it was able to
terminate the session or else it will respond with a Disconnect-NAK
packet.

If the AAA server is performing the disconnect operation, it MUST
respond with a Disconnect ACK Disconnect-ACK message if it successfully terminated
the session or a Disconnect NAK Disconnect-NAK message if it failed to terminate
the session.

If a any AAA server was is unable to route the Disconnect request Disconnect-Request it MUST
respond with a Disconnect-NAK packet.

Issue: A reason code in the NAK message should be provided so that
the prepaid server knows why the Disconnect failed. This may be
under consideration now by Chiba et al.

4.5.2 Unsolicited Change Filter of Authorization Operation

The Prepaid 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 Change-of-Authorization packet it MUST
contain identifiers that will uniquely identify the subscriber
session and the Access Device serving that session.

The HAAA upon

Upon receiving the Change of Filter Change-of-Authorization packet the HAAA will
either act on it or will proxy it to another AAA server until it is
received by a AAA server that can process is in the Change of Filter packet. same network as the serving
Access Device.

Each AAA MUST have must route the knowledge packet to route the packet. serving network. How the
routing decision is made is an implementation detail.

Once the Change of Filter Change-of-Authorization packet reaches a AAA that can act on it.
The AAA will either send is in the Change of Filter packet to
same network as the serving Access Device, if the Access Device directly or
supports Change-of-Authorization message, it may have will forward the
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 Change-of-Authorization packet, it
will respond with either a Change of Filter-ACK Change-of-Authorization-ACK packet if it
was able to change the filter or else it will respond with a Change of Filter -
NAK packet Change-
of-Authorization-NAK packet.

If the AAA server is performing the change of filter operation, it
MUST respond with a Change of Filter-ACK Change-of-Authorization-ACK message if it
successfully or a Change of Filter-NAK Change-of-Authorization-NAK packet if it failed to
change the filter.

If a AAA server was unable to route the Change of Filter request Change-of-Authorization it
MUST respond with a Change of Filter-NAK Change-of-Authorization-NAK packet.

Issue: A reason code in the NAK message should be provided so that
the prepaid server knows why the Change of Filter failed.

4.6 Termination Operation

The termination phase is initiated when either: the Subscriber logs off,
off; the quotas have been consumed, or when the Access Device
receives a Disconnect Message. In all of these instances, if the
session is a
prepaid PrePaid data session, the Access Device will generate and Accounting
Request (stop) packet that MUST contain the PPQ attribute send an
Authorize-Only Access-Request message with
Reason a PPAQ Update-Reason
attribute set to Terminate. 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 HAAA MUST validate the Authorize Only Access-Request using the
Message-Authenticator(80) as per [RFC2869] and if valid, use the referral information
PrePaidServer subtype in the PPQ PPAQ to forward the
Accounting Request(stop) Authorize Only
Access-Request packet to the serving Prepaid PrePaid Server or its
alternate if needed. The HAAA MAY record the Accounting
Request(stop) packet.

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. needed,
its alternate.

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 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 validate the
HAAA.

Upon receiving an Authorize Only Access Request message with Service-Type(6) set to
Prepaid, the HAAA SHALL
and use the referral information contained in the PPQ PPAQ 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
examine the PPQ attribute and use the Quota-ID to locate the session
and adjust
the subscriberÆs account accordingly balance and to close the session. The Prepaid PrePaid
Server SHALL reply respond back with an Access Accept Access-Accept message.

4.7 Mobile IP Operations

In roaming scenarios using mobile-ip, as the mobile subscriber roams
between networks, or between different types of networks such as
between WLAN and CDMA2000 networks, the prepaid PrePaid data session is
maintained transparently.

As the subscriber device associates with the new Access Device, the
Access Device sends a RADIUS Access Request Access-Request and the subscriber is
re-authenticated and reauthorized. If the Access Device has Prepaid PrePaid
Client capabilities, it MUST include the PPCC attribute in the
RADIUS Access Request. Access-Request. In this manner the procedure follows the
Authentication and Authorization procedure described earlier.

The Access Request Access-Request message is routed to the home network and MUST
reach the Prepaid PrePaid System that is serving the prepaid PrePaid session. The
Prepaid
PrePaid system will then correlate the new authorization request
with the existing active session and will assign a quota to the new
request. Any outstanding quota at the old Access Device will be
returned to the Prepaid PrePaid system due to the usual mobile-ip handoff
procedures. Specifically, the quota will be returned when the
Access Device sends the Accounting Request (stop) message. The
Prepaid Authorize Only Access-Request with PPAQ
Update-Reason subtype set to either ôRemote Forced disconnectö or
ô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
as well. Device.

If the subscriber has roamed to an Access Device that does not have
any Prepaid PrePaid Capabilities, prepaid PrePaid data service may still be possible
by requesting the Home Agent (providing it has Prepaid PrePaid Capabilities)
to assume responsibilities for metering the service. The procedure
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.

5. Attributes

As currently written, this draft is using the RADIUS [RFC2865]
namespace.

Subsequent version will probably be written to use VSAs. However,
the Vendor Identifier that would be proposed would be Prepaid PrePaid
Application.

Note

Note: as currently written, this draft proposes to use container
types, or attributes that contain sub-attributes, that will have
attributes from the prepaid PrePaid space and also attributes belonging to
RADIUS space. The technique for encoding such a structure will be
identified in future release of this document.

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.

5.1 PPCC attribute
The PPCC at tribute is sent in the Access Request Access-Request message and is
used to describe the Access Devices prepaid PrePaid capabilities. The
attribute is encrypted using the procedures defined in [RFC2868 ]
section 3.5.

TYPE: value of PPCC
LENGTH: 14

SUB-TYPE 1: 55
LENGTH: 6
DESCRIPTION:
The Event-Timestamp as defined by [RFC2869]

SUB-TYPE 2: value of PP-capabilities
LENGTH: 4
DESCRIPTION:
BIT-MAP with the following values:
1 Time metering
2 Volume metering
>2 Reserved

5.2 Dynamic-Capabilities attribute

The Dynamic Capabilities attribute is sent in the Access Request Access-Request and
describes the capabilities of the Access Device. Mainly it
describes the method for support for unsolicited session termination
and the method for support of unsolicited change of filters.

Subtype: Session-Termination-Methods 1
-None
-Disconnect-Message [CHIBA]
-Telnet
-SNMP

Subtype: Dynamic-Filter-Capabilities Dynamic-Authorization-Capabilities 1
-None
-CoF
-CoA [CHIBA]
-Telenet
-SNMP

5.3 PPQ-Response attribute PPAQ Attribute

The PPQ-Response PPAQ attribute is sent in the Access Response Authorize Only Access-Request and
describes
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 current quota for (initial quota and
subsequent quotas).

The attribute consists of a given prepaid data session.

Subtype Quota ID 1

Assigned number of subtypes. Subtypes not used
are omitted in the message.

Type: 26
Length: variable, greater than 8
Vendor-ID: 5535
Vendor-Type: 90
Vendor-Length: variable, greater than 2

Sub-Type (=1): Sub-Type for QuotaIDentifier attribute
Length: length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID):

The QuotaIDentifier Sub-Type is generated by the Prepaid PrePaid server
at allocation of a Volume and/or Duration Quota. The on-line
quota update RADIUS Access-Request message sent from the start Access
Device to the PPS shall include a previously received
QuotaIDentifier.

Sub-Type (=2): Sub-Type for VolumeQuota attribute
Length: length of VolumeQuota attribute (= 6 octets)
VolumeQuota (VQ):

The optional VolumeQuota Sub-Type is only present if Volume Based
charging is used. In RADIUS Access-Accept message (PPS to Access
Device direction), it indicates the session. It Volume (in octets) allocated
for the session by the PrePaid server. In RADIUS Authorize Only
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.

Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
Length: length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO):

The optional VolumeQuotaOverflow Sub-Type is used to correlate all other transactions for indicate how
many times the given prepaid data
session.

Subtype Volume-Quota 0-1

Optional. The maximum number VolumeQuota counter has wrapped around 2^32 over
the course of octets the service being provided.

Sub-Type (=4): Sub-Type for VolumeThreshold attribute
Length: length of VolumeThreshold attribute (= 6 octets)
VolumeThreshold (VT):

The VolumeThreshold Sub-Type shall always be present if
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 are allowed shall be used before
requesting quota update. This threshold should not be larger than
the VolumeQuota.

Sub-Type (=5): Sub-Type for VolumeThresholdOverflow
Length: length of VolumeThresholdOverflow attribute (= 4 octets)
VolumeThresholdOverflow (VTO):

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.

Sub-Type (=6): Sub-Type for this DurationQuota attribute
Length: length of DurationQuota attribute (= 6 octets)
DurationQuota (DQ):

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 beginning start of the session.

Subtype Volume-Threshold 0-1

Optional. Defines when accounting
session related to trigger quota replenishment. Current
Octets >= Volume-Threshold.

Subtype Time-Quota 0-1

Optional. The maximum number the QuotaID.

Sub-Type (=7): Sub-Type for DurationThreshold attribute
Length: length of seconds DurationThreshold attribute (= 6 octets)
DurationThreshold (DT):

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 are allowed for this shall be used by the session as measured from before requesting
quota update. This threshold should not be larger than the
DurationQuota and shall always be sent with the beginning DurationQuota.

Sub-Type (=8): Sub-Type for Update-Reason attribute
Length: length of Update-Reason attribute (= 4 octets)
Update-Reason attribute (UR):

The Update-Reason Sub-Type shall be present in the session.

Subtype Time-Threshold 0-1

Optional. Defines when on-line RADIUS
Access-Request message (Access Device to trigger PPS direction). It
indicates the reason for initiating the on-line quota replenishment. Current
Octets >= Time-Threshold

Subtype Action 1

Defines what to do when 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 has been reached.

-Drop in the session
-Replenish

Subtype PPS-Referral 1..2 RADIUS
Access_Accept message.

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

Sub-Type (=9): Sub-Type for PrePaidServer attribute
Length: Length of PrePaidServer (IPv4 = 6 octets, IPv6= 18 octets
PrePaidServer:

The first PPS-Referral attribute MUST be included and contains optional, multi-value PrePaidServer indicates the
IP address of
the primary serving Prepaid server. The second PPS-
Referral attributes MAY be included and contains PrePaid System. If present, the IP Home RADIUS server
uses this address of to route the message to the secondary serving Prepaid 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.

NOTES:

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.4 PPQ Attribute

This attribute reports the current prepaid usage at the access
device. It is contained in both the Access Request messages and
Accounting Requests message.

Subtype Quota ID 1

The Quota-ID assigned by the Prepaid server during the Access
Response.

Subtype Event-Timestamp(55) 1

Used to protect against replay attacks

Subtype Current-Volume 0-1

Optional. The current volume in octets since the session started.

Subtype Current-Time 0-1

Optional. The number of seconds since the session started.

Subtype Reason 1
The reason for sending this attribute:

-Interim,
-QuotaReplenish,
-Terminate

Subtype PPS-Referral 1..2

The IP address of the primary serving Prepaid Server and optionally
the IP address of the secondary serving Prepaid server.

5.5 Service Type

The following is a new value for the Service-Type(6) attribute.

12 Prepaid

5.6 Table of Attributes

TO BE COMPLETED.

Request Accept Reject Challenge # Attribute

Authorize_Only Request Accept Reject

6. Security Considerations

The protocol exchanges described are susceptible to the same
vulnerabilities as RADIUS and it is recommended that IPsec be
employed to afford better security.

If IPsec is not available the protocol in this draft improves the
security of RADIUS. The various security enhancements are explained
in the following sections.

6.1 Authentication and Authorization

RADIUS is susceptible to replay attacks during the Authentication
and Authorization procedures. The protocol given in this draft
prevents A successful replay attacks that can cause havoc such as the depletition
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 of the attribute to detect replay attacks. initial
Access-Request could result in an allocation of an initial quota.

To thwart such an attack...

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
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
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
purpose of this attribute is to route the Access Request message to
the home network.

The Access Request contains the PPQ attribute which contains the
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

A successful 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 attacks of the subscriber. Since
this attribute is encrypted it forms a very reliable credential for Authorize Only Access-Request
could deplete the subscribers prepaid subscriber at the Prepaid server. account.

To be completed.

7. IANA Considerations

To be completed.

This draft does create RADIUS attributes nor any new
number spaces for IANA administration. attributes. However, the authors
recognize that it may not be possible to obtain such attributes.
Therefore, is in subsequent drafts it will be proposed to use a Vendor
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

[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Server
(RADIUS)", RFC 2865, June 2000.

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
2000.

[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS
Extensions", RFC 2869, June 2000.

[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
Holdrege, M., Goyret, I., "RADIUS Attributes for
Tunnel Protocol Support" , RFC 2868, June 2000.
[CHIBA] Chiba, M., Dommety, G., Eklund, M., Mitton, D.,
Aboba, B., "Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service
(RADIUS)", Internet Draft (work in progress), draft-chiba-
radius-dynamic-authorization-07.txt, draft-
chiba-radius-dynamic-authorization-07.txt, February
2003.

[DIAMETERCC] Work in Progress.

Acknowledgments

Author's Addresses

Avi Lior Parviz Yegani, Ph.D.
Bridgewater Systems Mobile Wireless Group
303 Terry Fox Drive Cisco Systems
Suite 100 3625 Cisco Way
Ottawa Ontario San Jose, CA 95134
Canada USA
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
Bridgewater Systems
303 Terry Fox Drive
Suite 100
Ottawa Ontario
Canada
Yong.li@bridgewatersystems.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expiration Date

This memo is filed as <draft-lior-radius-extensions-for-prepaid-
00.txt>,
01.txt>, and will expire 25th August, 30th December, 2003.