. 53
( 132 .)


Figure 5.63 CHAP

shared secret and challenge and perform a hash function over the result. The hash value
is sent back in the response. Finally, the success or failure packets are used to indicate the
result of the authentication. The name on the challenge and response packets indicates the
identity of the system transmitting the packet. For a client wanting authentication from a
network access server, the name will indicate the client™s username. The message in the
success and failure packets can be displayed to the user when their request is accepted or

5.11.3 Network control protocol (NCP) for IP
To enable IP transport over the PPP connection the NCP protocol for IP must be used.
The NCP protocol for IP is called PPP Internet Protocol control protocol or IPCP (see
RFC 1332).
IPCP allows the con¬guration of IP options such as the IP host address and header
compression. The format of the packet is shown in Figure 5.64.
Note that this is the same format as the LCP packet except the protocol code has been
changed. The codes have the same meaning as LCP with only code numbers 1“7 being
supported; other values are to be ignored. It is also similar in operation in that options
are requested and the responder either accepts or rejects them. There are two options
supported by IPCP.

IP address
A peer can request the responder to give it an IP address by sending an IP address option
with the IP address set to all zeroes

flag address control protocol code identifier length data
01111110 11111111 3 8021 8-bits 8-bits 16-bits variable FCS

Figure 5.64 IPCP packet format

Header compression
A peer can request the responder to provide Van Jacobson TCP/IP header compression
(RFC 1144).
A client requesting an IP connection will send a con¬gure-request. The network access
server will respond with either a con¬gure-ack, con¬gure-nak or con¬gure-reject.

5.11.4 IP packet encapsulation

The encapsulation options for IP within PPP are shown in Figure 5.65. At the top is a
standard IP datagram with a protocol ¬eld of 0021. In the middle is a TCP/IP packet
with a Van Jacobson compressed header and at the bottom a Van Jacobson uncompressed
TCP/IP header. In the uncompressed case the IP protocol ¬eld of the IP header indicates
the slot to be updated.

5.11.5 PPP in 3G

PPP has been introduced as an access protocol in UMTS, allowing the transparent trans-
portation of protocols such as AppleTalk and IPX. Figure 5.66, shows how PPP is used
in this context.

flag address control protocol IP datagram

01111110 11111111 3 0021 IP header payload FCS

01111110 11111111 3 002d payload FCS
TCP/IP header

01111110 11111111 3 002f payload FCS
TCP/IP header

Figure 5.65 PPP IP encapsulation

protocol protocol PPP-NCP

Lower layers L1/L2

Figure 5.66 PPP protocol tunnelling



Link Link
layer layer

Air Air Physical Physical Physical Physical
interface interface layer layer layer layer
Radio Network PDSN End host

Figure 5.67 PPP for CDMA2000

PPP and IPCP are also used to provide IP access for CDMA2000 systems. The con-
¬guration is shown in Figure 5.67. PPP is used to provide transport between the mobile
station and the interworking function. Since PPP is being used any network protocol (e.g.
AppleTalk) can be transported as long as it is supported by both the interworking function
(IWF) and the mobile station (MS).


The remote authentication dial-in user service (RADIUS), de¬ned by RFC 2865, is a
protocol developed to carry out authorization, authentication and accounting functions
(AAA). The protocol allows a network access server to access a centrally located shared
authentication and accounting server. Figure 5.68 shows an example RADIUS con¬g-
uration for GPRS/UMTS. Here the GGSN is acting as a network access server and is
therefore a RADIUS client, communicating with the RADIUS server on behalf of the
mobile user. Managing a central database of authentication information in this way is the
simplest and most secure method of allowing authenticated access for a dispersed set of
access lines. RADIUS is used in CDMA2000 to provide connections between the packet
data serving node (PDSN) and the central authentication and accounting servers.

client server

PPP authentication RADIUS Authentication

Figure 5.68 RADIUS con¬guration

Each network access server acts as a RADIUS client, requesting services from the
central authentication (or accounting) server which acts as the RADIUS server. RADIUS is
not used to transport authentication data end-to-end, the actual authentication mechanism
between the network access client and the access server will be some other protocol such
as PPP authentication using CHAP.

5.12.1 RADIUS functions
RADIUS provides the following functions:

• Authentication: determination of identity of a user via the use of a shared secret.
• Authorization: allowing or rejecting user access to the network based on their pro¬le
and the current security policy.
• Host con¬guration: providing con¬guration data for a user connecting to the NAS, for
example providing an IP address for the host to use.
• Accounting: controlling usage statistics for accounting purposes (RFC 2866).

