ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Standards Track Dave Lidyard
<draft-ietf-roamops-actng-03.txt> Telco Research Corporation
28 July 1997 John R. Vollbrecht
Merit Network, Inc.
Session Record Accounting in Roaming
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-roamops-actng-03.txt>, and expires February 1, 1998. Please
send comments to the authors.
2. Abstract
This document describes the problems arising in session record
accounting in roaming systems, and proposes a standard accounting
record format.
3. Introduction
As detailed in [2], solution of the accounting problem in roaming
requires several elements to be put in place:
1. Mechanisms for real-time accounting should be provided in order
to support those ISPs who use these mechanisms for simultaneous
session control, fraud detection, and risk management.
2. A standardized accounting record format must be provided in
order to allow ISPs to communicate session accounting information
to the roaming consortia as well as to each other.
Mechanisms for real-time accounting are addressed in [24]. This
Aboba, Lidyard & Vollbrecht [Page 1]
INTERNET-DRAFT 28 July 1997
document concentrates on issues relating to session record accounting.
3.1. Terminology
This document frequently uses the following terms:
Network Access Server
The Network Access Server (NAS) is the device that clients
contact in order to get access to the network.
Accounting
The goal of network accounting is to accurately measure and
record metrics relevant to the analysis of usage and the
billing of users and organizations.
Interim accounting
An interim accounting packet provides a snapshot of usage
during a user's session. It is typically implemented in
order to provide for partial accounting of a user's session
in the event of a NAS reboot or other network problem that
prevents the reception of a session summary packet or ses-
sion record.
Session record
A session record represents a summary of the resource con-
sumption of a user over the entire session. Accounting gate-
ways creating the session record may do so by processing
interim accounting events.
Accounting Protocol
A protocol used for the communication of accounting events.
Intra-organizational accounting event
An intra-organizational accounting event is one which is
generated by the local ISP's customers.
Inter-organizational accounting event
An inter-organizational accounting event is one which is
generated by customers of other ISPs.
Accounting Gateway
The accounting gateway is a server which receives accounting
protocol packets from network devices such as a NASes and
routers and produces session records. In the case where
accounting packets describe an intra-organizational account-
ing event, accounting gateways handle the transmission of
accounting data to other accounting gateways or billing
servers. In the case where accounting data describes an
inter-organizational accounting event, accounting gateways
transmit session records to the organizational billing
server. Accounting Gateways providing real-time accounting
services proxy inter-organizational accounting packets to
other accounting gateways. Accounting gateways providing
Aboba, Lidyard & Vollbrecht [Page 2]
INTERNET-DRAFT 28 July 1997
session record accounting services transmit inter-organiza-
tional session records to other accounting gateways.
Billing Server
The Billing Server is a server which receives accounting
data from accounting gateways, and translates this informa-
tion into bills.
Accounting Agent
The function of the accounting agent is to compute charges
owed by member organizations. While a roaming consortium may
act as the accounting agent, it is also possible for ISPs to
settle among themselves.
4. Overview
The goal of accounting in roaming is to enable ISPs to be compensated
for use of their network infrastructure by roaming users, as well as
to control fraud and audit usage.
The roaming accounting architecture supports both real-time account-
ing, and session record accounting. It is expected that real-time and
session record accounting will be simultaneously deployed in some
roaming implementations, and therefore these accounting methods are
not mutually exclusive.
Real-time accounting is a practical necessity in many roaming systems,
since it provides for simultaneous session control and real-time moni-
toring of funds balances, allowing roaming consortia participants to
better manage risk. The real-time accounting architecture requires use
of the RADIUS accounting protocol, described in [4]. As described in
[24], when real-time accounting is used, RADIUS accounting packets are
proxied between the local ISP's NAS and the home RADIUS accounting
server, on the same path as RADIUS authentication packets. This path
is known as the roaming relationship path.
However, real-time accounting does not satisfy all accounting require-
ments in roaming systems. Currently, there is no standards-track
accounting protocol. In situations where ISPs within a roaming consor-
tium do not support RADIUS, it may be desirable to exchange accounting
information via use of a standard accounting record format. Due to the
limitations of RADIUS accounting, real-time accounting cannot provide
end-to-end security. As a result, it may be desirable to deploy a ses-
sion-record accounting mechanism in concert with a secure accounting
record transfer method so as to provide end-to-end security for
accounting information.
When session record accounting is used, session records are submitted
by the local ISP to the accounting agent, and subsequently copied to
the other entities on the roaming relationship path, typically being
transferred in batches. This reduces the overhead of providing
improved security, making it possible to digitally sign accounting
record bundles, and transmit them in encrypted form. The subject of
Aboba, Lidyard & Vollbrecht [Page 3]
INTERNET-DRAFT 28 July 1997
signed and encrypted transfers, while outside the scope of this docu-
ment, is addressed in references [6]-[12].
4.1. Session record accounting
The session record accounting architecture involves interactions
between network devices such as NASes and routers, accounting gate-
ways, billing servers, and accounting servers.
Accounting data received by the accounting gateway fall into two cate-
gories: intra-organizational accounting events, which are events gen-
erated by local customers; and inter-organizational accounting events,
which are events generated by customers from other members of the
roaming consortia. One of the functions of the accounting gateway is
to distinguish between the two types of events and route them appro-
priately. For accounting events originating on a local ISP, intra-
organizational accounting events are routed to the local billing
server, while inter-organizational accounting events will be routed to
accounting gateways operating at other organizations. While it is not
required that session record formats used in inter and intra-organiza-
tional accounting transfers be the same, this is highly desirable,
since this eliminates translations that would otherwise be required.
When the accounting agent's accounting gateway receives inter-organi-
zational events from a local ISP's accounting gateway, it routes the
events to the billing server, and in addition may send copies to the
home ISP. Copies are provided in order to enable the home ISP to audit
accounting agent charges, as well to bill back to the originating
domain. It should be noted that it is also possible for local ISPs to
send copies directly, rather than relying on the accounting agent for
this function.
Once received by the home ISP, the copied accounting records will be
processed by the home ISP's billing server, and will also typically be
copied to the originating organization.
The purpose of a billing server is to provide billing and auditing
services. In order to provide this services, billing servers import
session records provided to them by the accounting gateway.
In order to provide accounting capabilities, accounting gateways must
support session record accounting and may support real-time account-
ing. Accounting gateways supporting real-time accounting must support
the RADIUS accounting protocol, described in [4]. Accounting gateways
supporting session record accounting must send and receive accounting
records in a standardized format, described in this document.
Required support for session record accounting allows ISPs not using
RADIUS accounting to participate in roaming. Today there is no
accounting protocol on the standards track, and as a result, a variety
of accounting protocols have been deployed, including SNMP, TACACS+,
RADIUS, and SYSLOG.
Aboba, Lidyard & Vollbrecht [Page 4]
INTERNET-DRAFT 28 July 1997
The diagram below illustrates the architecture for session-record
accounting:
+------------+ +------------+ +------------+
| | | | | |
| ISPB | | ISPA | | ISPA |
| Router | | Billing |<---------| Acctg. |
| | | Server | | Gateway |
| | | | | |
+------------+ +------------+ +------------+
| ^
Accounting | |
Protocol | Inter-organizational |
(RADIUS, | Accounting Events |
SNMP, | |
Syslog, | |
TACACS+, | |
etc.) | |
V V
+------------+ +------------+
| | | |
| ISPB | Inter-organizational | ISPGROUP |
| Acctg. |<----------------------------->| Acctg. |
| Gateway |\ Accounting Events | Gateway |
| | \ | |
| | \ | |
+------------+ \ +------------+
^ \ |
| \ Intra-organizational |
Accounting | \ Accounting Events |
Protocol | \ |
(RADIUS, | \ |
SNMP, | \ |
Syslog, | \ |
TACACS+, | \ |
etc.) | \ |
| \ V
+------------+ +------------+ +------------+
| | | | | |
| ISPB | | ISPB | | ISPGROUP |
| NAS | | Billing | | Billing |
| | | Server | | Server |
| | | | | |
+------------+ +------------+ +------------+
^
PPP |
Protocol |
|
V
+------------+
| |
| Fred |
| |
+------------+
Aboba, Lidyard & Vollbrecht [Page 5]
INTERNET-DRAFT 28 July 1997
4.2. Example
Let us assume that we have a roaming user Fred, who works at BIGCO.
BIGCO has established a relationship with ISPA, who has joined the
roaming consortia ISPGROUP. Fred now travels to another part of the
world and wishes to dial in to the network provided by ISPB.
ISPB will account for Fred's resource usage, and will submit a session
record to ISPGROUP for compensation. ISPGROUP will in turn bill ISPA,
who will bill BIGCO. Eventually BIGCO will pay ISPA, ISPA will pay
ISPGROUP, and ISPGROUP will pay ISPB. In order for all parties to
verify that they have been properly charged or compensated for Fred's
session, the following events must occur:
ISPB: Network devices generate accounting data for Fred
ISPB: Accounting gateway generates a session record for Fred
ISPB: Accounting gateway routes the session record to
ISPGROUP and to the local billing server
ISPB: Billing server processes the session record,
credits ISPGROUP account
ISPGROUP: Accounting gateway routes the session record to the
accounting server and to ISPA
ISPGROUP: Accounting server processes the session record,
credits ISPA account, debits ISPB account
ISPA: Accounting gateway routes the session record to the
local billing server and to BIGCO
ISPA: Billing server processes the session record,
credits BIGCO account, debits ISPGROUP account
BIGCO: Accounting gateway routes the session record to the
local billing server
BIGCO: Billing server processes the session record,
credits Fred's account, credits ISPA account.
Each of these events is discussed below.
4.3. ISPB network devices generate accounting data for Fred
In order to keep track of network resources consumed by Fred, ISPB's
accounting gateway will collect accounting data produced by network
devices such as routers and NASes. This data may be produced in many
forms, and may be communicated via a variety of protocols, including
RADIUS, TACACS+, SNMP, and SYSLOG. The accounting data may be trans-
mitted from network devices to the accounting gateway (as in RADIUS,
TACACS+, SYSLOG, or SNMP traps), or the accounting gateway may poll
for the data (via SNMP GETs).
Accounting data may refer to resources consumed over the life of a
session, or it may be a checkpoint event. Checkpoint events refer to
resource consumption at a specific point in time, rather than repre-
senting a summary of resources consumed over a session. Prior to
transfer to a billing server or accounting agent, checkpoint events
are typically summarized into a session record.
Aboba, Lidyard & Vollbrecht [Page 6]
INTERNET-DRAFT 28 July 1997
4.4. ISPB accounting gateway generates a session record for Fred
Since there is currently no standards-track network accounting proto-
col, ISP accounting practices vary more widely than authentication
practices, where RADIUS authentication is very widely deployed. As a
result, it appears difficult to standardize on an accounting protocol
that can be used for communication between ISPs and a accounting
agent. Therefore, the roaming accounting architecture anticipates that
while ISPs will use an accounting protocol of their choice to communi-
cate accounting information between network devices and the accounting
gateway, a standardized accounting record format and transfer method
will be used for communication between accounting gateways.
In order to allow for transmission of accounting information to the
accounting agent, ISPB will summarize the accounting information
relating to Fred's session in a standard session record format.
4.5. ISPB accounting gateway routes the session record to ISPGROUP
and to the local billing server
ISPB's accounting gateway examines Fred's session record, and routes
it to the appropriate destinations. It does this based on whether the
accounting records refer to transactions occurring within the ISP's
organization, or whether they refer to transactions occurring between
organizations. In this case, since Fred is a roaming user, this is an
inter-organizational accounting event, and the accounting gateway will
send session record to the accounting agent, as well as to the local
biling server. In this example, the accounting agent is run by ISP-
GROUP, but it could just as easily be run by ISPA, in which case the
two ISPs would settle directly.
When routing accounting record bundles, ISPB's accounting gateway
machine will operate as an S/MIME or PGP/MIME-enabled SMTP server. In
order to improve efficiency, the accounting gateway will sort account-
ing records into bundles prior to mailing them to their destination.
When a suitable bundle of accounting records has been accumulated, the
accounting gateway will initiate the transfer. In this case, Fred's
accounting record will be sent to multiple destinations.
While intra-organizational accounting transfers typically will not
require signed accounting bundles or signed receipts, it still may
prove useful to request that a receipt be generated in order to be
able to confirm the success of the transfer. Use of receipts will
allow an accounting gateway to keep track of discrepancies between the
number of accounting record bundles it believes were successfully sent
to the local billing server, and the number of receipts collected.
These discrepancies can be used to detect partially completed account-
ing record transfers and to retransmit them.
When used to transfer an accounting record bundle to the accounting
agent, ISPB will encrypt the bundle, as well as signing it, and will
request a signed receipt.
Aboba, Lidyard & Vollbrecht [Page 7]
INTERNET-DRAFT 28 July 1997
4.6. ISPB billing server processes the session record, credits ISP-
GROUP account
In order to allow itself to audit the charges and/or compensation
offered by ISPGROUP, ISPB's billing server will process Fred's session
record and credit the ISPGROU account (an asset). If SMTP is used to
transmit the session record between the accounting gateway and billing
server, then the billing server will need to retrieve the accounting
record bundle from its mailbox and process it, sending a receipt in
response to the accounting gateway's request.
4.7. ISPGROUP accounting gateway routes the session record to the
accounting server and to ISPA
Once ISPGROUP receives the signed and encrypted accounting record bun-
dle from ISPB, it will send back a signed receipt as requested, and in
addition will verify the signature, decrypt the bundle, and then send
copies to the accounting server as well as to ISPA. This is done in
order to enable ISPA to audit the bill received from ISPGROUP, as well
as to bill back BIGCO for the charges. In transferring the accounting
record bundle to ISPA, ISPGROUP will encrypt it, and sign it, in addi-
tion to requesting a receipt.
4.8. ISPGROUP accounting server processes the session record, credits
ISPA account, debits ISPB account
ISPGROUP's accounting server processes the session record, and as a
result, ISPA's account (an asset) is credited, and ISPB's account (an
asset) is debited. If SMTP is used to transmit the session record
between ISPGROUP's accounting gateway and the accounting server, then
the accounting server will need to retrieve the accounting record bun-
dle from its mailbox and process it, sending a receipt in response to
the accounting gateway's request.
4.9. ISPA accounting gateway routes the session record to the local
billing server and to BIGCO
Once ISPA has received the signed accounting record bundle from ISP-
GROUP, it will send back a signed receipt as requested, and in addi-
tion will verify the signature, decrypt the bundle, and then send
copies to the local billing server as well as to BIGCO. This is done
in order to enable BIGCO to audit the bill for Fred's usage.In trans-
ferring the accounting record bundle to BIGCO, ISPA will encrypt it,
and sign it, in addition to requesting a receipt.
4.10. ISPA billing server processes the session record, credits BIGCO
account, debits ISPGROUP account
ISPA's billing server processes the session record, and as a result,
BIGCO's account (an asset) is credited, and ISPGROUP's account (an
asset) is debited. If SMTP is used to send the session record between
ISPA's accounting gateway and the billing server, then the billing
server will need to retrieve the accounting record bundle from its
mailbox and process it, sending a receipt in response to the
Aboba, Lidyard & Vollbrecht [Page 8]
INTERNET-DRAFT 28 July 1997
accounting gateway's request.
4.11. BIGCO accounting gateway routes the session record to the local
billing server
Once BIGCO has received the signed accounting record bundle from ISPA,
it will send back a signed receipt as requested, and in addition will
verify the signature, decrypt the bundle, and then forward the message
to the local billing server.
4.12. BIGCO billing server processes the session record, credits
Fred's account, credits ISPA account
BIGCO's billing server processes the session record, and as a result,
Fred's account (an asset) is credited, as is ISPA's account (a liabil-
ity). If SMTP is used to transit the session record between BIGCO's
accounting gateway and the billing server, then the billing server
will need to retrieve the accounting record bundle from its mailbox
and process it, sending a receipt in response to the accounting gate-
way's request.
4.13. Accounting transfer protocols
In order for session records to be transmitted between accounting
gateways, a transfer protocol is required. While the discussion of
transfer protocols is outside the scope of this document, roaming con-
sortia concerned about securing the transport of accounting data are
advised to consult the documents under development within the EDIINT
Working Group.
As described in [12], Internet Electronic Document Interchange (EDI)
provides for encryption and digital signatures as well as requests for
signed receipts. Since these features are also of interest in a wide
variety of EDI and Electronic Commerce (EC) applications, the EDIINT
working group has been chartered to standardize their use over the
Internet. For further information on the mechanisms proposed for
secure EDI over the Internet, please consult references [6] - [12].
It should be noted that in order to make use of the techniques pro-
posed in [11], it is not required that accounting record formats con-
form to EDI standards such as UN/EDIFACT or EDI X.12, although this
may be desirable in some circumstances. What is required is that a
MIME type be defined for the accounting record format.
4.14. Accounting metrics
Accounting in a roaming environment requires adherence to standards
which allow access to be measured, rated, assigned, and communicated
between appropriate service providers. In this inter-provider envi-
ronment, there is a need for a set of controls that can be used to
audit billing practices and to mediate billing disputes. The founda-
tion for satisfying these requirements is the content of the
Aboba, Lidyard & Vollbrecht [Page 9]
INTERNET-DRAFT 28 July 1997
accounting record. The goal of the accounting record is to identify
who is accessing the network, who is providing the access service,
from what location is access being provided, and when the accesses
occur.
The identity of the user, their home ISP, and service privileges are
the key elements for authenticating, authorizing, and assigning cost.
These components allow the local service provider to authorize service
and understand to whom accounting information should be sent. These
same components provide the home authenticating party with the infor-
mation to identify the originating user, their roaming consortium, and
the applicable service level agreements.
The local ISP provides access. Since the home ISP presents the bill to
the customer, in most cases they will be responsible for sales taxes,
but this may not universally be the case. It is possible that there
will be taxes or other charges mandated by local governing bodies
which need to be absorbed and rebilled. As a result, it is necessary
for the identity of both the local and home ISP to be included, as
well as the location of the called POP to be included in the account-
ing record. Including this information also allows roaming consortia
to evaluate access patterns and trends in an effort to leverage high
service areas for better rates and/or service.
It is also useful for the accounting record to include the date and
time of access, in order to make it possible to analyze diurnal curves
and devise programs oriented toward load leveling. Including session
duration is useful as an input to the rating process as well as for
capacity planning and fraud detection. The type of access and access
speed may also be relevant in rating.
Suggested accounting metrics include:
Session ID Unique ID identifying the session
Multi-Session ID For linking of multiple related sessions
NAI Network Access Identifier (NAI), the userID that is
presented during the authentication process.
Peer Network Address The IP address assigned to the user
Home ISP Identity of the home ISP.
Local ISP The local ISP providing access.
NAS Host Name The name of the NAS providing access.
NAS IP address The IP address of the NAS providing access.
NAS Port The physical port of the NAS providing access.
Call Type Indicates type of call, i.e. async vs. Sync ISDN, V.120, etc.
Service Type Type of service provided to the user
Call Direction Indicates inbound or outbound call
B Channel interface name Indicates name of B channel interface
Link Count Number of links up when record was generated
Local Time Zone Time zone where access was provided.
Start Date & Time Session starting date and time (at source)
Disconnect Date & Time Session ending date and time (at source)
Elapsed Duration Seconds of received service
Method of Access
Disconnect Cause Code The reason the call was disconnected
Aboba, Lidyard & Vollbrecht [Page 10]
INTERNET-DRAFT 28 July 1997
Originating Number Enables the computation of access charges in a toll area.
Access Number The phone number dialed to reach the local ISP.
Packets Transmitted Packets sent to port
Packets Received Packets received from port
OCTETS Transmitted Octets sent to port
OCTETS Received Octets received from port
Summary Charge Aggregated charge of this accounting record.
Charge detail Entries for each type of charge and the amount used to
compute the summary charge. This includes access service
fees, usage related charges, and taxes. Other
charge detail may be applicable.
Currency code Currency in which the charges are expressed.
Memo Data General area for ISPs to communicate additional
information related to each accounting record.
Authorization Code Digitally signed token included to ensure legitimacy.
Form TBD.
Roaming Rel. Path The path of roaming relationships connecting the local ISP
to the home authentication server..NH 2
4.15. Accounting record format requirements
In order to allow for accounting record bundles between organizations,
it is necessary to provide for a standard accounting record format.
Desirable qualities for an accounting record format include:
Compactness
Given the growth of the Internet, today's ISPs process a
large number of accounting records every day. Not only does
processing of the records require many CPU cycles, but
transmitting the records can consume considerable bandwidth.
Therefore it is desirable for the accounting record format
to be as compact as possible, and to contribute to efficient
processing.
Extensibility
While the standard accounting record format must be able to
encode metrics commonly used by ISPs in determining a user's
bill, it must also be extensible so that other metrics can
be added in the future. Traditionally, session records have
used fixed record formats, which while being compact, have
limited extensibility. In this application, the accounting
data to be exchanged may be interim accounting information
or session records; it may represent standard metrics or
vendor-specific information; it may need to express
attributes of arbitrary size; it may be called upon to rep-
resent data from any of the commonly used accounting proto-
cols including RADIUS, TACACS+, SNMP or SYSLOG.
4.16. Definition of the Accounting Data Interchange Format (ADIF)
ADIF, which is similar to the LDAP Data Interchange Format (LDIF)
specified in [23], is extensible as well as compact. While ADIF is
Aboba, Lidyard & Vollbrecht [Page 11]
INTERNET-DRAFT 28 July 1997
capable of expressing a wide variety of accounting data, most appli-
cations are expected to use only a small subset of capabilities.
Therefore, prior to exchanging accounting data, it is expected that
ISPs will consult with the accounting agent so as to understand which
metrics are required in a given situation. For example, an accounting
agent may require a small set of RADIUS attributes, with all other
attributes ignored. In this case, participating ISPs will need to pro-
vide ADIF records with these required attributes in order to have
their accounting data processed correctly.
Since the decision on required versus optional accounting data is typ-
ically made by the accounting agent rather than the submitting ISP,
ADIF does not provide the ability to mark accounting data as "manda-
tory", as is done in L2TP, described in [19]. It is felt that provid-
ing this capability would result in increased complexity without
adding much in the way of error detection. However, requirements from
a given accounting protocol do carry over to ADIF. For example, in
RADIUS accounting as described in [4] it is required that a RADIUS
Accounting-Request contain an Acct-Status-Type attribute, and these
same requirements would apply to an ADIF accounting record expressing
information obtained from RADIUS accounting packets.
Accounting records have traditionally been human-readable, so as to
allow them to be more easily debugged. ADIF permits attributes to be
expressed either in NVT ASCII (characters 32 through 126) or if non-
printable characters are required, in base64.
An ADIF file consists of a series of records separated by a separator,
and each record may consist of one or more lines. As with MIME,
described in [20], lines may be continued by putting a space or tab
character on the succeeding line, and thus attributes may be of arbi-
trary length. A version number (1 for this document), and a default
attribute type may be optionally included at the beginning of the ADIF
file. Lines beginning with the "#" character are taken as comments and
ignored.
In order to allow ADIF to be used to communicate accounting data from
a variety of sources, ADIF includes support for attribute types. This
specification includes support for RADIUS, SNMP, and TACACS+
attributes, and other types may be added as needed. Attribute types
may be indicated by prepending the attribute type, and a "//" to the
attribute name, i.e. RADIUS//Acct-Session-Time.
In order to provide the maximum degree of compactness, ADIF permits
attribute numbers to be used instead of names. For example,
RADIUS//46: may be used instead of RADIUS//Acct-Session-Time.
Since it is expected that most accounting record batches will use
attributes of a single type, a default attribute type may be indicated
at the beginning of an ADIF file. When a default attribute type is
used, attributes of the default type do not need to include their type
along with the attribute name. For example, if defaultType: RADIUS is
indicated at the beginning of the ADIF file, then Acct-Session-Time:
or 46: may be used instead of RADIUS//Acct-Session-Time: or
Aboba, Lidyard & Vollbrecht [Page 12]
INTERNET-DRAFT 28 July 1997
RADIUS//46:.
4.16.1. Vendor-specific attributes
ADIF supports vendor-specific metrics in several ways. It is possible
for a vendor to define their own attribute type (i.e. BIGCO//). How-
ever, this should only be done in cases where there are limited inter-
operability requirements.
In most cases, vendor-specific attributes can be accommodated within
existing attribute types, such as RADIUS or SNMP, through the encoding
of vendor-specific attributes. In RADIUS, this is typically accom-
plished using the Vendor-Specific attribute; in SNMP it is accom-
plished by definition of a MIB variable within the vendor area. In
both RADIUS and SNMP, vendors are identified using the SMI Network
Management Private Enterprise Code, as given in [22]. In the case of
RADIUS as described in [3], servers not equipped to support vendor-
specific attributes MUST ignore them.
Since vendor-specific attributes may be expressed in a variety of for-
mats, it is not possible to specify how they are to be represented in
general. However, in order to make vendor-specific attributes easier
to debug, it is recommended that RADIUS Vendor-Specific attributes be
encoded so as to break out the Vendor-Id and Vendor-Type from the
attribute-specific data. This may be accomplished by using a semi-
colon as a separator, as follows:
Vendor-Specific: Vendor-Id: <SMI Network Management Private Enterprise Code>;
<Type>: <Value>
4.16.2. ADIF Examples
Example 1: An ADIF file encoding RADIUS accounting data, using
attribute names:
version: 1
defaultType: RADIUS
NAS-IP-Address: 204.45.34.12
NAS-Port: 12
NAS-Port-Type: 2
User-Name: fred@bigco.com
Acct-Status-Type: 2
Acct-Delay-Time: 2
Acct-Input-Octets: 234732
Acct-Output-Octets: 15439
Acct-Session-Id: 185
Acct-Authentic: 1
Acct-Session-Time: 1238
Acct-Input-Packets: 153
Acct-Output-Packets: 148
Acct-Terminate-Cause: 11
Aboba, Lidyard & Vollbrecht [Page 13]
INTERNET-DRAFT 28 July 1997
Acct-Multi-Session-Id: 73
Acct-Link-Count: 2
Example 2: An ADIF file encoding RADIUS accounting data, using
attribute numbers:
version: 1
defaultType: RADIUS
4: 204.45.34.12
5: 12
61: 2
1: fred@bigco.com
40: 2
41: 2
42: 234732
43: 15439
44: 185
45: 1
46: 1238
47: 153
48: 148
49: 11
50: 73
51: 2
Example 3: An ADIF file with vendor-specific data:
version: 1
defaultType: RADIUS
4: 204.45.34.12
5: 12
61: 2
26: Vendor-Id: 311; dialClass: 1
1: fred@bigco.com
40: 2
41: 2
42: 234732
43: 15439
44: 185
45: 1
46: 1238
47: 153
48: 148
49: 11
50: 73
51: 2
Aboba, Lidyard & Vollbrecht [Page 14]
INTERNET-DRAFT 28 July 1997
4.16.3. Grammar
The following definition uses the augmented Backus-Naur Form specified
in [13].
adif-file = [version-spec SEP] [type-spec SEP] adif-record *(SEP adif-record)
version-spec = "version:" *SPACE version-number
version-number = 1*DIGIT
type-spec = "defaultType:" *SPACE attr-type
attr-type = "RADIUS" | "SNMP" | "TACACS+"
adif-record = 1*(attrval-series SEP)
attrval-series = 1*(attrval-spec)
attrval-spec = attr ( (":" *SPACE value) |
("::" *SPACE base64-value) )
attr = radattr | snmpattr | tacacsplusattr
radattr = ["RADIUS//"] radattrname
radattrname = <a RADIUS attribute name, as defined in [3],[4],[7]> |
<a RADIUS attribute number, as defined in [3],[4],[7]>
snmpattr = ["SNMP//"] snmpattrname
snmpattrname = <an SNMP object ID> | <an SNMP attribute name>
tacacsplusattr = ["TACACS+//"] tacacsplusattrname
tacacsplusattrname = <a TACACS+ attribute name, as defined in [11]>
value = 1*safe-initval *safe
safe = <ASCII values 040 - 0176 octal (32 - 126 decimal)
safe-initval = <ASCII values 040 - 0176 octal (32 - 126 decimal),
excluding colon (":", ASCII 58 decimal), SPACE,
and semi-colon (";", ASCII 59 decimal)
base64-value = <base-64-encoded value, defined in [10]>
SPACE = <ASCII SP, space>
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return>
LF = <ASCII LF, line feed>
DIGIT = <any ASCII decimal digit (60 - 71 decimal) >
5. Security issues
When session record accounting is employed, protection must be pro-
vided against the following attacks:
Theft of accounting data
Submission of fraudulent accounting records
5.1. Theft of accounting data
Since RADIUS accounting does not provide for encryption of accounting
data, when real-time accounting is used, it is possible for an inter-
mediate system to gain access to accounting information passing over
the wire. Such access may or may not be possible when session record
accounting is used, depending on whether encryption is used in the
accounting record transfer.
Aboba, Lidyard & Vollbrecht [Page 15]
INTERNET-DRAFT 28 July 1997
5.2. Submission of fraudulent accounting records
When session record accounting is used, it is possible for a local ISP
to submit a fraudulent accounting record to the accounting agent. This
includes submission of records for non-existent sessions, or submis-
sion of exaggerated session times for actual sessions. Such behavior
will only be easily detectable in the event that roaming users are
making use of voluntary or compulsory tunneling, in which case the
tunnel server (presumed to exist at BIGCO) will generate its own
accounting record, which may be compared to that generated by the
local ISP. However, tunneling is expected to represent only a small
percentage of roaming use.
With respect to submission of inaccurate accounting records, it makes
little difference whether the local ISP submits accounting records, or
proxies accounting protocol packets to the accounting agent. Either
accounting records or accounting protocol packets may be forged by the
local ISP; for example, an accounting gateway could hold incoming
RADIUS accounting packets and retransmit them later, making it appear
that the session was longer than it actually was.
Requiring the NAS to communicate directly with the accounting agent
provides little extra security. Aside from the scalability problems
that would result from this when a shared-secret authentication scheme
is used, the local ISP has access to all the NAS shared secrets or
private keys, and therefore has at its disposal all the information
necessary to forge authentication and accounting packets.
In order to detect changes in behavior by the local ISP, where real-
time accounting is used the accounting agent SHOULD carefully monitor
the balance of each local ISP so as to ensure that it remains within
normal limits.
Where hierarchical authentication routing is used, the parties on the
roaming relationship path will also typically have proxied the RADIUS
Access-Request and Access-Accept packets resulting in authentication
and authorization. As a result, each of the parties will be able to
match up the received accounting records with an event in their
authentication logs. This provides for a limited degree of auditing.
To enable the matching of authentication and accounting packets, the
Class attribute SHOULD be included in the RADIUS Access-Reply.
Where hierarchical authentication routing is employed, having the
accounting agent on the authentication route as the first hop is
highly desirable, since this makes it more difficult for the local ISP
to submit accounting records for fictitious sessions. If the authenti-
cation and accounting routes are aligned, this type of fraud requires
cooperation of one of the intermediate proxies.
6. Acknowledgements
Thanks to Pat Calhoun of 3Com for useful discussions of this problem
space.
Aboba, Lidyard & Vollbrecht [Page 16]
INTERNET-DRAFT 28 July 1997
7. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." Internet draft (work in progress), draft-ietf-
roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo,
Merit Network, June, 1997.
[2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft
(work in progress), draft-ietf-roamops-roamreq-05.txt, Microsoft,
June, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April,
1997.
[5] J. Gray, A. Reuter. Transaction Processing: Concepts and Tech-
niques, Morgan Kaufmann Publishers, San Francisco, California, 1993.
[6] R. Fajman. "An Extensible Message Format for Message Disposition
Notifications." Internet draft (work in progress), draft-ietf-
receipt-mdn-02.txt, National Institute of Health, November, 1996.
[7] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC
2015, The Aerospace Corporation, October, 1996.
[8] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting
of Mail System Administrative Messages." RFC 1892, Octel Network Ser-
vices, January, 1996.
[9] J. Galvin., et al. "Security Multiparts for MIME: Multi-
part/Signed and Multipart/Encrypted." RFC 1847, Trusted Information
Systems, October, 1995.
[10] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran-
denburg Consulting, March, 1995.
[11] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure
EDI." Internet draft (work in progress), draft-ietf-ediint-
as1-02.txt, LiNK, Actra, Mitre Corp, Drummond Group, November, 1996.
[12] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
Inter-operable Internet EDI." Internet draft (work in progress),
draft-ietf-ediint-req-01.txt, Actra, LiNK, Drummond Group, May, 1995.
[13] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1."
RFC 2068, UC Irvine, January, 1997.
[14] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location
of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter-
prises, October 1996.
Aboba, Lidyard & Vollbrecht [Page 17]
INTERNET-DRAFT 28 July 1997
[15] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security
Extensions." Internet draft (work in progress), draft-ietf-dnnsec-
secext-10.txt, CyberCash, Iris, August, 1996.
[16] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work
in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
[17] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[18] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[19] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A.
J. Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP."
Work in progress, Internet draft (work in progress), draft-ietf-
pppext-l2tp-03.txt, Ascend Communications, Microsoft, Copper Moun-
tain Networks, U.S. Robotics, March, 1997.
[20] Borenstein, N., Freed, N. "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
December 1993.
[21] D. Carrel, L. Grant. "The TACACS+ Protocol Version 1.75." Work
in progress, draft-grant-tacacs-00.txt, Cisco Systems, October, 1996.
[22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[23] G. Good. "The LDAP Data Interchange Format (LDIF)." Internet
draft (work in progress), draft-ietf-asid-ldif-00.txt, Netscape,
November, 1996.
[24] B. Aboba, J.R. Vollbrecht, and G. Zorn. "Guidelines for the
Secure Operation of RADIUS Proxies in Roaming." Internet draft (work
in progress), draft-ietf-roamops-auth-02.txt, Microsoft, Merit, July,
1997.
8. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Dave Lidyard
Telco Research Corporation
616 Marriott Drive
Aboba, Lidyard & Vollbrecht [Page 18]
INTERNET-DRAFT 28 July 1997
Nashville, TN 37214
Phone: 615-231-6110
EMail: dave@telcores.com
John R. Vollbrecht
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Phone: 313-763-1206
EMail: jrv@merit.edu
Aboba, Lidyard & Vollbrecht [Page 19]
