|
|
In 1997, the Internet Engineering Task Force (IETF) finalized the RADIUS protocol specification as RFC 2058. It was superseded by RFC 2138 and later RFC 2865. RFC 2059 was the first RADIUS accounting standard; it was made obsolete by RFC 2139 and later RFC 2866. Note the difference between the RADIUS protocol specification (RFC 2865) and the RADIUS accounting specification (RFC 2866). Although both are IETF standards, RFC 2866 is an informational standard only, and RFC 2865 is a formal IETF standard.
The RADIUS specification contains client and server roles, where the NAS performs the client role. Splitting the functionality provides the foundation for scalability, because a single RADIUS server can serve multiple clients (NASs), resulting in a single data store for user credentials. Two different RADIUS packet types exist: authentication and accounting packets. The NAS sends authentication requests to the RADIUS server to check the user's identity. This request consists of the user credentials and NAS IP address or identifier. The RADIUS server sends authentication replies that include the reply code and a set of additional attributes. An accounting request is sent to the server when the NAS reports an event, such as the session start and termination. For each successfully processed accounting request, the RADIUS server returns an accounting acknowledgment, which informs the NAS that the information was received. This handshake mechanism avoids packet loss over the UDP protocol. Authorization takes places after successful authentication. For example, your company may have policies for prohibiting access to sensitive information (such as finacial data or source code) over the Internet. In this case, even successful authentication would not grant access to sensitive data.
A typical user session occurs as follows: When a user connects to a NAS, first it verifies that the user is actually registered and that the supplied credentials are correct: this step is called authentication. The NAS forms an authentication request and sends it to the RADIUS server, which then verifies the user's credentials against the database. The acknowledgment packet is returned to the NAS. The server reply advises the NAS to assign an IP address to the user and to establish a connection between the user and the server that the user intends to connect to, assuming that the authentication was accepted.
As the second step, the NAS determines which services the user is permitted to use and optionally applies specific resource limitations for an individual or group. This step is called authorization. Authorization can be implemented in several ways, such as applying a preconfigured access control list (ACL) to restrict the user's access to resources and services based on one or more metrics (time of day, transport type, user group).
After a successful authentication and authorization, the NAS establishes a connection between the user and the application server. Now application data can be transmitted, while so far only access and authorization control traffic was exchanged. At this time, accounting starts as follows: the NAS stores the session's start time and generates an accounting-requests packet for the AAA server. The initiating packet is called "accounting-start," and the terminating packet is called "accounting-stop." During the session, optional accounting update packets can be sent. For each request, the AAA server replies with an accounting-response. A usage record typically consists of the session's start and stop times, duration, and number of input and output octets and packets transferred. Each AAA session consists of at least two report messages:
Accounting-start request message with the start time
Accounting-stop request message with the stop time and full accounting details
Figure 9-2 illustrates the interaction between the NAS and the RADIUS server.
RADIUS attributes carry the specific authentication, authorization, accounting, and configuration details for the request and response. Attributes are exchanged between the NAS and the server. Each attribute is associated with a set of properties that specifies how to interpret it. The most important property is the data type, which declares the type of data that the attribute identifies (character string, integer number, IP address, or raw binary data). The information to be transmitted with the request is packaged in a set of attribute/value pairs (AV pairs, or AVP), which consist of attribute numbers and the associated data. RFC 2865 describes the RADIUS protocol and defines the different AAA attributes. Note that RFC 2865 defines attributes 1 through 39 and 60 through 63, whereas 40 through 59 are reserved for accounting and are not defined in RFC 2865. The informational RFC 2866 extends this specification by defining the accounting-specific attributes (40 through 59). RFC 2869 is another informational RFC that extends RFC 2865 by specifying attributes 52 to 55. In summary, RFC 2865 (Standards Track) defines authentication and authorization, and the accounting part is defined in the informational RFCs 2866 and 2869.
Table 9-2 describes the significant RADIUS attributes from an accounting perspective. There are many more attributes. For a complete list, check RADIUS Attribute Types at http://www.iana.org/assignments/radius-types.
Note
The AVP Acct-Delay-Time is especially useful in situations in which the NAS creates duplicate accounting records. This can happen during timeouts in the conversation between the NAS and the RADIUS server. A duplicated record is an exact copy of the previous one, except for the Acct-Delay-Time, which indicates how many seconds the client has been trying to send this record. When the accounting record is sent for the first time, this value is always 0, whereas a resend record has a different value. An accounting application can search for accounting records in which all fields are equal, except for Acct-Delay-Time, and eliminate all but one of the records.
This section, which mainly focuses on the accounting part of RADIUS, covers only the most important commands. For the complete list of RADIUS commands, consult the Command Reference document.
router(config)# aaa new-model enables the AAA access control model.
router(config)# aaa group server radius group-name defines the AAA server group with a group name. It groups different RADIUS server hosts into distinct lists and distinct methods.
router(config-sg-radius)# server ip-address [auth-port port-number] [acct-port port-number] configures the IP address of the RADIUS server for the group server.
router(config)# aaa accounting {auth-proxy | system | network | exec | connection | commands level} {default | list-name} [vrf vrf-name] {start-stop | stop-only | none} [broadcast] group groupname configures the accounting for different features:
- system performs accounting for all system-level events not associated with users, such as reloads.
- network runs accounting for all network-related service requests, including Serial Line Internet Protocol (SLIP), PPP, PPP Network Control Protocols (NCP), and AppleTalk Remote Access Protocol (ARAP).
- exec—Runs accounting for the EXEC shell session.
- connection—Provides information about all outbound connections made from the network access server, such as Telnet, local-area transport (LAT), TN3270, packet assembler and disassembler (PAD), and rlogin.
router(config)# aaa accounting update [periodic number] enables periodic interim accounting records to be sent to the accounting server, where the number interval is specified in minutes.
The following example configures the RADIUS authentication and accounting for a user initiating a shell connection to the router. Accounting requests are sent with the start, stop, and periodic (every 1 minute) options. Note the default RADIUS accounting port of 1646. The following examples include the port number for completeness; this information is optional when using the default port.
router(config)# aaa new-model router(config)# aaa group server radius MyAdmin router(config-sg-radius)# server 10.48.66.102 auth-port 1645 acct-port 1646 router(config)# aaa authentication login default group MyAdmin router(config)# aaa accounting update periodic 1 router(config)# aaa accounting exec OpsAcctg start-stop group MyAdmin router(config)# radius-server host 10.48.66.102 auth-port 1645 acct-port 1646 key 7 01100F175804 router(config)# line vty 0 4 router(config-line)# accounting exec OpsAcctg
The RADIUS server would report the following information: Date, Time, User-Name, Group-Name, Calling-Station-Id, Acct-Status-Type, Acct-Session-Id, Acct-Session-Time, Service-Type, Framed-Protocol, Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets, Acct-Output-Packets, Framed-IP-Address, NAS-Port, and NAS-IP-Address. The following configuration example shows a leased-line PPP client that uses RADIUS for authentication and accounting:
router(config)# interface Serial2/0 router(config-if)# encapsulation ppp router(config-if)# ppp accounting SerialAccounting router(config-if)# ppp authentication pap router(config)# aaa accounting network SerialAccounting start-stop group MyAdmin
The preferred accounting solution for voice over IP is RADIUS. Most voice-specific MIBs are limited to legacy telephony environments. This section examines voice-specific extensions to the RADIUS protocol.
A call leg is a logical connection between the router and a classic telephony endpoint or another IP telephony endpoint using a session protocol, such as SIP or H.323. For an end-to-end connection, a separate call leg is generated for each segment that lies between two points of the connection. A call processed through a voice gateway, commonly referred to as just a gateway, consists of an outgoing (originate) and incoming (answer) call leg. A voice gateway is a device that allows telephone calls over a high-speed Internet connection. Its primary functions include voice and fax compression and decompression, packetization, call routing, and control signaling. Call leg directions (such as answer or originate) are named and described from the gateway's perspective. An end-to-end call going through an originating and terminating gateway consists of four call legs. Two are from the perspective of the source originating gateway (answer telephony, originate VoIP), and the other two are from the perspective of the destination terminating gateway (answer VoIP, originate telephony). Start-stop accounting has a separate start record and stop record for each call leg. Assuming that a call is established between two voice gateways, start-stop accounting generates four discrete start records and four discrete stop records, in which all eight records have the same ID. Depending on the device configuration, this unique ID is either specified in RADIUS attribute 26 as h323-conf-id or overloaded in RADIUS attribute 44:
h323-conf-id value in RADIUS attribute 26 VSA—h323-conf-id is a RADIUS attribute exported regardless of the voice protocol between the voice gateways. h323-conf-id is sent not only with H.323 configured between the voice gateways, but also when SIP is configured, which might be somewhat confusing. However, with SIP, this value is not identical for all the call legs. Instead, Call-id must be used.
Connection ID in RADIUS attribute 44 "Acct-Session-Id"—Acct-Session-Id works only when the H.323 protocol is used, as opposed to SIP.
Call-id values in RADIUS attribute 26 VSA—Call-id is the way to correlate call legs when SIP is used between voice gateways.
Figure 9-3 illustrates the four different call legs as they are generated through the voice call.
The four call legs are as follows:
Call leg 1 goes from the originating device (telephone, PC, fax machine) to the originating gateway. It is called answer telephony.
Call leg 2 is from the originating gateway over the IP cloud to the terminating gateway. It is called originate VoIP.
Call leg 3 is the mirror image of call leg 2. It is called answer VoIP from the perspective of the terminating gateway. The direction of the arrow in call leg 3 represents the call leg pointing to the originating gateway. This signifies that it is from the perspective of the terminating gateway and is the other half of a matching pair of VoIP dial peers for a single call.
Call leg 4 is from the terminating gateway to the terminating device. It is called originate VoIP.
An accounting system collects data for all calls, both legacy voice and VoIP. The most important elements of the data, other than the call's duration, are h323-conf-id and incoming-h323-conf-id, because they are required to correlate the different call legs. These two ID values are identical most of the time. This allows the correlation of the answer telephony call leg 1 (characterized by incoming-h323-conf-id) with the following originate VoIP call leg 2 (characterized by h323-conf-id). Because the h323-conf-id value is sent between the VoIP gateways as part of the H.323 protocol, the next VoIP gateway reports the same h323-config-id value for its call legs. Therefore, the RADIUS server correlates all the call legs of the same call. The billing system can combine the data from multiple call records with the same h323-conf-id value and store the call attributes (direction, duration, destination, source, volume) in its database to create a billing record.
In some cases the h323-conf-id and incoming-h323-conf-id are different. For example, the fact that there are two different ID variables has relevance in debit card calling when the user accesses the long pound facility for multisession calls. In this case, the RADIUS server needs to correlate the first two call legs with the incoming-h323-conf-id value.
When the VoIP signaling protocol between the two voice gateways is SIP, the Cisco AVP containing the Call-id value represents the unique conference ID, similar to h323-conf-id. The Call-id field is a mandatory header field in each call-related SIP message, which requires the next voice gateway to report its call legs with the same Call-id. Therefore, Call-id is the way to correlate call legs in a SIP scenario.
There is a major difference between configuring start-stop and stop-only records at the NAS. From a billing perspective, only the accounting-stop records are required, because they contain the call duration, transmitted volume, etc. Although the Interim-Update packets are not relevant for billing, they provide remarkable details for a performance management system. They contain performance metrics, such as early-packets, h323-voice-quality, lost-packets, round-trip-delay, and others. These are significant details for voice performance management, generated per call. This illustrates another intersection of accounting and performance management.
RADIUS VSAs The latest IETF RADIUS standards (RFC 2865 and RFC 2866) specify that you can use RADIUS attribute 26 to communicate vendor-specific information between a RADIUS client (NAS) and a RADIUS server. Attribute 26 is the VSA in RADIUS records.
The idea of VSAs is to offer vendors the opportunity to create new functions without going through the IETF standards process. This also implies that VSA records are not standardized, which means that different vendor implementations of VSAs might not be interoperable.
The concept of attributes is based on the X.500 definition, in which each attribute consists of a type identifier and one or more values. A VSA is an attribute that has been implemented by a particular vendor. It encapsulates the data as AVPs. The format is
vendor-specific = protocol:attribute = value
For example, cisco-avpair = timezone = UTC is an AVP in which timezone identifies the attribute and UTC is the value.
Cisco voice-specific VSAs are included in requests and responses between the voice gateway and the RADIUS server. The voice gateway, as a RADIUS client, sends and receives VSAs to and from a RADIUS server. Each Cisco voice-specific VSA conforms to the RADIUS specification for attribute 26. Figure 9-4 shows the format of RADIUS VSAs and Cisco voice-specific VSAs.
Table 9-3 describes the fields in the VSA.
Table 9-4 lists selected Cisco VSAs for accounting and performance management purposes.
To take advantage of standard RADIUS implementations that do not support VSAs, a different method is defined. It embeds the unsupported information elements in the RADIUS Acct-Session-Id (RADIUS value 44 from RFC 2865). The Acct-Session-Id field has a maximum length of 256 characters. It is defined to contain ten discrete fields, separated by a / as the delimited ASCII string. The overloaded Acct-Session-Id also contains connect and disconnect times, remote IP address, and disconnect cause. The following is the string format for the Acct-Session-Id field:
session id/call leg setup time/gateway id/connection id/call origin/call type/connect time/disconnect time/disconnect cause/remote ip address
One of these fields is the RADIUS connection id, which is a unique identifier that links accounting records associated with the same login session for a user. The internal representation of the connection-id field is 128 bits in hex format. This string can vary in appearance. An example is 3C5AEAB9 95C80008 0 587F34—denoted as a four-octet string, a space, a four-octet string, a space, a 0, a space, and a three-octet string.
Table 9-5 describes the overloaded Acct-Session-Id fields.
| Field | Description |
|---|---|
| session id | The standard (RFC 2139) RADIUS account-session-id. |
| call leg setup time | The setup time for this connection in NTP format. |
| gateway id | The name of the underlying gateway, as a string of the form gateway.domain_name |
| connection id | A unique global identifier used to correlate call legs that belong to the same end-to-end call. The field consists of four long words (128 bits). Each long word is displayed in hexadecimal value and is separated by a space. |
| call origin | The call's origin relative to the gateway. Possible values are originate and answer. |
| call type | The call leg type. Possible values are Telephony and VoIP. |
| connect time[*] | The connect time for this call leg in NTP format (stop only). |
| disconnect time[*] | The disconnect time for this call leg in NTP format (stop only). |
| disconnect cause[*] | Documented in the Q.850 specification. The value can be in the range of 1 to 127 (stop only). |
| remote IP address[*] | The IP address of the remote gateway used in this connection (stop only). |
[*] The last four attributes (connect and disconnect times, disconnect cause, and remote IP address) in the overloaded Acct-Session-Id are available only in the stop packets. In start packets and update packets, these fields are blank.
As a summary, consider the following rules for choosing between RADIUS attributes 26 and 44 for VoIP accounting:
The use of attribute 26 (VSA) is recommended whenever available, because it provides a superset of accounting information. After you enable VSAs, the Acct-Session-Id is no longer overloaded, because the information sent in the session ID is captured in VSAs.
Attribute 44 (overload) should be used only if VSA is not supported, because it provides a limited set of information. Furthermore, this attribute works only when the H.323 protocol is used, as opposed to SIP.
This section covers only the most important commands related to VoIP accounting with RADIUS. For the complete list of commands, consult the Command Reference document.
router(config)# gw-accounting aaa
enables VoIP gateway accounting. Previous IOS versions used the gw-accounting {h323 [vsa] | syslog | voip} CLI command for the same purposes.
router(config)# radius-server vsa send [accounting] [authentication]
allows the network access server to recognize and use VSAs as defined by RADIUS IETF attribute 26.
router(config-gw-accounting-aaa)# acct-template callhistory-detail
sends all voice attributes for accounting. It is valid only for RADIUS IETF attribute 26 VSA, not overloaded RADIUS IETF attribute 44, Acct-Session-Id.
router(config)# aaa session-id [common | unique]
specifies whether the same session ID is used for each AAA accounting service type within a call or whether a different session ID is assigned to each accounting service type. The default value is common.
The following configuration examples highlight the minimal configuration options that are necessary to carry out accounting in a voice environment.
router(config)# aaa new-model router(config)# aaa accounting connection MyMethod start-stop group radius router(config)# aaa session-id common router(config)# gw-accounting aaa router(config-gw-accounting-aaa)# method MyMethod router(config-gw-accounting-aaa)# acct-template callhistory-detail router(config)# radius-server host 172.18.192.154 auth-port 1645 acct-port 1646 router(config)# radius-server retransmit 1 router(config)# radius-server key lab
A typical example of the overloaded Acct-Session-Id is
session id/call leg setup time/gateway id/connection id/call origin/call type/connect time/disconnect time/disconnect cause/remote IP address
For example:
Acct-Session-Id = "2006/Bellem.vsig.cisco.com/293BDA58 CD2011D9 80A1CA93 1717A7D4/answer/VoIP/15:23:42.236 CEST Thu May 25 2006/15:23:48.906 CEST Thu May 25 2006/10/10.48.84.18"
The disconnect cause value of 10 in hexadecimal means normal call clearing.
router(config)# aaa new-model router(config)# aaa accounting connection MyMethod start-stop group radius router(config)# aaa session-id common router(config)# gw-accounting aaa router(config-gw-accounting-aaa)# method MyMethod router(config-gw-accounting-aaa)# acct-template callhistory-detail router(config)# radius-server host 172.18.192.154 auth-port 1645 acct-port 1646 router(config)# radius-server retransmit 1 router(config)# radius-server key lab router(config)# radius-server vsa send accounting
The report RADIUS packet looks like this:
Thu May 25 17:47:31 2006
Acct-Session-Id = "000002B8"
Calling-Station-Id = "90003"
Called-Station-Id = "3714"
h323-setup-time = " 17:49:11.626 CEST
Thu May 25 2006"
h323-gw-id = " Bellem.vsig.cisco.com"
h323-conf-id = " 0A41D482 CAD911D9 803900D0 BA187BD0"
h323-call-origin = " answer"
h323-call-type = " Telephony"
Cisco-AVPair = " 0A41D482 CAD911D9 803900D0 BA187BD0"
Cisco-AVPair = "subscriber=RegularLine"
Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:3714"
Cisco-AVPair = "calling-party-category=9"
Cisco-AVPair = "transmission-medium-req=0"
h323-connect-time = " 17:49:12.342
CEST Thu May 25 2006"
Acct-Input-Octets = "84720"
Acct-Output-Octets = "84800"
Acct-Input-Packets = "353"
Acct-Output-Packets = "530"
Acct-Session-Time = "11"
h323-disconnect-time = " 17:49:23.198 CEST Thu May 25 2006"
h323-disconnect-cause = " 10"
Cisco-AVPair = "h323-ivr-out=Tariff:Unknown"
Cisco-AVPair = "release-source=1"
h323-voice-quality = " 0"
Cisco-AVPair = "in-trunkgroup-label=2"
Cisco-AVPair = "gw-rxd-cgn=ton:0,npi:0,pi:0,si:0,#:90003"
Cisco-AVPair = "charged-units=0"
Cisco-AVPair = "disconnect-text=normal call clearing
(16)"
Cisco-AVPair = "peer-address=90003"
Cisco-AVPair = "info-type=speech"
Cisco-AVPair = "peer-id=9000"
Cisco-AVPair = "peer-if-index=148"
Cisco-AVPair = "logical-if-index=12"
Cisco-AVPair = "acom-level=0"
Cisco-AVPair = "coder-type-rate=g711alaw"
Cisco-AVPair = "noise-level=0"
Cisco-AVPair = "voice-tx-duration=5840 ms"
Cisco-AVPair = "tx-duration=5840 ms"
User-Name = "90003"
Acct-Status-Type = "Stop"
NAS-Port-Type = "Async"
NAS-Port = "0"
NAS-Port-Id = "ISDN 0:D:1"
Service-Type = "Login-User"
NAS-IP-Address = "10.48.88.121"
Acct-Delay-Time = "0"
Client-IP-Address = "10.48.88.121"
Acct-Unique-Session-Id = "495e4d5f519cdb44"
Timestamp = "1116866851"
Enabling the following extra command would report some extra information in the RADIUS attribute 26 VSA:
router(config)# gw-accounting aaa router(config-gw-accounting-aaa)# acct-template callhistory-detail
In an H.323 voice-signaling environment, the gatekeeper's role is to translate the phone numbers into IP addresses. This tells the H.323 endpoints where to send the H.225 packets and establishes a VoIP connection. In a SIP voice-signaling environment, the SIP proxy server has a similar role. However, it does not translate telephone numbers. Instead, it localizes the destination IP address or the next hop to the destination based on the To: header of the incoming INVITE message.
When the SIP proxy server is configured for record-route (as defined in RFC 3261, it instructs the endpoints to send all SIP signaling through the proxy. Therefore, the SIP proxy server sends the call stop record.
Cisco IP phones running SIP send the call accounting information (packets, bytes, and call duration) in the SIP BYE message. Therefore, the Cisco SIP proxy server adds the SIP phone accounting information to the stop record. The following example shows such a stop record example, where sip-hdr=RTP-RxStat and sip-hdr=RTP-TxStat are of special interest for accounting:
NAS-IP-Address = "10.48.80.149"
NAS-Port-Type = "Virtual"
User-Name = ""
Service-Type = "Login-User"
Acct-Status-Type = "Stop"
Acct-Session-Id = "CA942F10-D68C11D9-811FE469-92178729@10.48.88.121"
Called-Station-Id = "<sip:3714@10.48.80.149>;tag=003094c263c1120d2c180756-
5bc2f0d0"
Calling-Station-Id = "<sip:10.48.80.149>;tag=3E10453C-573"
h323-disconnect-time = "13:06:22.149 GMT
Tue Jun 08 2006"
h323-call-origin = " originate"
h323-call-type = " VoIP"
Cisco-AVPair = "sip-status-code=200"
Cisco-AVPair = "session-protocol=sip"
Cisco-AVPair = "call-id=CA942F10-D68C11D9-811FE469-92178729@10.48.88.121"
Cisco-AVPair = "method=BYE"
Cisco-AVPair = "prev-hop-via=SIP/2.0/UDP
10.48.88.121:5060;received=10.48.88.121;branch=z9hG4bK25E2E7"
Cisco-AVPair = "prev-hop-ip=10.48.88.121:5060"
Cisco-AVPair = "incoming-req-uri=sip:3714@10.48.80.149:5060;maddr=10.48.80.149"
Cisco-AVPair = "outgoing-req-uri=sip:3714@10.48.79.173:5060"
Cisco-AVPair = "next-hop-ip=10.48.79.173:5060"
Cisco-AVPair = "sip-hdr=From: <sip:10.48.80.149>;tag=3E10453C-573"
Cisco-AVPair = "sip-hdr=RTP-RxStat:
Dur=23,Pkt=0,Oct=0,LatePkt=0,LostPkt=0,AvgJit=0"
Cisco-AVPair = "sip-hdr=RTP-TxStat: Dur=23,Pkt=1148,Oct=183680"
Client-IP-Address = "10.48.80.149"
Acct-Unique-Session-Id = "9369859f1124cfa2"
Timestamp = "1118153527"
Sending RADIUS records from the SIP proxy server offers the advantage that the records are generated from a single place. For Cisco IP phones running SIP, this mechanism offers a nice alternative to exporting from all voice gateways that require the call legs correlation.
|
|