D ISSERTATION  O RGANIZATION

Based on the mobile/ wireless network model described in this chapter, we investigate

the VoIP performance in the mobile/wireless network environment. In Chapter 2, we study the authentication delay for real-time applications such as VoIP. Before VoIP call setup, the MS (i.e., a call party) is required to attach to the mobile network and be authenticated. In our study, the authentication key in UMTS can be reused in the IEEE 802.1X authentication mechanism in WLAN environment to achieve telecom grade security. In this WLAN-3G integrated security approach, we conduct a modeling study to tune the IEEE 802.1X parameters to yield better authentication delay performance.

In Chapter 3, we investigate the VoIP packet delivery efficiency in the wireless environment (i.e., WLAN network). In 3GPP specifications, the authenticated WLAN MS is allowed to access the 3G network through the WAG/PDG. However, to ensure telecom grade security, the VoIP traffic between the MS and the WAG/PDG must be protected with IPsec.

We analyze the performance of IPsec-based VoIP service in a IEEE 802.11b WLAN environment. The IPsec overheads in terms of throughput, packet loss rate, latency, and jitter are investigated.

In Chapter 4, we present the VoIP performance in the vehicle environment. We conduct trials in the real WiMAX network which supports high-speed mobile broadband services and investigate the WiMAX-based VoIP of a Mobile Taiwan (M-Taiwan) funded program conducted during 2007-08 in the Taipei area. For the worst-case-scenario, the tests were conducted under a stringent condition of both communicating devices, wirelessly connected to the same WiMAX base station under a heavy background traffic and interference, were experiencing simultaneous handovers during the communication. The results show excellent performance for the VoIP applications when both Customer Premise Equipments (CPEs) are stationary. An acceptable VoIP performance is observed when the CPEs move at the speeds up to 50 Km/h.

Finally, we conclude this dissertation in Chapter 5 by discussing our contributions and future work.

Chapter 2

Effects of the EAPOL Timers in IEEE 802.1X Authentication

This chapter studies IEEE 802.1X authentication for WLAN and cellular integration. In the IEEE 802.1X standard, several timeout timers are defined for message exchanges in the EAPOL protocol, where the same fixed value is suggested for these timeout timers. We observe that the delays for the EAPOL message exchanges may significantly vary. A modeling study is performed to tune the values of individual timers to yield better performance than that for the identical timeout period setting. Our study provides guidelines to select appropriate timeout values for IEEE 802.1X operation.

2.1 Introduction   

The IEEE 802.1X standard specifies authentication and authorization for IEEE 802 LAN [7], which has also been widely adopted for mobile devices to access WLAN. Furthermore, if WLAN is integrated with cellular network (such as GSM or UMTS [8]), the SIM module (in the mobile device) and the Authentication Center (AuC) are utilized together with IEEE 802.1X for authentication. An example of WLAN and cellular integration (in terms of authentication) is illustrated in Figure 2.1.

In this figure, the HLR is a mobility database that stores and manages all mobile subscriptions of a specific operator. The AuC provides security data management for mobile subscribers.

The AuC is typically collocated with the HLR. The AP provides radio access to a mobile device. Before a mobile device is authenticated, the AP only allows this mobile device to send

the IEEE 802.1X authentication messages. When the Remote Authentication Dial In User Service (RADIUS) server receives an authentication request from the mobile device, it retrieves the authentication information of the mobile device from the HLR/AuC. After the HLR/AuC returns the authentication information, the RADIUS server authenticates the mobile device following the standard GSM/UMTS authentication procedure [9].

Figure 2.1: A WLAN and Cellular Integration Environment

Figure 2.2 illustrates the protocol stack for the WLAN and cellular integration system. In this figure, the mobile device to be authenticated is called a supplicant. The server (typically a RADIUS server) performing authentication is called the authentication server. The authenticator (e.g., a wireless access point) facilitates authentication between the IEEE 802.1X supplicant and the authentication server.

The integrated system utilizes the Extensible Authentication Protocol (EAP) to support multiple authentication mechanisms based on the challenge-response paradigm [10]. The IEEE 802.1X supplicant encapsulates the EAP packets in EAP over LAN (EAPOL) frames before they are transmitted to the authenticator. Upon receipt of an EAPOL frame, the authenticator decapsulates the EAP packet from the EAPOL frame. Then the EAP packet is sent to the authentication server using the RADIUS protocol [11]. Implemented on top of UDP, RADIUS provides mechanisms for per-packet authenticity and integrity verification

