draft-ietf-radius-accounting-v2-03.txt   draft-ietf-radius-accounting-v2-04.txt 
RADIUS Working Group C Rigney RADIUS Working Group C Rigney
INTERNET-DRAFT Livingston INTERNET-DRAFT Livingston
expires August 2000 February 2000 expires August 2000 February 2000
RADIUS Accounting RADIUS Accounting
draft-ietf-radius-accounting-v2-03.txt draft-ietf-radius-accounting-v2-04.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 RFC 2026. all provisions of Section 10 of RFC 2026.
This document obsoletes RFC 2139 [1]. A summary of the changes
between this document and RFC 2139 is available in the "Change Log"
appendix.
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-Drafts. other groups may also distribute working documents as Internet-
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
skipping to change at page 2, line 14 skipping to change at page 2, line 16
Implementation Note Implementation Note
This memo documents the RADIUS Accounting protocol. The early This memo documents the RADIUS Accounting protocol. The early
deployment of RADIUS Accounting was done using UDP port number 1646, deployment of RADIUS Accounting was done using UDP port number 1646,
which conflicts with the "sa-msg-port" service. The officially which conflicts with the "sa-msg-port" service. The officially
assigned port number for RADIUS Accounting is 1813. assigned port number for RADIUS Accounting is 1813.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 4
1.1 Specification of Requirements ................... 4 1.1 Specification of Requirements ................... 5
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 5
2. Operation ............................................. 4 2. Operation ............................................. 5
2.1 Proxy ........................................... 5 2.1 Proxy ........................................... 6
3. Packet Format ......................................... 6 3. Packet Format ......................................... 7
4. Packet Types .......................................... 8 4. Packet Types .......................................... 9
4.1 Accounting-Request .............................. 9
4.2 Accounting-Response ............................. 11
4.1 Accounting-Request .............................. 8 5. Attributes ............................................ 12
4.2 Accounting-Response ............................. 10 5.1 Acct-Status-Type ................................ 13
5.2 Acct-Delay-Time ................................. 14
5.3 Acct-Input-Octets ............................... 15
5.4 Acct-Output-Octets .............................. 16
5.5 Acct-Session-Id ................................. 17
5.6 Acct-Authentic .................................. 18
5.7 Acct-Session-Time ............................... 19
5.8 Acct-Input-Packets .............................. 19
5.9 Acct-Output-Packets ............................. 20
5.10 Acct-Terminate-Cause ............................ 21
5.11 Acct-Multi-Session-Id ........................... 23
5.12 Acct-Link-Count ................................. 24
5.13 Table of Attributes ............................. 25
5. Attributes ............................................ 11 6. IANA Considerations ................................... 27
5.1 Acct-Status-Type ................................ 12
5.2 Acct-Delay-Time ................................. 13
5.3 Acct-Input-Octets ............................... 14
5.4 Acct-Output-Octets .............................. 15
5.5 Acct-Session-Id ................................. 16
5.6 Acct-Authentic .................................. 17
5.7 Acct-Session-Time ............................... 18
5.8 Acct-Input-Packets .............................. 18
5.9 Acct-Output-Packets ............................. 19
5.10 Acct-Terminate-Cause ............................ 20
5.11 Acct-Multi-Session-Id ........................... 22
5.12 Acct-Link-Count ................................. 23
5.13 Table of Attributes ............................. 24
6. IANA Considerations ................................... 26 7. Security Considerations ............................... 27
7. Security Considerations ............................... 26
8. Change Log ............................................ 26 8. Change Log ............................................ 27
9. References ............................................ 26
10. Acknowledgements ...................................... 27 9. References ............................................ 27
11. Chair's Address ....................................... 27 10. Acknowledgements ...................................... 28
12. Author's Address ...................................... 27
13. Full Copyright Statement .............................. 28 11. Chair's Address ....................................... 28
12. Author's Address ...................................... 28
13. Full Copyright Statement .............................. 29
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) document [1] The RADIUS (Remote Authentication Dial In User Service) document [2]
specifies the RADIUS protocol used for Authentication and specifies the RADIUS protocol used for Authentication and
Authorization. This memo extends the use of the RADIUS protocol to Authorization. This memo extends the use of the RADIUS protocol to
cover delivery of accounting information from the Network Access cover delivery of accounting information from the Network Access
Server (NAS) to a RADIUS accounting server. Server (NAS) to a RADIUS accounting server.
This document obsoletes RFC 2139 [1]. A summary of the changes
between this document and RFC 2139 is available in the "Change Log"
appendix.
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.
The RADIUS accounting server is responsible for receiving the The RADIUS accounting server is responsible for receiving the
skipping to change at page 4, line 9 skipping to change at page 5, line 9
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 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. These document are to be interpreted as described in RFC 2119 [3]. These
key words mean the same thing whether capitalized or not. key words mean the same thing whether capitalized or not.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
service The NAS provides a service to the dial-in user, such as PPP service The NAS provides a service to the dial-in user, such as PPP
or Telnet. or Telnet.
session Each service provided by the NAS to a dial-in user session Each service provided by the NAS to a dial-in user
skipping to change at page 5, line 4 skipping to change at page 6, 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. until it receives an acknowledgement, using some form of backoff. If
If no response is returned within a length of time, the request is no response is returned within a length of time, the request is re-
re-sent a number of times. The client can also forward requests to sent a number of times. The client can also forward requests to an
an alternate server or servers in the event that the primary server alternate server or servers in the event that the primary server is
is down or unreachable. An alternate server can be used either after down or unreachable. An alternate server can be used either after a
a number of tries to the primary server fail, or in a round-robin 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.
2.1. Proxy 2.1. Proxy
See the "RADIUS" RFC [1] for information on Proxy RADIUS. Proxy See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy
Accounting RADIUS works the same way, as illustrated by the following Accounting RADIUS works the same way, as illustrated by the following
example. example.
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 the request to the response packet, and sends the accounting-
accounting-response to the forwarding server. 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 6, line 12 skipping to change at page 7, line 12
server has very different characteristics than the link between NAS server has very different characteristics than the link between NAS
and forwarding server. and forwarding server.
Extreme care should be used when implementing a proxy server that Extreme care should be used when implementing a proxy server that
takes responsibility for retransmissions so that its retransmission takes responsibility for retransmissions so that its retransmission
policy is robust and scalable. policy is robust and scalable.
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 [3], where the UDP Destination Port field indicates 1813 field [4], 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.
This memo documents the RADIUS Accounting protocol. The early This memo documents the RADIUS Accounting protocol. The early
deployment of RADIUS Accounting was done using UDP port number 1646, deployment of RADIUS Accounting was done using UDP port number 1646,
which conflicts with the "sa-msg-port" service. The officially which conflicts with the "sa-msg-port" service. The officially
assigned port number for RADIUS Accounting is 1813. assigned port number for RADIUS Accounting is 1813.
skipping to change at page 7, line 30 skipping to change at page 8, line 30
Authenticator Authenticator
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 [5] 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 Authenticator field in Accounting-Request packets contains a one-
one-way MD5 hash calculated over a stream of octets consisting of way MD5 hash calculated over a stream of octets consisting of the
the Code + Identifier + Length + 16 zero octets + request Code + Identifier + Length + 16 zero octets + request attributes +
attributes + shared secret (where + indicates concatenation). shared secret (where + indicates concatenation). The 16 octet MD5
The 16 octet MD5 hash value is stored in the Authenticator field hash value is stored in the Authenticator field of the
of the Accounting-Request packet. 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 The Authenticator field in an Accounting-Response packet is called
called the Response Authenticator, and contains a one-way MD5 the Response Authenticator, and contains a one-way MD5 hash
hash calculated over a stream of octets consisting of the calculated over a stream of octets consisting of the Accounting-
Accounting-Response Code, Identifier, Length, the Request Response Code, Identifier, Length, the Request Authenticator field
Authenticator field from the Accounting-Request packet being from the Accounting-Request packet being replied to, and the
replied to, and the response attributes if any, followed by the response attributes if any, followed by the shared secret. The
shared secret. The resulting 16 octet MD5 hash value is stored resulting 16 octet MD5 hash value is stored in the Authenticator
in the Authenticator field of the Accounting-Response packet. 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 11, line 35 skipping to change at page 12, line 35
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [5]. field are specified in the most recent "Assigned Numbers" RFC [6].
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 document [1]) 1-39 (refer to RADIUS document [2])
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 document [1]) 60+ (refer to RADIUS document [2])
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 MUST be silently discarded. Length, the entire request MUST be silently discarded.
Value Value
The Value field is zero or more octets and contains information The Value field is zero or more octets and contains information
specific to the attribute. The format and length of the Value specific to the attribute. The format and length of the Value
field is determined by the Type and Length fields. field is determined by the Type and Length fields.
Note that a "string" in RADIUS does not terminate with a NUL (hex Note that a "string" in RADIUS does not terminate with a NUL (hex
00). The Attribute has a length field and does not use a 00). The Attribute has a length field and does not use a
terminator. Strings may contain UTF-8 [6] characters or 8-bit terminator. Strings may contain UTF-8 [7] characters or 8-bit
binary data and servers and servers and clients MUST be able to binary data and servers and servers and clients MUST be able to
deal with embedded nulls. RADIUS implementers using C are deal with embedded nulls. RADIUS implementers using C are
cautioned not to use strcpy() when handling strings. cautioned not to use strcpy() when handling strings.
The format of the value field is one of four data types. The format of the value field is one of four data types.
string 1-253 octets. Strings of length zero (0) MUST NOT be string 1-253 octets. Strings of length zero (0) MUST NOT be
sent; omit the entire attribute instead. sent; omit the entire attribute instead.
address 32 bit value, most significant octet first. address 32 bit value, most significant octet first.
skipping to change at page 26, line 10 skipping to change at page 27, line 10
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. IANA Considerations 6. IANA Considerations
The Packet Type Codes, Attribute Types, and Attribute Values The Packet Type Codes, Attribute Types, and Attribute Values defined
defined in this document are registered by the Internet Assigned in this document are registered by the Internet Assigned Numbers
Numbers Authority (IANA) from the RADIUS name spaces as described Authority (IANA) from the RADIUS name spaces as described in the
in the "IANA Considerations" section of RFC xxxx [1], in "IANA Considerations" section of RFC xxxx [2], in accordance with BCP
accordance with BCP 26 [10]. 26 [8].
7. Security Considerations 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.
8. Change Log 8. Change Log
US-ASCII replaced by UTF-8. US-ASCII replaced by UTF-8.
skipping to change at page 26, line 41 skipping to change at page 27, line 41
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.
Added an IANA Considerations section. Added an IANA Considerations section.
Updated references. Updated references.
9. References 9. References
[1] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[2] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
Authentication Dial In User Service (RADIUS)", RFC xxxx, Authentication Dial In User Service (RADIUS)", RFC xxxx,
February 2000. February 2000.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] 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 [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[4] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", [5] 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 [6] 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 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
10. 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.
11. 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:
 End of changes. 32 change blocks. 
75 lines changed or deleted 95 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/