draft-ietf-radius-accounting-v2-02.txt   draft-ietf-radius-accounting-v2-03.txt 
RADIUS Working Group C Rigney RADIUS Working Group C Rigney
INTERNET-DRAFT Livingston INTERNET-DRAFT Livingston
expires August 2000 February 2000
RADIUS Accounting RADIUS Accounting
draft-ietf-radius-accounting-v2-02.txt draft-ietf-radius-accounting-v2-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is a submission to the RADIUS Working Group of the This document is a submission to the RADIUS Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the ietf-radius@livingston.com mailing list. to the ietf-radius@livingston.com mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
Implementation Note Implementation Note
This memo documents the RADIUS Accounting protocol. The early This memo documents the RADIUS Accounting protocol. The early
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Specification of Requirements ................... 4 1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Operation ............................................. 4 2. Operation ............................................. 4
2.1 Proxy ........................................... 5 2.1 Proxy ........................................... 5
3. Packet Format ......................................... 6 3. Packet Format ......................................... 6
4. Packet Types .......................................... 8 4. Packet Types .......................................... 8
4.1 Accounting-Request .............................. 8 4.1 Accounting-Request .............................. 8
4.2 Accounting-Response ............................. 10 4.2 Accounting-Response ............................. 10
5. Attributes ............................................ 11 5. Attributes ............................................ 11
5.1 Acct-Status-Type ................................ 12 5.1 Acct-Status-Type ................................ 12
5.2 Acct-Delay-Time ................................. 13 5.2 Acct-Delay-Time ................................. 13
5.3 Acct-Input-Octets ............................... 14 5.3 Acct-Input-Octets ............................... 14
5.4 Acct-Output-Octets .............................. 15 5.4 Acct-Output-Octets .............................. 15
5.5 Acct-Session-Id ................................. 15 5.5 Acct-Session-Id ................................. 16
5.6 Acct-Authentic .................................. 16 5.6 Acct-Authentic .................................. 17
5.7 Acct-Session-Time ............................... 17 5.7 Acct-Session-Time ............................... 18
5.8 Acct-Input-Packets .............................. 18 5.8 Acct-Input-Packets .............................. 18
5.9 Acct-Output-Packets ............................. 19 5.9 Acct-Output-Packets ............................. 19
5.10 Acct-Terminate-Cause ............................ 19 5.10 Acct-Terminate-Cause ............................ 20
5.11 Acct-Multi-Session-Id ........................... 22 5.11 Acct-Multi-Session-Id ........................... 22
5.12 Acct-Link-Count ................................. 22 5.12 Acct-Link-Count ................................. 23
5.13 Table of Attributes ............................. 24 5.13 Table of Attributes ............................. 24
6. Security Considerations ............................... 26 6. IANA Considerations ................................... 26
7. Change Log ............................................ 26 7. Security Considerations ............................... 26
8. References ............................................ 26 8. Change Log ............................................ 26
9. Acknowledgements ...................................... 26 9. References ............................................ 26
10. Chair's Address ....................................... 27 10. Acknowledgements ...................................... 27
11. Author's Address ...................................... 27 11. Chair's Address ....................................... 27
12. Full Copyright Statement .............................. 28 12. Author's Address ...................................... 27
13. Full Copyright Statement .............................. 28
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
skipping to change at page 5, line 4 skipping to change at page 5, line 4
been received. At the end of service delivery the client will been received. At the end of service delivery the client will
generate an Accounting Stop packet describing the type of service generate an Accounting Stop packet describing the type of service
that was delivered and optionally statistics such as elapsed time, that was delivered and optionally statistics such as elapsed time,
input and output octets, or input and output packets. It will send input and output octets, or input and output packets. It will send
that to the RADIUS Accounting server, which will send back an that to the RADIUS Accounting server, which will send back an
acknowledgement that the packet has been received. acknowledgement that the packet has been received.
The Accounting-Request (whether for Start or Stop) is submitted to The Accounting-Request (whether for Start or Stop) is submitted to
the RADIUS accounting server via the network. It is recommended that the RADIUS accounting server via the network. It is recommended that
the client continue attempting to send the Accounting-Request packet the client continue attempting to send the Accounting-Request packet
until it receives an acknowledgement, using some form of backoff. If until it receives an acknowledgement, using some form of backoff.
no response is returned within a length of time, the request is re- If no response is returned within a length of time, the request is
sent a number of times. The client can also forward requests to an re-sent a number of times. The client can also forward requests to
alternate server or servers in the event that the primary server is an alternate server or servers in the event that the primary server
down or unreachable. An alternate server can be used either after a is down or unreachable. An alternate server can be used either after
number of tries to the primary server fail, or in a round-robin a number of tries to the primary server fail, or in a round-robin
fashion. Retry and fallback algorithms are the topic of current fashion. Retry and fallback algorithms are the topic of current
research and are not specified in detail in this document. research and are not specified in detail in this document.
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.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
1. The NAS sends an accounting-request to the forwarding server. 1. The NAS sends an accounting-request to the forwarding server.
2. The forwarding server logs the accounting-request (if desired), 2. The forwarding server logs the accounting-request (if desired),
adds its Proxy-State (if desired) after any other Proxy-State adds its Proxy-State (if desired) after any other Proxy-State
attributes, updates the Request Authenticator, and forwards the attributes, updates the Request Authenticator, and forwards the
request to the remote server. request to the remote server.
3. The remote server logs the accounting-request (if desired), 3. The remote server logs the accounting-request (if desired),
copies all Proxy-State attributes in order and unmodified from copies all Proxy-State attributes in order and unmodified from
the request to the response packet, and sends the accounting- the request to the response packet, and sends the
response to the forwarding server. accounting-response to the forwarding server.
4 The forwarding server strips the last Proxy-State (if it added 4 The forwarding server strips the last Proxy-State (if it added
one in step 2), updates the Response Authenticator and sends one in step 2), updates the Response Authenticator and sends
the accounting-response to the NAS. the accounting-response to the NAS.
A forwarding server MUST not modify existing Proxy-State or Class A forwarding server MUST not modify existing Proxy-State or Class
attributes present in the packet. attributes present in the packet.
A forwarding server may either perform its forwarding function in a A forwarding server may either perform its forwarding function in a
pass through manner, where it sends retransmissions on as soon as it pass through manner, where it sends retransmissions on as soon as it
skipping to change at page 7, line 33 skipping to change at page 7, line 33
The Authenticator field is sixteen (16) octets. The most significant The Authenticator field is sixteen (16) octets. The most significant
octet is transmitted first. This value is used to authenticate the octet is transmitted first. This value is used to authenticate the
messages between the client and RADIUS accounting server. messages between the client and RADIUS accounting server.
Request Authenticator Request Authenticator
In Accounting-Request Packets, the Authenticator value is a 16 In Accounting-Request Packets, the Authenticator value is a 16
octet MD5 [4] checksum, called the Request Authenticator. octet MD5 [4] checksum, called the Request Authenticator.
The NAS and RADIUS accounting server share a secret. The Request The NAS and RADIUS accounting server share a secret. The Request
Authenticator field in Accounting-Request packets contains a one- Authenticator field in Accounting-Request packets contains a
way MD5 hash calculated over a stream of octets consisting of the one-way MD5 hash calculated over a stream of octets consisting of
Code + Identifier + Length + 16 zero octets + request attributes + the Code + Identifier + Length + 16 zero octets + request
shared secret (where + indicates concatenation). The 16 octet MD5 attributes + shared secret (where + indicates concatenation).
hash value is stored in the Authenticator field of the The 16 octet MD5 hash value is stored in the Authenticator field
Accounting-Request packet. of the Accounting-Request packet.
Note that the Request Authenticator of an Accounting-Request can Note that the Request Authenticator of an Accounting-Request can
not be done the same way as the Request Authenticator of a RADIUS not be done the same way as the Request Authenticator of a RADIUS
Access-Request, because there is no User-Password attribute in an Access-Request, because there is no User-Password attribute in an
Accounting-Request. Accounting-Request.
Response Authenticator Response Authenticator
The Authenticator field in an Accounting-Response packet is called The Authenticator field in an Accounting-Response packet is
the Response Authenticator, and contains a one-way MD5 hash called the Response Authenticator, and contains a one-way MD5
calculated over a stream of octets consisting of the Accounting- hash calculated over a stream of octets consisting of the
Response Code, Identifier, Length, the Request Authenticator field Accounting-Response Code, Identifier, Length, the Request
from the Accounting-Request packet being replied to, and the Authenticator field from the Accounting-Request packet being
response attributes if any, followed by the shared secret. The replied to, and the response attributes if any, followed by the
resulting 16 octet MD5 hash value is stored in the Authenticator shared secret. The resulting 16 octet MD5 hash value is stored
field of the Accounting-Response packet. in the Authenticator field of the Accounting-Response packet.
Attributes Attributes
Attributes may have multiple instances, in such a case the order of Attributes may have multiple instances, in such a case the order of
attributes of the same type SHOULD be preserved. The order of attributes of the same type SHOULD be preserved. The order of
attributes of different types is not required to be preserved. attributes of different types is not required to be preserved.
4. Packet Types 4. Packet Types
The RADIUS packet type is determined by the Code field in the first The RADIUS packet type is determined by the Code field in the first
skipping to change at page 26, line 12 skipping to change at page 26, line 8
[Note 1] An Accounting-Request MUST contain either a NAS-IP-Address [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address
or a NAS-Identifier (or both). or a NAS-Identifier (or both).
The following table defines the above table entries. The following table defines the above table entries.
0 This attribute MUST NOT be present 0 This attribute MUST NOT be present
0+ Zero or more instances of this attribute MAY be present. 0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present. 1 Exactly one instance of this attribute MUST be present.
6. Security Considerations 6. IANA Considerations
The Packet Type Codes, Attribute Types, and Attribute Values
defined in this document are registered by the Internet Assigned
Numbers Authority (IANA) from the RADIUS name spaces as described
in the "IANA Considerations" section of RFC xxxx [1], in
accordance with BCP 26 [10].
7. Security Considerations
Security issues are discussed in sections concerning the Security issues are discussed in sections concerning the
authenticator included in accounting requests and responses, using a authenticator included in accounting requests and responses, using a
shared secret which is never sent over the network. shared secret which is never sent over the network.
7. Change Log 8. Change Log
US-ASCII replaced by UTF-8. US-ASCII replaced by UTF-8.
Added notes on Proxy. Added notes on Proxy.
Framed-IP-Address should contain the actual IP address of the user. Framed-IP-Address should contain the actual IP address of the user.
If Acct-Session-ID was sent in an access-request, it must be used in If Acct-Session-ID was sent in an access-request, it must be used in
the accounting-request for that session. the accounting-request for that session.
New values added to Acct-Status-Type. New values added to Acct-Status-Type.
8. References Added an IANA Considerations section.
Updated references.
9. References
[1] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote [1] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, Authentication Dial In User Service (RADIUS)", RFC xxxx,
January 1997. February 2000.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels." BCP14, RFC 2119, March, 1997. Levels." BCP14, RFC 2119, March, 1997.
[3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August [3] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[4] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", [4] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992. RFC 1321, April 1992.
[5] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC [5] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1700, October 1994. 1700, October 1994.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
9. Acknowledgements 10. Acknowledgements
RADIUS and RADIUS Accounting were originally developed by Steve RADIUS and RADIUS Accounting were originally developed by Steve
Willens of Livingston Enterprises for their PortMaster series of Willens of Livingston Enterprises for their PortMaster series of
Network Access Servers. Network Access Servers.
10. Chair's Address 11. 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
4464 Willow Road 4464 Willow Road
Pleasanton, California 94588 Pleasanton, California 94588
Phone: +1 925 737 2100 Phone: +1 925 737 2100
EMail: cdr@livingston.com EMail: cdr@livingston.com
11. Author's Address 12. 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
4464 Willow Road 4464 Willow Road
Pleasanton, California 94588 Pleasanton, California 94588
EMail: cdr@livingston.com EMail: cdr@livingston.com
12. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 23 change blocks. 
48 lines changed or deleted 64 lines changed or added

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