between the authenticator and the authentication server.

Figure 2.2: The Protocol Stack for WLAN and Cellular Integration

IEEE 802.1X authentication for the WLAN and cellular integration network has been investigated in [12], [13] and [14]. These studies focused on the design of the network integration architectures, and proposed IEEE 802.1X authentication procedures for the integration network. In [15], we proposed an integration solution for Third Generation (3G) and WALN services, called the WLAN-based GPRS Support Node (WGSN). WGSN re-uses 3G mechanisms for WLAN user authentication and network access without introducing new procedure and without modifying the existing 3G network components. In WGSN, the mobile device must obtain an IP address before it is authenticated by the HLR/AuC. This chapter describes IEEE 802.1X authentication that enhances the WGSN security by allowing a mobile device to be authenticated before it is assigned an IP address.

In our solution, the WLAN and cellular integration network in Figure 2.1 employs EAP-SIM authentication, which is an EAP-based authentication protocol utilizing the GSM Subscriber Identity Module (SIM) [16]. In GSM, a secret key Ki is stored in the HLR/AuC as well as in the SIM. The authentication server communicates with the HLR/AuC to obtain the GSM authentication information through the Mobile Application Part (MAP) implemented on top of the Signaling System Number 7 (SS7) protocol [8]. In the EAP-SIM authentication, the MAP is responsible for retrieving the GSM authentication information in the HLR/AuC.

In the implementation of IEEE 802.1X authentication for WGSN, we observe that the elapsed times for authentication message pairs exchanged between the mobile device and the network are different. In IEEE 802.1X specification, the message pairs are associated with fixed timeout timers. We analyze the timeout timers used in IEEE 802.1X authentication and improve the performance of IEEE 802.1X authentication by selecting appropriate timer values.

2.2 SIM­based IEEE 802.1X Authentication   

This section describes the SIM-based IEEE 802.1X authentication procedure. The authentication message flow is illustrated in Figure 2.3, which consists of the following steps:

Stap 1. The mobile device (the supplicant) sends the EAPOL‐Start packet to the AP to initiate the IEEE 802.1X authentication.

Stap 2. The AP requests the identity of the mobile device through the EAP‐Request message with type Identity. When the AP receives the EAP‐Response/Identity message from the mobile device, it encapsulates this message in the Access‐Request packet. Then the packet is sent to the RADIUS server.

Stap 3. Upon receipt of the Access‐Request packet, the RADIUS server conducts the EAP-SIM authentication with the mobile device (the supplicant). Specifically, the RADIUS server generates an Access‐Challenge packet that encapsulates the EAP‐Request/SIM/Start in the EAP-Message attribute and sends it to the AP. This message requests the mobile device to initiate the EAP-SIM authentication. The AP decapsulates the EAP‐Request from the Access‐Challenge packet, and delivers it to the mobile device by an EAPOL packet.

Figure 2.3: SIM-based IEEE 802.1X Authentication Message Flow

Stap 4. The mobile device responds the RADIUS server with the EAP‐Response/SIM/Start message containing a random nonce AT_NONCE_MT. The random nonce will be used to generate the encryption key for data transmission between the mobile device and

the RADIUS server after the IEEE 802.1X authentication.

Stap 5. To obtain the authentication information of the mobile device, the RADIUS server sends the SS7 MAP_Send_Authentication_Info_Request message (with the argument IMSI) to the HLR/AuC.

The HLR returns the authentication vector (RAND, SRES, Kc) through the SS7 MAP_Send_Authentication_Info_Response message, where RAND is a random number generated by the HLR/AuC. By exercising the GSM authentication algorithm A3, both the SIM module and the HLR/AuC use the RAND and the secret key Ki to produce a signed result SRES (see Step 7). The RADIUS server will authenticate the mobile device by comparing the signed result SRES* generated by the SIM module with the SRES generated by the HLR/AuC (see Step 8). If they are equal, the mobile device is successfully authenticated and an encryption key Kc* is produced by the GSM encryption/decryption key generation algorithm A8 (using Ki and RAND as inputs) [8].

Stap 6. The RADIUS server sends the EAP‐Request/SIM/Challenge (with the parameter RAND, which is encapsulated as AT_RAND) to the mobile device. To ensure the integrity of the challenge message, the message contains a Message Authentication Code (MAC) AT_MAC. Detailed usage of MAC can be found in [16], and will not be elaborated here.

