diff options
Diffstat (limited to 'doc/rfc/rfc2866.txt')
| -rw-r--r-- | doc/rfc/rfc2866.txt | 1571 |
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc2866.txt b/doc/rfc/rfc2866.txt new file mode 100644 index 0000000..82da1dc --- /dev/null +++ b/doc/rfc/rfc2866.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2866 Livingston +Category: Informational June 2000 +Obsoletes: 2139 + + + RADIUS Accounting + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +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. The early + deployment of RADIUS Accounting was done using UDP 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 + 2.1 Proxy ......................................... 4 + 3. Packet Format ................................... 5 + 4. Packet Types ................................... 7 + 4.1 Accounting-Request ............................ 8 + 4.2 Accounting-Response ........................... 9 + 5. Attributes ...................................... 10 + 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 ............................... 15 + + + +Rigney Informational [Page 1] + +RFC 2866 RADIUS Accounting June 2000 + + + 5.6 Acct-Authentic ................................ 16 + 5.7 Acct-Session-Time ............................. 17 + 5.8 Acct-Input-Packets ............................ 18 + 5.9 Acct-Output-Packets ........................... 18 + 5.10 Acct-Terminate-Cause .......................... 19 + 5.11 Acct-Multi-Session-Id ......................... 21 + 5.12 Acct-Link-Count ............................... 22 + 5.13 Table of Attributes ........................... 23 + 6. IANA Considerations ............................. 25 + 7. Security Considerations ......................... 25 + 8. Change Log ...................................... 25 + 9. References ...................................... 26 + 10. Acknowledgements ................................ 26 + 11. Chair's Address ................................. 26 + 12. Author's Address ................................ 27 + 13. Full Copyright Statement ........................ 28 + +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 [2] + 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. + + 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: + + 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. + + + + + +Rigney Informational [Page 2] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. + + 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 + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [3]. These + key words mean the same thing whether capitalized or not. + +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. + + 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. + + + +Rigney Informational [Page 3] + +RFC 2866 RADIUS Accounting June 2000 + + +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. + +2.1. Proxy + + See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy + Accounting RADIUS works the same way, as illustrated by the following + example. + + 1. The NAS sends an accounting-request to the forwarding server. + + 2. The forwarding server logs the accounting-request (if desired), + adds its Proxy-State (if desired) after any other Proxy-State + attributes, updates the Request Authenticator, and forwards the + request to the remote server. + + + + + + +Rigney Informational [Page 4] + +RFC 2866 RADIUS Accounting June 2000 + + + 3. The remote server logs the accounting-request (if desired), + copies all Proxy-State attributes in order and unmodified from + the request to the response packet, and sends the accounting- + response to the forwarding server. + + 4. The forwarding server strips the last Proxy-State (if it added + one in step 2), updates the Response Authenticator and sends + the accounting-response to the NAS. + + A forwarding server MUST not modify existing Proxy-State or Class + attributes present in the packet. + + A forwarding server may either perform its forwarding function in a + pass through manner, where it sends retransmissions on as soon as it + gets them, or it may take responsibility for retransmissions, for + example in cases where the network link between forwarding and remote + server has very different characteristics than the link between NAS + and forwarding server. + + Extreme care should be used when implementing a proxy server that + takes responsibility for retransmissions so that its retransmission + policy is robust and scalable. + +3. Packet Format + + Exactly one RADIUS Accounting packet is encapsulated in the UDP Data + field [4], 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. The early + deployment of RADIUS Accounting was done using UDP 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. + + + + + + + + + + + + +Rigney Informational [Page 5] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. The RADIUS server can detect a duplicate request if + it has the same client source IP address and source UDP port and + Identifier within a short span of time. + + 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 + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and maximum length + is 4095. + + 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. + + + +Rigney Informational [Page 6] + +RFC 2866 RADIUS Accounting June 2000 + + + Request Authenticator + + In Accounting-Request Packets, the Authenticator value is a 16 + octet MD5 [5] 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. + + 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. + + + + + + + + + + + + +Rigney Informational [Page 7] + +RFC 2866 RADIUS Accounting June 2000 + + +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. + + If the Accounting-Request packet includes a Framed-IP-Address, + that attribute MUST contain the IP address of the user. If the + Access-Accept used the special values for Framed-IP-Address + telling the NAS to assign or negotiate an IP address for the user, + the Framed-IP-Address (if any) in the Accounting-Request MUST + contain the actual IP address assigned or negotiated. + + A summary of the Accounting-Request 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + + + +Rigney Informational [Page 8] + +RFC 2866 RADIUS Accounting June 2000 + + + 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- + 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. The Response Authenticator field MUST contain + the correct response for the 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. + + + +Rigney Informational [Page 9] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. + +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. + + + + +Rigney Informational [Page 10] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 [6]. + 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 [2]) + 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 [2]) + + 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 MUST 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. + + Note that none of the types in RADIUS terminate with a NUL (hex + 00). In particular, types "text" and "string" in RADIUS do not + terminate with a NUL (hex 00). The Attribute has a length field + and does not use a terminator. Text contains UTF-8 encoded 10646 + + + +Rigney Informational [Page 11] + +RFC 2866 RADIUS Accounting June 2000 + + + [7] characters and String contains 8-bit binary data. Servers and + servers and clients MUST be able to deal with embedded nulls. + RADIUS implementers using C are cautioned not to use strcpy() when + handling strings. + + The format of the value field is one of five data types. Note + that type "text" is a subset of type "string." + + text 1-253 octets containing UTF-8 encoded 10646 [7] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + string 1-253 octets containing binary data (values 0 through 255 + decimal, inclusive). Strings of length zero (0) MUST NOT + be sent; omit the entire attribute instead. + + address 32 bit value, most significant octet first. + + integer 32 bit unsigned value, most significant octet first. + + time 32 bit unsigned value, most significant octet first -- + seconds since 00:00:00 UTC, January 1, 1970. The + standard Attributes do not use this data type but it is + presented here for possible use in future 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 12] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 40 for Acct-Status-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Start + 2 Stop + 3 Interim-Update + 7 Accounting-On + 8 Accounting-Off + 9-14 Reserved for Tunnel Accounting + 15 Reserved for Failed + +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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Rigney Informational [Page 13] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 41 for Acct-Delay-Time. + + Length + + 6 + + 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. + + + + + + + + +Rigney Informational [Page 14] + +RFC 2866 RADIUS Accounting June 2000 + + +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. + + 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. An + Accounting-Request packet MUST have an Acct-Session-Id. An + Access-Request packet MAY have an Acct-Session-Id; if it does, + then the NAS MUST use the same Acct-Session-Id in the Accounting- + Request packets for that session. + + The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] + characters. + + + + + +Rigney Informational [Page 15] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. + + 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 | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 44 for Acct-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of UTF-8 encoded 10646 [7] + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 16] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 45 for Acct-Authentic. + + Length + + 6 + + 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. + + + + + +Rigney Informational [Page 17] + +RFC 2866 RADIUS Accounting June 2000 + + +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. + + 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. + + + + + + + + +Rigney Informational [Page 18] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. + + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + +Rigney Informational [Page 19] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 49 for Acct-Terminate-Cause + + Length + + 6 + + 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. + + + +Rigney Informational [Page 20] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. + + 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 contain UTF-8 encoded 10646 [7] characters. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + + +Rigney Informational [Page 21] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 + + 50 for Acct-Multi-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD contain UTF-8 encoded 10646 [7] 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + +Rigney Informational [Page 22] + +RFC 2866 RADIUS Accounting June 2000 + + + 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. + + 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 + + + +Rigney Informational [Page 23] + +RFC 2866 RADIUS Accounting June 2000 + + + 0-1 NAS-IP-Address [Note 1] + 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 + 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 [Note 1] + 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 + + + + +Rigney Informational [Page 24] + +RFC 2866 RADIUS Accounting June 2000 + + + 0-1 NAS-Port-Type + 0-1 Port-Limit + 0-1 Login-LAT-Port + + [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address + or a NAS-Identifier (or 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. + +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 2865 [2], in accordance with BCP + 26 [8]. + +7. Security Considerations + + Security issues are discussed in sections concerning the + authenticator included in accounting requests and responses, using a + shared secret which is never sent over the network. + +8. Change Log + + US-ASCII replaced by UTF-8. + + Added notes on Proxy. + + 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 + the accounting-request for that session. + + New values added to Acct-Status-Type. + + Added an IANA Considerations section. + + Updated references. + + Text strings identified as a subset of string, to clarify use of + UTF-8. + + + + +Rigney Informational [Page 25] + +RFC 2866 RADIUS Accounting June 2000 + + +9. References + + [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. + + [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [5] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 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 + + RADIUS and RADIUS Accounting were originally developed by Steve + Willens of Livingston Enterprises for their PortMaster series of + Network Access Servers. + +11. 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 925 737 2100 + EMail: cdr@telemancy.com + + + + + + + + +Rigney Informational [Page 26] + +RFC 2866 RADIUS Accounting June 2000 + + +12. Author's Address + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@telemancy.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 27] + +RFC 2866 RADIUS Accounting June 2000 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 28] + |