draft-ietf-radius-accounting-04.txt   rfc2059.txt 
RADIUS Working Group C Rigney Network Working Group C. Rigney
INTERNET-DRAFT Livingston Request for Comments: 2059 Livingston
expires in six months June 1996 Category: Informational January 1997
RADIUS Accounting RADIUS Accounting
draft-ietf-radius-accounting-04.txt
Status of this Memo Status of this Memo
This document is a submission to the RADIUS Working Group of the This memo provides information for the Internet community. This memo
Internet Engineering Task Force (IETF). Comments should be submitted does not specify an Internet standard of any kind. Distribution of
to the ietf-radius@livingston.com mailing list. this memo is unlimited.
Distribution of this memo is unlimited.
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract Abstract
This document describes a protocol for carrying accounting This document describes a protocol for carrying accounting
information between a Network Access Server and a shared Accounting information between a Network Access Server and a shared Accounting
Server. Server.
Table of Contents Table of Contents
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 2
2. Operation ............................................. 3
3. Packet Format ......................................... 4
4. Packet Types .......................................... 6
4.1 Accounting-Request .............................. 6
4.2 Accounting-Response ............................. 7
5. Attributes ............................................ 9
5.1 Acct-Status-Type ................................ 10
5.2 Acct-Delay-Time ................................. 11
5.3 Acct-Input-Octets ............................... 12
5.4 Acct-Output-Octets .............................. 13
5.5 Acct-Session-Id ................................. 13
5.6 Acct-Authentic .................................. 14
5.7 Acct-Session-Time ............................... 15
5.8 Acct-Input-Packets .............................. 16
5.9 Acct-Output-Packets ............................. 17
5.10 Acct-Terminate-Cause ............................ 17
5.11 Acct-Multi-Session-Id ........................... 20
5.12 Acct-Link-Count ................................. 20
5.13 Table of Attributes ............................. 22
Security Considerations ...................................... 24
References ................................................... 24
Acknowledgements ............................................. 24
Chair's Address .............................................. 25
Author's Address ............................................. 25 1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Operation ............................................. 3
3. Packet Format ......................................... 4
4. Packet Types .......................................... 6
4.1 Accounting-Request .............................. 7
4.2 Accounting-Response ............................. 8
5. Attributes ............................................ 9
5.1 Acct-Status-Type ................................ 11
5.2 Acct-Delay-Time ................................. 12
5.3 Acct-Input-Octets ............................... 13
5.4 Acct-Output-Octets .............................. 13
5.5 Acct-Session-Id ................................. 14
5.6 Acct-Authentic .................................. 15
5.7 Acct-Session-Time ............................... 16
5.8 Acct-Input-Packets .............................. 17
5.9 Acct-Output-Packets ............................. 17
5.10 Acct-Terminate-Cause ............................ 18
5.11 Acct-Multi-Session-Id ........................... 20
5.12 Acct-Link-Count ................................. 21
5.13 Table of Attributes ............................. 22
Security Considerations ...................................... 24
References ................................................... 24
Acknowledgements ............................................. 24
Chair's Address .............................................. 25
Author's Address ............................................. 25
1. Introduction 1. Introduction
Managing dispersed serial line and modem pools for large numbers of Managing dispersed serial line and modem pools for large numbers of
users can create the need for significant administrative support. users can create the need for significant administrative support.
Since modem pools are by definition a link to the outside world, they Since modem pools are by definition a link to the outside world, they
require careful attention to security, authorization and accounting. require careful attention to security, authorization and accounting.
This can be best achieved by managing a single "database" of users, This can be best achieved by managing a single "database" of users,
which allows for authentication (verifying user name and password) as which allows for authentication (verifying user name and password) as
well as configuration information detailing the type of service to well as configuration information detailing the type of service to
deliver to the user (for example, SLIP, PPP, telnet, rlogin). deliver to the user (for example, SLIP, PPP, telnet, rlogin).
The RADIUS (Remote Authentication Dial In User Service) Internet- The RADIUS (Remote Authentication Dial In User Service) document [4]
Draft specifies the RADIUS protocol used for Authentication and specifies the RADIUS protocol used for Authentication and
Authorization. This Internet-Draft extends the use of the RADIUS Authorization. This memo extends the use of the RADIUS protocol to
protocol to cover delivery of accounting information from the Network cover delivery of accounting information from the Network Access
Access Server (NAS) to a RADIUS accounting server. Server (NAS) to a RADIUS accounting server.
Key features of RADIUS Accounting are: Key features of RADIUS Accounting are:
Client/Server Model Client/Server Model
A Network Access Server (NAS) operates as a client of the A Network Access Server (NAS) operates as a client of the
RADIUS accounting server. The client is responsible for RADIUS accounting server. The client is responsible for
passing user accounting information to a designated RADIUS passing user accounting information to a designated RADIUS
accounting server. accounting server.
skipping to change at page 2, line 5 skipping to change at page 2, line 50
Transactions between the client and RADIUS accounting server Transactions between the client and RADIUS accounting server
are authenticated through the use of a shared secret, which is are authenticated through the use of a shared secret, which is
never sent over the network. never sent over the network.
Extensible Protocol Extensible Protocol
All transactions are comprised of variable length Attribute- All transactions are comprised of variable length Attribute-
Length-Value 3-tuples. New attribute values can be added Length-Value 3-tuples. New attribute values can be added
without disturbing existing implementations of the protocol. without disturbing existing implementations of the protocol.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. of the specification. These words are often capitalized.
1.1 Specification of Requirements
MUST This word, or the adjective "required", means that the MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification. definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute MUST NOT This phrase means that the definition is an absolute
prohibition of the specification. prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be ignore this item, but the full implications must be
understood and carefully weighed before choosing a understood and carefully weighed before choosing a
skipping to change at page 4, line 8 skipping to change at page 4, line 35
The RADIUS accounting server MAY make requests of other servers in The RADIUS accounting server MAY make requests of other servers in
order to satisfy the request, in which case it acts as a client. order to satisfy the request, in which case it acts as a client.
If the RADIUS accounting server is unable to successfully record the If the RADIUS accounting server is unable to successfully record the
accounting packet it MUST NOT send an Accounting-Response accounting packet it MUST NOT send an Accounting-Response
acknowledgment to the client. acknowledgment to the client.
3. Packet Format 3. Packet Format
Exactly one RADIUS Accounting packet is encapsulated in the UDP Data Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
field [1], where the UDP Destination Port field indicates 1646 field [1], where the UDP Destination Port field indicates 1813
(decimal). (decimal).
When a reply is generated, the source and destination ports are When a reply is generated, the source and destination ports are
reversed. reversed.
A summary of the RADIUS data format is shown below. The fields are A summary of the RADIUS data format is shown below. The fields are
transmitted from left to right. transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Authenticator | | Authenticator |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ... | Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-
Code Code
The Code field is one octet, and identifies the type of RADIUS The Code field is one octet, and identifies the type of RADIUS
packet. When a packet is received with an invalid Code field, it is packet. When a packet is received with an invalid Code field, it is
silently discarded. silently discarded.
RADIUS Accounting Codes (decimal) are assigned as follows: RADIUS Accounting Codes (decimal) are assigned as follows:
4 Accounting-Request 4 Accounting-Request
skipping to change at page 9, line 35 skipping to change at page 10, line 23
Type Type
The Type field is one octet. Up-to-date values of the RADIUS Type The Type field is one octet. Up-to-date values of the RADIUS Type
field are specified in the most recent "Assigned Numbers" RFC [2]. field are specified in the most recent "Assigned Numbers" RFC [2].
Values 192-223 are reserved for experimental use, values 224-240 Values 192-223 are reserved for experimental use, values 224-240
are reserved for implementation-specific use, and values 241-255 are reserved for implementation-specific use, and values 241-255
are reserved and should not be used. This specification concerns are reserved and should not be used. This specification concerns
the following values: the following values:
1-39 (refer to RADIUS Internet-Draft) 1-39 (refer to RADIUS document [4])
40 Acct-Status-Type 40 Acct-Status-Type
41 Acct-Delay-Time 41 Acct-Delay-Time
42 Acct-Input-Octets 42 Acct-Input-Octets
43 Acct-Output-Octets 43 Acct-Output-Octets
44 Acct-Session-Id 44 Acct-Session-Id
45 Acct-Authentic 45 Acct-Authentic
46 Acct-Session-Time 46 Acct-Session-Time
47 Acct-Input-Packets 47 Acct-Input-Packets
48 Acct-Output-Packets 48 Acct-Output-Packets
49 Acct-Terminate-Cause 49 Acct-Terminate-Cause
50 Acct-Multi-Session-Id 50 Acct-Multi-Session-Id
51 Acct-Link-Count 51 Acct-Link-Count
60+ (refer to RADIUS Internet-Draft) 60+ (refer to RADIUS document [4])
Length Length
The Length field is one octet, and indicates the length of this The Length field is one octet, and indicates the length of this
attribute including the Type, Length and Value fields. If an attribute including the Type, Length and Value fields. If an
attribute is received in an Accounting-Request with an invalid attribute is received in an Accounting-Request with an invalid
Length, the entire request should be silently discarded. Length, the entire request should be silently discarded.
Value Value
skipping to change at page 22, line 9 skipping to change at page 22, line 41
"10" "12" Start 3 "10" "12" Start 3
"10" "13" Start 4 "10" "13" Start 4
"10" "12" Stop 4 "10" "12" Stop 4
"10" "13" Stop 4 "10" "13" Stop 4
"10" "10" Stop 4 "10" "10" Stop 4
5.13. Table of Attributes 5.13. Table of Attributes
The following table provides a guide to which attributes may be found The following table provides a guide to which attributes may be found
in Accounting-Request packets. No attributes should be found in in Accounting-Request packets. No attributes should be found in
Accounting-Response packets (except possibly for Vendor-Specific). Accounting-Response packets except Proxy-State and possibly Vendor-
Specific.
# Attribute # Attribute
0-1 User-Name 0-1 User-Name
0 User-Password 0 User-Password
0 CHAP-Password 0 CHAP-Password
0-1 NAS-IP-Address [4] 0-1 NAS-IP-Address [4]
0-1 NAS-Port 0-1 NAS-Port
0-1 Service-Type 0-1 Service-Type
0-1 Framed-Protocol 0-1 Framed-Protocol
0-1 Framed-IP-Address 0-1 Framed-IP-Address
skipping to change at page 24, line 23 skipping to change at page 24, line 34
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980. USC/Information Sciences Institute, August 1980.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994. 1700, USC/Information Sciences Institute, October 1994.
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, MIT Laboratory for Computer Science, RSA Data RFC 1321, MIT Laboratory for Computer Science, RSA Data
Security Inc., April 1992. Security Inc., April 1992.
[4] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2058,
January 1997.
Acknowledgments Acknowledgments
RADIUS and RADIUS Accounting were originally developed by Livingston RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises for their PortMaster series of Network Access Servers. Enterprises for their PortMaster series of Network Access Servers.
Chair's Address Chair's Address
The RADIUS working group can be contacted via the current chair: The RADIUS working group can be contacted via the current chair:
Carl Rigney Carl Rigney
Livingston Enterprises Livingston Enterprises
6920 Koll Center Parkway, Suite 220 6920 Koll Center Parkway, Suite 220
Pleasanton, California 94566 Pleasanton, California 94566
Phone: +1 510 426 0770 Phone: +1 510 426 0770
E-Mail: cdr@livingston.com EMail: cdr@livingston.com
Author's Address Author's Address
Questions about this memo can also be directed to: Questions about this memo can also be directed to:
Carl Rigney Carl Rigney
Livingston Enterprises Livingston Enterprises
6920 Koll Center Parkway, Suite 220 6920 Koll Center Parkway, Suite 220
Pleasanton, California 94566 Pleasanton, California 94566
E-Mail: cdr@livingston.com EMail: cdr@livingston.com
 End of changes. 19 change blocks. 
97 lines changed or deleted 74 lines changed or added

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