Stap 7. After verifying AT_MAC received from the RADIUS server, the mobile device passes the random number RAND to the SIM module to perform GSM authentication. The SIM module computes its signed result SRES* and the encryption key Kc* based on the received RAND and the authentication key Ki stored in the SIM card. Then the mobile device sends SRES* (encapsulated in AT_MAC) to the RADIUS server through

the EAP‐Response/SIM/Challenge message.

Stap 8. The RADIUS server verifies AT_MAC and compares SRES* calculated by the mobile device with the SRES received from the HLR/AuC. If the values are identical, the RADIUS server notifies the AP that authentication is successful through the EAP‐Success message (encapsulated in the RADIUS Access‐Accept packet). The AP passes the EAP‐Success message to the mobile device. At this point, the mobile device is allowed to access the network through the AP. If the signed results are not the same, the RADIUS server notifies the AP that the authentication fails through the EAP‐Failure message (encapsulated in the RADIUS Access‐Reject packet).

2.3 EAPOL Timers 

In the IEEE 802.1X supplicant (mobile device), three EAPOL timers are defined:

1. startWhen (associated with message pair ●a in Figure 2.3): When the IEEE 802.1X supplicant initiates the authentication, it sends EAPOL-Start to the authenticator and starts the startWhen timer. If the supplicant has not received any response from the authenticator after this timer expires, it resends EAPOL-Start. The supplicant gives up when it sends EAPOL-Start for n1 times. In the IEEE 802.1X specification [7], the default n1 value is 3.

The default value of the startWhen timer is 30 seconds.

2. authWhile (associated with message pairs ●b, ●c, and ●d in Figure 2.3): Every time the supplicant sends an authentication message (Steps 2.2, 4.1, and 7.1 in Figure 2.3), it starts the authWhile timer. If the supplicant does not receive any response from the authenticator after this timer has expired, the supplicant sends an EAPOL‐Start message to re-start the authentication procedure. The supplicant gives up after it has consecutively sent

EAPOL‐Start for n2 times. The default n2 value is 3. The default value of the authWhile timer is 30 seconds.

3. heldWhile (associated with Step 8.2 message in Figure 2.3 if the client fails the authentication): If the IEEE 802.1X authentication fails, the supplicant has to wait for a period heldWhile before it re-starts the authentication procedure. The default value of the heldWhile timer is 60 seconds.

Selection of the EAPOL timer values is not trivial. If the timer value is too large, it will take long time before the mobile device detects the failure of the network (e.g., RADIUS server failure). If the timer value is too small, the timer may expire before the mobile device receives the response message. In this case, the mobile device needs to re-start the authentication process due to false failure detection.

Table 2.1 shows the expected Round-Trip Times (RTTs) of message exchanges that measured from the WGSN implemented in National Chiao Tung University. These measurements do not experience waiting delays due to queuing at the network nodes (i.e., AP, RADIUS server and HLR/AuC).

Table 2.1: Expected Round-Trip Times for EAP-SIM Authentication Messages (Without Queuing Delays)

Events occurring at the mobile device Associated timer RTT (sec.) (no queueing)

●a in Figure 2.3 startWhen 0.005

●b in Figure 2.3 authWhile 0.013

●c in Figure 2.3 authWhile 1.087

●d in Figure 2.3 authWhile 0.013

In our measurement, the mobile device and the AP are located in one subnet. The RADIUS server and the HLR are located in another subnet. The data rate of the fixed network is

100Mbps. It is observed that the RTT of a message exchange between the mobile device and the RADIUS server are much shorter than that of a message exchange between the mobile device and the HLR/AuC. This significant RTT discrepancy is due to the fact that accessing the HLR/AuC is much more time-consuming than accessing the RADIUS server. This phenomenon is especially true when the HLR/AuC is fully loaded by cellular user accesses and when the RADIUS server and the HLR/AuC are located at different cities or different countries. To reduce the false failure detection probability without non-necessary timer timeout delay, the values of the startWhen timer and authWhile timers should not be identical for all message exchanges in the IEEE 802.1X authentication. For example, the authWhile timer for ●c in Table 2.1 should be different from that for ●b and ●d.

2.4 Performance Modeling   

We propose an analytic model to investigate the false failure detection probability p_f of the IEEE 802.1X authentication procedure and the expected elapsed (response) time E[τ] for executing the IEEE 802.1X authentication procedure. Input parameters and output measures used in the model are listed in Table 2.2.

