Networks
Said Zaghloul
Technical University Carolo-Wilhelmina – Braunschweig, Germany Admela Jukan
Technical University Carolo-Wilhelmina – Braunschweig, Germany
Copyright © 2008, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
AbstrAct
The architecture, and protocols for authentication, authorization, and accounting (AAA) are one of the most important design considerations in third generation (3G)/fourth generation (4G) telecommunica-
tion networks. Many advances have been made to exploit the benefits of the current systems based on
the protocol remote authentication dial in user service (RADIUS)protocol, and the evolution to migrate into the more secure, robust, and scalable protocol Diameter. Diameter is the protocol of choice for the IP multimedia subsystem (IMS) architecture, the core technology for the next generation networks. It is envisioned that Diameter will be widely used in various wired and wireless systems to facilitate robust and seamless AAA. In this chapter, we provide an overview of the major AAA protocols RADIUS and
Diameter, and we discuss their roles in practical 1xEV-DO network architectures in the three major
network tiers: access, distribution, and core. We conclude the chapter with a short summary of the cur- rent and future trends related to the Diameter-based AAA systems.
IntroductIon
Many 3G cellular providers consider the archi- tecture for the authentication, authorization, and accounting (AAA) system as one of the most important functional blocks for the success of service delivery. Typically, users are authenti- cated when requesting a service and only after successful authentication they are authorized to use the service. Once the user is granted access to the service, the network generates accounting messages based on the user’s activity. Currently, the remote authentication dial in user service (RADIUS) protocol is the most widely deployed protocol in cellular networks to perform subscriber AAA. Since RADIUS is susceptible to various se- curity threats, a standard developed by the Internet Engineering Task Force (IETF), called Diameter, was proposed to substitute RADIUS in the future. Unlike its predecessor RADIUS, Diameter of- fers reliable and secure communication enabling seamless roaming among operators and support of auditability, capability negotiation, and peer discovery and configuration. Diameter augments its reliable transmission capabilities by defining failover mechanisms and thus embraces two crucial elements for the robust communication of sensitive billing and authentication messages. Since most of the current equipment and radio standards only support RADIUS for authentication, it is evident that cellular network operators will be running both protocols in the near future. Therefore, it can not be sufficiently emphasized that prudent decisions need to be made when designing AAA systems with multiple protocols in mind at the three major tiers: access, distribution, and core.
The purpose of this chapter is to address the specific aspects of the AAA system architecture of these three major tiers. Given the broadness of the scope and the myriad of the existing AAA standards, we sharpen our focus on a reference 3G cellular network architecture which we define and show in Figure 1. As can be seen from Figure 1, a typical AAA system in 3G architectures is characterized by three distinctive architectural elements: (1) radio access network (RAN), (2) distribution network based on mobile IP (MIP),
and (3) a multimedia domain (MMD)1 based
core including both IP multimedia system (IMS) networks and Internet access deployments. The RAN, based on one of the 1x carrier evolution data only (1xEV-DO) standards/revisions for wireless transmission, consists of various base stations (BSs) and radio network controllers (RNCs). The distribution network consists of the MIP elements, that is, the packet data serving node (PDSN) playing the foreign agent’s (FA) role and the home agent (HA). It is worth observing that this architecture has a hierarchical nature, where multiple BTSs are governed by a single RNC and multiple RNCs are covered by a single PDSN region. Finally, at the core, we have the IMS elements, including it standardized elements such as the call session control functions (CSCF) and home subscriber servers (HSS) enabling robust applications and services such as gaming, presence, voice over IP (VoIP), and so forth.
Upon receiving a mobile subscriber call, the RNC authenticates the subscriber’s request by communicating with the access network AAA (AN-AAA) over the RADIUS-based A12 interface. Once authenticated, the RNC contacts the PDSNs through the A10/A11 interface (3rd Generation Partnership Project 2 [3GPP2] A.S0008-B, 2006). Note that since the A12 interface is RADIUS based, a translation agent (TA) needs to be used to translate the RADIUS requests to Diameter for authentication. In Figure 1, we illustrate that the AAA contacts an Oracle-based users’ database to authenticate the incoming calls. We assume that the TA, AAA, and the AN-AAA are collocated in the same physical platform for simplicity. For higher reliability, RNCs usually connect to multiple AAAs (one primary and another secondary AAAs) to allow redundancy to admit users into the system in case of AN-AAA connectivity problems.
Once admitted, the mobile node (MN) starts a point-to-point (PPP) session with the PDSN. Dur- ing the process of PPP establishment, the PDSN advertises itself as a MobileIP FA and challenges the user. The user then replies with a Mobile IP registration request that answers the PDSN’s chal- lenge. The PDSN forwards this information to the AAA. The AAA validates the user’s response
0
based on the MN-AAA shared secret and responds to the PDSN. In case of successful authentication, the PDSN proceeds with the MobileIP registration process with the HA and establishes a MobileIP tunnel to serve the user’s traffic. At this point, the PDSN starts to generate accounting towards the AAA server to reflect the subscriber’s usage. Ac- counting data is reformatted and is communicated to the upstream billing systems for further process- ing. Here, we assume simple secure FTP (SFTP) communication. Note that the PDSN also connects to multiple AAA’s for redundancy purposes. In our illustrative architecture, the PDSN implements the Diameter MobileIP application and thus needs no translation functionality.
In this illustrative reference architecture, RA- DIUS is deployed in the access tier and translation agents were utilized to convert between RADIUS and Diameter, while Diameter applications at the distribution and network tiers were natively supported. Following this example, we organize the chapter as follows. First, we present the AAA concept and quickly survey RADIUS and its cur- rent deployment features. Then, we discuss the evolution from RADIUS to Diameter and shortly review the current Diameter standard. Afterwards, we illustrate a prospective end-to-end application
of Diameter at all the three major network tiers in the wireless network, including access, distribu- tion, and core. Finally, we summarize the chapter and discuss open issues and future work.
bAckground
the rAdIus Protocol
AAA systems received significant attention from network service providers throughout the past decade. The need for a standardized, simple, and scalable protocol that accomplishes the required AAA functionality was the main motivation for the introduction of the (RADIUS) protocol (Ri- gney, 2000; Rigney Willens, Rubens, & Simpson, 2000; RFC2866). In 1998, RADIUS was the only protocol that seemed to satisfy the IETF NASREQ working group’s requirements for authentication and authorization (Rigney, 1998). Due to its wide implementation by many networking equipment vendors, its simplicity and scalability, it became the protocol of choice for many service providers. RADIUS was quickly extended to support various networking protocols such as MobileIP (Perkins, 2002), IP security (IPsec) (Kent & Seo, 2005), and the IEEE 802.1x authentication.
Figure 1. A 1xEV-DO reference network architecture
diameter RNC RNC PDSN (FA) HA Internet Internet PDSN (FA) HA users db Billing System f a ilo ve r l in k Primary link A10/A11 A12 o rac le s q l *n e t 2 s f t P MIP tunnel Acronyms
bts: Base Transceiver Station rnc: Radio Network Controller
An/AAA: Access Network AAA
Pdsn: Packet Data Serving Node MIP: Mobile IP
fA: Foreign Agent HA: Home Agent tA: Diameter Translation Agent IMs: IP Multimedia Subsystem
sftP:Secure File Transfer Protocol
sql:Structured Query Language
1xEv-do radio Access network (rAn)
IMs IMs An/AAA tA A12 (rAdIus) An/AAA tA diameter t1 circuits bts 4 bts 6 bts 5 bts 1 bts 2 bts 3 bts 4 bts 6 bts 5 bts 1 bts 2 bts 3 Multimedia domain (MMd)
In RADIUS, after the user is granted access, the
network access server (NAS) generates accounting messages based on the user’s activity. The NAS is usually the gateway to the IP network. Routers, WiFi access points (APs), PDSNs, and gateway general packet radio service (GPRS) support nodes (GGSN) in GPRS networks, are typical examples of NASs in telecom networks. As shown in Figure 2, a user tries to access the Internet through a dialup modem connection. The PPP protocol is mainly used to establish the communication between the user and the NAS, that is, the router in this example. The NAS attempts to authenticate the user either through the password authentication protocol (PAP) or the challenge handshake authentication protocol (CHAP). Upon obtaining the responses from the client, the NAS generates an Access-Requestand sends it to the RADIUS server in order to validate the user’s responses. Typically, the RADIUS server is connected to an external database that contains the user’s credentials and authorized services. Thus, the RADIUS server returns an Access-Accept message if the user credentials are valid, otherwise it returns an Access-Reject. The Access-Accept message may contain authorization information. For example, an Access-Accept message may contain: filters to grant the user access to internal networks, specific routing instructions to the NAS, quality of service (QoS) settings, and so forth. This authorization set is returned as a group of attribute value pairs (AVP) in the Access-Accept message.2 Once the user is
granted access, the NAS generates accounting messages based on user’s activity (connection time, total bytes used, etc).
The RADIUS message format is shown in Fig- ure 3. It consists of a 20 octet header followed by multiple AVPs. AVPs include standardized types and values. For example, the username is passed to the AAA server using the User-Name attribute. To allow expandability, the AVP type 26 is reserved for vendor-specific AVPs (VSAs). Thus, a vendor requests a Vendor ID from the Internet Assigned Numbers Authority (IANA) to be able to define specific attributes for his equipment. The following are sample vendor ID values: Cisco (9), Nortel (2637), 3GPP (10415), and 3GPP2 (5535). Usually, AAA implementations include dictionary files that define the AVP type and the expected values, for example refer to Braunöder (2003). RADIUS accounting is composed of three primary message types: (1) Accounting-Start, (2) Accounting-Interim, and (3) Accounting-Stop. Accounting messages usually carry the user’s session information. For example, in CDMA2000-based systems accounting messages may contain the user’s assigned IP address; user’s sent and received byte counts; user’s electronic serial number; calling and called station numbers; accounting session ID; BS ID; and so forth, (3GPP2 A.S0008-B, 2006; 3GPP2 X.S0011-005-C, 2006). Note that the electronic serial number and the BS ID attributes are 3GPP2 VSAs augmented to the standard RADIUS AVPs.
Figure 2. A simple service provider’s architecture with AAA functionality
Pstn
Internet Internet
AAA server
AAA server billing systemsbilling systems
A c c o u n tin g A u th e n tic a tio n & A u th o ri z a tio n db users’ database db db users’ database R A D IU S T ra ff ic PPP PPP tcP/IP sql, ldAP s/ftP, sql nAs
RADIUS offers reliability over the intrinsically unreliable user datagram protocol (UDP)3 by requir-
ing a response for each request. If a response is not received within a predefined time period (TO), the request times out. It is then up to the requestor (RADIUS client) to either retry the same server, another RADIUS server, or even drop the request. The timeout value and the maximum number of
allowed retransmissions are configurable param-
eters at the client. It is noteworthy to mention that the failover mechanism was not standardized in RADIUS and often raised interoperability issues due to the inherent differences in the AAA imple- mentations (Calhoun, Loughney, Guttman, Zorn, & Arkko, 2003).
RADIUS follows a client/server model where clients maybe NASs or other RADIUS servers. RADIUS clients and servers share a common secret to secure their communications. This method is weak and is only intended to secure communica- tion within a trusted network.4 Sometimes an AAA
server serves as a RADIUS client/proxy when it is provisioned with a policy instructing it to forward
the request to another RADIUS server. Such poli- cies are occasionally based on the domain in the user’s network access identifier (NAI). Standards (Aboba & Vollbrecht, 1999) refer to this setup as the proxy-chain configuration. For instance, in a roaming scenario the host AAA is usually config- ured to forward AAA requests from the hosting NAS to the home AAA. Note that multiple proxies maybe traversed along the path to the home AAA server as shown in Figure 4.