One document matched: draft-ietf-roamops-actng-01.txt
Differences from draft-ietf-roamops-actng-00.txt
ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-actng-01.txt >
6 March 1997
The Accounting Problem 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-01.txt>, and expires September 15, 1997. Please
send comments to the authors.
2. Abstract
This document describes the accounting problems that arise in the pro-
vision of inter-provider services, such as provision of dialup roaming
capabilities. These include issues relating to standardization of
accounting record formats, and inter-provider transfers of accounting
record bundles. Work relevant to the solution of these problems are
reviewed, and recommendations are made on the direction of future
standardization work.
3. Introduction
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.
Aboba [Page 1]
INTERNET-DRAFT 6 March 1997
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.
Checkpoint event
A checkpoint event is an accounting event that presents a
snapshot of resource usage during a user's session.
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
checkpoint events.
Accounting Protocol
A protocol used for the communication of accounting events.
Full Service Accounting Protocol
An accounting protocol that in addition to communicating
accounting events provides for encryption and signing of
accounting data, as well as signed receipts. Full service
accounting protocols are desirable for use in inter-organi-
zational accounting .
Intra-organizational accounting event
An intra-organizational accounting event is one which is
generated by the local ISP's users.
Inter-organizational accounting event
An inter-organizational accounting event is one which is
generated by users from outside the local ISP's domain.
Accounting Gateway
The Accounting Gateway is a server which receives accounting
data from network devices such as a NASes and routers,
translates this data into session records, and routes the
session records to intra and inter-organizational billing
servers.
3.2. Roaming accounting requirements
Given the growth of the Internet, it is likely that authentication and
accounting servers involved in roaming will need to handle a large
flow of events. For example, if a roaming association has 10 members,
each of whom have 100,000 users, and 5 percent of all logins involve
roaming, then if the users log in 20 times a month on average, each
accounting server will need to handle approximately 2 million
records/month and the accounting agent will need to handle 1 million
records/month. For this reason, it is very important that the
accounting record formats be compact and that the accounting transfer
processes be efficient.
Aboba [Page 2]
INTERNET-DRAFT 6 March 1997
Given that large sums of money may change hands as a result of roaming
accounting transfers, it is highly desirable that the accounting
records be transferred securely and robustly. In order to address
security concerns, it is desirable for an inter-organizational
accounting transfer protocol to support "full service" functions such
as mutual authentication; signing of accounting record bundles;
signed receipts for accounting record transfers; and encryption of
accounting record bundles. Accounting gateways will also need to be
able to reliably route accounting record bundles to the appropriate
destinations.
Since intra-organizational accounting events do not cross organiza-
tional boundaries, "full service" accounting transfer features such as
digital signing of accounting bundles and non-repudiation of receipt
typically are not required, although it is highly desirable that both
inter and intra-organizational accounting transfers exhibit the char-
acteristics of high reliability transaction processing systems, such
as atomicity, consistency, isolation and durability (ACID), as
described in [5].
Durability implies that an inter or intra-organizational accounting
transfer protocol must be able to recover from a variety of faults,
including partially completed transfers and non-supported metrics.
It is desirable that accounting record formats be flexible. While the
standard accounting record format must be able to encode metrics com-
monly used by ISPs in determining a user's bill, it must also be
extensible so that other metrics can be added in the future. These
metrics may either be IETF-standard metrics, or they may be vendor-
specific metrics. Since it is possible that the accounting record
format will itself evolve over time, or that multiple formats will be
in common use, it is necessary that the type and version of the
accounting record be communicated as part of the accounting record
transfer.
4. Overview of the roaming accounting architecture
The goal of the roaming accounting architecture is to enable ISPs to
be compensated for use of the their network infrastructure by roaming
users. The accounting architecture, which is shown below, involves
interactions between network devices such as NASes and routers,
accounting gateways, billing servers, and accounting servers.
In this architecture, local ISPs operating accounting gateways in
order to translate between the accounting protocols used by NAS
devices and routers and the roaming standard accounting record format
and transfer method. Local ISP accounting gateways are also responsi-
ble for summarizing checkpoint events into session records, as well as
routing accounting events.
Accounting events originating on a local ISP fall into two categories:
intra-organizational accounting events, which are events generated by
local customers; and inter-organizational accounting events, which are
Aboba [Page 3]
INTERNET-DRAFT 6 March 1997
events generated by customers from other domains. One of the functions
of the accounting gateway is to distinguish between the two types of
events and route them appropriately. 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 the accounting agent.
While it is not required that the accounting record formats used in
inter and intra-organizational accounting transfers be the same, this
is highly desirable, since this elminates translations that would oth-
erwise be required.
In the roaming accounting architecture, 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 possi-
ble for ISPs to settle among themselves. When the accounting agent's
accounting gateway receives inter-organizational events from a local
ISP's accounting gateway, it routes the events to the accounting
server, in addition to sending copies to the home ISP. Copies are pro-
vided in order to enable the home ISP to audit accounting agent
charges, as well to bill back to the originating domain.
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.
+------------+ +------------+ +------------+
| | | | | |
| ISPB | | ISPA | | ISPA |
| Router | | Billing |<---------| Acctg. |
Aboba [Page 4]
INTERNET-DRAFT 6 March 1997
| | | 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 | | Accounting |
| | | Server | | Server |
| | | | | |
+------------+ +------------+ +------------+
^
|
PPP |
Protocol |
|
|
V
+------------+
| |
| |
| Fred |
| |
| |
+------------+
Aboba [Page 5]
INTERNET-DRAFT 6 March 1997
5. Accounting transfer protocol recommendation
The requirements for roaming accounting record transfers closely
resemble the requirements for interoperable Internet Electronic Docu-
ment Interchange (EDI), as described in [12], since both applications
may transmit encrypted and signed entities, and request and receive
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].
Given the close correspondence between the work of the EDIINT working
group and the requirements for roaming accounting record transfer, it
is proposed that the ROAMOPS working group consider adoption of MIME-
based Secure EDI, as described in [11], for "full service" accounting
record transfers.
Since Secure MIME-enabled mail servers are expected to become widely
available in the next year, use of this technology will enable a "full
service" accounting transfer method to be made available in relatively
short order. Since it is likely that this technology will become
available sooner than it would be possible for the ROAMOPS group to
develop a secure accounting transfer method based on alternative secu-
rity techniques (such as shared secrets), it is recommended that the
group focus on use of Secure MIME as an accounting record transfer
mechanism.
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.
When MIME-based secure EDI is used to transfer accounting record bun-
dles between organizations, it is recommended that the bundles be
encrypted as well as signed, and that a signed receipt be requested.
Either S/MIME or PGP/MIME may be used to accomplish this.
Since MIME-based secure EDI requires public key authentication tech-
nology, a mechanism must be provided for acquiring the public key of
the participants in an exchange. While DNS Security can be used for
this purpose, this is not required, since in roaming messages need
only be sent between entities with a pre-existing business relation-
ship. As a result, it is possible to statically configure accounting
gateways with the required public keys.
With MIME-based secure EDI, the accounting records are transferred
using S/MIME or PGP/MIME over SMTP. Since SMTP server technology is
mature, it is believed that this method can satisfy durability as well
as security requirements.
Aboba [Page 6]
INTERNET-DRAFT 6 March 1997
5.1. Case study
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,
debits ISPA account, credits ISPB account
ISPA: Accounting gateway routes the session record to the
local billing server and to BIGCO
ISPA: Billing server processes the session record,
debits BIGCO account, debits ISPGROUP account
BIGCO: Accounting gateway routes the session record to the
local billing server
BIGCO: Billing server processes the session record,
debits Fred's account, debits ISPA account.
Each of these events is discussed below.
5.2. 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 [Page 7]
INTERNET-DRAFT 6 March 1997
5.3. 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.
5.4. 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 [Page 8]
INTERNET-DRAFT 6 March 1997
5.5. 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 ISPGROUP account. 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.
5.6. 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.
5.7. ISPGROUP accounting server processes the session record, debits
ISPA account, credits ISPB account
ISPGROUP's accounting server processes the session record, and as a
result, ISPA's account is debited, and ISPB's account is credited. 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 bundle from its
mailbox and process it, sending a receipt in response to the account-
ing gateway's request.
5.8. 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.
5.9. ISPA billing server processes the session record, debits BIGCO
account, debits ISPGROUP account
ISPA's billing server processes the session record, and as a result,
BIGCO's account is debited, and ISPGROUP's account is also debited.
Aboba [Page 9]
INTERNET-DRAFT 6 March 1997
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 accounting gateway's request.
5.10. 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.
5.11. BIGCO billing server processes the session record, debits
Fred's account, debits ISPA account
BIGCO's billing server processes the session record, and as a result,
Fred's account is debited, as is ISPA's account. 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 gateway's request.
6. Location of the accounting agent
In order to be able to upload an accounting record bundle to a
accounting agent, it will typically be necessary for a relationship to
exist between the local ISP and the accounting agent. As a result, it
is expected that the ISP's accounting gateway will be statically con-
figured with the domain names and addresses of its accounting agents.
The configuration files might appear as follows:
ispc.com accounting-agent=acct.ispc.com port=25
ispgroup1.com accounting-agent=acct.ispgroup1.com port=25
ispgroup2.com accounting-agent=www.ispgroup2.com port=1649
These configuration files imply that ISPB belongs to the roaming con-
sortia ISPGROUP1 and ISPGROUP2, and that accounting records bound for
these roaming consortia should be sent to the accounting agents oper-
ated within these domains. On the other hand, ISPB sends accounting
bundles to the ISPC accounting agent directly.
In this case, the configuration file indicates that accounting bundles
for ISPC should be sent to the machine acct.ispc.com on port 25; that
accounting bundles for ISPGROUP1 should be sent to acct.ispgroup1.com
on port 25, and that accounting bundles for ISPGROUP2 should be sent
to www.ispgroup2.com on port 1649.
In order to provide information on the transaction endpoints as well
as all the intermediate participants, it is desirable for accounting
records to include the roaming relationship path, and for accounting
Aboba [Page 10]
INTERNET-DRAFT 6 March 1997
record bundles to include the name of the accounting agent to whom the
records are to be submitted.
Where a DNS Roaming Relationship record is used, the accounting gate-
way needs to maintain a cache mapping domains to roaming relationship
paths and accounting agents. When the accounting gateway receives a
RADIUS Accounting-Request message (START or STOP), it will find the
roaming relationship path and accounting agent corresponding to the
NAI in the cache, and will insert this in the accounting record for
the session.
The cache filled in as DNS Roaming Relationship records are received.
Ordinarily a Roaming Relationship resource record is kept in the cache
until it times out. This implies that the cache will typically remain
constant between the time that the authentication is processed and
when the accounting records are generated.
The possible exceptions to this behavior are when the TTL expires in
mid-session or if the accounting gateway is restarted, resulting in a
flushing of the cache. In these cases if the Roaming Relationship
record has changed it is possible that the existing sessions may be
accounted for incorrectly. To avoid this, the accounting gateway MUST
NOT modify the cache entry for a domain with a session in progress.
7. Accounting record formats
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:
Extensibility
In the future it is likely that new accounting metrics will
arise, or existing metrics will fall by the wayside. There-
fore it is important that the accounting record format be
extensible. In particular, it is highly desirable for ven-
dors to be able to generate their own metrics without fear
of colliding with each other.
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.
7.1. ASCII vs. BINARY formats
Today most accounting records are in NVT ASCII, often with a fixed
record format. This has the advantage of being easy to read and debug,
Aboba [Page 11]
INTERNET-DRAFT 6 March 1997
as well as being easy to parse. However, the use of a fixed format is
a substantial liability, since new accounting metrics are continually
emerging.
In order to provide for extensibility, it is possible to specify a
fixed format for the initial portion of the accounting record, while
allowing additional metrics to be added via use of appropriate tags.
In order to allow a record to extend over multiple lines, it is possi-
ble to specify that lines beginning with one or more spaces should be
considered a continuation of the previous line.
Most NVT ASCII accounting formats now in use consume between 60 and
140 octets per record. However, these records are highly compressible,
often exhibiting compression ratios of 3:1 or greater, so that when
compressed accounting bundles are transmitted, space consumption of 50
octets/record is frequently achievable.
Via use of Attribute Value Pairs (AVPs), binary accounting record for-
mats are easily engineered for extensibility, and as a result, they
are popular for use in accounting protocols such as RADIUS and
TACACS+. Via use of a vendor field, it is possible to ensure that ven-
dor-specific metrics will not conflict with IETF-defined accounting
metrics, and assuming that suitable space is left for length and
attribute fields, it is possible to allow for representation of a
large number and variety of accounting metrics.
Since NAS devices and routers typically provide accounting data in
binary format, binary accounting records can typically be generated
more easily than NVT ASCII records. Similarly, billing servers can
process these records more efficiently, since less parsing and conver-
sion is required.
Binary accounting records are also typically more compact than NVT
ASCII formats, although this advantage is reduced when compression is
employed. Although binary accounting records are typically compress-
ible, they are typically much less compressible than equivalent NVT
ASCII formats.
7.2. Example accounting metrics
Examples of accounting metrics include:
User Name (String; the user's ID, including prefix or suffix)
NAS IP address (Integer; the IP address of the user's NAS)
NAS Port (Integer; identifies the physical port on the NAS)
Service Type (Integer; identifies the service provided to the user)
NAS Identifier (Integer; unique identifier for the NAS)
Delay Time (Integer; time client has been trying to send)
Input Octets (Integer; in stop record, octets received from port)
Output Octets (Integer; in stop record, octets sent to port)
Session ID (Integer; unique ID identifying the session)
Authentication (Integer; indicates how user was authenticated)
Session Time (Integer; in stop record, seconds of received service)
Aboba [Page 12]
INTERNET-DRAFT 6 March 1997
Input Packets (Integer; in stop record, packets received from port)
Output Packets (Integer; in stop record, packets sent to port)
Termination Cause (Integer; in stop record, indicates termination cause)
Multi-Session ID (String; for linking of multiple related sessions)
Link Count (Integer; number of links up when record was generated)
NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
7.3. Binary accounting format proposal
7.3.1. Attribute Value Pair format
The Binary Accounting Format represents accounting records as a series
of Attribute Value Pairs (AVPs), similar to those described in [20].
The AVP format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M 0 0| Overall Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M = Mandatory. This bit is used to provide an accounting agent with
guidance as to how it should respond when encountering attributes that
it does not understand.
M = 0 indicates that the accounting agent may ignore the attribute.
M = 1 indicates that the accounting agent not supporting this
attribute must not process the record, and should return an error.
7.3.1.1. Length
The length field, indicates the number of octets in the AVP, including
the Flags, Length, Vendor ID, Attribute, and Value fields. Given that
the length field is 13 bits long, AVPs may have a maximum length of
8192 octets.
7.3.1.2. Vendor ID
Vendor ID is the IANA assigned "SMI Network Management Private Enter-
prise Codes" value, encoded in entwork byte order. The value 0,
reserved in this table, corresponds to IETF adopted Attribute values,
defined within this document. Vendors looking to implement EAF exten-
sions can use their own Vendor ID along with private attribute values
in order to guarantee that they will not collide with another vendor's
Aboba [Page 13]
INTERNET-DRAFT 6 March 1997
extensions.
7.3.1.3. Attribute
The attribute field, which is 16 bits in length, indicates the
accounting metric encoded in the value field.
7.3.1.4. Value
The value field encodes the value of the attribute indicate in the
attribute field.
7.4. Attributes
The IETF attribute space is subdivided into the following regions:
Attributes Purpose
---------- -------
0 - 255 RADIUS attributes
256 - 1023 Reserved
In order to provide for the efficient operation of accounting gate-
ways, the first 256 attributes in EAF are reserved for use by RADIUS
attributes.
Only RADIUS attributes described in [4], [5], and [9] are allowed to
use Vendor ID 0. Vendor-specific attributes MUST NOT use the RADIUS
Vendor-specific attribute along with EAF Vendor ID 0, but instead MUST
set the vendor ID field appropriately.
7.4.1. Global attributes
The following attributes refer not to the characteristics of a partic-
ular accounting record, but to the entire set of records being pre-
sented. These attributes MUST be included first in the accounting
record stream, prior to the inclusion of any accounting records. The
global attributes are separated from the accounting records by an End
of Global Attributes AVP.
7.4.1.1. Timestamp
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| 14 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | NTP Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba [Page 14]
INTERNET-DRAFT 6 March 1997
| |
| |
/ NTP Timestamp /
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Timestamp AVP is a 64-bit NTP timestamp used to identify the
time at which the packet was first sent. It is used as a unique
identifier for the packet, so that if the transmission is aborted,
a subsequent retransmission will use the same timestamp field.
7.4.1.2. Source
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1025 | Source...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source AVP is a string indicating the fully qualified domain
name of the ISP from which the accounting data is being sent. This
attribute MUST be included in every accounting record bundle.
7.4.1.3. Destination
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1026 | Destination...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Destination AVP is a string indicating the fully qualified
domain name of the accounting agent to whom the accounting data is
being sent. This attribute MUST be included in every accounting
record bundle.
7.4.1.4. Number of Records
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1027 | Number of records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba [Page 15]
INTERNET-DRAFT 6 March 1997
| Number of records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Number of Records AVP provides the number of records included
in the accounting record bundle. This attribute is optional.
7.4.1.5. Error Reporting Email Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1028 | Admin Email Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Reporting Email Address AVP provides the e-mail address
to which error messages should be sent in the event of problems
with the accounting record bundle. This attribute MUST be included
in every accounting record bundle.
7.4.1.6. Administrative Contact
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1029 | Admin Contact...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Administrative Contact AVP denotes the E-mail address, phone
number, address, etc. of the person who should be contacted in the
event of problems with the accounting record stream. This attribute
MUST be included in every accounting record bundle.
7.4.1.7. Accounting Gateway FQDN
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1030 | Accounting Gateway FQDN...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Accounting Gateway FQDN AVP provides the fully qualified domain
name of the accounting gateway sending the accounting record bun-
dle. This AVP is optional.
Aboba [Page 16]
INTERNET-DRAFT 6 March 1997
7.4.1.8. Accounting Gateway IP Address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1031 | Accounting Gateway IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accounting Gateway IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Accounting Gateway IP Address AVP provides the IP address of
the accounting gateway sending the accounting record bundle. This
AVP is optional.
7.4.1.9. Attribute List
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| >=10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1032 | Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute List AVP is used to provide the accounting agent with
a list of all the Vendor ID/attributes included in the accounting
record bundle. This provides a quick way for the accounting agent
to determine whether it is capable of processing the bundle. Use
of the Attribute List AVP is optional.
7.4.1.10. End of Global Attributes
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| 6 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2047 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The End of Global Attributes AVP is included in order to separate
the global attributes from the accounting records. It MUST be
included at the end of the global attributes.
7.4.2. Accounting record attributes
The following attributes refer to the characteristics of a particular
accounting record.
Aboba [Page 17]
INTERNET-DRAFT 6 March 1997
7.4.2.1. Accounting Record Separator
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 6 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2048 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Accounting Record Separator AVP is used to denote the end of an
accounting record. This attribute MUST be included for every
accounting record.
7.4.2.2. Roaming relationship path
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2049 | Roaming Relationship path...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The roaming relationship path AVP is a string indicating the roam-
ing relationship path by which the user was granted access to the
network. This AVP MUST be included for roaming accounting records.
7.4.2.3. Time zone
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2050 | Time Zone |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Zone |
+-+-+-+-+-+-+-+-+
The Time Zone AVP is a string indicating the timezone abbreviation
for the timestamps included in this accounting record.
7.4.2.4. Elapsed Time
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 10 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2051 | Elapsed Time |
Aboba [Page 18]
INTERNET-DRAFT 6 March 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Elapsed Time AVP is binary value encoding the elapsed time in
seconds for the accounting event. This can be ued when start and
stop times are not available.
7.4.2.5. Reason
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| >=7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2052 | Reason...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reason AVP is a string providing information on why the event
occurred.
7.4.2.6. Pages
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2053 | Pages |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pages |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Pages AVP is a binary number indicating the number of pages of
text associated with the event.
7.4.2.7. Bandwidth reserved
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2054 | Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bandwidth reserved AVP is a binary number indicating the of
bandwidth reserved during the event.
Aboba [Page 19]
INTERNET-DRAFT 6 March 1997
8. Security considerations
In a pure RADIUS proxy-based scheme without access to public key
authentication it is not possible to sign accounting record bundles or
request signed receipts. As a result, without public key authentica-
tion it is not possible to verify the origin of an accounting record
bundle, or to prove that an accounting record bundle was received.
Nevertheless, it is possible to request receipts and provide for non-
signed receipts, and to provide some degree of protection for account-
ing transfers via use of shared-secret authentication.
However, even with public key authentication technology, roaming
accounting remains vulnerable to fraud on the part of local ISPs.
Since the local ISP must have access to any private keys used for
signing by accounting gateways, it is possible for the local ISP to
submit inaccurate accounting records to the accounting agent. All pub-
lic key technology provides is the ability to verify the origin of
those fraudulent accounting records.
In this respect, it makes little difference whether the local ISP sub-
mits 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 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, since the local ISP has access to all the NAS shared secrets
or private keys, it has at its disposal all the information necessary
to forge authentication and accounting packets.
Note that an authentication proxy run by the accounting agent is not
on the authentication route path, then the accounting agent will not
be able to match a session record submitted for payment with a proxied
authentication.
When used in concert with public key authentication and a token-based
scheme, such matching can protect against fictitious sessions created
by the local ISP. As a result, accounting agents may require that all
authentications pass through their proxies as the first hop, even
where the authentication could be handled directly between the local
ISP proxy and the home authentication server.
Without public key authentication, this matching process does not pro-
tect against fictitious sessions created by the local ISP, although it
does require the local ISP to forge both the authentication and the
subsequent accounting record.
Aboba [Page 20]
INTERNET-DRAFT 6 March 1997
9. Acknowledgements
Thanks to Glen Zorn of Microsoft for useful discussions of this prob-
lem space.
10. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen-
tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass
Alliance, Asiainfo, January, 1997.
[2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf-
roamops-roamreq-02.txt, Microsoft, January, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
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." 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: Multipart/Signed
and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo-
ber, 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." 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." draft-ietf-ediint-req-01.txt, Actra,
LiNK, Drummond Group, May, 1995.
[13] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1."
draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
Aboba [Page 21]
INTERNET-DRAFT 6 March 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.
[15] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security
Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August,
1996.
[16] B. Aboba. "The Roaming Relationships (REL) Resource Record in
the DNS. " draft-ietf-roamops-dnsrr-02.txt, Microsoft, March, 1997.
[17] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius-
ext-00.txt, Livingston, January, 1997.
[18] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[19] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." draft-bradner-key-words-02.txt, Harvard University, August,
1996.
[20] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft-
ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996.
11. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-22 06:11:13 |