In Table 2.2, t_X is the RTT of the message exchange without waiting delay (i.e., the queueing at a network node) where X = s, a1, a2, or a3. This RTT is called “service time” in the queueing model. For our measurement in Table 2.1, E[ts] =0.005 seconds, E[ta1] = 0.013 seconds, E[ta2] = 1.087 seconds, and E[ta3] = 0.013 seconds. The response time τ_X of the message exchange is the RTT of the message exchange including the queuing delay. Since we cannot conduct large-scale service trial in our IEEE 802.1X prototype, τ_X are derived from the service times using the M/G/1 queuing model. Let EAPOL message arrivals to the AP be a Poisson stream with rate λ. The service time t_X of the message exchange has an arbitrary

distribution with the distribution function B_X(．), the density function b_X(．), and the Laplace Transform B_X*(．). The response time of the message exchange is represented by the random variable τ_X, which has the distribution function F_X(．), the density function f_X(．) and the Laplace Transform F_X*(．).

Table 2.2: Input Parameters and Output Measures Input Parameters

p_f the false failure detection probability of the IEEE 802.1X authentication procedure; p_f = Pr[the mobile device has consecutively sent the EAPOL-Start frame for three times]

E[τ ] the expected response time of the IEEE 802.1X authentication procedure

By applying the Pollaczek-Khintchine transform equation for the sojourn time, we can express F_X*(．) as [18]:

Let T_X be the timeout period associated with the timer for the message pair X and p_X be the timeout probability of the message exchange.

p_X = Pr[ τ_{X ≥ TX} ] = ⌠∞

⌡T_X f_X ( t ) d t (2.3)

The expected response time E[τ_X] of the message exchange can be obtained by differentiating the Laplace Transform F_X*(．).

E[τ_X] = p_X T_X + (1 – p_X ) ⌠T^X

⌡0 t f_X ( t ) d t (2.4)

The probability transition diagram of the mobile device is illustrated in Figure 2.4. In IEEE 802.1X, the AP can also control the number of retransmissions for EAPOL‐Start (○¹ in Figure 2.3) sent from the mobile device to the AP. To simplify our discussion, we assume that the number of retransmissions is sufficiently large, so that the state diagram in Figure 2.4 is not affected.

Figure 2.4: The Probability Transition Diagram of the IEEE 802.1X Authentication Message Exchange

During IEEE 802.1X authentication, the mobile device restarts the procedure (i.e., come back

to state ○¹ again) whenever the authWhile timer (associated with message exchanges ●b, ●c, and ●d) expires. The authentication exits and is considered failed if the startWhen timer (associated with message exchange ●a) has consecutively expired for three times (i.e., the finite state machine (FSM) moves from state ○¹ , ○⁶ , ○⁷ , to state ○⁸ ).

Let x be the probability that the FSM starts from state ○¹ and eventually comes back to state

○¹ (i.e., state ○¹ may be revisited zero or more times). All possible scenarios for the probability transitions in Figure 2.4 are described as follows:

Scenario I: From state ○¹ (i.e., state ○¹ may have been visited zero or more times), the startWhen timer consecutively expires for three times (i.e., the last transitions are

○¹ Æ○⁶ Æ○⁷ Æ○⁸ ). The probability for Scenario I is xps³.

Scenario II: From state ○¹ , the startWhen timer consecutively expires for two times, and the procedure successes at the third try (i.e., the last transitions are ○¹ Æ○⁶ Æ○⁷ Æ○² Æ○³ Æ○⁴ Æ○⁵ ). The probability for Scenario II is x ps² ( 1 – ps )( 1 – pa1 )( 1 – pa2 )( 1 – pa3 ).

Scenario III: From state ○¹ , the startWhen timer expires once, and the procedure successes at the second try (i.e., the last transitions are ○¹ Æ○⁶ Æ○² Æ○³ Æ○⁴ Æ○⁵ ). The probability for Scenario III is xps( 1– ps )( 1 – pa1 )( 1 – pa2 )( 1 – pa3 ).

Scenario IV: From state ○¹, the procedure successes without incurring any timer expiration (i.e., the last transitions are ○¹ Æ○² Æ○³ Æ○⁴ Æ○⁵ ). The probability for Scenario IV is x ( 1 – ps )( 1 – pa1 )( 1 – pa2 )( 1 – pa3 ).

It is apparent that the false failure probability p_f is the probability that Scenario I occurs. The success probability (1 – p) is the probability that either Scenarios II, III, or IV occur. That is,

p_f = Pr[Scenario I occurs] = xps³ (2.5)

and

1 – p_f = Pr[Scenarios II, III, or IV occur]