The user connecting to the network access server (NAS) can request a range of services
via the RADIUS architecture, for example a PPP connection or login connection to a
particular host using telnet.

5.12.2 RADIUS authentication and con¬guration
When the NAS has a client requesting access to the network, it constructs an access-
request message. This message will contain the username and password and also infor-
mation about what type of service is being requested. The username will typically be in
the format of a network access identi¬er. This looks very much like an email address, i.e.
user@host. An example would be bobsmith@orbitage.com. The password in the request
is obscured by only sending a hash dependant of the password instead of the password
itself. The NAS (RADIUS client) then sends the access-request to the authentication
server (RADIUS server).
The RADIUS server will look up the user™s name within its database and retrieve the
user™s password. It will then use the password to check the authenticity of the request. If
the identity of the user is con¬rmed and the server determines they should have access
(authorization check) an access-accept message is sent back to the RADIUS client. If any
of the conditions for access are not met, an access-reject message is sent back. If the
username is not present in the database the access request will be silently discarded.
It is also possible for the server to generate an access-challenge message in response
to the original request. In this case the radius client (NAS) is expected to re-submit
the original access request using the shared secret to generate the hash as well as state
information found in the access-challenge message. This technique is more secure than
the standard access procedure.

The con¬guration data for the RADIUS client is contained with the access-accept
message. Possible con¬guration values are:

• IP address to be allocated to the host;
• compression technique for link;
• remote host address for login.

5.12.3 RADIUS accounting
RADIUS accounting is covered by RFC 2866. The NAS acts as a client to the RADIUS
accounting server and sends information to it regarding the usage statistics of clients.
Two types of message are supported, accounting-request and accounting-response. The
accounting-request is sent from client to server; the server replies with the accounting
response. Each type of accounting request is distinguished by the acct-status-type attribute.
Possible values for this ¬eld are;:

• start: start accounting for a user session;
• stop: stop accounting for a user session;
• on: turns on accounting (for example on NAS start up);
• off: turns off accounting for this user (on scheduled NAS shutdown).

When a client connects to the NAS, a start accounting-request message is sent to the
accounting server. This contains a unique session ID attribute, username and an identi¬er
(or IP address) for the NAS. This information allows the accounting server to build a
unique record for each session.
At the end of the session a stop accounting-request is sent. This contains attributes
giving the user™s usage statistics for example the number of bytes sent/received. It will
also contain the same session information as found in the start accounting-request, so the
server can update the correct charging record.

The AAA working group of the IETF focuses on authentication, authorization and account-
ing functions for network access. The group identi¬ed the following requirements for
AAA. 3GPP recommends the use of DIAMETER to provide accounting functions in the
IP multimedia subsystem (IMS; see Chapter 9).

• Support for IPv6
• Backwards compatibility with RADIUS
• Explicit proxy support
• Lightweight security model.

A number of RFCs have been produced by the AAA working group. The core func-
tionality is provided by a protocol called DIAMETER (www.ietf.org/internet-drafts/draft-
ietf-aaa-diameter-17.txt). This is a base protocol which is extendable to produce a range
of AAA applications. Table 5.19 shows some of the AAA documents released to date.
The DIAMETER base protocol does not provide full AAA functionality on its own
and is used in conjunction with the application protocols. For example, a NAS will be
expected to support the DIAMETER base protocol as well as the DIAMETER network
access application.
The base protocol supports session management and the transfer of attribute value pairs
(AVPs) (between peers, these are explained in the following section). It also provides a
base set of commands to handle simple accounting transactions. DIAMETER supports
enhanced reliability using the dynamic peer discovery. A domain will be con¬gured with
both primary and backup DIAMETER servers.

5.13.1 Attribute value pairs (AVPs)
DIAMETER and DIAMETER application protocols move data between peers using AVPs.
Each AVP consists of a data structure containing an attribute descriptor and its value.
Figure 5.69 shows the basic AVP format.
The AVP code in conjunction with the vendor ID identi¬es each attribute uniquely. The
use of the vendor ID is optional and is indicated by the setting of the V bit to 1. This
allows a particular vendor to develop their own speci¬c application by de¬ning their own
set of AVPs. The M or mandatory bit is set for AVPs that must be supported for a given
request. If a peer receives a DIAMETER request containing an AVP with the M bit set


. 53
( 132 .)