diff options
Diffstat (limited to 'rfc/rfc2139.txt')
| -rw-r--r-- | rfc/rfc2139.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/rfc/rfc2139.txt b/rfc/rfc2139.txt new file mode 100644 index 00000000..88c5af8d --- /dev/null +++ b/rfc/rfc2139.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2139 Livingston +Obsoletes: 2059 April 1997 +Category: Informational + + + RADIUS Accounting + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document describes a protocol for carrying accounting + information between a Network Access Server and a shared Accounting + Server. + +Implementation Note + + This memo documents the RADIUS Accounting protocol. There has been + some confusion in the assignment of port numbers for this protocol. + The early deployment of RADIUS Accounting was done using the + erroneously chosen port number 1646, which conflicts with the "sa- + msg-port" service. The officially assigned port number for RADIUS + Accounting is 1813. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 3 + 1.2 Terminology ..................................... 3 + 2. Operation ............................................. 4 + 3. Packet Format ......................................... 5 + 4. Packet Types .......................................... 7 + 4.1 Accounting-Request .............................. 7 + 4.2 Accounting-Response ............................. 8 + 5. Attributes ............................................ 10 + 5.1 Acct-Status-Type ................................ 11 + 5.2 Acct-Delay-Time ................................. 12 + 5.3 Acct-Input-Octets ............................... 13 + 5.4 Acct-Output-Octets .............................. 14 + 5.5 Acct-Session-Id ................................. 14 + 5.6 Acct-Authentic .................................. 15 + 5.7 Acct-Session-Time ............................... 16 + 5.8 Acct-Input-Packets .............................. 16 + + + +Rigney Informational [Page 1] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 .............................................. 24 + Author's Address ............................................. 25 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + The RADIUS (Remote Authentication Dial In User Service) document [4] + specifies the RADIUS protocol used for Authentication and + Authorization. This memo extends the use of the RADIUS protocol to + cover delivery of accounting information from the Network Access + Server (NAS) to a RADIUS accounting server. + + Key features of RADIUS Accounting are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of the + RADIUS accounting server. The client is responsible for + passing user accounting information to a designated RADIUS + accounting server. + + The RADIUS accounting server is responsible for receiving the + accounting request and returning a response to the client + indicating that it has successfully received the request. + + The RADIUS accounting server can act as a proxy client to other + kinds of accounting servers. + + + + + + + + +Rigney Informational [Page 2] + +RFC 2139 RADIUS Accounting April 1997 + + + Network Security + + Transactions between the client and RADIUS accounting server + are authenticated through the use of a shared secret, which is + never sent over the network. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added + without disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + +1.2. Terminology + + This document uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + + + + + + + + + +Rigney Informational [Page 3] + +RFC 2139 RADIUS Accounting April 1997 + + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that, with each session + generating a separate start and stop accounting record with + its own Acct-Session-Id. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. Operation + + When a client is configured to use RADIUS Accounting, at the start of + service delivery it will generate an Accounting Start packet + describing the type of service being delivered and the user it is + being delivered to, and will send that to the RADIUS Accounting + server, which will send back an acknowledgement that the packet has + been received. At the end of service delivery the client will + generate an Accounting Stop packet describing the type of service + that was delivered and optionally statistics such as elapsed time, + input and output octets, or input and output packets. It will send + that to the RADIUS Accounting server, which will send back an + acknowledgement that the packet has been received. + + The Accounting-Request (whether for Start or Stop) is submitted to + the RADIUS accounting server via the network. It is recommended that + the client continue attempting to send the Accounting-Request packet + until it receives an acknowledgement, using some form of backoff. If + no response is returned within a length of time, the request is re- + sent a number of times. The client can also forward requests to an + alternate server or servers in the event that the primary server is + down or unreachable. An alternate server can be used either after a + number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + The RADIUS accounting server MAY make requests of other servers in + order to satisfy the request, in which case it acts as a client. + + If the RADIUS accounting server is unable to successfully record the + accounting packet it MUST NOT send an Accounting-Response + acknowledgment to the client. + + + +Rigney Informational [Page 4] + +RFC 2139 RADIUS Accounting April 1997 + + +3. Packet Format + + Exactly one RADIUS Accounting packet is encapsulated in the UDP Data + field [1], where the UDP Destination Port field indicates 1813 + (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS Accounting protocol. There has been + some confusion in the assignment of port numbers for this protocol. + The early deployment of RADIUS Accounting was done using the + erroneously chosen port number 1646, which conflicts with the "sa- + msg-port" service. The officially assigned port number for RADIUS + Accounting is 1813. + + A summary of the RADIUS data format is shown below. The fields are + transmitted from left to right. + + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Code | Identifier | Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +| Authenticator | +| | +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attributes ... ++-+-+-+-+-+-+-+-+-+-+-+-+- + + +Code + + 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 + silently discarded. + + RADIUS Accounting Codes (decimal) are assigned as follows: + + 4 Accounting-Request + 5 Accounting-Response + +Identifier + + The Identifier field is one octet, and aids in matching requests and + replies. + + + +Rigney Informational [Page 5] + +RFC 2139 RADIUS Accounting April 1997 + + +Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + should be treated as padding and should be ignored on reception. If + the packet is shorter than the Length field indicates, it should be + silently discarded. The minimum length is 20 and maximum length is + 4096. + +Authenticator + + The Authenticator field is sixteen (16) octets. The most significant + octet is transmitted first. This value is used to authenticate the + messages between the client and RADIUS accounting server. + +Request Authenticator + + In Accounting-Request Packets, the Authenticator value is a 16 octet + MD5 [3] checksum, called the Request Authenticator. + + The NAS and RADIUS accounting server share a secret. The Request + Authenticator field in Accounting-Request packets contains a one- way + MD5 hash calculated over a stream of octets consisting of the Code + + Identifier + Length + 16 zero octets + request attributes + shared + secret (where + indicates concatenation). The 16 octet MD5 hash + value is stored in the Authenticator field of the Accounting-Request + packet. + + Note that the Request Authenticator of an Accounting-Request can + not be done the same way as the Request Authenticator of a RADIUS + Access-Request, because there is no User-Password attribute in an + Accounting-Request. + +Response Authenticator + + The Authenticator field in an Accounting-Response packet is called + the Response Authenticator, and contains a one-way MD5 hash + calculated over a stream of octets consisting of the Accounting- + Response Code, Identifier, Length, the Request Authenticator field + from the Accounting-Request packet being replied to, and the response + attributes if any, followed by the shared secret. The resulting 16 + octet MD5 hash value is stored in the Authenticator field of the + Accounting-Response packet. + + + + + + + +Rigney Informational [Page 6] + +RFC 2139 RADIUS Accounting April 1997 + + +Attributes + + 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 different types is not required to be preserved. + +4. Packet Types + + The RADIUS packet type is determined by the Code field in the first + octet of the packet. + +4.1. Accounting-Request + + Description + + Accounting-Request packets are sent from a client (typically a + Network Access Server or its proxy) to a RADIUS accounting server, + and convey information used to provide accounting for a service + provided to a user. The client transmits a RADIUS packet with the + Code field set to 4 (Accounting-Request). + + Upon receipt of an Accounting-Request, the server MUST transmit an + Accounting-Response reply if it successfully records the + accounting packet, and MUST NOT transmit any reply if it fails to + record the accounting packet. + + Any attribute valid in a RADIUS Access-Request or Access-Accept + packet is valid in a RADIUS Accounting-Request packet, except that + the following attributes MUST NOT be present in an Accounting- + Request: User-Password, CHAP-Password, Reply-Message, State. + Either NAS-IP-Address or NAS-Identifier MUST be present in a + RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- + Port-Type attribute or both unless the service does not involve a + port or the NAS does not distinguish among its ports. + + A summary of the Accounting-Request packet format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + +Rigney Informational [Page 7] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 4 for Accounting-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + Note that if Acct-Delay-Time is included in the attributes of an + Accounting-Request then the Acct-Delay-Time value will be updated + when the packet is retransmitted, changing the content of the + Attributes field and requiring a new Identifier and Request + Authenticator. + + Request Authenticator + + The Request Authenticator of an Accounting-Request contains a 16- + octet MD5 hash value calculated according to the method described + in "Request Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + Attributes. + +4.2. Accounting-Response + + Description + + Accounting-Response packets are sent by the RADIUS accounting + server to the client to acknowledge that the Accounting-Request + has been received and recorded successfully. If the Accounting- + + + +Rigney Informational [Page 8] + +RFC 2139 RADIUS Accounting April 1997 + + + Request was recorded successfully then the RADIUS accounting + server MUST transmit a packet with the Code field set to 5 + (Accounting-Response). On reception of an Accounting-Response by + the client, the Identifier field is matched with a pending + Accounting-Request. Invalid packets are silently discarded. + + A RADIUS Accounting-Response is not required to have any + attributes in it. + + A summary of the Accounting-Response packet format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 5 for Accounting-Response. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Accounting-Request which caused this Accounting-Response. + + Response Authenticator + + The Response Authenticator of an Accounting-Response contains a + 16-octet MD5 hash value calculated according to the method + described in "Response Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney Informational [Page 9] + +RFC 2139 RADIUS Accounting April 1997 + + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization + and accounting details for the request and response. + + Some attributes MAY be included more than once. The effect of this + is attribute specific, and is specified in each attribute + description. + + The end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the attribute format is shown below. The fields are + transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. This specification concerns + the following values: + + 1-39 (refer to RADIUS document [4]) + 40 Acct-Status-Type + 41 Acct-Delay-Time + 42 Acct-Input-Octets + 43 Acct-Output-Octets + 44 Acct-Session-Id + 45 Acct-Authentic + 46 Acct-Session-Time + 47 Acct-Input-Packets + 48 Acct-Output-Packets + 49 Acct-Terminate-Cause + 50 Acct-Multi-Session-Id + 51 Acct-Link-Count + 60+ (refer to RADIUS document [4]) + + + + + + + +Rigney Informational [Page 10] + +RFC 2139 RADIUS Accounting April 1997 + + + Length + + The Length field is one octet, and indicates the length of this + attribute including the Type, Length and Value fields. If an + attribute is received in an Accounting-Request with an invalid + Length, the entire request should be silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the attribute. The format and length of the Value + field is determined by the Type and Length fields. + + The format of the value field is one of four data types. + + string 0-253 octets + + address 32 bit value, most significant octet first. + + integer 32 bit value, most significant octet first. + + time 32 bit value, most significant octet first -- seconds + since 00:00:00 GMT, January 1, 1970. The standard + Attributes do not use this data type but it is presented + here for possible use within Vendor-Specific attributes. + +5.1. Acct-Status-Type + + Description + + This attribute indicates whether this Accounting-Request marks the + beginning of the user service (Start) or the end (Stop). + + It MAY be used by the client to mark the start of accounting (for + example, upon booting) by specifying Accounting-On and to mark the + end of accounting (for example, just before a scheduled reboot) by + specifying Accounting-Off. + + A summary of the Acct-Status-Type attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 11] + +RFC 2139 RADIUS Accounting April 1997 + + + Type + + 40 for Acct-Status-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Start + 2 Stop + 7 Accounting-On + 8 Accounting-Off + +5.2. Acct-Delay-Time + + Description + + This attribute indicates how many seconds the client has been + trying to send this record for, and can be subtracted from the + time of arrival on the server to find the approximate time of the + event generating this Accounting-Request. (Network transit time + is ignored.) + + Note that changing the Acct-Delay-Time causes the Identifier to + change; see the discussion under Identifier above. + + A summary of the Acct-Delay-Time attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 41 for Acct-Delay-Time. + + Length + + 6 + + + +Rigney Informational [Page 12] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets. + +5.3. Acct-Input-Octets + + Description + + This attribute indicates how many octets have been received from + the port over the course of this service being provided, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Input-Octets attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 42 for Acct-Input-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.4. Acct-Output-Octets + + Description + + This attribute indicates how many octets have been sent to the + port in the course of delivering this service, and can only be + present in Accounting-Request records where the Acct-Status-Type + is set to Stop. + + A summary of the Acct-Output-Octets attribute format is shown below. + The fields are transmitted from left to right. + + + + +Rigney Informational [Page 13] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 43 for Acct-Output-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.5. Acct-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to match + start and stop records in a log file. The start and stop records + for a given session MUST have the same Acct-Session-Id. It is + strongly recommended that the Acct-Session-Id be a printable ASCII + string. + + For example, one implementation uses a string with an 8-digit + upper case hexadecimal number, the first two digits increment on + each reboot (wrapping every 256 reboots) and the next 6 digits + counting from 0 for the first person logging in after a reboot up + to 2^24-1, about 16 million. Other encodings are possible. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + +Rigney Informational [Page 14] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 44 for Acct-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of printable ASCII characters. + +5.6. Acct-Authentic + + Description + + This attribute MAY be included in an Accounting-Request to + indicate how the user was authenticated, whether by RADIUS, the + NAS itself, or another remote authentication protocol. Users who + are delivered service without being authenticated SHOULD NOT + generate Accounting records. + + A summary of the Acct-Authentic attribute format is shown below. The + fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 45 for Acct-Authentic. + + Length + + 6 + + + + + +Rigney Informational [Page 15] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets. + + 1 RADIUS + 2 Local + 3 Remote + +5.7. Acct-Session-Time + + Description + + This attribute indicates how many seconds the user has received + service for, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Session-Time attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 46 for Acct-Session-Time. + + Length + + 6 + + Value + + The Value field is four octets. + +5.8. Acct-Input-Packets + + Description + + This attribute indicates how many packets have been received from + the port over the course of this service being provided to a + Framed User, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + + + +Rigney Informational [Page 16] + +RFC 2139 RADIUS Accounting April 1997 + + + A summary of the Acct-Input-packets attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 47 for Acct-Input-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.9. Acct-Output-Packets + + Description + + This attribute indicates how many packets have been sent to the + port in the course of delivering this service to a Framed User, + and can only be present in Accounting-Request records where the + Acct-Status-Type is set to Stop. + + A summary of the Acct-Output-Packets attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 48 for Acct-Output-Packets. + + + + + +Rigney Informational [Page 17] + +RFC 2139 RADIUS Accounting April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + +5.10. Acct-Terminate-Cause + + Description + + This attribute indicates how the session was terminated, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Terminate-Cause attribute format is shown + below. The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 49 for Acct-Terminate-Cause + + Length + + 6 + + + + + + + + + + + + + + + + + +Rigney Informational [Page 18] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets, containing an integer specifying + the cause of session termination, as follows: + + 1 User Request + 2 Lost Carrier + 3 Lost Service + 4 Idle Timeout + 5 Session Timeout + 6 Admin Reset + 7 Admin Reboot + 8 Port Error + 9 NAS Error + 10 NAS Request + 11 NAS Reboot + 12 Port Unneeded + 13 Port Preempted + 14 Port Suspended + 15 Service Unavailable + 16 Callback + 17 User Error + 18 Host Request + + + + The termination causes are as follows: + + User Request User requested termination of service, for + example with LCP Terminate or by logging out. + + Lost Carrier DCD was dropped on the port. + + Lost Service Service can no longer be provided; for + example, user's connection to a host was + interrupted. + + Idle Timeout Idle timer expired. + + Session Timeout Maximum session length timer expired. + + Admin Reset Administrator reset the port or session. + + Admin Reboot Administrator is ending service on the NAS, + for example prior to rebooting the NAS. + + Port Error NAS detected an error on the port which + required ending the session. + + + +Rigney Informational [Page 19] + +RFC 2139 RADIUS Accounting April 1997 + + + NAS Error NAS detected some error (other than on the + port) which required ending the session. + + NAS Request NAS ended session for a non-error reason not + otherwise listed here. + + NAS Reboot The NAS ended the session in order to reboot + non-administratively ("crash"). + + Port Unneeded NAS ended session because resource usage fell + below low-water mark (for example, if a + bandwidth-on-demand algorithm decided that + the port was no longer needed). + + Port Preempted NAS ended session in order to allocate the + port to a higher priority use. + + Port Suspended NAS ended session to suspend a virtual + session. + + Service Unavailable NAS was unable to provide requested service. + + Callback NAS is terminating current session in order + to perform callback for a new session. + + User Error Input from user is in error, causing + termination of session. + + Host Request Login Host terminated session normally. + +5.11. Acct-Multi-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to link + together multiple related sessions in a log file. Each session + linked together would have a unique Acct-Session-Id but the same + Acct-Multi-Session-Id. It is strongly recommended that the Acct- + Multi-Session-Id be a printable ASCII string. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 20] + +RFC 2139 RADIUS Accounting April 1997 + + + Type + + 50 for Acct-Multi-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of printable ASCII characters. + +5.12. Acct-Link-Count + + Description + + This attribute gives the count of links which are known to have + been in a given multilink session at the time the accounting + record is generated. The NAS MAY include the Acct-Link-Count + attribute in any Accounting-Request which might have multiple + links. + + A summary of the Acct-Link-Count attribute format is show below. The + fields are transmitted from left to right. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 51 for Acct-Link-Count. + + Length + + 6 + + Value + + The Value field is four octets, and contains the number of links + seen so far in this Multilink Session. + + + + + + +Rigney Informational [Page 21] + +RFC 2139 RADIUS Accounting April 1997 + + + It may be used to make it easier for an accounting server to know + when it has all the records for a given Multilink session. When + the number of Accounting-Requests received with Acct-Status-Type = + Stop and the same Acct-Multi-Session-Id and unique Acct-Session- + Id's equals the largest value of Acct-Link-Count seen in those + Accounting-Requests, all Stop Accounting-Requests for that + Multilink Session have been received. + + An example showing 8 Accounting-Requests should make things + clearer. For clarity only the relevant attributes are shown, but + additional attributes containing accounting information will also + be present in the Accounting-Request. + + Multi-Session-Id Session-Id Status-Type Link-Count + "10" "10" Start 1 + "10" "11" Start 2 + "10" "11" Stop 2 + "10" "12" Start 3 + "10" "13" Start 4 + "10" "12" Stop 4 + "10" "13" Stop 4 + "10" "10" Stop 4 + +5.13. Table of Attributes + + The following table provides a guide to which attributes may be found + in Accounting-Request packets. No attributes should be found in + Accounting-Response packets except Proxy-State and possibly Vendor- + Specific. + + # Attribute + 0-1 User-Name + 0 User-Password + 0 CHAP-Password + 0-1 NAS-IP-Address [5] + 0-1 NAS-Port + 0-1 Service-Type + 0-1 Framed-Protocol + 0-1 Framed-IP-Address + 0-1 Framed-IP-Netmask + 0-1 Framed-Routing + 0+ Filter-Id + 0-1 Framed-MTU + 0+ Framed-Compression + 0+ Login-IP-Host + 0-1 Login-Service + 0-1 Login-TCP-Port + 0 Reply-Message + + + +Rigney Informational [Page 22] + +RFC 2139 RADIUS Accounting April 1997 + + + 0-1 Callback-Number + 0-1 Callback-Id + 0+ Framed-Route + 0-1 Framed-IPX-Network + 0 State + 0+ Class + 0+ Vendor-Specific + 0-1 Session-Timeout + 0-1 Idle-Timeout + 0-1 Termination-Action + 0-1 Called-Station-Id + 0-1 Calling-Station-Id + 0-1 NAS-Identifier [4] + 0+ Proxy-State + 0-1 Login-LAT-Service + 0-1 Login-LAT-Node + 0-1 Login-LAT-Group + 0-1 Framed-AppleTalk-Link + 0-1 Framed-AppleTalk-Network + 0-1 Framed-AppleTalk-Zone + 1 Acct-Status-Type + 0-1 Acct-Delay-Time + 0-1 Acct-Input-Octets + 0-1 Acct-Output-Octets + 1 Acct-Session-Id + 0-1 Acct-Authentic + 0-1 Acct-Session-Time + 0-1 Acct-Input-Packets + 0-1 Acct-Output-Packets + 0-1 Acct-Terminate-Cause + 0+ Acct-Multi-Session-Id + 0+ Acct-Link-Count + 0 CHAP-Challenge + 0-1 NAS-Port-Type + 0-1 Port-Limit + 0-1 Login-LAT-Port + + + [5] An Accounting-Request MUST contain either a NAS-IP-Address or a + NAS-Identifier, and it is permitted (but not recommended) for it to + contain both. + + The following table defines the above table entries. + + 0 This attribute MUST NOT 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. + 1 Exactly one instance of this attribute MUST be present. + + + +Rigney Informational [Page 23] + +RFC 2139 RADIUS Accounting April 1997 + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + authenticator included in accounting requests and responses, using a + shared secret which is never sent over the network. + +References + + [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, RSA Data + Security Inc., April 1992. + + [4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, + April 1997. + +Acknowledgments + + RADIUS and RADIUS Accounting were originally developed by Livingston + Enterprises for their PortMaster series of Network Access Servers. + +Chair's Address + + The RADIUS working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510 426 0770 + EMail: cdr@livingston.com + + + + + + + + + + + + + +Rigney Informational [Page 24] + +RFC 2139 RADIUS Accounting April 1997 + + +Author's Address + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@livingston.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 25] + |