= x( ps² + ps¹ + 1)( 1 – ps )( 1 – pa1 )( 1 – pa2 )( 1 – pa3 )

= x( 1 – ps³)( 1 – pa1 )( 1 – pa2 )( 1 – pa3) (2.6)

From (2.5) and (2.6), we have

p_f + (1 – p_f ) = x [ps³ + ( 1 – ps³)( 1 – pa1 )( 1 – pa2 )( 1 – pa3)] (2.7)

By rearranging (2.7), we have

x = 1

ps³ + ( 1 – ps³ ) ( 1 – pa1 ) ( 1 – pa2 ) ( 1 – pa3 ) (2.8)

From (2.8) and (2.5),

p_f = ps³

ps³ + ( 1 – ps³ ) ( 1 – pa1 ) ( 1 – pa2 ) ( 1 – pa3 ) (2.9)

By using (2.3) and (2.9), the value of p_f can be computed from λ, fs, fa1, fa2, and fa3. Table 2.3: The p_X Values: Analysis Versus Simulation

(T_X = 10 × E[t_X], var[t_X ] = E[t_X]²,and X = s, a1, a2, or a3).

(UNIT: 1

E[TX]) 0.2 0.4 0.6 0.8

SIMULATION 0.0003 0.0025 0.0183 0.1353

ANALYTIC 0.0004 0.0027 0.0196 0.1271

ERROR 0.0001 0.0002 0.0013 0.0082

The above analytic model is validated against simulation experiments. The simulation model follows the discrete event approach [19], and the details are omitted. Table 2.3 indicates that the analytic and the simulation results are consistent (the errors are within 1%). Therefore, both the analytic model and the simulation implementation are validated.

2.5 Numerical Examples 

This section uses numerical examples to investigate the impact of timers on the performance of IEEE 802.1X authentication. The input parameters and the output measures are listed in Table 2.2. The expected service times of the EAPOL message exchanges E[ts], E[ta1], E[ta2], and E[ta3] are obtained from the measurements as listed in Table 2.1. Other parameters include the EAPOL message arrival rate λ, and the variances of the EAPOL service times (i.e., var[t_X], where X = s, a1, a2, or a3). We have the following observations.

limps→1 p_f = 1 and lim

ps→0 p_f = 0.

Observation 2. The probabilities pa1, pa2, and pa3 have indirect impact on p_f .

Increasing pa1, pa2, and pa3 will increase the probability that the FSM moves toward state ○¹ (i.e., loops among states ○¹ , ○² , ○³ , and ○⁴) and thus decrease the probability that the FSM enters state ○⁵ . However, the effect in Observation 2 is not as significant as that in Observation 1.

Based on simulation experiments, Table 2.4 shows how timeout period T_X (X = s, a1, a2, or a3) affects p_f when the variance of t_X is large (i.e., var[t_X] = 100 × E[t_X]²). These results in Table 2.4 are consistent with Observations 1 and 2. That is, T_S has more significant effect on p_f than Ta1, Ta2, and Ta3 do, especially when the EAPOL message arrival rate λ is high. Specifically, when λ = 0.975 × E[ta2]^–1 and if Ta1, Ta2, and Ta3 are fixed to 10 seconds, changing the value of T_S from 5 seconds to 15 seconds will reduce p_f from 95.69% to 50.00% (about 50%

improvement). Conversely, changing any of the values for Ta1, Ta2, and Ta3 from 5 to 15 seconds only insignificantly affects p_f (less than 13% improvement).

When var[t_X] is small (e.g., var[t_X] is less than E[t_X]²), the service time t_X does not significantly vary, and the IEEE 802.1X authentication message exchange is more likely to complete if the value for T_X is set larger than the expected service time E[t_X] of the corresponding EAPOL message pair exchange. Therefore, we have the following observation.

Observation 3. When var[t_X] is small and T_X is sufficiently large, changing T_X only insignificantly affects p_f .

Table 2.5 shows how T_X and var[t_X] affect E[τ] when the EAPOL message arrival rate λ is set

to 0.5 × E[ta2]^–1. From this table, we have the following observations.

Observation 4. When var[t_X] is small (i.e., var[t_X] = E[t_X]²), E[τ] is insignificantly affected by the change of T_X if T_X is larger than the expected response time of the EAPOL message

Observation 4. When var[t_X] is small (i.e., var[t_X] = E[t_X]²), E[τ] is insignificantly affected by the change of T_X if T_X is larger than the expected response time of the EAPOL message