[PDF] IP telephony: mobility and security JON-OLOV VATN

1 IP telephony: mobility and security JON-OLOV VATN Doctoral Thesis in Teleinformatics Stockholm, Sweden 20052 3 IP tele...

IP telephony: mobility and security

J O N - O LOV VAT N

Doctoral Thesis in Teleinformatics Stockholm, Sweden 2005

IP telephony: mobility and security

Jon-Olov Vatn May 2005 Doctoral thesis

TRITA-IMIT-TSLAB AVH 05:01 ISSN 1651-4114 ISRN KTH/IMIT/TSLAB/AVH-05/01--SE Telecommunication Systems Laboratory Department of Microelectronics and Information Technology (IMIT) KTH, Royal Institute of Technology Stockholm, Sweden

A dissertation submitted to Royal Institute of Technology (KTH) for partial fulfillment of the requirements for the Doctor of Technology degree.

c 2005 Jon-Olov Vatn Telecommunication Systems Laboratory Department of Microelectronics and Information Technology (IMIT) KTH, Royal Institute of Technology Stockholm, Sweden

Abstract With the introduction of IP based telephony services, the Internet has started to challenge the traditional PSTN networks as an infrastructure for providing real-time interactive services. This upcoming paradigm shift is not only driven by the desire to provide cost efficient solutions, but by basing the communication on IP we expect that the end-users will experience a greater set of attractive services over a single connection compared to what is provided by a PSTN today. Looking a little further ahead, mobile communication systems will also become IP based. Companies, universities and private persons have started to extend their local area networks to provide wireless access by attaching wireless access points (APs) to their LAN. Wireless ISPs (WISPs) are putting up wireless LAN (WLAN) APs at public hot spots, thereby providing a complement or even a competitive alternative to the wireless WANs (WWANs) being developed and deployed today. As more and more people start to communicate using WLAN access, they will naturally wish to use this infrastructure for interactive real-time applications, such as mobile telephony. This thesis concerns mobility and security support for IP telephony in public WLAN environments. The security issues addressed relate both to user requirements such as end-to-end confidentiality, and operator requirements such as network access control. Alternatives for how the voice media stream can be protected and the procedure to establish a secure call using SIP are described. Public WLAN architectures enabling service providers to share access network infrastructure are described and evaluated. To enforce access control the use of either IEEE 802.11i or L2TP/IPSec is suggested, since both meet the proposed security requirements, and both are standardized solutions available on modern systems. The case where mobile users perform handovers between APs on the same LAN (layer-2 handover) and across IP subnets (layer-3) is studied. For layer-2 handovers the properties of IEEE 802.11b handover mechanisms and its impact on voice traffic, and the effect of the network access control mechanism on the handover performance are examined. The mechanisms necessary to perform layer-3 handovers and their impact on handover performance are described. The analysis focus on “SIP mobility” and Mobile IPv6, since these mobility management schemes provide optimal routing, thus are well suited for IP telephony.

Sammanfattning I samband med introduktionen av IP-baserade telefonitj¨anster har Internet ¨ ¨ att tillhanborjat utmana de traditionella PSTN-n¨aten som en infrastruktur for dah˚alla interaktiva realtidstj¨anster. Detta stundande paradigmskifte drivs inte ¨ ¨ enbart av en onskan att tillhandah˚alla kostnadseffektiva losningar. Genom att ¨ kommunikation kan vi forv¨ ¨ anta oss att slutanv¨andarna anv¨anda IP som bas for ¨ f˚ar uppleva ett storre utbud av attraktiva tj¨anster a¨ n vad som finns tillg¨angligt i dagens PSTN-n¨at. Om man blickar lite l¨angre fram kommer a¨ ven mobila kom¨ munikationssystem baseras p˚a IP. Foretag, universitet och privatpersoner har ¨ ¨ att forse ¨ redan borjat koppla in WLAN accesspunkter p˚a sina lokala n¨atverk for ¨ access. Tr˚adlosa ¨ Internetleverantorer ¨ anv¨andarna med tr˚adlos (WISP) placerar accesspunkter vid publika “hot spots”, och erbjuder ett kompletterande eller ¨ 3G-n¨at som utvecklas och rullas ut ett konkurrerande alternativ till de tr˚adlosa ¨ idag. N¨ar allt fler anv¨andare borjar kommunicera genom WLAN-access faller ¨ interaktiva det sig naturligt att de a¨ ven vill anv¨anda denna infrastruktur for realtidstj¨anster som mobiltelefoni. ¨ mobilitet och s¨akerhet for ¨ IP-telefoni i Denna avhandling handlar om st¨od for ¨ De s¨akerhetsfr˚agor som behandlas ror ¨ b˚ade anv¨andarpublika WLAN-miljoer. krav som avlyssningss¨akra samtal och operat¨orskrav som accesskontroll. Alter¨ att skydda ett samtal och genomf¨ora sj¨alva uppkopplingen nativa metoder for ¨ publika av ett s¨akert samtal med hj¨alp av SIP presenteras. N¨atarkitekturer for ¨ ¨ for ¨ olika tj¨ansteleverantorer ¨ WLAN som mojligg or att dela accessn¨at beskrivs ¨ att genomfora ¨ accesskontroll foresl˚ ¨ och utv¨arderas. For as att antingen IEEE 802.11i eller L2TP/IPSec anv¨ands, eftersom b˚ada uppfyller de uppst¨allda ¨ s¨akerhetskraven och b˚ada a¨ r standardiserade losningar tillg¨angliga i moderna system. ¨ overl¨ ¨ Fallen n¨ar en mobil anv¨andare genomfor amning (handover) mellan ¨ accesspunkter p˚a samma lokaln¨at (lager-2 overl¨ amning) och mellan IP-subn¨at ¨ ¨ lager-2 overl¨ ¨ ¨ egenska(lager-3 overl¨ amning) studeras. For amning undersoks ¨ perna hos overl¨ amningsmekanismen hos IEEE 802.11b och dess p˚averkan p˚a ¨ taltrafik och effekterna av n¨atens accesskontrollmekanism p˚a overl¨ amnings¨ att genomfora ¨ lager-3 overl¨ ¨ prestanda. Metoder for amning beskrivs liksom ¨ dess p˚averkan p˚a overl¨ amningsprestanda. Analysen fokuserar p˚a “SIP mobi¨ optimala litet” och “Mobil-IPv6” eftersom dessa mobilitetsmetoder m¨ojliggor ¨ IP-telefoni. v¨agval i n¨aten och d¨armed l¨ampar sig v¨al for

Acknowledgments First, I will give my greatest thanks to my family. Thank you, my beloved wife Katarina and my sons Daniel, Niklas and Martin for your support and patience. My son Victor, happily enough you only had to experience the final completion of this work. Thank you, Monica and Jon, for helping me whenever I needed. Many thanks to my main advisor Professor Bj¨orn Pehrson for giving me the opportunity and supporting me in this work. He has created an extraordinary creative environment and he has been a source of inspiration during my studies. A special thanks to my second advisor Professor Gerald Q. Maguire Jr. for always being there for me. I would not have been able to finish this work without you. Thank you Dr Fredrik Orava, Dr Theo Kanter, Dr Peter Sj¨odin, and Dr Lars Ramfelt for additional advising at different stages of my studies. I would like to thank my colleagues Erik Eliasson and Johan Bilien for all work we have done together and all help I have received, and Jiang Wu for interesting discussions and useful feedback. During my time at TSLab I have had the opportunity to meet so many great persons, who have made my time here enjoyable and stimulating. With the hope that persons who I unintentionally have missed will forgive me, I would like to thank the following persons (in approximate order of appearance): Mikael Sundqvist, Markus Hidell, Per Lindgren, Christer Bohm, ¨ Lars Gauffin, Olov Schagerlund, Ulf Bilting, Anders Bostr¨om, Tobias Obrink, Johan Wennlund, Fredrik Lundevall, Michael Liljenstam, Sven Sk¨old, Claes ¨ ¨ Thornberg, Robert Ronngren, Leif Kahlbom, Kristina Edstrom, Sofia Olsson, Lena Wosinska, Ignacio M´as Ivars, Evgueni Ossipov, Henrik Lundqvist, Ian Marsh, H´ector Velayos, Alberto Escudero-Pascual, Iyad Al-Khatib, Eva Jansson, Alexander La-Torre Yurkow, Jonas Will´en, Fredrik Lilieblad, Lena Ramfelt, Americo Muchanga, Sermed Al-Abbasi, Peter L¨ofqvist, Louise Berthilson, Voravit Tanyingyong, Khurram Jahangir, Lennart Helleberg, B. Svante Eriksson, Israel Abad Caballero, Johan Montelius, Lazar Rusu, Tobias Dalhammar, Joachim Orrblad, Chen Jie, Max Zomborszki, and Bj¨orn Knutsson. I must also thank Rita Johnsson, Agneta Herling, Margreth Hellberg, and Gunnar Johansson for helping me with administrative as well as other matters. A special thought goes to Barbro Persson who unfortunately is no longer with us. Finally, great thanks to everyone else at the department that have helped me in various ways. This work has been financially supported in part by the Graduate School of Teleinformatics, Telia AB, and the Royal Institute of Technology, which are gratefully acknowledged. I also want to thank HP for providing the iPAQs used in some of my measurements (Grant for Mobile Technology for Higher Education in 2003 to KTH).

Contents 1

Introduction 1.1 Service architecture . . . . . . . . . . . . . . . . . . . . 1.1.1 Applications and end-systems for packet voice 1.1.2 Call establishment and end-to-end security . . 1.1.3 Authentication infrastructure . . . . . . . . . . 1.1.4 Wireless access using WLANs . . . . . . . . . 1.1.5 Shared access network . . . . . . . . . . . . . . 1.1.6 Access control . . . . . . . . . . . . . . . . . . . 1.1.7 Layer-3 access and mobility . . . . . . . . . . . 1.1.8 Accounting . . . . . . . . . . . . . . . . . . . . 1.2 Outline of thesis . . . . . . . . . . . . . . . . . . . . . . 1.3 My contribution . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Own publications used in this thesis . . . . . . 1.3.2 Other contributions . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

1 1 3 3 3 4 4 4 6 6 7 8 8 12

Interactive audio over packet based networks 2.1 Overview of audio data processing . . . . . . . . . . . . . . . . . 2.1.1 Sender side: Generating and transmitting audio data . . 2.1.2 Receiver side: Receiving and playing audio data . . . . . 2.2 Voice conversation properties and effect of speech interruption . 2.2.1 On-off patterns in conversations . . . . . . . . . . . . . . 2.2.2 Effect of packet loss and loss location . . . . . . . . . . . 2.3 Forward Error Correction (FEC) . . . . . . . . . . . . . . . . . . . 2.3.1 Overview of FEC methods . . . . . . . . . . . . . . . . . 2.3.2 FEC lag suitable for VoIP loss characteristics . . . . . . . 2.4 Transport of real-time traffic . . . . . . . . . . . . . . . . . . . . . 2.5 Network delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Handling jitter at the receiver: play-out buffer algorithms . . . . 2.6.1 Adaptive play-out buffer algorithm principles . . . . . . 2.6.2 Handling sudden delay spikes . . . . . . . . . . . . . . . 2.6.3 FEC and play-out buffer algorithms . . . . . . . . . . . . 2.7 Packet loss concealment . . . . . . . . . . . . . . . . . . . . . . . 2.8 Efficient end-system implementation . . . . . . . . . . . . . . . . 2.9 Summary of audio chapter . . . . . . . . . . . . . . . . . . . . . .

15 15 16 18 20 20 23 24 25 26 27 28 28 29 30 30 32 32 33

. . . . . . . . . . . . .

CONTENTS

Using SIP to establish a secure phone call 3.1 Regular SIP call setup . . . . . . . . . . . . . . . . . . 3.2 Security issues for IP telephony . . . . . . . . . . . . 3.3 Securing VoIP media - at what layer? . . . . . . . . . 3.4 Secure call establishment . . . . . . . . . . . . . . . . 3.4.1 Integrated keying . . . . . . . . . . . . . . . . 3.4.2 Separate keying . . . . . . . . . . . . . . . . . 3.5 SIP authentication infrastructure . . . . . . . . . . . 3.5.1 Certificate Authority for SIP users . . . . . . 3.5.2 PKI models including SIP providers as CAs .

. . . . . . . . .

34 34 36 38 39 40 45 46 48 49

. . . . . . . . . .

51 51 52 52 54 59 59 60 61 67 75

Secure public WLAN infrastructures 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Security requirements in public WLAN networks . . . . 5.1.2 Extensions to access network topology . . . . . . . . . . 5.1.3 Solution alternatives considered . . . . . . . . . . . . . . 5.2 Solutions utilizing PPP tunnels . . . . . . . . . . . . . . . . . . . 5.2.1 General PPP connection establishment . . . . . . . . . . 5.2.2 PPP with authentication and confidentiality . . . . . . . 5.2.3 EAP authentication . . . . . . . . . . . . . . . . . . . . . . 5.2.4 PPP over Ethernet (PPPoE) . . . . . . . . . . . . . . . . . 5.2.5 Point-to-Point Tunneling Protocol (PPTP) . . . . . . . . . 5.2.6 Layer-2 Tunneling Protocol (L2TP) . . . . . . . . . . . . . 5.3 Solutions using IEEE 802.11 security enhancements . . . . . . . 5.3.1 4-way handshake . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Pre-authentication . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Centralized authenticator service . . . . . . . . . . . . . . 5.4 Achieving a secure operator neutral access network . . . . . . . 5.4.1 General concepts . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Single ISP with POP - Roaming . . . . . . . . . . . . . . . 5.4.3 Multiple ISPs with POP - native operator neutral access 5.4.4 Hybrid solutions . . . . . . . . . . . . . . . . . . . . . . . 5.5 Conclusions of secure public WLAN infrastructures . . . . . . .

79 79 79 80 82 85 85 88 90 95 97 99 102 104 105 107 108 109 109 113 117 118

. . . . . . . . .

Handover in IEEE 802.11 networks 4.1 Introduction to IEEE 802.11 WLAN . . . . . . . . . . . 4.1.1 Assumptions . . . . . . . . . . . . . . . . . . . 4.2 Other experimental 802.11 handover studies . . . . . 4.3 IEEE 802.11 handover process . . . . . . . . . . . . . . 4.4 Use of bridging APs to serve one WLAN . . . . . . . 4.4.1 Station cache issue for handover within a LAN 4.5 WLAN handover tests and measurements . . . . . . . 4.5.1 Handover without competing traffic . . . . . . 4.5.2 Competing traffic . . . . . . . . . . . . . . . . . 4.5.3 Measurement summary and analysis . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

CONTENTS

IP Mobility support 6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Detecting layer-3 mobility . . . . . . . . . . . . . . . . . . . . 6.2.1 Using the ESSID as a LAN identifier . . . . . . . . . . 6.2.2 Using the ESSID as an operator identifier . . . . . . . 6.2.3 Summary of layer-3 mobility detection . . . . . . . . 6.3 Acquiring a care-of IP address . . . . . . . . . . . . . . . . . . 6.3.1 Synchronization Avoidance . . . . . . . . . . . . . . . 6.3.2 Duplicate Address Detection . . . . . . . . . . . . . . 6.4 IP layer mobility issues and approaches . . . . . . . . . . . . 6.5 Macro-mobility support schemes . . . . . . . . . . . . . . . . 6.5.1 Some security concerns for layer-3 mobility schemes 6.5.2 MIPv6 with route optimization . . . . . . . . . . . . . 6.5.3 SIP mobility . . . . . . . . . . . . . . . . . . . . . . . . 6.5.4 MIPv4 and MIPv6 with reverse tunneling . . . . . . . 6.6 Micro-mobility support schemes . . . . . . . . . . . . . . . . 6.6.1 Host based routing . . . . . . . . . . . . . . . . . . . . 6.6.2 Local tunnels . . . . . . . . . . . . . . . . . . . . . . . 6.6.3 Other micro-mobility approaches . . . . . . . . . . . . 6.7 Summary of layer-3 mobility management . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

119 120 121 122 123 124 124 125 127 129 131 132 133 136 142 144 145 148 149 150

Putting it all together 7.1 System overview . . . . . . . . . . . . . . . 7.2 Overall handover performance . . . . . . . 7.2.1 Before the handover . . . . . . . . . 7.2.2 Hints about an upcoming handover 7.2.3 Performing the handover . . . . . .

. . . . .

152 152 156 156 158 159

Conclusions and Future Work 8.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

162 162 165

Acronyms and abbreviations

167

Bibliography

170

. . . . .

Chapter 1

Introduction IEEE 802.11 wireless local area networks (WLANs) have become an increasingly popular user access technology and a flexible alternative to wired access. WLANs are now appearing not only as wireless extensions of private corporate networks, but also in homes and public hot-spots. An attractive concept is to use these WLAN access networks for public mobile telephony. However, to be practically useful and manageable, such a system must provide both (1) a satisfactory level of security and performance to the users, and (2) authentication, authorization, and accounting (AAA) primitives to the system providers. This thesis concerns the design of a WLAN based architecture to provide security and mobility support for real-time Internet services focusing on offering fast handover support to a mobile voice over IP (VoIP) application. When presenting the different components of the architecture we will also describe how the related protocol mechanisms will affect the handover performance (packet loss and delay) when a user conducts a layer-2 as well as layer-3 handover. VoIP applications are usually designed to handle both packet loss and delay variations, since these are natural characteristics of a packet based network. The focus of this thesis is to evaluate these mechanisms with respect to the specific delay and loss patterns originating from user mobility. This chapter contains an overview of the infrastructure and introduces its components. The parts of the system will be covered in more depth throughout the rest of this thesis. At the end of the thesis we will synthesize these results to evaluate the overall handover performance for several handover scenarios.

1.1

Service architecture

The network infrastructure we present should enable mobile Internet users to roam within and between wireless access networks, while keeping an ongoing IP telephone call with little or no impact on the voice call performance. The proposed architecture is shown in Fig. 1.1. The figure shows the terminals of two mobile users (Alice and Bob), who wish to communicate,

CHAPTER 1. INTRODUCTION

Alice’s ISP (ispA.com) MIP HA

SIP server

Bob’s ISP (ispB.com)

AAAH

SIP server

MIP HA

Internet

Bob

Visited network j

Visited network i AAAF AP

AAAF AP

Alice Figure 1.1: Overview of suggested service architecture for mobile VoIP. (The visited networks could be shared by multiple ISPs. Although not explicitly shown Bob (just as Alice) can connect via wireless access networks.

and some of the important infrastructure entities. For simplicity we will use the names Alice and Bob throughout this thesis when referring to either the mobile users (as persons) or their terminals. Alice (and similarly Bob) will have an account with an Internet service provider (ISP), ispA.com, in order to get Internet access. She will be able to roam between access networks where a roaming partner of her ISP (or her ISP itself) is present. We use the terms AAAH A and AAAF A to denote the AAA server of Alice’s ISP and the roaming partner respectively. This is to some extent in-line with the terminology used for the AAA solutions being developed for Mobile IP (MIP)[33, 50], however, the access networks in our architecture are designed for both IP version 4 (IPv4) and IP version 6 (IPv6) hosts and the choices of network access server (NAS) solution and IP mobility management scheme are more independent. In Fig. 1.1 it is assumed that Alice’s and Bob’s ISPs in addition to AAA also provide Session Initiation Protocol (SIP[147]) and possibly also MIP services. This model is a simplification, since Alice and Bob could have SIP and MIP provided by a service provider other than their ISP. Thus, to enable mobile IP telephony Alice may use multiple service providers and identities

1.1. SERVICE ARCHITECTURE

associated with these providers, such as [emailprotected] for Internet access, [emailprotected] for SIP services, and (optionally) [emailprotected] for MIP services. In the following sub-sections we will briefly describe properties of the architecture and its different design alternatives.

1.1.1

Applications and end-systems for packet voice

The focus of this thesis is on infrastructure and end-system support for secure and mobile IP telephony between two Internet users. Using a packet based network such as the Internet for interactive voice applications implies other challenges as compared to the public switched telephone network (PSTN). Applications for packet based audio must be able to manage the delay, jitter, and loss characteristics inherent in a packet network as the Internet. Furthermore, IP telephony applications have the flexibility to use various audio CODECs and provide stereo sound, thereby providing telephony with higher audio quality than “regular” PSTN telephony. Properties of packet based audio are examined further in chapter 2.

1.1.2

Call establishment and end-to-end security

Let us consider the case when a user Alice ([emailprotected]) calls her friend Bob ([emailprotected]). To establish the call we assume the use of SIP. Alice will send a SIP INVITE message to her SIP server, which will use the domain name portion of the universal resource locator (URL), sipB.com, to find Bob’s SIP server at sipB.com. Bob’s SIP server will in turn forward the SIP INVITE message to his current location (i.e., the IP address and port he has registered). As part of the call setup Alice and Bob should perform mutual authentication and create a security association assisted by the trust infrastructure (see section 1.1.3). This security association could be used to generate session keys to protect the call content (i.e., RTP media traffic) between Alice and Bob. The possibility for users to authenticate each other is likely to become important, since it enables us to filter out spam phone calls even before answering. Adding confidentiality to a voice call is straightforward once the users have mutually authenticated. Although users expect call establishment to be carried out quickly, this is not as time critical as the timely delivery of voice packets within an ongoing call. Secure call establishment is examined in chapter 3.

1.1.3

Authentication infrastructure

In addition to providing confidentiality of user data (end-to-end and/or over the wireless link) there are additional security concerns related to, e.g., network access and roaming, and layer-3 mobility. To support authentication, session key establishment, etc. with so many parties involved, an appropriate authentication infrastructure is required. This infrastructure can either be based on public key cryptography, i.e., a public key infrastructure (PKI), or secret key cryptography, i.e., a “Kerberos-like” model. In Fig. 1.1 we only showed the existence of AAA servers serving the users in the various domains, but not the trust infrastructure which these AAA servers base their interactions

CHAPTER 1. INTRODUCTION

upon. There are security issues for various system components, thus trust and trust infrastructures will be covered in several chapters (3 and 5-8).

1.1.4

Wireless access using WLANs

In this thesis we have limited the scope to the case when Alice and Bob use IEEE 802.11 WLANs as access technology. This does not prohibit Alice and Bob from using other, complementary access technologies, however, here we only analyze mobility within and across WLAN access networks.

1.1.5

Shared access network

It is unlikely that a single wireless ISP (WISP) will be able to achieve city wide WLAN coverage by itself. In addition to the cost involved, it may be difficult to get permission to put up WLAN access points (APs) at all necessary positions, especially if another WISP is already present at this location or if the organization (or person) at this location already has a private WLAN access network in place. The solution proposed here is that the WLAN access infrastructure is shared between ISPs. The way to implement network sharing is likely to vary. Some APs may be associated with a single WISP, either directly or in cooperation with some local partner such as a company, a store, or even a private person. In this thesis we examine various NAS solutions (with focus a on IEEE 802.1X and PPP based approaches) and their ability to separate the public traffic from the partner’s own private networks. For example, with IEEE 802.1X the AP could map different users to different virtual LANs (VLANs). With these solutions a WLAN access network originally used as an extension to a company network, could also be used publicly by the company’s visitors (and others) without exposing the company’s internal network. In addition to enabling separation of the private (company) and public (WISP) traffic, IEEE 802.1X could be used to share the same APs between multiple WISPs in a more neutral way than roaming between them, see Fig. 1.2. However, it is unreasonable and infeasible for every WISP to be connected to every access network of interest, so WISPs will need to establish roaming agreements at locations where they have no local presence. Alice’s ISP needs to have a roaming agreement with at least one of the WISPs present in the foreign network (ISP1 or ISP2 in Fig. 1.2) where Alice is currently located. Of course, the most challenging case to address is when Alice moves between access networks run by different roaming partners.

1.1.6

Access control

Alice connects to the Internet via some (available) IEEE 802.11 AP in her vicinity. Since Alice may move out of range of her current AP, her terminal may need to perform multiple handovers between APs during the course of her ongoing conversation. Each handover may interrupt her Internet access. Before Alice is granted network access, she not only has to detect and associate with a suitable AP, but must also complete the authentication and authorization procedure for this access network. NAS technologies such as IEEE 802.1X and PPP provides the primitives necessary to accomplish this, and the procedure is the same from Alice’s perspective whether she is connecting

1.1. SERVICE ARCHITECTURE

Internet R ISP1

R ISP2 Separated data streams (e.g. VLAN) WLAN associations (possibly encrypted)

Figure 1.2: Example of WISPs sharing a WLAN access network.

to an AP of her own ISP or using an AP operated by one of her ISP’s roaming partners. The procedure to acquire remote access can be divided into four steps: 1. Pure IEEE 802.11 matters: Alice will need to detect movement, scan for new APs, and execute the IEEE 802.11 handover. 2. AAA mechanisms: Alice will authenticate to her ISP’s AAA server (AAAH A ) via a NAS1 in the visited network. AAAH A then informs the NAS that Alice is authorized to be granted network access. IEEE 802.1X (and optionally also PPP) makes use of the extensible authentication protocol (EAP)[23] to negotiate an authentication scheme between Alice and AAAH A and to carry these authentication messages. The NAS, AAAF A , and AAAH A are likely to use RADIUS[141] for their communication, although in the future use of Diameter[32] protocol is preferred. 3. Wireless link security: Alice and the NAS should perform mutual authentication, and as part of this establish keys to protect the data traffic on the “hop” between them. We believe that the communication over the wireless link should be authenticated (to enforce access control) and optionally also encrypted2 . 4. ISP selection and traffic mapping: If there are multiple ISPs providing service via the AP, a fourth step, mapping of Alice’s data traffic to a suitable ISP, may be needed. 1 This

NAS can reside within an AP or some other device. link level encryption would not be needed if the traffic already is encrypted end-toend. Users may wish to use other (unsecured) applications over the WLAN, but will hesitate to use them if no link level encryption is available. However, we will not consider these other applications within this thesis. 2 Specific

CHAPTER 1. INTRODUCTION

In chapter 4 we will examine properties of IEEE 802.11 handovers (step 1). In chapter 5 we will investigate the implications of steps 2-4.

1.1.7

Layer-3 access and mobility

If Alice is authorized to connect to the visited access network, the NAS will start to forward packets to and from Alice. Alice can now acquire an IP address (IPv4 or IPv6) and access the Internet. Many handovers are likely to occur between APs attached to the same LAN, but in the heterogeneous environment we are anticipating handovers will often occur across LAN borders and in particular between access networks run by different operators. In these situations Alice must acquire a new IP address associated with the new IP subnet. Once Alice has received a new IP address, it is important to quickly redirect data traffic of ongoing sessions to her new location. To avoid losing an ongoing voice call there are two main alternatives; use of MIP to provide mobility at the IP layer, or to use “SIP mobility”[181] to provide mobility at the application layer. In this thesis we focus on MIPv6[77] and SIP mobility, since both support route optimization, which we believe is necessary for delay sensitive applications as voice. Layer-3 mobility issues are studied in chapter 6.

1.1.8

Accounting

As mentioned in section 1.1.6 our architecture utilizes RADIUS (or Diameter) for carrying EAP authentication/authorization messages between the NAS, the local AAA server (AAAF A ), and AAAH A . Therefore we inherit RADIUS’ accounting mechanisms. Although accounting is not the major focus of this study, it is important to understand whether the suggested architecture prohibits certain desirable accounting models or if accounting mechanisms affect the handover latency. Finding accounting models in packet based networks that are satisfactory for customers, ISPs, and local operators is not a trivial task. Traditionally customers have become accustomed to pay for the duration of their call, but as telephony becomes a service on the Internet traditional charging models will be difficult to apply. Users may not be willing to pay extra for a (low bandwidth) VoIP phone call, when they encounter no extra cost when they are surfing the web or downloading a DVD movie. Therefore flat rate pricing is likely to also become the future accounting model for telephony. Below we will elaborate on some of the issues related to accounting in the proposed architecture. Everything would be very simple if Alice pays a fixed monthly fee independent of her connection time or amount of data transfer, i.e., flat rate. This may be feasible if Alice’s ISP and its roaming partners do not care about charging each other based upon the details of the service given to each others’ customers. If so, then there is no need for accounting messages to be exchanged between the AP, AAAF A , and the AAAH A . However, if an ISP would like to charge based on actual usage, a likely model would be that Alice could pay a fixed monthly fee up to a threshold, but then have variable charges after that. Also, there should be some

1.2. OUTLINE OF THESIS

mechanisms available to measure actual user resource consumption (time or data transferred) in case the ISPs want to base roaming agreements upon measurable service delivery. Although we prefer “flat rate” charging models, we will elaborate on the impact of usage based charging models below. One approach to measure resource consumption would be to measure the time from when Alice is authorized to use the remote network until she either explicitly disconnects or leaves the coverage area of the AP. There are several issues related to this approach: • If Alice has a fixed price connectivity up to a threshold time, she will disconnect as soon as she has nothing to transmit. This implies that a NAS will block both incoming and outgoing traffic as soon as she disconnects, hence Bob will not be able to call her. This is clearly undesirable. This could be handled by allowing traffic to Alice to pass through the NAS (for free) even if she is not authorized to send traffic. If Alice receives a SIP INVITE message from Bob, she could re-authenticate and then continue the call establishment. • Using the regular European telephony payment model, Alice does not pay for incoming calls at all. Unless users accept that incoming calls also affect their usage charges, it may be necessary to try approaches where some services (such as incoming calls) should not3 generate an accounting event (or generate an accounting event with a zero charge). • The remote network does not want to grant Alice access before it knows that it can charge Alice’s ISP for this access (according to their roaming agreement). However, waiting for accounting clearance should not affect the handover latency, since the accounting attributes could be processed by the AAAH A together with the authentication attributes in the (initial) authentication procedure (see section 1.1.6). Therefore accounting is not considered further in the analysis of the handover latency. These items, except perhaps for the last, are not related to handover latency. Instead they raise questions as to whether IEEE 802.1X or PPP are appropriate NAS technologies for IP telephony applications when using accounting models other than flat rate. Nevertheless, there is little that suggests that using NAS devices based on IEEE 802.1X or PPP should be more difficult than other alternatives when it comes to accounting.

1.2

Outline of thesis

The thesis starts by examining aspects related to the IP telephony application. Chapter 2 serves as an introduction to packet based audio. The purpose is to describe audio applications ability to handle loss and delay in general before we investigate the loss and delay patterns resulting from terminal mobility. Chapter 3 explains how SIP can be used to establish a secure IP telephone call. The following chapters examine link layer and IP layer mobility mechanisms and their impact on an ongoing voice call. Chapter 4 concerns link 3 Note

that free calls in Sweden may not appear on the user’s bills!

CHAPTER 1. INTRODUCTION

layer handover between two bridged WLAN APs without access control4 . In chapter 5 the access network is extended with capabilities for access control and operator neutrality (shared access networks). Chapter 6 examines mobility between IP subnets. In chapter 7 we present the overall system (in more detail than in this chapter) and describe the total architectural impact on the handover performance as well as its requirements on security bindings. Chapter 8 contains concluding remarks and suggestions of future work.

1.3

My contribution

This thesis is based both on material from earlier publications as well and unpublished material. Section 1.3.1 contains a summary of the used publications and section 1.3.2 provides a list of other contributions with pointers to related sections in this dissertation.

1.3.1

Own publications used in this thesis

1. Jon-Olov Vatn and Gerald Q. Maguire Jr., The effect of using co-located care-of addresses on macro handover latency, In Proceedings of 14th Nordic Teletraffic Seminar, August 1998, Lyngby, Denmark[177]. This paper considers the use of co-located care-of addresses (COAs), and its effect on the care-of address retrieval delay (Tcoa ). The focus is on the use of DHCP[40] in IPv4 networks, which enables a mobile node (MN) attached to a multiple access link to lease an IP address from a DHCP server. The major problem of using co-located COAs was found to be the need to perform address conflict checking, i.e, before using an IP address, one should make sure that no-one else is already using that address. In DHCP, it is recommended that the DHCP server and the client (i.e, the MN) “probe” the subnet to make sure that no-one “answers” on the address about to be leased by the MN. This mechanism is not designed to support low latency handover, since “waiting for things not to happen” is a time consuming procedure. To obtain low Tcoa , while still achieving a reasonable level of robustness, the paper suggests that address conflict checking should be performed as a background process by the DHCP server alone, thus removing it from the time critical COA assignment process. Contributions of the author of the paper were: carrying out experimental tests and measurements, analysis of results, writing, and some of the ideas for suggested improvements. Initial ideas and some of the suggested improvements are due to the second author. Material from this paper has been used in chapter 6. 4 By

access control we refer to the ability to limit access to authorized users.

1.3. MY CONTRIBUTION

2. Jon-Olov Vatn, Long Random Wait Times for Getting a Care-of Address are a Danger to Mobile Multimedia, 1999 IEEE International Workshop on Mobile Multimedia Communications (MoMuC’99), 15-17 November 1999, San Diego, CA USA.[172] This short paper also concerns the delay involved when acquiring a care-of address (Tcoa ). It extends the study made in paper 1[177], by taking a closer look at Tcoa when using foreign agent COAs in MIPv4 and co-located COAs in MIPv6 (using IPv6 stateless address autoconfiguration[165]). The use of IPv6 stateless address auto-configuration to acquire co-located COAs was found to experience the same problem as using DHCP in paper 1, i.e., there was a need to check for address conflicts. However, a different solution is suggested, since there is no server present that could check for conflicts in advance. Instead, the paper suggests that address conflict checking should be skipped (or done reactively), at least on links where the IPv6 address can be formed based upon some global identifier, e.g., an IEEE 48 bit MAC address. In both MIPv4 and MIPv6, random waiting times were found in the ICMP Router Solicitation/Advertisement exchange. These delays were in the interval 0-1 second, and are included in the protocols to avoid synchronization of processes[46] on different machines. In the paper we question whether this delay is relevant on links with few (usually only one) routers and suggest that this delay interval should be decreased (or skipped) for high speed links, in order to support low latency handover for mobile nodes. Material from this paper has been used in chapter 6. 3. Jon-Olov Vatn, End-to-end and Redirection Delays in IP Based Mobility, Proceedings of IFIP Conference on Personal Wireless Communication ´ (PWC’2000), September 14-15, 2000, Gdansk, Poland[173]. (An earlier version was published as Technical Report TRITA-IT R 00:01, ISSN-1103534X, ISRN KTH/IT/R–00/01–SE, 2000, Royal Institute of Technology, Sweden)[174] The objective for this paper is to evaluate a set of mobility support schemes according to two important metrics: the end-to-end delay (Tee ) and path redirection delay (Tredir ). For each of the mobility schemes, symbolic expressions for Tee and Tredir are presented. The schemes are then compared, based upon how many backbone traversals their Tee and Tredir may involve. For handovers performed within one operator, schemes based on hierarchical or smooth handover were found to be suitable for fast handover support. Tredir was low since no signaling across the backbone was necessary to redirect packets in-flight towards the MN. It should be noted that all of the examined schemes had problems to successfully support handover between operators. In this case, Tredir was in the order of two to three backbone traversals. Another result was that schemes providing low Tee did not necessarily have low Tredir . In IPv4 networks, MIPv4 with route optimization[123] was

CHAPTER 1. INTRODUCTION

considered as the most promising scheme due to its low Tee ; however, its long Tredir could lead to bad handover performance. The paper also suggests that MNs should be able to send data via the new subnet at about the same time as it sends the Registration Request to register its new COA with the HA. Currently, schemes using FAs will wait for a positive Registration Reply before updating its routing table, possibly resulting in an upstream Tredir in the order of a backbone roundtrip time. Material from this paper has been used in chapter 6. 4. Jon-Olov Vatn, A roaming architecture for IP based mobile telephony in WLAN environments, Mobility Roundtable 2003, May 2003, Stockholm, Sweden[175]. This paper presents a roaming architecture with shared WLAN access networks using IEEE 802.1X/802.11i as NAS technology. To enable mobility to VoIP applications an overview of handover mechanisms for IEEE 802.11i and MIPv6 with route optimization is provided, and symbolic expressions for the handover latency are presented. As an optimization for MIPv6 it is suggested the binding management key is based on a pre-configured key created based on the same authentication infrastructure as used to establish the secure VoIP call. Material from this paper have been used in chapters 1, 5 and 6. 5. Jon-Olov Vatn, An experimental study of IEEE 802.11b handover performance and its effect on voice traffic, Technical Report TRITA-IMITTSLAB R 03:01, ISSN 1651-7709 ISRN KTH/IMIT/TSLAB/R–03/01–SE, July, 2003, Royal Institute of Technology, Sweden[176]. This study concerns handover performance for mobility between IEEE 802.11b access points in the middle of a call. By observing both voice traffic and IEEE 802.11b management messages I was able to identify properties of the handover mechanisms not revealed by simply monitoring management messages only. While IEEE management and control messages give an indication of the time interval when voice packets are affected (i.e., the handover interval), our observations give more information on how the voice data is affected. The study also presents a test method of general interest where mobility is emulated by controlling the transmission power of access points. Material from this paper have been used in chapter 5 6. Johan Bilien, Erik Eliasson and Jon-Olov Vatn, Call establishment delay for secure VoIP, Short paper in proceedings of Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks (WiOpt’04), March 2004, Cambridge, UK In this paper we show that the additional delay due to MIKEY processing is insignificant for a human user. My contribution in this publication: initial ideas, discussions, majority of writing, setting up servers in testbed. Contribution of co-authors: Implementation of SIP user agent (minisip) with required security features, carrying out measurements, discussions, and minor contributions to the writing.

1.3. MY CONTRIBUTION

Material from this paper has been used in chapter 3. 7. Johan Bilien, Erik Eliasson, Joachim Orrblad and Jon-Olov Vatn, Secure VoIP: call establishment and media protection, Accepted for the 2nd Workshop on Securing Voice over IP, June 2005, Washington DC, USA[21]. In this paper we study the possibility of establishing a secure VoIP telephone call using SIP. Different security services relevant for VoIP are presented and we argue that end-to-end authentication and encryption should be provided by default. For media protection we evaluate the possibility of using either SRTP or IPSec, and we examine several alternatives of how a secure VoIP call can be established. The solution we suggest is based on SRTP for media protection, S/MIME and MIKEY for end-to-end authentication and keying, and TLS for hop-by-hop protection of SIP messages. We also present measurements of secure call establishment for MIKEY, SRTP and IPSec using our own SIP user agent (minisip). Our conclusion is that the call establishment delay will not be significantly affected by introducing these security protocols. My contribution in this publication: initial ideas, discussions, majority of writing (except for the measurements, this publication is to a large extent based on an earlier version of chapter 3 in this thesis). Contribution of co-authors: Initial ideas, implementation of SIP user agent (minisip) with required security features, carrying out measurements, discussions, and minor contributions to the writing. Material from this paper has been used in chapter 3. In addition to my own publications I have also made contributions as a supervisor in a set of master thesis projects related to secure VoIP (chapter 3). The finished thesis are listed below: • Israel Abad, Secure Mobile VoIP, Master thesis, Department of Microelectronics and Information Technology, Royal Institute of Technology, June 2003[30]. I specified and initiated this master thesis project, in which SRTP was added to minisip, and its performance was evaluated. The work was supervised by me, Erik Eliasson, and professor Gerald Q. Maguire Jr.. • Johan Bilien, Key Agreement for Secure Voice over IP, Master thesis, Department of Microelectronics and Information Technology, Royal Institute of Technology, December 2003[20]. I specified and initiated this master thesis project in which MIKEY[7] was added to minisip, and its performance was evaluated. The work was also supervised by me, Erik Eliasson, and professor Gerald Q. Maguire Jr.. This resulted in the first open source MIKEY implementation, and our (Johan, Erik, and I) interaction with the MIKEY design team was acknowledged in RFC 3830 (MIKEY)[7].

CHAPTER 1. INTRODUCTION

• Joachim Orrblad, Alternatives to MIKEY/SRTP to secure VoIP, Master thesis, Department of Microelectronics and Information Technology, Royal Institute of Technology (KTH), Sweden, March 2005[115]. I specified and initiated this master thesis project, in which support to secure VoIP sessions by IPSec (ESP) was added to minisip, including a solution for key agreement. Erik Eliasson, Johan Bilien, and I supervised this project. Erik Eliasson, Johan Bilien and I are currently supervising two more master thesis projects related to secure VoIP: • Chen Jie, PKI infrastructures for secure VoIP [Tentative title], Master thesis, Department of Microelectronics and Information Technology, Royal Institute of Technology (KTH), July 2005 [expected date], http://web.it.kth.se/˜iw03 jch/Thesis.htm. The PKI trust models discussed section 3.5 are from Radia Perlman[126]. My contribution is to apply this to end-to-end security for VoIP. I have initiated/specified this master thesis project where TOP-DOWN and UPCROSS-DOWN trust models are being implemented in minisip, and the applicability of these trust models will be evaluated. In this (ongoing) thesis project Johan Bilien, Erik Eliasson, and I are supervisors. • Max Zomborszki, Caller and Callee preferences for secure VoIP [Tentative title], Master thesis, Department of Microelectronics and Information Technology, Royal Institute of Technology (KTH), July 2005 [expected date], http://web.it.kth.se/˜max/. I initiated/specified this master thesis project in which mechanisms to block unwanted calls (among other policy related matters) will be implemented into minisip and evaluated. In this (ongoing) thesis project Johan Bilien, Erik Eliasson and I are supervisors.

1.3.2

Other contributions

Some of the chapters contain contributions which are not included in the listed publications. This primarily applies to chapters 2, 5 and 6. • Chapter 2: The intention with this chapter is to make a survey and present information on the requirements from the IP telephony application on the handover performance (loss intervals, delays etc.). As part of this work I provide suggestions of how a VoIP application should behave to handle the delay and loss characteristics which occur due to mobility. – In section 2.3.1 I suggest and motivate the use of media independent FEC (2,1)5 with FEC lag equal to 1. – In section 2.6.3 I explain how the “look-ahead delay” introduced to avoid front-end clipping in silence suppression schemes will be hidden by the FEC delay, i.e., the delays are not additive. 5 Also

referred to as media dependent FEC with the same primary and secondary CODEC.

1.3. MY CONTRIBUTION

– Some of my proposals rely on the assumption that the VoIP application can receive hints from the link-layer about an upcoming handover, and in some cases control the timing of the handover execution. ∗ In section 2.2.1 I propose the idea that handovers could be triggered in periods of mutual silence and give suggestions of how this could be done. Alternatively, the handover should be triggered immediately after the mobile station has finished a talk-spurt to avoid play-out delay losses, as described in section 2.6.2. ∗ In sections 2.3.2 and 2.6.2 I recommend that when the mobile station gets a handover indication it should notify the remote end to increase the FEC lag, and that both ends set their playout point so that more delayed packets can be accepted. ∗ In section 2.2.2 I recommend that upon receiving a handover indication the mobile station should “make” both sides use stateless waveform encoding (or at least the remote side), thereby avoiding the occurrence of packet loss affect more packets than necessary. • Chapter 5: In this chapter I present designs for shared WLAN access networks. The designs evaluated focus on NAS solutions enabling authentication and ISP selection before the user is assigned an IP address by its ISP. In the evaluated designs suggestions of how to provide local services independent of the connected ISP. – In section 5.2.4 I provide suggestions of how a PPPoE client should act upon handover to limit connectivity disruption. – In Table 5.1 I summarize signalling requirements and security features for various NAS solutions (applicable both for roaming and native methods to accomplish shared access networks). The presented values are based on protocol analysis and in many cases also practical verifications. – In section 5.4.3.1 I describe issues using multiple ESSID/BSSID for shared access networks. – In section 5.4.3.3 I explain how shared access networks can be designed using PPTP and L2TP as NAS solution. – In section 5.4.3.4 I describe issues and alternatives when IEEE 802.11i is used as NAS solution in a shared access network. In particular I describe a security issue with a model referred to as “Authenticator managed by access network operator” (which I proposed in [175]). To remedy this issue I provide an alternative approach referred to as “ISPs enforcing access control”. – In section 5.4.4 I point at the need for a “dynamic roaming protocol” in hybrid roaming/native operator neutral access networks. • Chapter 6: In [177, 172, 173] I and Gerald Q. Maguire Jr. describe issues and opportunities related to layer-3 handover and their impact on handover delay, as mentioned in section 1.3.1. In addition to this

CHAPTER 1. INTRODUCTION

I provide the following contributions related to IP layer handover in chapter 6: – In section 6.2 I describe the issues of using the WLAN ESSID as a “LAN identifier” or an “operator identifier”. In section 6.2.1 I suggest the use of a protocol such as CARD to enable cross-ESSID handover. – In section 6.3.2 I point at the benefits of using a specific duplicate address detection mechanism for MIPv6 (proposed by Koodli’s and Perkins[85]) not only pro-actively, but also re-activly (i.e., after a handover has occurred). – In section 6.5.2.1 I propose the idea to utilize the security relationship from the SIP call to improve handover performance for MIPv6 (I have also presented this idea in [175]). – In section 6.5.3 I analyze the redirection delay for SIP mobility, extending one of my earlier studies[173], which primarily concerned redirection delays for MIP schemes. – In section 6.5.3.1 I investigate possibilities and delay consequences of securing the re-INVITE. I also propose the use of an “echoingCODEC” to defeat a certain DOS attack. – In section 6.6.2 I propose a method to reduce the global handover delay when using “hierarchical MIPv6” for micro-mobility. – In Table 6.1 I summarize signalling and delay characteristics for various layer-3 handover schemes. • Chapter 7: The contributions of this chapter are to describe the proposed system as a whole, and to present the resulting handover delay resulting of layer-2 handover, layer-3 handover, and access control mechanisms.

Chapter 2

Interactive audio over packet based networks The idea of using a packet based network such as the Internet for interactive audio is not new. Despite this, a commercial interest in IP based telephony did not appear until recently, usually in the form of public telephone operators offering public switched telephone network (PSTN) to Internet gateway services, or as private branch exchange (PBX) replacements at large companies. In the future it is likely that most phone calls will be carried by IP end-to-end, at least in countries with wide spread broadband Internet and Intranet infrastructures. When providing telephony services over a packet based network such as the Internet the applications must be able to handle the loss, delay, and jitter characteristics inherent in such a network. In this chapter we describe the mechanisms developed to handle these network characteristics, so that later we can evaluate how well these mechanisms handle the specific loss and delay patterns related to terminal mobility, which will be described in the following chapters. We start this chapter by providing an overview of the path of the audio data from the generation at the sender’s lips and input to their microphone to emission by the recipient’s speaker for perception at their ear (section 2.1). In section 2.2 we then look at the properties of voice and voice conversations, with the aim of presenting how an on-going voice conversation can be affected by interruptions in the data stream. We also explore the idea of using predicted periods of mutual silence in the conversation and examine the feasibility of masking the effect of a handover by triggering the handover during such a silence period. Sections 2.3-2.8 will cover the components of the system that are introduced in section 2.1, focusing on the parts that are related to the audio application in the end-nodes (while topics related to the network infrastructure and the network delay are covered in later chapters). Section 2.9 summarizes the findings in this chapter.

2.1

Overview of audio data processing

For a real-time application such as interactive voice it is important that the endto-end (i.e., mouth-to-ear) delay is kept within acceptable limits. This end-to-

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

Sound card Mixer

Mic. Line in

A/D

Kernel space Buffer/ queue

DMA

Kernel buffer

User space read (unit)

CODEC (G.711, ...) VAD FEC

Network Interface Card Network

Buffer/ queue

IP− process.

write (sock)

RTP/SRTP

Figure 2.1: Generating and transmitting audio data at the sender. end delay bound is not rigid, but values in the range 150-400 ms are commonly given[73, 37, 106]. Cole and Rosenbluth[37] show the relationship between quality and delay as two roughly linear regions, where additional delays above the knee (∼180 ms) have a worse impact on the perceived quality. The components contributing to the delay are either related to the different audio processing mechanisms at the sender and receiver, the CODing and DECoding (CODEC), or to the process of moving the data packets over the Internet (or Intranet). In this section we will give an overview of the mechanisms contributing to delay at the sender and receiver. These mechanisms will then be examined further throughout this chapter. In this chapter we will also briefly examine network delay characteristics, since the audio processing mechanisms at the receiver must be able to address the results of the network behavior. Network delay components specific to mobility support will be examined further in chapter 6.

2.1.1

Sender side: Generating and transmitting audio data

Consider an analog audio signal captured by a microphone and encoded as pulse code modulation (PCM) samples in the audio hardware, as shown in Fig. 2.1. In this analog-to-digital (A/D) conversion process the signal first passes through a low pass filter (to avoid aliasing), a sampler (converting it to a time discrete signal), and a quantizer (creating an amplitude discrete signal) whereupon the signal can be encoded as a linear or non-linear PCM codeword, usually with 8, 16 or 24 bits of resolution (all represented by the A/D-box in Fig. 2.1). Also, in the path there is usually an input mixer to allow for multiple audio sources to be mixed or simply selected, although for IP telephony applications only a single source (the microphone) is commonly used. Each of these inputs might be stereo, although for IP telephony we generally use only one channel. The audio samples are first stored in a small buffer/queue inside the audio hardware, from where the audio data is subsequently moved to a kernel space buffer in main memory using direct memory access (DMA) under control of the audio driver. The audio driver provides a software interface allowing

2.1. OVERVIEW OF AUDIO DATA PROCESSING

Sender

Network

Tfetch Tframe Tframe

Talg Tsender

Tlook−ahead/VAD Tcodec−proc Tsecurity

Transmission of packet(s) with encoded audio (+FEC) and headers (RTP, UDP, ...)

Network delay at sender

Figure 2.2: Overview of the sender delay for packet audio (similar to [37, fig 6]). In this example the CODEC takes two frames per RTP packet (N = 2).

applications to read (one or more) samples for further audio processing in user space1 . The audio CODEC usually processes audio in blocks (here referred to as audio frames). Hence, to improve efficiency it is desirable if the application can read the PCM samples from kernel space a frame at a time rather than a sample at a time[143]. In the audio CODEC a frame with a set of PCM codewords are processed and encoded using a suitable audio format, as selected by the session description (see section 3.1). The CODEC may encode the audio frames independently, but many CODECs are stateful, thus the encoding of the current frame depends on the values of the prior frames in order to increase encoding efficiency, and some CODECs even consider “future” frames, introducing a look-ahead delay. The sum of the (frame) buffering delay (T f rame ) and the look-ahead delay (Tlook−ahead ) is referred to as the CODEC’s algorithmic delay, and is the minimum delay added by a CODEC. This is in contrast to the processing delay of the CODEC, which varies depending on the CODEC implementation and the processing environment. The CODEC may also perform voice activity detection (VAD), whereby frames with speech are encoded as usual, otherwise frames are either encoded as noise or simply not sent at all. VAD could lead to delay at the sender when the CODEC does look-ahead in order to avoid front-end clipping (here we will consider all such delay as included in the Tlook−ahead of the algorithmic delay). Fig. 2.2 provides an overview of delay components at the sender side, and equation 2.1 presents a formula for the associated sender delay (Tsender ). Tsender

T f etch + TCODEC + Tsecurity = T f etch + Talg + TCODEC−proc + Tsecurity = T f etch + N ∗ T f rame + Tlook−ahead + TCODEC−proc + Tsecurity (2.1)

1 Some

sound cards can perform the coding (and encoding) on the sound card.

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

• T f etch : The time to fetch a frame from the soundcard is denoted T f etch . • TCODEC : The delay imposed by the CODEC has multiple components: – Talg : When sending voice data over the Internet one or more speech frames are placed into a RTP payload. The delay will increase by T f rame for every additional frame that is added. For simplicity we consider this as part of the CODEC’s algorithmic delay, i.e., Talg = N ∗ T f rame + Tlook−ahead . For a G.729 CODEC with a frame length (T f rame ) of 10 ms and 5 ms look-ahead (Tlook−ahead ), and with 2 frames per packet (as the example in Fig. 2.2) , the Talg would be 25 ms. – TCODEC−proc : The time for a CODEC to perform the actual encoding is denoted TCODEC−proc and depends on the CODEC implementation and the hardware performance. – (TFEC :) When packets are forwarded over a packet switched network such as the Internet, there is a risk that packets may be corrupted or lost on the way to the receiver. In order to improve performance when one or more packet is lost the sender application could perform forward error correction (FEC). To do this the sender sends redundant data to the receiver, either as a separate stream[144] or “piggybacked” on a following RTP packet[121], i.e., in the latter case an RTP packet contains both “new” and “old” RTP payloads. Use of FEC leads to some additional delay; however, as this delay only becomes visible if the receiver wants to be able to use the FEC information, we will treat this as a receiver related delay, see section 2.1.2. • Tsecurity : The data may be subject to security processing (Tsecurity ) at the sender to provide data confidentiality and authentication, e.g., using generic IPSec[82] services or protocols designed specifically for RTP packets such as SRTP[18] (for further details, see chapter 3). In equation 2.1 we have not considered any delay related to normal network processing and transmission in the end node; instead such delays are considered to be part of the network delay, see section 2.5.

2.1.2

Receiver side: Receiving and playing audio data

At the receiver the inverse process occurs. In addition the receiver has mechanisms to handle loss and jitter experienced by the audio stream during the traversal of the Internet. When receiving an audio packet first the regular IP/UDP processing is performed, then based upon the packet type and port number the RTP packet is delivered to the application. In the case of SRTP, the packet is first decrypted and the authentication tag is verified (Tsecurity ), if such security services are in use2 ). The RTP payload type specifies the format of the payload, and 2 Decryption and authentication could also be done at the IP layer (in kernel) when using IPSec[82].

2.1. OVERVIEW OF AUDIO DATA PROCESSING

Speaker Line out

Sound card Splitter

Headphone

D/A

Buffer/ Regist.

User space

Kernel space DMA

write (unit)

Kernel buffer

Appl. buffer (playout) CODEC (G.711, ...) FEC PLC

Network Interface Card Network

Buffer/ Regist.

IP− process.

read (sock)

RTP/SRTP

Figure 2.3: Receiving audio data at the receiver.

the receiving application passes the payload to the appropriate CODEC for decoding (Tcodec−proc ). As audio packets traverse the Internet they will experience different delays. In order to smooth out the effect of the delay variation (jitter) the receiver implements a playout (de-jitter) buffer. The goal is that audio data should be played with the same relative timing as it was generated (using timestamp information provided by RTP). Furthermore, the playout delay (Tplayout ) should be set long enough so that most audio packets will arrive before their scheduled playout time. However, this playout delay increases the mouth-toear delay, and using too large a value will not be acceptable for interactive applications such as telephony – this leads to a trade-off between delay and packet loss. Many audio applications make use of an adaptive playout buffer management algorithm, in which the playout point adapts to changes in network delay jitter. Packets that are lost (in the network or due to late arrival) may still be

Network

Sender Network delay at receiver Tsecurity Tcodec−proc Treceiver

Tplayout Tput

Playout point ~(jitter, FEC,...)

Figure 2.4: Overview of the receiver delay for packet audio

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

possible to recover using FEC techniques if the sender sends redundant data (the receiver generally needs to extend Tplayout to take advantage of FEC). To limit the effect of losses remaining after FEC processing, the receiver could utilize packet loss concealment (PLC) techniques, e.g., packet repetition or interpolation[125]. The CODEC will also add comfort noise if the sender uses VAD to refrain from sending audio packets during periods of silence. Data is written (preferably a frame at a time) from the user level playout buffer to a kernel buffer managed by the audio driver. The audio data is then transferred from the kernel audio buffer to the audio device (using DMA) for playout (Tput ). Treceiver

2.2

Tsecurity + Tcodec−proc + Tplayout + Tput

(2.2)

Voice conversation properties and effect of speech interruption

When considering the effect of packet loss on the user perceived performance it is important to understand the properties of the voice streams in the ongoing conversation. Based on this we can easily see that it is desirable to trigger handover during a silent period or when less critical audio data is transmitted.

2.2.1

On-off patterns in conversations

Human speech exhibits an on-off pattern with alternating periods of voice activity and silence. In packet audio systems this property is often exploited by voice activity detectors (VADs) to avoid data transmission during silent periods, thereby making better use of the available capacity. These silence periods can also be used to adjust for possible clock skew between the sender and receiver clocks and to adapt the playout time according to variations in network delay. We will return to these topics in later sections of this chapter. In this section we are interested in describing the on-off characteristic of speech in a voice conversation in order to understand if it is possible to trigger handover during periods of mutual silence. Brady has studied the on-off patterns by observing the voice activity during real conversations[28, 29]. He used a VAD that measured the signal energy during 5 ms periods. The energy was compared to a sensitivity threshold; energy above and below the threshold was considered as speech (on) and silence (off) respectively. He used the term spurt to denote a consecutive sequence of on-periods and gap to denote a sequence of off-periods, see Fig. 2.5. Determining the appropriate threshold value for voice activity detection is non-trivial. As we will discuss further below, speech sounds are often classified as being voiced or unvoiced where the voiced sounds generally contain more energy and are formed by the vibration of the vocal cords, while unvoiced sounds contain less energy with a wide spectrum and are often modeled as noise. Speech levels have a large dynamic range and its level frequently falls into the noise, even during segments audible to a listener[28]. Other reasons why a VAD may detect short gaps in the a voice stream (that a listener would consider to be a continuous flow) could be caused by momentary interruptions due to stop consonants and inter-syllabic gaps. To address the

2.2. VOICE CONVERSATION PROPERTIES AND EFFECT OF SPEECH INTERRUPTION 21

Gap

Spurt

010100 11

11100 000 11

0110101 0 00 1 1 000 11 10 1 1010101 0 00 1 1 000 1100 11 10 1 Talkspurt

Talkspurt

Pause

010 001 11 11100 000 00 11 11 10 Talkspurt

Pause

0110 00 11 11100 000 00 11 11 111 000 10 Talkspurt

0110 11 00 111 000 00 11 00 10 11 1010 11 00 111 000 00 1100 00 11 10 11 Talkspurt

Fill−in time

Pause

Talkspurt

Hang−over time

Figure 2.5: Gaps and spurts in speech (a). Bridging gaps using fill-in (b) and hangover (c).

difficulty of distinguishing between speech with low energy and silence VADs use a technique known as hangover to bridge (short) gaps between closely located spurts. With hangover the VAD verifies that a silence period equal to the hangover time (150-250 ms) exists after a spurt before silence suppression takes effect. This will bridge spurts separated by short gaps and the result will be a sequence of longer on- and off-periods referred to as talk-spurts and pauses, see Fig. 2.5a and Fig. 2.5c (we use the terminology given by Brady[28], although alternative definitions exist). As an alternative to hangover Brady uses a technique known as fill-in. Fill-in is similar to hangover except that hangover fills the beginning of every gap (regardless of its length) while fill-in avoids filling any part of the gap following a talk-spurt (compare Fig. 2.5b and Fig. 2.5c). The fill-in technique imposes a look-ahead delay equal to the fill-in time[75] (150-250 ms as mentioned below), thus fill-in is not of interest for interactive voice applications such as telephony. It is also noteworthy that some VADs, such as the one used in NeVoT[152], buffer the most recent (suppressed) frames during silence periods, and when the VAD then detects a frame with speech it first transmits the last frame (or last few frames) detected as silence. This technique may reduce an impairment referred to as front-end clipping, however, it will lead to burstier traffic, and just like fill-in this pre-spurt hangover will increase the end-to-end delay somewhat (by approximately T f rame or N · T f rame if N frames are transmitted). This additional delay may be masked if FEC is used, see section 2.3. Most short interruptions are below 150-250 ms, thus using a hangover time (or fill-in time) of 200 ms usually eliminates most short gaps[75]. The durations of the resulting on-off periods, i.e., the talk-spurts and pauses, have been covered in several studies. Although the result will depend on the sensitivity

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

Speaker A Speaker B Both A and B

111 000

00000 11111 1111111 0000 000 1111 0000 111 0000 000 1111000 111 000000 111111 Mutual silence

Figure 2.6: Mutual silence and voice activity during a conversation

of the voice detector, the average talk-spurt and pause periods when using a hangover of 200 ms are reported to be in the order of 1-2 seconds [75]. This is in-line with the studies by Brady, who gives an average talk-spurt and pause duration of 1.2 s and 1.8 s respectively in his tests (for -40 dBm) using 200 ms fill-in[29], which would correspond to 1.4 s and 2.0 s using 200 ms hangover. In our case we are more interested in the on-off pattern of the conversation than in the on-off pattern of the individual speakers, i.e., we focus on the pattern of alternating periods when at least one party is talking and periods of mutual silence, see Fig. 2.6. Brady[29] reports that in his tests mutual silence occupied about 25% of the time with an average duration of 466 ms (using a 200 ms fill-in time). This would mean that the average period with at least one party active would be about 1.4 s ((0.75/0.25) · 466ms = 1398ms). To convert these values for the mutual silence and voice activity periods to the case when using hangover is not easily done without having access to Brady’s original data. However, I believe that a reasonable estimation could be approximated by simply reducing the mutual silence average and increasing the voice activity period by the hangover time (here 200 ms), i.e., the average mutual silence period would be around 266 ms and the average duration when at least one party is actively speaking would be around 1.6 s for the subjects in Brady’s study. If it was possible to control when handovers occur, we would like a handover to be initiated at the beginning of a mutual silence period. Although one cannot be sure that the silence period will always be long enough to mask any effects of a handover, the probability that the handover will finish with little or no performance degradation is vastly increased. This assumes that the time to initiate a handover can be controlled, and that the handover mechanism can be triggered quickly. • The application will need to inform the link layer when handovers are preferable. That would also require that the link layer can postpone the handover for a few seconds (on average 0.8 s if the link layer would like to start the handover during an ongoing active period). • If the “moving party” is the one talking (and the other party is stationary), the mobile could initiate the handover as soon as the hangover period has finished (e.g., one could utilize the output of the VAD (speech or no speech) as an indication of handover time preference). This would give the mobile about 266 ms on average to finish the handover without packet loss).

2.2. VOICE CONVERSATION PROPERTIES AND EFFECT OF SPEECH INTERRUPTION 23

• If the “remote party” is the one talking, the time to initiate the handover is more difficult to find, since the recipient (the moving party) does not know when the hangover period started. One possible approach would be to analyze the content of the incoming packets to look for long sequences of low energy (200 ms), possibly ended by a silence suppression packet. The voice activity detection method at the sender as well as jitter in network delay may affect the effectiveness of this operation.

2.2.2

Effect of packet loss and loss location

In the end we are interested in the perceived voice quality during handover, and as we will see later a handover may lead to delay or loss of the voice data. In this section we will examine the effect of packet loss on speech quality and intelligibility. When evaluating speech quality it is common to use either subjective or objective evaluation methods. In subjective tests a group of human “subjects” are given the task to rate the quality of a set of (recorded) speech sequences affected by various speech impairments. The rating is commonly a 5 level grading where the values 1-5 correspond to the grades bad, poor, fair, good, and excellent. The rating by the different subjects are then averaged, resulting in a mean opinion score (MOS) for each specific test case. Subjective evaluation is important, but often error prone and very cumbersome to conduct. The alternative to subjective evaluation is to use objective evaluation methods. Such methods are designed to automatically evaluate speech quality according to certain criteria. The idea is that these criteria should model human perception of voice quality. The advantage of these methods is that they can easily be performed, even countinously. As mentioned in the previous section speech sounds are categorized as being voiced or unvoiced. Voiced speech generally contains high energy and is created by vibrations of the vocal cords. This vibration is achieved by passing air through the glottis, and the resulting sound contains a fundamental frequency (often referred to as the pitch period) as well as formants created by the resonance in the vocal tract, and voiced sound is quasi-periodic in the time domain[151]. This is in contrast to unvoiced speech, which is formed by “forcing a steady flow of air at high velocities through a constriction region in the vocal tract to produce a turbulence”[151]. Unvoiced sound generally contain less energy than voiced sound and span a much wider frequency spectrum. Within regions of either voiced or unvoiced sounds, small units known as phonemes can be distinguished. Phonemes are the smallest unit that convey linguistic meaning, e.g., the ’h’ and ’th’ sounds in here and there. In order to avoid losing information in the speech conversation, we could consider the “length” of a phoneme as a critical time duration for packet loss. That is, if we want to avoid losing the meaning of what was said (speech intelligibility) we should not lose a full phoneme. Sanneck specifies that the length of a phoneme is approximately 40-100 ms[151] while Perkins et al. give the interval 5-100 ms[125]. Gruber and Strawczynski[51] have studied the effect of packet loss on speech quality using subjective methods. Three of their results that are relevant

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

to our study are: • For the same occurrence frequency, longer loss bursts lead to worse quality. (This is of course what one would intuitively expect.) • For a fixed loss percentage, the subjects tended to prefer frequent very short losses (16 ms) rather than less frequent longer (64 ms) losses. This indicates that the perceived quality degrades when entire phonemes are lost. • When comparing longer losses the subjects preferred a few long losses (256 ms) rather than frequent but shorter (64 ms) losses. A possible reason for this (somewhat unexpected) preference could be that the subjects were asked to rate speech quality and not speech intelligibility. The effect of the loss position relative to voiced and unvoiced segments has been the studied by Sun et al.[163] and Le[89]. Loss of voiced audio segments, in particular the data packets at the beginning of such a segment, can have a major effect on the perceived performance while users are more tolerant to loss of unvoiced speech. The extent of the impact depends on the size of the burst loss and CODEC type. Waveform CODECs have less convergence time[151], while vocoders which carry more state in the first packet of a voiced segment will require a longer time to converge if that packet is lost. We have earlier suggested that handovers could be triggered during periods of mutuals silence to mask the effects of disconnectivity to the users. If the handover execution is still in process when the mutual silence periods ends we risk losing the initial frames of the next speech segment. Losing audio data during a handover can be difficult to avoid, but in order to limit the effect of the loss it seems desirable if waveform encoding (with fast convergence) be used during periods when handover is likely to occur. If appropriate link layer support exists (as discussed in section 2.2.1) it would be possible for the mobile to use different CODECs when it is about to make a handover than when it is not. In order for the remote party to change CODEC when the mobile is about to move one could either (a) use the mobile’s change of CODEC act as a hint, or (b) use explicit signalling, possibly by adding appropriate extensions to the RTCP[154] protocol. To sum up we would like to limit loss of data to approximately 40 ms to avoid loss of complete phonemes. This can be compared to commercial wireless systems, e.g., [93] states that “most ATM-based 3G voice cellular protocols try to keep total voice handover delay less than 40-80 msec”. Although we aim for such short interruptions we will later see Internet users will occasionally have to face longer handover delays (Vakil et al.[170] gives that 2-3 seconds as upper bound for interruption during handover).

2.3

Forward Error Correction (FEC)

To recover from packet loss there are two different methods available: Forward Error Correction (FEC) and error concealment (also referred to as packet loss concealment (PLC)). FEC involves both the sender and the receiver – the sender

2.3. FORWARD ERROR CORRECTION (FEC)

needs to send redundant data, which the receiver can use to recover lost data in other packets. Conversely error concealment mechanisms occur local to the recipient and include different algorithms to estimate lost voice data by looking at previous (and perhaps also future) data in the voice stream. FEC and concealment are complementary techniques and should be used in combination to achieve the best possible voice quality. This section examines FEC, while error concealment is covered in section 2.7.

2.3.1

Overview of FEC methods

When FEC the sender sends redundant information which the receiver can use for loss recovery. Such techniques are commonly used to detect and recover from transmission errors on a bit-level, e.g., by adding a parity bit to an ASCII character when doing asynchronous transmission over a serial line. Here we are interested in using the same kind of mechanisms, but use them to recover from lost packets rather than single bits. For example one could send a parity packet for every k data packets where each bit in the parity packet would be formed by “XOR-ing” the respective bits of the preceding k data packets. The FEC mechanisms used to recover the loss of whole data packets are often classified as being media independent or media dependent[125]. Examples of media independent FEC are parity check and Reed-Solomon codes, where k data packets result in the transmission of n packets, and are able to recover n − k lost packets for every n transmitted packets. Although Reed-Solomon codes have several desirable properties (as do other media independent FEC mechanisms) these codes imply significant additional delay at the receiver for large values of ’k’ and ’n’. This makes them inappropriate for interactive applications such as IP telephony. With media dependent FEC the sender sends one or more copies of the same voice data, possibly using different CODECs for the first and the later copies. An example is when the audio segment is first transmitted with a primary encoding of high quality, and then a highly compressed version of the same segment (using a secondary encoding) is piggybacked onto the next packet. This type of media dependent FEC is referred to as low bit-rate redundancy (LBR)[76]. However, there are good reasons for using the same CODEC for the different copies of the audio data: • It is straightforward to substitute a lost frame with a copy encoded with the same CODEC, while recovery is more difficult using general LBR schemes. If the secondary encoder is a (stateful) “synthetic” vocoder the secondary encoder will lose its synchronization when a prior packet is lost[125, 151, 76]. Jiang and Schulzrinne address this by re-encoding the secondary encoding carried in the lost packet at the receiver[76]; however, this adds to the complexity of the receiver. • The additional overhead of duplication can be relatively small, especially when considering the size of the RTP/UDP/IP headers[76]. • Using two CODECs adds complexity and increases the processing requirements. In contrast, when using the same CODEC you have already used for encoding simply repeating the data requires little additional processing.

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

Therefore we suggest the usage of “media dependent FEC using the same CODEC for the primary and secondary encoding”. We can denote our suggestion as “media independent FEC with a simple parity check (k = 1, n = 2)”, recognizing that this special case of media independent FEC sends an identical packet for every data packet. Jiang and Schulzrinne[76] compares media independent3 FEC(k,n) with LBR, and argues for the use of media independent FEC. Thus, our suggestion is consistent with their proposal when FEC(2,1) is used, i.e., a simple parity check. As mentioned above, other media independent schemes (with larger ’k’ and ’n’) increase the end-to-end delay and are therefore of less interest.

2.3.2

FEC lag suitable for VoIP loss characteristics

If the FEC with the secondary encoding is piggybacked on the next audio data packet it is said to be sent with lag equal to one. Increasing the lag will improve the receiver’s possibility to recover the audio segments during periods of burst losses as shown by Hardman, et al.[57]. The main drawback with longer lags is that the end-to-end delay generally increases if the receiver wants to be able to take advantage of the FEC data; however, the amount of delay added by FEC depends on the interaction between the FEC and the play-out buffer management. This will be examined further in section 2.6.3. In general we want to select a short lag to achieve low end-to-end delay, but not so short that we fail to recover from the most common loss patterns. The loss characteristics for voice-like traffic over the Internet has been investigated in several studies[24, 25, 184]4 . According to these studies losses appear to be correlated rather than random and packet losses are therefore often modeled as Markov chains with two states (also referred to as a Gilbert model) or more. However, the majority of packet losses are single losses. Therefore we recommend that FEC with lag 1 is used by default to recover from most packet losses, while keeping the effects the end-to-end delay reasonably low. Furthermore, for packet loss bursts of length two or larger the loss burst can at least partially be recovered; for bursts of length two, which is a substantial part of the remaining loss patterns, 50% of the packets can be recovered. Since this thesis is primarily concerned with the performance of mobile VoIP users, the loss patterns due to handovers are of special interest. The loss (and delay) patterns during handover will be examined further in chapters 46. When Alice performs a handover we will see that this results in a loss of connectivity for a short, but non-negligible period of time, and that (in general) packets heading towards Alice are lost and packets from Alice are delayed during this time period. The following can be said about FEC usage during handover: • There is no need for Alice to extend the FEC lag for her outgoing packets at the time of handover. 3 Jiang and Schulzrinne do not use the term FEC when referring to what we call media independent FEC. 4 These studies have not been conducted using WLAN links. However, 802.11 WLAN links perform link-layer retransmissions. Except for losses due to handover, WLAN specific losses will therefore not affect the discussion of FEC support.

2.4. TRANSPORT OF REAL-TIME TRAFFIC

Encoded audio data UDP Hdr

RTP Hdr

RTP Payload

Contains sequence number, time−stamp, payload type indication, etc. Figure 2.7: Encapsulation of encoded audio data using UDP/RTP transport.

• However, the remote party (Bob) should extend his FEC lag (as much as possible with respect to the end-to-end bound) while Alice is performing a handover in order to recover (some of) the lost packets. This implies that Alice should temporarily increase her play-out delay during handover (see also sections 2.6.2 and 2.6.3). Similar to the discussion of CODEC change during handover (section 2.2.2) and the trigger of handover during periods of mutual silence (section 2.2.1), the ability for the remote party to change FEC lag requires the mobile to have appropriate link-layer support to gather hints about an approaching handover, and that it is able to inform the remote party about this.

2.4

Transport of real-time traffic

Real-time media streams generally use the user datagram protocol (UDP[131]) as the transport protocol, although the newer stream control transmission protocol (SCTP[114]) may be the preferred choice for future VoIP applications. The encoded audio frames are first encapsulated into real-time transport protocol (RTP[154]) packets and then into UDP packets, see Fig. 2.7. RTP adds information such as packet sequence number and time-stamp to detect packet loss and enable ordered and timely delivery, and a payload type to specify the payload encoding. RTP is accompanied by the RTP control protocol (RTCP[154]) which enables Alice and Bob to exchange session quality information, etc. A call between Alice and Bob will consist of two RTP sessions, one in each direction. An RTP session is defined by the destination transport address, i.e., the destination IP address and UDP port number when using UDP transport. The RTP header also contains synchronizing source (SSRC) and contributing source (CSRC) identifiers enabling a receiver to distinguish the source of an RTP packet in multi-party communication sessions and in presence of mixers[153]. As defined an RTP session is independent of the sender’s IP address and UDP port number, thus Alice can change IP address during a call and continue to send audio data to Bob without modifying the RTP stream in that direction. In practice Bob may have issued a UDP socket “connect” system call, which usually implies that he will only accept packets from a certain source address/port pair. However, this property will affect layer-3 mobility performance as will be discussed in section 6.5.3.2. The reason for “connecting”

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

a UDP socket is due an idiosyncrasy of the Unix socket interface where a UDP socket must be “connected” to enable delivery of ICMP destination unreachable messages. Stevens[161] provides further details on and a solution to this issue. RFC 2198[121] specifies an RTP profile enabling RTP to carry multiple audio frames in the same RTP packet, the purpose here is to support FEC (see section 2.3). In this case the payload type in the original RTP header indicates the encapsulation of “multiple RTP payloads” each carrying its own payload type field specifying the encoding. In chapter 3 we will introduce an additional RTP profile for media protection, specifically secure RTP (SRTP[18]).

2.5

Network delay

Internet is a packet switched network and as such packets belonging to the same audio stream will generally experience variable delays as studied by Bolot[24] and Marsh[99]. IP provides an unreliable datagram service where each packet is routed individually, and may arrive at the receiver out of order, duplicated or not at all. The delay-bound for interactive real-time voice services such as IP telephony is therefore more difficult to meet in a best-effort network such as the Internet. Protocols for resource reservation (RSVP[27]) and differentiated services (Diffserv[22]) have been standardized for improved quality of service (QoS) in IP networks. Additionally, the IEEE 802.11 Task Group E (TGE) is working on QoS enhancements specifically for WLAN links. Nevertheless, in this thesis we will that IP telephony is possible over the Internet without relying on these QoS improvements. The complexity of QoS protocols will make them difficult to deploy, and the increasing use of broadband access is removing the access network as the source of bottlenecks for VoIP.

2.6

Handling jitter at the receiver: play-out buffer algorithms

To handle the delay variation introduced by the network, the receiver uses a play-out buffer, also referred to as a de-jitter buffer. Arriving packets are decoded and placed at the proper location in the buffer according to their RTP timestamp. The buffer introduces a play-out delay, so that each audio sample in the audio packets can be played out at the same rate as they were generated, thereby masking network jitter . Packets arriving after their scheduled playout time are considered lost, thus there is a tradeoff between low end-to-end delay (low play-out delay) and low packet loss rate (high play-out delay). Packet voice applications can utilize fixed or adaptive play-out buffer algorithms. With fixed play-out buffering a fixed delay will be added to packets, i.e., without considering changes in delay jitter characteristics of the network; while adaptive play-out buffer algorithms adapt the play-out delay on a “per talk-spurt” basis[138, 107, 54]. Since low end-to-end delay leads to better perceived audio quality[37], hence we assume the use of adaptive play-out algorithms.

2.6. HANDLING JITTER AT THE RECEIVER: PLAY-OUT BUFFER ALGORITHMS

t1k t2k

t1k+1 t2k+1

t kk

Sender

Receiver

time

arrival play−out

time n

p1k p2k

p kk

p1k+1p2k+1

p kk

Figure 2.8: Scheduling play-out delay per talk-spurt (based on a similar figure in [107]).

2.6.1

Adaptive play-out buffer algorithm principles

With adaptive play-out buffer algorithms the play-out delay is adapted on a “per talk-spurt” basis. This assumes the use of silence suppression between talk-spurts. The following description is based on [107, 138]. The receiver (Bob) estimates the delay (uˆ ik ) and variation (vˆik ) per packet i and talk-spurt k. When the first packet in each new talk-spurt arrives at Bob the play-out delay pˆ k is estimated as: n

k−1 k−1 + βvˆ k−1 pˆ k = uˆ k−1

(2.3)

where β is variation coefficient (larger β implies longer play-out delay, but less packet loss due to late arrival). The play-out point for subsequent packets (j) in the same talk-spurt are computed as an offset from the first packet (i) equal to their difference in RTP time-stamps. j

pˆ k = pˆ k + tk − tik

(2.4)

The play-out delay is only recomputed at the beginning of each talk-spurt, although the variables (uˆ ik ) and (vˆik ) are updated at the arrival of each packet. The way to update these variables and the selection of a variation coefficient (β) differs between adaptive play-out algorithms. These play-out algorithms do not require synchronized clocks and only base their calculation of play-out delay on delay variation. Thus, the playout algorithm at Bob is unaware of the actual end-to-end delay perceived by Bob. Forcing the algorithms to consider the actual end-to-end delay, e.g., in order to keep the delay below 180 ms([37]), would require clock synchronization between Alice and Bob, which is a non-trivial problem examined by Montgomery[106]. An alternative would be to utilize the network time protocol (NTP[103]); however, we leave this for future work.

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

2.6.2

Handling sudden delay spikes

In chapters 4-6 we will study the impact on a voice stream when Alice performs a handover during a call to Bob. As we will see, this may lead to delay spikes for packets from Alice to Bob and loss of packets in the reverse direction. If the handover occurs while Alice is silent Bob will (of course) not notice any delay spike. However, if Alice is talking during a spike, then two scenarios can occur: • Talk-spurt starts first: If Alice performs the handover while talking, then Bob will lose packets in the delay spike. The play-out delay will be set at the start of talk-spurt, thus the algorithm will be unable to adapt to the sudden increase in delay for the remainder of that talk-spurt. (This playout deadline violation problem is mentiond by Perkins and Koodli[85].) • Handover starts first: If Alice starts to talk while the handover is in progress, the first packet in the talk-spurt will be at the head of the delay spike. The following packets are likely to arrive shortly thereafter leading to a linear decrease in the delay spike. To address the second case Moon, et al.[107] describe an adaptive playout algorithm aiming to handle such delay spikes efficiently. It uses two modes, a normal mode when play-out delay for a talk-spurt is computed as in equation 2.3, and a spike mode where the play-out delay is set to the delay of the first packet in the talk-spurt. To address the first case Alice needs additional link layer support: • Hints from the link-layer: If Alice receives a hint from the link-layer about an upcoming handover, she could notify Bob to temporarily increase his play-out delay. Alice and Bob could either utilize some proprietary protocol to exchange such notifications, or utilize appropriate extensions to RTCP. This idea is not explored further in this thesis, but is left as future work. • Hints to the link-layer: If Alice is (to some extent) able to control the time when handover is triggered, her SIP user agent could ask the link-layer to delay the handover until immediately after finishing her talk-spurt. If Alice generates another talk-spurt it would occur after the handover has started and the play-out algorithm by Moon et al.[107] would handle the resulting delay spike. Exploring this idea is also left as future work. In some mobility management schemes (in particular the micro-mobility management schemes described in chapter 6) an entity at Alice’s previous location can forward data to her new location after a handover. This would lead to a sudden, temporary increase in the network delay, but now for the traffic going from Bob to Alice. To avoid losing this data due to late arrival we suggest that Alice also increases her play-out delay temporarily while performing the handover when such micro-mobility schemes are in use. This assumes Alice receives hints about upcoming handovers from the link-layer.

2.6.3

FEC and play-out buffer algorithms

How FEC and play-out buffer algorithms should be used differs between when Alice is about to perform a handover and when she is not. We first consider

2.6. HANDLING JITTER AT THE RECEIVER: PLAY-OUT BUFFER ALGORITHMS

the case, specifically when Alice is not moving. In Fig. 2.8 we see how the play-out delay can be adjusted per talkspurt without using FEC to recover lost packets. However, if the play-out buffer algorithms only compute a play-out delay just large enough for most “original” packets to arrive in time to be played, then the “redundant” packets (piggybacked in some later packet) risk arriving too late to be useful. In order to take advantage of FEC the play-out delay needs to be increased: • Purely additive FEC lag: If the adaptive playout buffer algorithm bases its play-out delay computations on the “redundant” FEC copy rather than the “original” data, thus the increase in play-out delay in would be equal to the FEC lag. One should notice that the first packet in a talk-spurt may not include any redundant data (at least not of interest when computing the play-out delay of the new packet), since that would correspond to an earlier talkspurt. Being aware of the FEC lag in use, the receiver would be able to add it to the play-out delay computation. • Variable additional delay: Rosenberg, et al.[149] present an optimization where the play-out delay is increased more during periods of high loss rates than during low loss rates, thus the receiver should wait for FEC copies when there is higher chance of needing them. Here the additional delay would be less than or equal to the FEC lag. In section 2.2.1 we mentioned that silence suppression schemes may suffer from front-end clipping. When detecting voice activity some voice applications therefore send a stored copy of the last (suppressed) audio packet, thereby “extending the talk-spurt backwards”. This means that the first two audio packets in the talk-spurt will generally arrive close together while the arrival intervals of the following packets will depend more on the interval at which audio packets are generated (see section 2.1.1). When using this approach to avoid front-end clipping, the first audio packet experiences a buffering delay at the sender (a kind of “look-ahead” delay) which makes it inappropriate to base the play-out delay computation on. The suggestion proposed here is that the play-out delay should be based on both the first and the second audio packet in the talk-spurt: • We assume that Alice and Bob use a FEC lag of 1. When Alice detects voice activity after a period of silence, she sends a copy of the last suppressed audio frame as a “redundant” FEC copy together with the first audio frame where voice activity was detected (alternatively she could send the suppressed data in a packet by itself, see also the comments below). That is, the RTP payload of the first packet sent to Bob will contain the two first audio packets of the talk-spurt: the second packet as “original” data and the first packet as a “redundant” FEC copy. (Thus, this case differs somewhat from what was stated when discussing “Purely additive FEC lag” above.) • When Bob receives these packets he should utilize both audio packets when computing the play-out delay:

CHAPTER 2. INTERACTIVE AUDIO OVER PACKET BASED NETWORKS

– He first computes a play-out delay ( pˆ k2 ) using the second packet of the talk-spurt in equation 2.3. – If this play-out delay ( pˆ k2 ) enables him to also play the first packet, then it will be used as the play-out delay for this talk-spurt. (He has to check that the play-out time for the first packet has not yet passed.) Otherwise he would use the delay of the first packet as play-out the delay for this talk-spurt (similar to what was done in spike mode as described in section 2.6.2). This case would occur when the jitter experienced between Alice and Bob was so low that the play-out buffer (normally) contained one packet at most. When using this algorithm it would be possible to hide the look-ahead delay used to avoid front-end clipping. However, a problem will occur if the packet containing the two first audio packets was lost. To avoid this situation one could consider sending an additional packet at the start of the talk-spurt, either containing both “packets 1 and 2” or only “packet 1” (i.e., the packet earlier being detected as silence). When Alice is about to perform a handover it would be good if both Alice and Bob temporarily skipped using the adaptive play-out buffering algorithms and instead used a larger (fixed) play-out delay. As mentioned in section 2.3.2 it would be beneficial if Alice could inform Bob to increase his FEC lag accordingly. Having Alice temporarily increase her play-out delay would also be beneficial when micro-mobility management schemes for “smooth handover” are used (as mentioned in section 2.6.2).

2.7

Packet loss concealment

When Alice and Bob use FEC with lag 1 they are able to recover all single packet losses. To fill-in the remaining packet losses the receiver can use packet loss concealment (PLC) algorithms. Perkins, et al. have presented a survey on packet loss recovery techniques including both FEC and PLC approaches[125]. The receiver can independently choose which PLC method to use (if any) and the choice is likely to depend on the receiver’s computing power. A method referred to as repetition with fading is “a good compromise between the other poorly performing insertion-based concealment techniques and the more complex interpolation-based and regenerative concealment methods”[125].

2.8

Efficient end-system implementation

We have earlier discussed the mouth-to-ear delay bound for audio applications. Based on results by Cole and Rosenbluth[37] we aim to keep the delay as low as possible, and if possible avoid longer delays than 180 ms. This constrains our ability to use long FEC lags or long play-out delays to handle network packet loss and delay. When describing the components contributing to the end-to-end delay we have more or less ignored the delay due to audio processing in the end-

2.9. SUMMARY OF AUDIO CHAPTER

nodes. Although such delays are likely to decrease with improved end-system hardware, the delay introduced by current voice applications can constitute a significant part of the end-to-end delay[54]. As with other delay components, delay introduced by the end-system decreases the performance and limits the our ability to use FEC for packet loss recovery. Hagsand, et al.[54] describe methods for efficient end-system implementation and report delay reduction up to hundreds of milliseconds compared to other tested audio applications. They achieve good performance, e.g, by handling the play-out buffering within the operating system (rather than in the application) using the sound card’s memory as a de-jitter buffer. Investigating how their approach can be utilized together with encryption (see chapter 3), various audio CODECs, FEC schemes etc. is an interesting research topic; however, we leave this to future work.

2.9

Summary of audio chapter

In order to reduce the effect of packet loss and unacceptable delay, we believe that the sender should utilize media dependent forward error correction with the same CODEC for the primary and secondary encoding. When each audio packet contains a copy of the previous audio unit as well as the current, the length of the loss burst will be reduced by one (thus, single lost packets will not be noticed) at the price of a somewhat longer playout delay and some additional per per-packet overhead. The effect of remaining losses could be reduced by using loss concealment methods at the receiver (what scheme to use will depend on the CODEC in use). However, since FEC and concealment methods are unlikely to recover all packet losses related to handovers, we should also try to trigger handovers at times when there is no audio traffic or when the audio traffic contains “less important” audio data. Ideally, remaining packet loss bursts should be shorter than the length of a phoneme, i.e., around 40 ms or less. Even though users may occasionally have to accept longer loss bursts during handover, the intention should be to conduct most (or all) handovers within this delay bound. The audio data units encoded by the sender’s CODEC will be delivered in RTP packets to the receiver. To provide end-to-end confidentiality and authentication of the audio data a specific RTP format, secure RTP (SRTP), could be used as an alternative to IPSec, which provides a similar service at the network layer. Details of how to establish VoIP sessions protected by SRTP or IPSec will be presented in the next chapter. The receiver uses a playout buffer to handle the delay variation (jitter) of the incoming packets, and will play the samples that arrive in time at roughly the same rate as they were generated. Unlike traditional telephone systems where every device is synchronized to a single (atomic) clock, our devices are not globally synchronized (nor need they be). To achieve the best possible audio quality the playout buffer algorithm should be able to adjust the playout point based on recent network characteristics, thus avoiding unnecessarily long buffering delays. The silence periods between the talk-spurts can be used to adapt the playout point and also to adjust for clock drifts between the two (or more) parties. The delay introduced by the end-systems is also related to the efficency of the end-system implementation.

Chapter 3

Using SIP to establish a secure phone call In this chapter we will examine VoIP security. The primary objective is to describe how the media streams between Alice and Bob can be protected, and how such a secure call can be established. The solutions we introduce for VoIP security will have an impact on the mechanisms set to manage mobility between IP subnets, as will be seen in chapter 6. In addition to the purely handover related aspects there are other implications of VoIP security that influence the overall system; it is of particular interest to describe the various actors in VoIP (i.e., VoIP users and SIP providers), what security associations will be required to establish a secure VoIP call, and what authentication infrastructure will be needed to achieve this. In this chapter we will first describe the VoIP call establishment procedure when using the session initiation protocol (SIP[147]) as signalling protocol, see section 3.1. Based on this, section 3.2 gives an overview of VoIP security issues and approaches to address these issues. Section 3.3 describes alternatives of how to protect the media streams in more detail, while section 3.4 examines mechanisms to establish a secure call. Section 3.5 concerns solutions for authentication between various VoIP actors and the related requirements for authentication infrastructures.

3.1

Regular SIP call setup

In this section we describe the procedure to establish a VoIP call (i.e., a bidirectional RTP stream) between two Internet users, Alice and Bob, using SIP as signalling protocol. The main purpose of SIP is to help Alice and Bob to find each other, i.e., to exchange information about the IP addresses and UDP port numbers to use for the bidirectional RTP session. During the call establishment phase Alice and Bob also exchange information about what CODEC(s) to use and other relevant session parameters. Since we only consider VoIP calls between Internet users both Alice and Bob will have an IP phone, i.e., a SIP User Agent (UA) software running on, e.g., a PC, a PDA, or

3.1. REGULAR SIP CALL SETUP

sipB.com SIP−B server

is Reg

trat ion

sipA.com SIP−A server

ion trat

Reg is

Internet

UA [emailprotected]

Figure 3.1: SIP user agents send a registration message to their SIP servers.

a dedicated IP phone1 . As before we commonly use the name of the user, e.g. Alice, when referring to the user as well as when referring to her UA. (Alice could be reachable via different IP phones, thus in general the relationship between Alice and her UA is one-to-many rather than one-to-one). Alice and Bob are identified by their respective SIP URIs: sip:[emailprotected] and sip:[emailprotected]. These URIs are associated with the domain of their SIP providers. In order for a user (Alice) to receive calls she first must register information about her current location (i.e., current IP address or fully qualified domain name (FQDN), etc.) with a SIP server2 at her SIP provider, see Fig. 3.1. Alice could have the name/IP address of her SIP server(s) pre-configured or she could also look up SIP servers in her SIP provider’s domain (sipA.com) using DNS SRV resource records as described in [146]. Fig. 3.2 describes the message exchange carried when Alice wants to call Bob. She enters/selects the URI of Bob (sip:[emailprotected]) and puts this information into a SIP INVITE message which she sends to her SIP server. As shown in Fig. 3.2 Alice may first perform a DNS look-up to find her SIP server, unless she has cached this information during the registration process. In the body of the SIP message Alice has put a payload of the session description protocol (SDP[56]) containing the parameters necessary for the RTP session such as the IP address and (UDP) port number to use to reach her, supported CODECs, etc. Upon reception of Alice’s INVITE message her SIP server in turn uses the same DNS mechanisms to look-up the SIP server of the domain sipB.com and passes the INVITE on to Bob’s SIP server. Bob’s SIP server forwards this INVITE to the IP address and port number (and transport protocol) which he has registered (if Bob registered a domain name rather than an IP address this step may include a DNS lookup). Unless Bob is busy the reception of the INVITE will cause Bob to send a RINGING message back to Alice and generate a local ring tone. Once Bob picks up his phone he sends an OK message including a SDP payload describing his RTP session parameters. 1 If one of the users were attached to the PSTN, then this party’s IP connection would end at the VoIP gateway to/from the PSTN. 2 The SIP server that a user registers with is usually referred to as a SIP Registrar. There are also other types of SIP servers such as SIP Proxy, SIP Redirect, and SIP Location servers. Here we usually refer to them as simply SIP servers or SIP proxies.

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

Alice’s SIP−server

Alice

DIAL

(DNS lookup)

Bob’s SIP−server

DNS lookup (DNS lookup)

INVITE 100 Trying

Bob

INVITE 100 Trying

INVITE 100 Trying 180 RINGING

180 RINGING 180 RINGING

200 OK ACK

200 OK

OFF HOOK

DNS lookup (cache)

ACK ACK

RTP session

Figure 3.2: Establishing a VoIP session using SIP. (The ACK may alternatively be sent directly from Alice to Bob.)

Alice will respond with an ACK message and the RTP session can begin3 .

3.2

Security issues for IP telephony

In the previous section the necessary steps to establish a regular VoIP call between two Internet users was presented. However, in order for IP telephony to be widely adopted we strongly believe that security facilities must be provided. In particular we argue that end-to-end authentication between Alice and Bob is not only possible, but that this initial authentication handshake should also establish session keys, which can be used to protect the subsequent (voice) data stream. We believe that a user (Alice) will associate the term secure VoIP call with properties such as: 1. A call will only be established with the callee she expects. Securing the SIP Registration messages will defeat some of the simple redirection attacks. 3 Alice and Bob should be prepared to receive media packets as soon as they have sent their SDP Offer (INVITE) and SDP Answer (200 OK) respectively. Bob is able to transmit data after sending the 200 OK and Alice is able to transmit data as she receives the 200 OK, see [35] for further details.

3.2. SECURITY ISSUES FOR IP TELEPHONY

To ensure Alice that it is really Bob’s user agent she is communicating with, end-to-end authentication is needed. 2. Charging is done correctly. If charging is desired its correctness is vital, however, we assume that flat rate will be used for Internet calls (fixed monthly cost or free), thus we will not consider this requirement further in this thesis. 3. Unwanted calls will be efficiently blocked to avoid VoIP spamming. If VoIP calls are flat rate (or even a very low rate) one can expect a similar situation for spam phone calls as is currently the case for email spam. However, an authentication handshake at call establishment makes it possible to reject a call automatically based on user preferences. 4. The voice data will be protected against eavesdropping. If Alice initiates a secure call she expects to be able to speak in private with the callee (Bob). The need for this service is probably greater for VoIP than for regular telephony (PSTN), because the possibility of eavesdropping of an IP call is greater, in particular since many (commodity) tools to do this are readily available. Fortunately, session keys to encrypt and integrity protect the (RTP) audio streams can be generated as a side-effect of the authentication handshake. 5. Information about who Alice is calling (or who is calling Alice) should not be revealed by eavesdropping. This security requires that one must encrypt the SIP call setup messages in Fig. 3.2, e.g., by using TLS transport. While an attacker may still be able to guess who Alice is calling, e.g., by inspecting the DNS traffic (if Bob has his own domain) or watching the RTP traffic (if Bob has a fixed IP address), this will not directly indicate whom she has called. 6. Alice’s identity should not be revealed by eavesdropping. This requirement is hard to meet and we do not believe that many users find this property crucial. Even if we are able to protect all SIP signaling from revealing her identity there may be many other ways for a persistent attacker to acquire this information, perhaps by observing other traffic that the user sends and receives. 7. Alice’s identity should be hidden from the callee. A system should allow a caller to be anonymous. By introducing an initial authentication handshake we do not exclude the possibility for callers to be anonymous; however, the callee can reject such calls. Items 1 and 3 are addressed by enabling Alice and Bob to authenticate each other during call establishment. Authentication can be seen as part of a keying protocol used to establish a security association between Alice and Bob, i.e., to negotiate what cipher suite to use, create a (master) session key, etc. This security context can then be used by a security protocol, to encrypt and integrity protect user data, thereby addressing item 4. In section 3.3 the use of IPSec/ESP[81] and the secure real-time transport protocol (SRTP[18])4 to 4 Other security protocols could be used (including proprietary protocols), however as IETF standards IPSec and SRTP are likely to gain high acceptance.

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

Optional RTP Hdr

RTP Payload

SRTP MKI SRTP MIC

Encrypted Recommended

Integrity protected a)

IP Hdr

ESP Hdr

Original IP Payload

ESP Trailer

ESP MIC

Encrypted Integrity protected b) Figure 3.3: Packet formats for (a) SRTP and (b) IPSec/ESP (tunneling mode).

protect real-time audio data is described. In section 3.4 alternative approaches of how keying protocols can be used with SIP to establish a VoIP call protected by SRTP or IPSecis examined. To address the security concerns raised in items 5 and 6 we recommend that SIP messages be secured ’hop-by-hop’ using TLS tunnels between the respective SIP entities, at least on the path between a user agent and his or her SIP server. The usage of TLS to protect the SIP signaling follows the specification of a secure SIP URI (SIPS[147]), although the usage of a SIPS URI implies that all hops between SIP entities (except perhaps for the last between Bob’s proxy and Bob) must be protected by TLS. It is worth noting that the use of the SIPS URI does not imply end-to-end authentication or encryption of voice data – it only specifies hop-by-hop protection of the SIP signaling. It is likely that users will find this neither satisfactory nor intuitive.

3.3

Securing VoIP media - at what layer?

The major question when supporting end-to-end security is what layer should provide this; i.e., the network layer or some higher layer? For reliable data transfers the major alternatives are either IPSec (network layer) or TLS (transport/application layer). For real-time UDP traffic the main alternative is SRTP (i.e., transport/application layer). Although operating at different layers, SRTP and IPSec provide similar services: • Encapsulation format: Fig. 3.3 illustrates both SRTP and IPSec packet formats. SRTP specifies the encapsulation format for the protected RTP packet, as well as what parts of the RTP packet are covered by the encryption and authentication algorithms respectively. Only two fields

3.4. SECURE CALL ESTABLISHMENT

are added: the authentication tag (recommended) and the master key index (MKI) field (optional). IPSec[82] defines two IP headers, the authentication header (AH[80]) and the encapsulation security payload (ESP[81]). Here we only consider IPSec with ESP in transport mode. As opposed to SRTP, use of IPSec/ESP will require additional encapsulation for NAT traversal[83]. However, IPSec aware NATs exist. • Cryptographic transforms: SRTP defines the protocols to use for encryption (the default is the advanced encryption standard (AES) in counter mode (AES-CM[92]) with a 128 bit session key). AES-CM enables the receiver to process the packets in random order, a feature which is desirable for real-time applications where packets are not delivered reliably and thus may certainly be out of order. SRTP also defines protocols to use for packet authentication/integrity protection. The default is HMAC-SHA1[87, 111] using a 128 session key and a 32 bit authentication tag. IPSec does not target any specific application, thus it does not use the same default encryption mechanism as SRTP. However, AES-CM and HMAC-SHA1 are available for ESP[67, 94], thus IPSec should be able to handle real-time voice traffic as efficiently as SRTP. • Session key generation mechanism: SRTP requires a master key to be provided, e.g., using a keying protocol such as MIKEY (see section 3.4.1.1). Based on this master key SRTP can derive the session keys for its security transforms (encryption key, authentication key, and salt). Just as SRTP, ESP relies on a keying mechanism to provide the security association for the communication between Alice and Bob as well as performing user authentication, negotiation of ciphers and establishment of session keys. For this purpose IETF standardized the Internet key exchange protocol (IKE)[58]. Use of SRTP is signalled as a parameter in the SDP message (RTP/SAVP) carried in the SIP INVITE. Using SRTP with the default cryptographic transforms does not affect the end-to-end delay or the end-node processing load significantly as compared to sending regular (non-protected) RTP traffic. Abad presents measurements results showing there is an additional roughly 80 µs end-to-end delay, resulting in a data throughput of 20 Mbit/s when using SRTP on a 700 MHz Pentium III[30]. Although cryptographic performance is implementation dependent, we see no reason why performing the corresponding cryptographic operations with IPSec/ESP (in kernel space) should not perform as well as SRTP.

3.4

Secure call establishment

The previous section described how confidentiality and integrity could be added to the media stream using SRTP or IPSec/ESP provided that the required security association, keys, etc. have already been established. This requires a key agreement protocol, which in turn relies on the existence of a

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

long-term secret between Alice and Bob in order to do mutual authentication. This long-term secret could either be manually configured into Alice and Bob or involve one or more trusted third parties for enhanced scalability. When selecting a keying protocol to use for secure VoIP there are three main issues: (1) which keying protocol to use, (2) if it should be run natively or carried within the SIP signaling packets, and (3) if so, how SIP should carry these keying protocol messages. The alternative approaches have been grouped according to the second issue: in section 3.4.1 we examine solutions where keying messages are carried by SIP (integrated keying) and section 3.4.2 describes approaches where keying protocols are run natively (separate keying).

3.4.1

Integrated keying

When Alice calls Bob she generally does not know his current location beforehand. “Piggybacking” the keying messages in the SIP call establishment signaling messages is therefore a natural approach. SIP is a text-based protocol sharing several similarities with SMTP (and HTTP) and the SIP header contains a MIME content type line, specifying the kind of message(s) carried in the SIP body. We now have the choice of encoding the keying messages (or keying parameters) as SDP attributes, or to use a separate MIME type. We also have the choice between using S/MIME[139] (or other protocols designed for SMTP or HTTP) to protect the keying messages, or use some protocol designed more specifically for VoIP such as the the multimedia Internet keying protocol (MIKEY[7]). We will examine MIKEY and how it can be used as a keying protocol for SRTP and IPSec/ESP in sections 3.4.1.1 and 3.4.1.2, while approaches relying on S/MIME are described in section 3.4.1.3. 3.4.1.1

Multimedia Internet Keying (MIKEY)

MIKEY[7] supports three different authentication mechanisms: shared key, public key, and signed Diffie-Hellman authentication. The negotiation of MIKEY parameters (including authentication mechanism) follows the SDP Offer/Answer model and is integrity protected by the authentication mechanism offered, i.e., a message integrity code (MIC) for the shared key, or a digital signature for the other two mechanisms. Shared key authentication is probably going to be used in early deployments as people can manually exchange secret keys with their friends. To enable secure IP telephony on a larger scale a PKI should be introduced. A likely scenario is that user agents will store a small set of root certificate authority (CA) certificates, just as web browsers do today. SIP providers will probably have certificates signed by one of these root CAs, and these providers will in turn issue user certificates to their customers. Of the certificate based authentication mechanisms signed Diffie-Hellman is preferred, since the public key mechanism likely leads to a longer delay call setup delay (Alice will somehow have to retrieve Bob’s public key before sending the INVITE), and with signed Diffie-Hellman one gets perfect forward secrecy5 5 With

perfect forward secrecy an attacker (Trudy) would be unable to decipher a recorded

3.4. SECURE CALL ESTABLISHMENT

When including certificates in the MIKEY messages the SIP messages become too large for UDP transport (SIP messages larger than 1300 bytes must be sent using congestion controlled transport[147]). For signed Diffie-Hellman one generally has to use TCP or TLS, however, using TLS would be the default choice for users who wish to avoid unnecessary exposure of who they are calling or receiving calls from. MIKEY is an extensible keying protocol capable of exchanging parameters for various security protocols, however, SRTP is currently the only protocol which MIKEY has been standardized to support. Adding an “IPSec/ESP profile” to MIKEY would be a straightforward task as shown by Orrblad[115]. As stated earlier there are two design issues when SIP is used to carry a keying protocol such as MIKEY: how should MIKEY be encoded and which SIP messages should be used to carry the MIKEY messages. We start with the issue of how MIKEY messages should be encapsulated within a SIP packet. As Orrblad[115] points out the approach will differ if MIKEY is used to setup a SRTP or an IPSec connection. Encapsulation of MIKEY messages Current work within IETF suggests the use of SDP key management extensions to carry MIKEY messages (as well as other keying mechanisms) within a new SDP attribute, the “key-mgmt” attribute[12]. This works fine when using MIKEY as keying protocol for SRTP, however, when MIKEY is used with IPSec/ESP Orrblad[115] argues that a SDP attribute is not the right location for a MIKEY message. To use MIKEY as keying protocol for IPSec/ESP Orrblad suggests that the MIKEY message is encoded as a multi-part MIME message in the SIP body. Both alternatives are described below: • MIKEY message as SDP attribute: Within the MMUSIC IETF WG work is in progress to define a SDP key management attribute (key-mgmt) attribute enabling Alice to offer Bob one or more keying mechanisms during the connection establishment[12]. Although more than one keying protocol could be offered in parallel, most effort has been focused on MIKEY. Fig. 3.4 shows how the “key management attribute” could be used to offer three keying protocols (MIKEY and two others) in SDP. Each attribute carries the data for the key management protocol being offered (encoded in base64). The “key-mgmt” attribute works well when MIKEY is used to establish SRTP sessions, however, as described by Orrblad the “keymgmt” attribute as specified is tightly connected to the media transport and therefore unsuitable for IPSec/ESP[115]. Orrblad suggests the introduction of a “new” SDP attribute, which should be independent of the media transport, but otherwise similar to the “key-mgmt” attribute. • MIKEY message as MIME payload: Instead of carrying the MIKEY message in an SDP attribute, Orrblad suggests that the MIKEY message is carried as multi-part MIME body as the preferred solution when conversation between Alice and Bob even if she at a later stage would gain access to their private keys.

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

establishing IPSec/ESP connections. To have MIKEY messages carried as a MIME payload a corresponding MIME type has to be registered. The feasibility of this approach has been demonstrated by implementing support for this in minisip6 user agent[115]. 3.4.1.2

Mapping MIKEY messages to SIP messages

Whether MIKEY messages are carried as SDP attributes or as a multi-part MIME body we need to decide which SIP messages should be used to carry the MIKEY messages. Alice will put the MIKEY Init in her INVITE message to Bob, but in which SIP message should Bob put the MIKEY Reply? Below three different alternatives are described, where the last two alternatives assume Alice and Bob have implemented support for reliable provisional acknowledgments (PRACKs[146]). • MIKEY Reply in 200 OK: The most straightforward alternative is to put the MIKEY Reply in the 200 OK sent when Bob picks up his phone. This approach is shown in Fig. 3.5 and the SIP messages exchanged are the same as in the regular SIP call establishment in Fig. 3.2. The reason the 200 OK (and not the 180 Ringing) is used to carry the MIKEY Reply is that the 200 OK is sent reliably as opposed to the 180 Ringing provisional response. This mechanism is currently used by minisip and can be used if either (or both) Alice or Bob does not support PRACKs. The advantage of this solution is its simplicity. Note that Bob is able to filter VoIP spam calls, since he authenticates the callee and checks the call against his policy configuration before his phone rings. The drawbacks are (1) that some MIKEY and SRTP/IPSec setup processing takes place after Bob has picked up his phone, which can lead to clipping effects at the beginning of the call, and (2) that Bob may suffer from ghost ringing if Alice for some reason rejects his MIKEY Reply, and thus the call. Although we expect this to happen only rarely, it may happen if 6 The

minisip SIP user agent, http://www.minisip.org.

v=0 o=alice 2891092738 2891092738 IN IP4 lost.example.com s=Secret discussion t=0 0 c=IN IP4 lost.example.com a=key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO... a=key-mgmt:keyp1 727gkdOshsuiSDF9sdhsdKnD/dhsoSJokdo7eWD... a=key-mgmt:keyp2 DFsnuiSDSh9sdh Kksd/dhsoddo7eOok727gWsJD... m=audio 39000 RTP/SAVP 98 a=rtpmap:98 AMR/8000 m=video 42000 RTP/SAVP 31 a=rtpmap:31 H261/90000 Figure 3.4: SDP key management extension example (from [12]).

3.4. SECURE CALL ESTABLISHMENT

Alice Dial Ringing Delay

Bob INVITE (M

IKEY Init)

180 Ringing EY Reply)

Verify MIKEY, Check Policy

200 OK (MIK ACK

Verify MIKEY, Check Policy Phone rings Off hook

Figure 3.5: MIKEY messages in SIP INVITE and 200 OK

Alice’s policy check does not accept the credentials Bob presents7 . (If Alice wants to reject a call before it has been established she can do this by sending a CANCEL message to Bob.) • MIKEY Reply in a SIP Provisional Response: To avoid clipping effects due to cryptographic processing at the start of the media session and to eliminate the risk of ghost ringing the SIP UAs should implement support for reliable provisional acknowledgments (PRACKs[146]). Two approaches are presented (note only the second eliminates the risk of ghost ringing): – MIKEY Reply in 180 Ringing: If Alice announces PRACK support in her INVITE Bob could send the MIKEY Reply in the 180 Ringing message, see Fig. 3.6. Alice would be able to send her PRACK immediately; as opposed to the next example she has no reason to wait for the outcome of the MIKEY verify and policy processing. As compared to the prior case Alice will experience a somewhat longer Ringing delay, since Bob has to construct his MIKEY Reply before sending the 180 Ringing message. This should not constitute any problem since Alice should be less sensitive to delays before she gets a local ringing tone as opposed to clipping effects at the beginning of the call. As in the previous case Alice can send a CANCEL message to Bob if she rejects the MIKEY Reply (this would happen after she sends the PRACK. As Bob’s phone starts to ring at the time he sends the MIKEY Reply this solution still suffers from ghost ringing. – MIKEY Reply in 183 Session in Progress: To eliminate the risk for ghost ringing the MIKEY Reply can be sent in a 183 Session in Progress message and that Bob’s phone rings first when the corresponding PRACK arrives. Although this will increase the 7 Examples of situations when Alice can reject Bob’s credentials is if his certificate has expired, if she would be unable to find a valid trust path of his certificate, or if there is a mismatch in MIKEY time-stamps.

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

Alice Dial

Ringing Delay Verify MIKEY, Check Policy

Bob INVITE IKEY Supported(M : 100rel Init)

Verify MIKEY, ) Check Policy Create MIKEY Reply

ply (MIKEY Re 180 Ringin0g0rel Require: 1

Phone rings

PRACK ACK)

200 OK (PR

VITE)

200 OK (IN ACK

Off hook

Figure 3.6: MIKEY messages in SIP INVITE and 180 Ringing

Bob

Alice Dial

Ringing Delay Verify MIKEY, Check Policy

INVITE IKEY Supported(M : 100rel Init) EY Progr. (MIK 183 Sess. inequire: 100rel REPLY) R

Verify MIKEY, Check Policy Create MIKEY Reply

PRACK ACK) 200 OK (PR 180 Ringing VITE)

200 OK (IN

Phone rings

Off hook

ACK

Figure 3.7: progress

MIKEY messages in SIP INVITE and 183 Session in

3.4. SECURE CALL ESTABLISHMENT

Ringing delay even more, this should be the most appropriate way to send the MIKEY Reply. In order for this approach to work Alice has to wait until she has accepted Bob’s reply before she sends the PRACK. (If she rejects the message she should as usual send a CANCEL). 3.4.1.3

Using S/MIME to protect keying:

In the previous sections the use of MIKEY as a keying protocol was examined, as well as various methods of how MIKEY messages should be integrated with the SIP call establish signaling. In this section two approaches where S/MIME is used to protect the keying messages are we briefly presented. The second approach suggests using “unauthenticated” MIKEY as keying protocol by relying on S/MIME for protection. Using S/MIME with the SDP “crypto” attribute Within the MMUSIC IETF WG work is in progress to define a SDP “crypto” attribute to hold security parameters for SRTP[5], relying on some external security protocol such as S/MIME or TLS to protect these parameters. The main drawback with this approach compared to MIKEY (with signed Diffie-Hellman) is that it lacks support for perfect forward secrecy. Using S/MIME with MIKEY Bilien has suggested the use of S/MIME and MIKEY8 , where MIKEY/Diffie-Hellman is used for keying and security parameter exchange (SRTP or IPSec), and S/MIME (instead of MIKEY) is used “externally” to protect the message. With this approach perfect forward secrecy is achieved for the protected media session and one gets a uniform way to achieve end-to-end security of MIKEY as well as other parts of the SIP message. For example, S/MIME could protect the SDP message and relevant fields of the SIP header[128] in addition to MIKEY. The SIP messages would be smaller, since a single certificate9 is used to protect all the desired parts of the SIP message. It would also avoid interoperability issues occurring when both S/MIME and MIKEY each carry certificates, there are questions as whether the certificate identifiers must match or not. Unfortunately MIKEY currently only allows “external” protection of the MIKEY message when using pre-shared key authentication (“null” key). If “null authentication” becomes available for MIKEY/Diffie-Hellman the combination of S/MIME and MIKEY/Diffie-Hellman would be the preferred choice of keying mechanism for VoIP.

3.4.2

Separate keying

As an alternative to using SIP as a carrier of keying messages, Alice and Bob could use an existing keying protocol and run it natively between each other. 8 Discussion on the IETF MSEC WG mailing list, March 2005 (subject “MIKEY D-H + SIP layer signature”). 9 The number of certificates actually carried in the SIP message would vary if a single or a chain of certificates is transmitted. It is also possible to send URLs to certificates instead of the certificate itself.

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

The main purpose for selecting this alternative would be if IPSec is preferred over SRTP and if, e.g., IKE or KINK[164] is preferred over MIKEY as a keying protocol for IPSec. However, even if Alice prefers to run IKE (natively) she still relies on SIP to find the location of Bob, since she only knows his SIP URI ([emailprotected]). Below three approaches are described for how IKE could be used together with SIP to establish a secure call: • Regular call establishment: Alice starts by establishing an insecure call to Bob (as shown in Fig. 3.2), and runs IKE once the call is established. This is a simple approach, but has several drawbacks. For example, neither Alice nor Bob will know in advance if the other side supports IPSec, and the start of the voice session will either be unprotected or delayed while the IPSec tunnel is being established. • Key agreement using SIP OPTIONS message: RFC 3329[9] specifies a mechanism where Alice could use a SIP OPTIONS message to agree on a what keying protocol to use with her SIP proxy. One could consider a similar approach, where negotiation of keying protocol was done between Alice and Bob instead of between Alice and her SIP proxy. In short this would mean that an initial SIP OPTIONS/200 OK exchange would take place between Alice and Bob via the SIP proxies (similar to Fig. 3.2). Alice would learn Bob’s address from the SIP Contact header and is thus able to setup an IPSec connection to Bob. Further SIP signaling (e.g. INVITE) as well as media streams can be sent directly between Alice and Bob. • Using SDP Security Preconditions: RFC 3312[34] describes a generic framework for preconditions with SIP and is designed to address situations where Alice and Bob need to run a separate protocol end-toend (e.g. RSVP) before the session can be established. Within the IETF MMUSIC WG work is in progress to define security preconditions in-line with this framework[6]. However, this current proposal only describes how to signal the use of MIKEY and SRTP (which instead can be done as shown in Fig. 3.7), and does not provide the primitives for Alice and Bob to specify the use of IKE. If the security preconditions framework would support establishment of IPSec connections, then the call setup may proceed as shown in Fig. 3.8. Alice sends an INVITE (via her SIP proxies) to Bob requiring the use of IPSec. Bob responds using a 183 Session in progress message. Both sides will then modify their IPSec policy databases according to the media streams specified by SDP. Alice would start IKE and once the IPSec connection is up she will send a SIP UPDATE to resume the call establishment. If IKE is to be used to establish secure VoIP calls the last alternative is the one most likely to gain acceptance.

3.5

SIP authentication infrastructure

In order to provide secure VoIP calls in a larger context an authentication infrastructure needs to be available. As we will explore in later chapters the

3.5. SIP AUTHENTICATION INFRASTRUCTURE

Alice Dial

Set IPSec Policy DB Start IKE Ringing Delay IKE finished

Bob INVITE in Progress 183 Session PRACK

Set IPSec Policy DB

ACK)

200 OK (PR

IPSec tunnel established

UPDATE DATE) 200 OK (UP 180 Ringing VITE)

200 OK (IN

Phone rings

Off hook

ACK

Figure 3.8: Using security preconditions with IKE/IPSec.

need for an authentication infrastructure exists also for network access control (users, ISPs and roaming agreements, see chapter 5) and would be useful even for IP mobility support schemes (e.g., as a complement to the MIPv6 return routability mechanism, see chapter 6). In an initial deployment stage of secure VoIP solutions the possibility of placing secure public phone calls will be very limited, since most existing VoIP users are unlikely to have user agents with support for this kind of security. The initial need for a global authentication infrastructure will also be relatively limited due to other reasons: • Users may accept manually distributing long-term secrets the for limited number of persons they feel they need to talk securely to. • Users could easily distribute keys to secure a call using, e.g., (unsigned) Diffie-Hellman. Although that would make the call vulnerable to certain active attacks (e.g., man-in-the-middle and impersonation attacks) the achieved security level might very well be perceived as being sufficient for most users. As VoIP becomes more widely used, we expect that the need for an authentication infrastructure will increase. This will enable users to reach (and be reached by) more people and services, while still ensuring that they talk to whom they expect and that their conversation will be secure. Furthermore, since calls over the Internet are likely to be free of charge (i.e., no additional cost beyond the customers’ usual ISP charges) the need for authentication of the caller will

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

increase in order to reduce VoIP spam. An authentication infrastructure will certainly help in such a situation, however, it must be complemented by policy mechanisms to enable the user to specify what callers to accept10 . The authentication infrastructure should contain multiple trusted third parties and could be realized based on either public key or symmetric key cryptography. In this dissertation we have limited our scope to consider only public key cryptography, i.e., the authentication infrastructure will be a public key infrastructure (PKI). This means that Alice and Bob should have certificates issued by a CA, which in turn could be part of a larger PKI. We start by examining who should act as a CA for the users and following that we discuss PKI models suitable for VoIP security.

3.5.1

Certificate Authority for SIP users

There are several possible actors that could take the role of CA for users: SIP providers Having Alice’s SIP provider issue a certificate for her is perhaps the most straightforward solution. Since Alice already needs to establish a security relationship with her provider in order to secure her SIP Registration messages, having the provider issue a certificate for her is a relatively simple matter (especially as Alice could even use the certificate to secure her Register messages). Additionally, there are at least two motivations for having the SIP provider issue Alice’s certificate. • The SIP provider (generally) have control of the domain name part of Alice’s SIP URI. Thus it is natural that they issue certificates for users in their domain name space. • The SIP provider may also provide additional services on behalf of the user, e.g., voice-mail services. If the SIP provider is Alice’s CA, then such services could be managed more easily. Other providers with a relationship with Alice As we will see in later chapters Alice will need to have a security relationship with her ISP (in order to get network access) and also with her mobility provider, i.e., her Mobile IP provider (if Mobile IP is used for layer 3 mobility support). Some other actor There could be various other actors who could act as CAs for users. • In some countries (e.g., Sweden) the citizens can have an electronic “identity card” (e-id) issued by, e.g., the tax office or a bank. In Sweden this e-id is associated with the user’s personal identity number and can be used to sign their yearly tax declaration online among other things. Using this e-id for the mutual authentication of Alice and Bob is an interesting alternative. However, there are some drawbacks that may render this approach less desirable; as users may feel reluctant to expose their personal identity number in order to make phone calls, and the scheme may not be general enough to include calls between citizens of different countries. 10 An ongoing Master thesis project on the topic “Caller and Callee preferences for secure VoIP” is mentioned in section 1.3.1.

3.5. SIP AUTHENTICATION INFRASTRUCTURE

• Additionally, there may be companies specialized in CA operation. These companies may be interested in acting as CAs for SIP customers. • There are global initiatives to provide third party authentication for web services, in particular Passport11 (by Microsoft) and the liberty alliance12 . • Alice could use a SIP URI with a domain name part not owned by her SIP provider. She could, e.g., use a domain name of her company or a domain she has registered herself. In this case her SIP provider is only hosting the SIP service for a domain of someone else and the role as CA would left to Alice company or herself respectively. Having the organization controlling the domain part of Alice’s SIP URI act as CA is beneficial, since it enables the use of trust models based on name subordination[126]. In the rest of this dissertation we assume that Alice and Bob use SIP URIs associated with their SIP providers, thus their SIP providers also act as their CAs.

3.5.2

PKI models including SIP providers as CAs

Since Alice and Bob generally cannot be assumed to have the same SIP provider they will not have certificates issued by the same CA. There are several ways that CAs can be arranged in a PKI trust model. Three interesting examples are the “Configured plus delegated CAs”, “Top-Down” and “UpCross-Down” trust models described by Perlman[126]. Configured plus delegated CAs: This is the model used by current browsers. Each browser comes with a set of root CA certificates. Applying this model to SIP security Alice’s and Bob’s user agents would have some root CAs pre-installed. Their own certificates would be issued by their respective SIP provider, which in turn had their certificates issued by one of the root CAs. The major strength of this model is its easy deployment; the major drawback is that security will be lost if even one of the CAs (root or delegated) is compromised. This is no different than the case for web browsers today. Top-down This PKI model would commonly have single root CA pre-configured into the client, which can delegate to other CAs, which in turn can delegate to other CAs, and so on. However, a CA will only be trusted to certify key/name mappings for names in the subtree with the root being that CA[126] (name subordination). This reduces the penalty if some CA in the hierarchy is compromised to that portion of the name space. This PKI model is used by DNSSEC[1], thus DNSSEC could be utilized if this PKI model is desired. However, DNSSEC has not yet been deployed globally and the mechanisms to manage root CA certificates for DNSSEC is still under investigation. Instead of relying on a single root CA the clients could install a set of root certificates for different branches in the name space. 11 Microsoft 12 The

.Net Passport, http://www.passport.net. Liberty Alliance project, http://www.projectliberty.org.

CHAPTER 3. USING SIP TO ESTABLISH A SECURE PHONE CALL

Up-Cross-Down This PKI model assumes a hierarchical name space with name subordination, but the trust model does not assume the existence of global root CAs. Instead Alice starts with her own certificate and her own list of cross certificates to see if she can find a certificate of a common ancestor to Bob. If she cannot do that she will contact her parent CA who repeats the same procedure. One of the main advantages of this approach is that security within an organization can be deployed and controlled within that organization without relying on external CAs. The PKI can be extended incrementally (hierarchically) and/or by cross-certificates. In the latter case the organization need not depend an external root CA organization. We demonstrated the first model (Configured plus delegated CAs) by using it for signed Diffie-Hellman authentication (MIKEY) in the minisip user agent[19, 21]. To simplify certificate verification Alice includes both her own and her SIP provider’s certificate in the MIKEY Init message. If Bob has the proper root CA certificate pre-installed, then verification can be done without searching or downloading additional certificates from some certificate database. For the same reason Bob includes both his and his SIP provider’s certificates in his MIKEY Reply. The additional delay for MIKEY processing will not affect the call establishment significantly; however, the network related delay may increase somewhat since the inclusion of certificates leads to large SIP/SDP payloads, requiring use of TCP or TLS transport. The delay measurements in [19, 21] did not involve any certificate revocation checking. The “Top-Down” and “Up-Cross-Down” trust models are currently being implemented into minsip (see comment on master thesis project on “PKI infrastructures for secure VoIP” in section 1.3.1). Of the presented models the “Up-Cross-Down” model would probably be the model best suited to introduce within organizations concerned about secure VoIP.

Chapter 4

Handover in IEEE 802.11 networks 4.1

Introduction to IEEE 802.11 WLAN

IEEE 802.11b[68] wireless local area networks (WLANs) have had a tremendous market success as a wireless extension to local area networks, replacing wired Ethernet as the access technology of choice in corporate and campus networks as well as at public hot-spots and in home networks. As commonly used IEEE 802.11 can be viewed as a “wireless Ethernet” where the wireless stations (STAs) communicate via an access point (AP) attached to a wired backbone, and the STAs compete for media access by a distributed medium access control (MAC) protocol referred to as the distributed coordination function (DCF). WLANs have so far been used mostly for ordinary Internet services such as web browsing, file transfers, and electronic mail; however, as the usage of IP telephony increases these WLAN networks are increasingly used as cordless telephony systems. In this chapter the IEEE 802.11 handover process and its performance are covered with a focus on IEEE 802.11b. This description is to a large extent based on material from the IEEE 802.11 specification[68], and upon practical tests presented in a separate study[176]. The system under study is a mobile STA performing a handover between two (bridging) APs attached to the same LAN, i.e., a layer-2 handover. The purpose is to describe the message exchange taking place for a pure layer-2 handover, and also to present data about the related communication interruption interval, i.e., the layer-2 handover delay. The results in this chapter form the basis for the more advanced configurations presented in the following chapters. The results in this chapter can also be used to model the performance in bridged WLAN networks without admission control mechanisms. As part of the IEEE 802.11 handover process the mobile STA will conduct both an authentication and a reassociation message exchange. The standard specifies a mechanism by which the APs can authenticate the STAs using a shared key during this authentication phase[68]. The same key can also be

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

used to encrypt and integrity protect the data being exchanged between the STA and AP, using a technique known as wired equivalent privacy (WEP). It has been shown[180, 179, 26] that the IEEE 802.11 security mechanisms contains several security flaws, and therefore we do not consider this shared key authentication or the WEP encryption and integrity mechanisms here. Layer2 security and access control are instead assumed to be handled either by the IEEE 802.11 security enhancements developed by the IEEE 802.11 Task Group I (IEEE 802.11i[70]) or by the related Wi-Fi Protected Access protocol (WPA[183]) developed by the Wi-Fi Alliance. The usage of either WPA and IEEE 802.11i will imply that a set of additional messages will be exchanged after the IEEE 802.11 reassociation phase, and their affect on the layer-2 handover delay will therefore be analyzed separately in chapter 5.

4.1.1

Assumptions

In this chapter we have limited the scope to in-LAN handover, where all the APs are configured to belong to the same extended service set (ESS). We assume that APs are densely populated and that the STA is configured to take advantage of this (this configuration enables the STA to initiate a handover before losing connectivity with its old AP). We have also assumed that the STA performs active scanning when searching for candidate APs as handover targets. Details of this scanning process are given below. As already mentioned the IEEE 802.11 shared key authentication mechanism is not considered for access control, i.e., open system authentication is used. Our STA has only been equipped with a single WLAN interface. Although use of multiple WLAN interfaces would enable an improvement in handover performance, we assume STAs with a single WLAN interface will be dominant in the market for the foreseeable future. In the tests conducted the data traffic consists of UDP packets with 172 bytes of payload every 20 ms in order to emulate a 64 kbit/s pulse code modulated (PCM) voice stream packetized into 160 byte units plus a 12 byte real-time protocol (RTP)[154] header. These UDP packets are then carried inside IPv6 packets, thus except for the difference in IP header size our measurements should be valid for IPv4 as well. As access points we have used stationary Linux PCs equipped with WLAN PCI cards and the HostAP WLAN driver[66]. This enabled us to initiate handover by controlling the transmission power of the APs instead of physically moving the STA. The outline of the rest of this chapter is as follows. Section 4.2 covers related work regarding other experimental WLAN handover studies. Section 4.3 provides some theoretical background on the IEEE 802.11 handover process and section 4.4 examines issues related to the use of briding APs. Section 4.5 presents the results of the measurements carried out.

4.2

Other experimental 802.11 handover studies

The two main purposes of the experiments which are described here were to establish a suitable test-bed for handover latency measurements and to use this test-bed to measure in-LAN handover latency in IEEE 802.11b WLANs.

4.2. OTHER EXPERIMENTAL 802.11 HANDOVER STUDIES

Other studies concerning measurements of the IEEE 802.11b handover latency include [104] and [178]. My initial aim was therefore to verify their results and to study more complex handover scenarios. However, the experiments were performed in fundamentally different ways, thus the results show both similarities and differences. Subsequent to my study[176], Shin et al. published an experimental study of IEEE 802.11 handover[156].

Mishra et al.[104] measured handovers for a mobile STA, which is moved around in a real WLAN network. The handover is measured by observing the 802.11 management traffic via a set of monitoring machines. They observed that the handover latency is significant and that the probe phase (referred to as the search phase here and in [178]) was the primary contributer to the handover latency (more than 90%). The handover latency was found to depend heavily on the type of WLAN card used, in particular for the STA, but to some extent also the AP. The best combination among the equipment tested (Lucent STA and Cisco AP) showed an average latency of the order of 60 ms. This study also gives a good description of the factors affecting the search phase. The main difference between their experiments and mine is that they do not attempt to transfer any voice data during the handover and therefore miss some of the relevant handover properties. Velayos and Karlsson[178] also measure handover latency by observing the messages exchanged when a STA reassociates with a new AP. In their study the STA actually exchanges data traffic with some host on the wired side of the AP. However, no details of this data traffic were given except that it had “the characteristics of voice over IP”. In their setup they use stationary Linux PCs with PCI WLAN cards as APs rather than commercial APs. To a large extent their study comes to the same result as Mishra et al.[104]. The biggest difference between them is that [178] claims that movement detection is a large contributer to the handover latency. Their study contains a good analysis of the detection and search phases and gives suggestions of how to reduce them. The most significant difference between their study and mine is probably due to the way handover was triggered. In their experiments the power to the current AP is simply switched off, while handover in my experiments is triggered by decreasing the transmission power of the current AP. That is, in their handover scenario the STA suddenly looses connectivity with its current AP, while the STA in my case will begin the handover process before losing connectivity via the current AP. Shin et al.[156] suggests the use of an adjacent AP caching algorithm, which enables them to reduce the impact of the AP scanning phase on handover performance. They present practical measurements for IEEE 802.11b networks utilizing a similar method to mine, e.g., they also transmitted audio-like data at a 20 ms interval during the handover. Except for their AP caching mechanism, they present results that show both similarities and differences with my study, thus I use their study as verification of my results, but will also explain why our results sometimes differ.

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

Internet

Ethernet bridge

ESS

BSS

STA Figure 4.1: A STA about to perform a handover between APs in the same ESS. The APs are attached to an Ethernet bridge (layer-2 Ethernet switch).

4.3

IEEE 802.11 handover process

When a mobile STA is operating in infrastructure mode it will try to associate with an AP in its vicinity. Each AP constitutes a basic service set (BSS) and all the traffic to and from the STA will go via the AP, even traffic between two STAs associated with the same AP. To cover a larger area, multiple APs can be connected via a distribution system (DS) to form an extended service set (ESS). A STA moving out of the coverage area (cell) of one AP could reassociate with another AP (within the same ESS) in the new location, thus performing a layer2 (link layer) handover. APs with overlapping coverage areas are commonly configured to operate on different frequency channels to avoid interference between the cells. The standard does not specify the design of the DS[68], but a commonly used solution is to connect a set of bridging APs via one or several Ethernet bridges as shown in Fig. 4.1. When a STA moves away from its current AP, the signal quality of the messages received from the AP will decrease. At some (configurable) signal quality threshold, the STA will start to look for a better AP to reassociate with, thus triggering a handover. The standard specifies that a STA can only be associated with one AP at a time[68], so there is a risk that communication is interrupted while the STA performs the handover. The duration of the period when the STA in unable to exchange data traffic via its old and new AP is often referred to as the handover latency or handover delay. However, the full definition of the handover latency needs to be done with care. To facilitate this discussion Fig. 4.2 shows the messages usually exchanged as part of a handover. If the mobile STA experiences degraded signal quality in the communi-

4.3. IEEE 802.11 HANDOVER PROCESS

AP (old)

AP (new)

11111111111111111 00000000000000000 00000000000000000 11111111111111111 00000000000000000 11111111111111111 00000000000000000 11111111111111111 Data

1: Probe Request

2: Probe Response

3: Probe Request 4: Probe Response

Probe messages exchanged on different channels

STA detects movement

STA

5: Authentication Request Execution

Selection of new channel and AP

6: Authentication Reply 7: Reassociation Request

1111111111111111111 0000000000000000000 0000000000000000000 1111111111111111111 0000000000000000000 1111111111111111111 0000000000000000000 1111111111111111111 0000000000000000000 1111111111111111111 8: Reassociation Reply

Data

Figure 4.2: Handover procedure as commonly described.

cation with its AP (e.g., by measuring the quality of the received beacons), it will at some point in time trigger a handover procedure to start. If the handover threshold value is configured so that a handover is triggered before connectivity with the current AP is lost, then the time to detect movement will not affect the total handover latency1 . To find candidate APs to reassociate with the STA will start to scan the different radio channels; scanning can either be done passively (by listening for beacon messages from APs) or actively by sending a probe request message on each channel and listening on that channel for probe responses from APs, see Fig. 4.2 messages 1..4 (the STA will send at least one probe request and receive zero or more responses per channel depending on the number of APs on that channel serving the ESS specified in the probe 1 Note that this is in contrast to [178], but since they simply powered off an AP to trigger the handover they could not see the details of a real handover.

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

request). We assume that active scanning is used. This phase of the handover is referred to as as the search phase[178]. When the STA has finished scanning for candidate (new) APs, it will initiate the reassociation procedure with the best candidate AP. This reassociation can be divided into two sub-procedures, the authentication message exchange (messages 5 and 6 in Fig. 4.2) and the reassociation message exchange (messages 7 and 8 in Fig. 4.2). Velayos and Karlsson [178] refer to all of this as the execution phase of the handover. However, to give a more precise description of the execution phase the following should be noted. There are two different authentication methods: open system authentication which uses a 2-way handshake (as shown in Fig. 4.2) and shared key authentication (not considered here) which involves 4 messages between the STA and the new AP. The STA is allowed to authenticate with multiple APs, and the STA can do so while keeping its association with its AP (this feature is known as preauthentication). When subsequently reassociating with the new AP, the STA could also send a Disassociation message to its old AP, notifying it that it is leaving. Neither the pre-authentication feature nor the Disassociation message were observed in the measurements performed in [176]. If we consider Fig. 4.2 and assume that the STA is not able to send or receive any data during the search or execution phases, then the handover latency would be the sum of the search and execution latencies. We make this assumption because existing WLAN hardware commonly only has a single receiver and single a single transmitter; both operating in the same radio channel. However, when analyzing the results of the measurements it was found that Fig. 4.2 did not match the actual message exchange seen on the wireless links, and that the STA actually was able to exchange some data traffic during the period from initiating the search phase until the end of the execution phase[176]. This is shown in Fig. 4.3, which describes the layer-2 handover procedure. This more accurate handover procedure will be referred to from now on. If the STA is continuously transmitting data, these upstream packets will be buffered in the STA during the search and execution phases. Upstream data scheduled to be sent during the search phase may be flushed to the old AP between the search and execution phases or sent to the new AP after the execution phase. I have denoted these phases as the flush phase and the posthandover phase in Fig. 4.3. (Fig. 4.3 also contains an additional message, the link-layer update message, that we will return to in section 4.4.) If we consider the opposite case where the old AP receives (downstream) data for the STA, the AP may buffer these packets if told to do so by the STA (the STA could do this by “telling” the AP that it enters power save mode). After the search phase the STA could notify the AP that it is back in active mode, which would enable the AP to flush buffered data to the STA before the STA enters the execution phase. Unless the STA does the power save mode trick, the AP will try to transmit data frames to the STA as they arrive. What is interesting is that these packets need not necessarily be lost; during the search phase there is a chance that some of these downstream packets may actually get through to the STA. This can happen if the AP sends these frames while the STA is scanning on the channel used by the old AP (marked δ1 in Fig. 4.3).

4.3. IEEE 802.11 HANDOVER PROCESS

AP (old) AP (new)

111111111111111 000000000000000 000000000000000 111111111111111 000000000000000 111111111111111 111111111111111 000000000000000 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 000000000000000 111111111111111 000000000000000 111111111111111 00 11 111111111111111 000000000000000 00 11 00 11 00 11 00 11 00 11 00 11 00 11 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 000000000000000000 111111111111111111 111111111111111111 000000000000000000 Data

1: Probe Request

2: Probe Response

3: Probe Request

Flush

5: Authentication Request

Execution

Selection of new channel and AP

4: Probe Response

Old AP tries to send data (but fails)

δ1

Old AP succesfully sends data

STA sends buffered data Old AP tries to send data

6: Authentication Reply

7: Reassociation Request 8: Reassociation Reply

Post handover

Probe messages exchanged on different channels

STA detects movement

STA

Link−layer update to DS

Data

Figure 4.3: Handover procedure according to measurements presented in [176].

Thus, the exact handover behavior not only varies depending on the hardware (and resident software or firmware) used, but also on whether there are upstream, downstream, or bidirectional data flows during the handover2 . For example, if there is only downstream data during the handover, there will generally3 be no flush phase and post-handover phases. Defining good quality metrics for the handover becomes a bit complex, since it is not only the 2 If the handover takes place between talk-spurts, the users may not notice the handover at all (we discussed this in detail in section 2.2.1). 3 There can be a flush phase for downstream traffic if the power save mode trick is used.

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

time intervals of the different phases that are of interest. The direction of the data flow and the pattern of packets, their correlation with these phases that determines what packets that may get through during these phases are also of interest. Below we give the metrics we find useful for handover measurements, and their corresponding definition as used in this chapter. Definition 1 (L2 handover interval) The handover interval (Thandover ) is time interval when packets scheduled for transmission over the WLAN link can be affected (delayed or lost) due to the STA performing a handover. ✷ Definition 2 (L2 handover data) Those data packets transmitted over the WLAN link or buffered at the STA or (old) AP during the handover interval. ✷ Definition 3 (Upstream delay) The delay imposed on upstream handover data packets. ✷ Definition 4 (Lucky packet) A downstream data packet transmitted by the old AP over the WLAN link during the handover interval that manages to reach the STA. ✷ Definition 5 (Downstream loss) The loss pattern for the downstream handover data packets. Since some of these data packets may actually get through, i.e., lucky packets, we have divided the downstream loss into three sub-definitions: • All scheduled packets (packet all−sched ) which correspond to the number of all downstream handover data packets. ✷ • Observed handover packets (packetobserved ) which correspond to the handover data burst length actually perceived by the applications, which can be less than or equal to packet all−sched . The difference is that packetobserved only counts packets from the first loss to the last lost handover packet (inclusive), while packet all−sched also includes lucky packets at the start or end of the handover data. ✷ • Maximum consecutive handover data packets lost (packetmax−cons ), which corresponds to the longest consecutive loss burst within each handover data. ✷ Note that packet all−sched , packetobserved , and packetmax−cons will all be equal if there are no lucky packets. Furthermore, these numbers depend on the transmission interval for the (audio) data stream and its correlation with the handover. Fig. 4.4 shows packetall−sched , packetobserved , and packetmax−cons for an example set of handover data. Regarding the L2 handover interval (Thandover ) we will approximate it here with the sum of the search, flush, and execution phases, although in some cases (upstream) packets, generated after the execution phase, are delayed due the transmission of buffered handover data. Furthermore, viewing the search, flush, and execution phases as purely additive components of the handover interval need not be true, for example, if terminals have multiple WLAN interfaces or if the terminal had a single WLAN interface with an additional receiver.

4.4. USE OF BRIDGING APS TO SERVE ONE WLAN

lucky

lucky max−consecutive (3) observed (5) all−scheduled (6)

Figure 4.4: An example set of handover data and the corresponding values for (packet all−sched ), packetobserved , and packetmax−cons .

4.4

Use of bridging APs to serve one WLAN

In this chapter we consider handover between APs configured to serve a common LAN via their respective WLAN interfaces, i.e., each AP belongs to the same ESS and a mobile station could reassociate with another AP in the ESS without having to modify its layer-3 configuration. Such WLAN access networks are commonly built by attaching bridging APs to a (switched) IEEE 802.3/Ethernet layer-2 backbone. This is a simple method to provide WLAN access for an organization within a small geographical area, and evaluating the handover performance for this case forms a basis for other, more complex setups. It should be noted that APs can be configured to serve a single WLAN even if they are not connected via a simple (switched) layer-2 infrastructure. The distribution system could be realized using various tunneling techniques for more complex backbone infrastructures, e.g., based on VLAN, MPLS or even “Ethernet over IP” (an example of the latter approach was demonstrated in [38], by using the Unix virtual tunnels (VTUN)4 facilities. The measurement values presented in this chapter, however, assumes a simpler setup as the one shown in Fig. 4.1). In chapter 6 we will cover handover between WLAN APs serving different LANs (and IP subnets). Then the task will be more complex; the mobile station will have to handle issues related to change of IP address, and it will generally need support for performing handover between APs associated with different ESSIDs.

4.4.1

Station cache issue for handover within a LAN

Layer-2 Ethernet switches (bridges) generally keep a station cache holding entries with information about where to forward packets to a certain MAC address. The switches use this facility to filter unicast packets to only traverse those links of the spanning tree that connect the (layer-2) source and destination. Moving a host within a layer-2 infrastructure generally means that the layer-2 switches (i.e., the bridges) will need to have the corresponding 4 Virtual

tunnels, see http://vtun.sourceforge.net.

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

entry in their respective station cache updated (or cleared) before packets towards the mobile station will be forwarded to its current LAN segment. When moving wired PC within a layer-2 infrastructure this does not constitute any major problem (the default station cache timeout value is 5 minutes[71]), however, to support fast handover for mobile stations such delays are not acceptable. The IEEE 802.11F standard[69] specifies the usage of a link-layer update message to update stale station caches in switches of a layer-2 distribution system upon a handover. The link-layer update frame is a layer-broadcast message sent by the new AP to the distribution system on behalf of the mobile station, i.e., the link-layer update frame will use the MAC address of the mobile station as source address. (As I pointed out in [176] it is important to also update any stale station cache in the new AP itself.) One could also consider methods where the link-layer update message was sent by the mobile station itself, however, due to the deployment base of IEEE 802.11 WLAN interfaces, updating the APs seems like a reasonable design choice. Thus, although not part of the IEEE 802.11 standard[68], we have assumed that the new AP sends a link-layer update message to the distribution system upon a successful handover, as shown in Fig. 4.3. As will be seen in the measurements section, the mobile STA in our tests is able to receive packets via the new AP a lot faster than reported by Shin et al.[156]. Even though it is hard to say what caused the delay in their study, it is possible that their AP did not transmit the link-layer update as fast as it should have, or that L2-switches in their distribution system reacted too slow upon receiving the link-layer update.

4.5

WLAN handover tests and measurements

In Fig. 4.3 we gave a general overview of the layer-2 handover process as treated within this thesis. In this section we will present refined descriptions of the handover process, by observing layer-2 handover procedure in situations where the mobile station is actively transmitting or receiving data while moving. The interested reader is refereed to [176] for further details on the measurements conducted. In section 4.5.1 we start by presenting measurements of the case where the mobile STA is the only station associated with the monitored APs. The STA is either sending or receiving a (unidirectional) audio stream during the handover, and two different PC-cards (Lucent Silver or D-Link 650 WLAN PC-cards) were tested at the STA – this would model the case when a STA is performing a handover during a voice call when only one party is talking and silence detection is performed by the other party. (Tests were also conducted with bidirectional traffic during handover, however, the resulting upstream and downstream performance did not differ significantly from what was observed for the unidirectional tests, thus those results are not presented here.) In section 4.5.2 we study the impact of a competing station associated with the AP the STA is moving to. This test was only performed using the PC card (Lucent) that performed best in the prior tests (i.e., section 4.5.1). Section 4.5.3 contains a further analysis and summary of the measurement results.

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS

Tsearch T f lush Texecution T f alse−reassoc. Tnormal−exec. Thandover Tpost−ho1 Tpost−ho2 Tpost−ho3

Upstream Lucent D-Link Mean σ Mean σ [ms] [ms] [ms] [ms] 72.5 7.8 188.7 31.5 1.8 0.0 15.1 0.3 6.7 1.6 7.2 1.5 3.1 1.5 2.4 0.6 3.6 0.5 4.8 1.9 81.0 7.9 211.0 31.7 0.9 0.2 1.1 0.2 7.7 1.1 1.0 0.3 2.1 0.3 10.1 0.2

Downstream Lucent D-Link Mean σ Mean σ [ms] [ms] [ms] [ms] 82.3 13.2 193.6 28.1 NA NA 12.8 0.3 7.2 1.9 7.4 0.7 2.6 1.5 2.3 0.4 4.6 0.9 5.1 0.6 89.5 13.6 213.9 29.2 7.9 5.8 10.4 6.3 19.9 1.1 20.1 1.1 19.6 3.8 19.9 1.1

Table 4.1: Summary of measured delay intervals without competition. Number of handovers were 29 (Lucent Up), 29 (D-Link Up), 30 (Lucent Down) and 29 (D-Link Down); all with data transmission interval of 20 ms.

4.5.1

Handover without competing traffic

The testbed was located in an area with many WLAN APs and users from other WLAN networks. In this section we present measurements of handovers without competing traffic, and by this we mean that the mobile STA was the only station associated with and sending traffic via the testbed APs. However, the measurements have to some extent been affected by the traffic from other, overlapping WLAN cells. Section 4.5.1.1 covers the cases when a Lucent STA and a D-Link STA are sending unidirectional data upstream, i.e., towards a station in the fixed network, with focus on the Lucent STA. Sections 4.5.1.2 covers the corresponding cases when a the STA is receiving downstream data. The handover interval measurements of these four tests are presented in table 4.1.

Smart Hub

AP1

Sniff

AP2

STA Figure 4.5: Basic test-bed layout

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

AP(old)

STA

AP(new)

Data k−1

Flush

Data k Probe Msg (first seen)

Probe Msg (first seen)

Probe Msg (last seen)

False Reass. Normal Exec.

Execution

Data k+1 Reassociation Request Deauthentication Authentication Request Authentication Reply Reassociation Request Data k+2

(To DS) Link Upd. (dropped)

Data k+2

(dropped)

Data k+2

(dropped)

Reassociation Reply Post−ho1 Post−ho2

Data k+3 Post−ho3

Data k+4

Figure 4.6: Handover procedure when sending upstream data for Lucent STA.

4.5.1.1

Upstream data traffic

Measurements when the mobile station was sending data upstreams were conducted both for the Lucent and D-link card, however, since the D-link station performed a lot worse than the Lucent station, see Table 4.1, we have concentrated the discussion here to the Lucent case (see [176] for further details about the D-link upstream test). Fig. 4.6 shows the management and data messages sent over the wireless link when a mobile station equipped with a Lucent Orinoco silver card is sending audio-like traffic during a handover. The most interesting observations are: • The Lucent station sends one buffered packet (k+1) to the old AP in the flush phase between the search and execution phases. The other tested card (D-Link) actually transmitted two buffered packets in the flush phase, and in some tests including competing traffic sources, the Lucent STA often sent even longer sequences of packets via the old AP during the flush phase. This in turn indicates that the search and execution phases can be considered as (relatively) independent tasks, i.e., that a search phase

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS

[ms] ✻ 80 .... 60

[ms] ✻ 80 ....

....

60 ....

....

-20 1

❞

❞ ❞

20 ....

0 ✲ 5 pkt

Figure 4.7: Measured upstream delay (mean ± σ) for Lucent STA (upstream data at 20 ms interval; 29 handovers). The 2nd packet is dropped.

❞

✲ 5 pkt

-20 1

Figure 4.8: Predicted average upstream delay for Lucent STA after some possible enhancements as described below (upstream data at 20 ms interval).

can be executed without having to be followed by an execution phase, and that an execution phase could be run without being immediately preceded by a search phase. Shin et al.[156] also report that their tested STAs send packets to the AP between the search and execution phases, however, no details are given. They use PC-cards with the same chip-set as our D-Link STA (with a different driver version), thus it might be that their STAs also sent two packets just like the D-Link STA. • In these tests the Lucent station (as well as the D-Link station) incorrectly sent a reassociation message to the new AP before authenticating to it. This behavior (which has also been reported for some other WLAN cards[104]) leads to an additional handover delay of 3 ms on average (3.1 ms, see Table 4.1) for mobile station). • The first data packet sent by the Lucent station after the handover was sent using the old AP’s BSSID as the destination MAC address. This not only lead to the loss of this packet, but also to some additional delay for the subsequent packets (head-of-line blocking). Although the last two peculiarities of the tested station resulted in worse handover performance than expected, the overall handover performance was relatively good, in particular when compared to the other card tested. The major difference was that the Lucent station had a relatively short search phase of around 70 ms on average (72.5 ms, see Table 4.1). Fig. 4.7 shows the additional end-to-end delay imposed on packets scheduled for transmission during handover with a Lucent STA (Shin et al.[156] do not present how the handover affects the end-to-end delay of individual packets). As packets were generated every 20 ms to resemble the properties of packet audio traffic, the delay decreased almost linearly; except for the second packet that was lost due to reasons explained above. Fig. 4.8 shows the predicted average delay values if the Lucent STA (1) would have authenticated to the new AP before sending the reassociation message and (2) had sent the first data packet in the post-handover

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

AP(old)

STA

AP(new)

Data k−1 Data k Probe Msg (first seen)

Probe Msg (first seen)

Data (not all lost)

False Reass. Normal Exec.

Data (only occational, always lost)

Execution

Probe Msg (last seen)

Post−ho1 Post−ho2 Post−ho3

Probe Msg (last seen) Reassociation Request Deauthentication Authentication Request Authentication Reply Reassociation Request Reassociation Reply

(To DS) Link Upd.

Data k+l+1 Data k+l+2 Data k+l+3

Figure 4.9: Handover procedure when sending downstream data for Lucent STA.

phase using the BSSID of the new AP as destination address. No data packets would be lost, and for those (three) packets that are affected the imposed delay decreases roughly linearly as a function of the transmission interval. 4.5.1.2

Downstream data traffic

While traffic sent by the mobile station is delayed due to an ongoing handover, downstream data scheduled for transmission by an AP to a mobile station performing handover is generally lost. However, as observed during actual handover measurements all downstream handover data need not necessarily be lost. Fig. 4.9 shows the data and management messages sent during handovers for a Lucent receiving data generated every 20 ms. The most surprising property of the Lucent station was that it was often able to receive one of the packets transmitted to it during the search phase. As shown in Fig. 4.4 this meant that observed handover packets (packetobserved ) and maximum consecutive handover packets were less than the number of packets scheduled for transmission during the L2 handover interval (packetall−sched ). Fig. 4.11-4.13 present the distribution of packet all−sched ), packetobserved and packetmax−cons . The median value of packet all−sched is 4 packets (80 ms of voice), which corresponds

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS

AP(old)

STA

AP(new)

Data k−1 Data k

PS Sleep Probe Msg (first seen)

Probe Msg (first seen)

Probe Msg (last seen)

Flush

PS Up Occasionally (rarely) a packet gets through

Data k+1 PS Up

False Reass. Normal Exec.

Data (lost)

Execution

Data (lost) Reassociation Request Deauthentication Authentication Request Authentication Reply Reassociation Request Reassociation Reply Post−ho1 Post−ho2 Post−ho3

(To DS) Link Upd.

Data k+l+1 Data k+l+2 Data k+l+3

Figure 4.10: Handover procedure when sending downstream data for D-Link STA.

well to the measured average handover delay (search and execution phases) of 90 ms. The interesting result is that the packetobserved and packetmax−cons (which both are of more interest to the user) have median values of 3 packets (60 ms) and 2 packets (40 ms) respectively. The D-link station showed substantially worse handover performance compared to the Lucent station (handover latency average around 210 ms), however, its handover mechanism differed from the Lucent station in an aspect of particular interest for downstream traffic. When the D-Link station performs a handover while receiving traffic, the old AP refrains from forwarding arriving packets to the STA during the search phase. The reason for this is that the D-Link station informs the AP that it enters power save mode at the beginning of the search phase, see Fig. 4.10, and after the search phase the it notifies the AP that it leaves power save mode. Therefore it makes

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

Handovers 16

15 9

10 5

3 1

0 0

9 10 Number of packets

Figure 4.11: packet all−sched : Distribution of packets sent by old AP during handover for Lucent STA (downstream data at 20 ms interval, 30 handovers).

Handovers

15 11 10

5 1

0 0

9 10 Number of packets

Figure 4.12: packetobserved : Distribution of perceived handover data (from first lost to last lost) for Lucent STA (downstream data at 20 ms interval, 30 handovers).

Handovers 16

15 10 6 4

0 0

9 10 Number of packets

Figure 4.13: packetmax−cons : Distribution of longest consecutive loss burst for Lucent STA (downstream data at 20 ms interval, 30 handovers).

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS 20

Handovers

8 6

5 1

0 0

10 11 12 13 14 15 Number of packets Figure 4.14: packet all−sched : Distribution of packets scheduled for transmission by old AP during handover for D-Link STA (downstream data at 20 ms interval, 29 handovers). 1

sense to talk about a flush phase also for the downstream traffic, since the AP has buffered data that it could flush to the STA after the search phase. The problem is, however, that the D-Link station does not wait for any buffered packets to arrive from the AP before it enters the execution phase. Only rarely (2 out of 29 handovers) did any of the buffered packets get through to the mobile station, thus packetobserved and packetmax−cons did not differ significantly from packet all−sched ), see Fig. 4.14. As one can see, a lot more packets are affected (lost) than for the Lucent station. In the median 10 packets were lost, corresponding to 200 ms of voice data. In the conducted tests the sender of the audio stream was located in the same LAN as the receiver (on the wired side of the AP), thus its packets did not experience the same delay variation as if the packets would have to traverse a WAN such as the Internet. The results of the downstream tests performed may therefore have differed somewhat, since packets would not arrive to the AP as periodically in a real network environment.

4.5.2

Competing traffic

This section considers handover performance when there is another STA (associated with the new AP) competing for access to the media. Figure 4.15 shows the modified testbed used for this scenario. A few seconds before the STA performs the handover to the new AP (AP2 in figure 4.15) host H2 started to upload a large file to host H1 (to be precise, it was actually host H1 who downloaded the file from H2 using the wget5 application). Thus, the STA would have to compete for media access in the new cell with host H2 sending large TCP blocks and with AP2 sending TCP acknowledgments. Host H2 was a Dell Latitude CPx laptop with the same characteristics as the STA (Intel Pentium III, 500 MHz 128 MB RAM running Redhat 7.3). H2 had a D-Link 650 WLAN PCMCIA card and was configured to have a low sensitivity (e.g., low AP density) so that it would not “move” back and forth between the APs. Host H1 was a Fujitsu Lifebook C1020 (Intel Pentium 4, 1400 MHz 256 RAM) running Redhat 7.3. 5 See

the Linux wget(1) manual page.

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

Tsearch T f lush Texecution T f alse−reassociation Tnormal−execution Thandover Tpost−ho1 Tpost−ho2 Tpost−ho3

Upstream Mean [ms] σ [ms] 155.2 49.7 3.6 1.2 22.5 14.6 4.3 2.3 18.3 14.6 181.3 46.5 2.1 3.4 45.2 3.2 3.7 2.0

Downstream Mean [ms] σ [ms] 124.1 6.7 NA NA 18.2 6.7 6.7 2.5 11.5 5.9 142.3 7.9 21.5 6.9 15.2 12.2 17.1 7.3

Table 4.2: Measured delay intervals (average and standard deviation) for the different handover phases for a Lucent STA sending either upstream or downstream data, with competing upstream bulk data transfer at the new AP (data transmission interval 20 ms; 5 handovers upstream; 10 handovers downstream).

This test was performed both for upstream traffic from and downstream traffic to the STA, but limited to using the Lucent PC card at the mobile node, since it performed best in the prior tests. Most of the downstream handovers and many of the upstream handovers observed here showed the same message exchange as when testing the Lucent STA without competing traffic (see figures 4.6 and 4.9); what differs here was that the delays involved were longer. We refer to these handovers as “normal” and the delays for the normal handovers for upstream and downstream traffic is presented in table 4.2 (these results will be discussed further in sections 4.5.2.1 and 4.5.2.2). Also of interest is that many of the handovers occurring during the test-runs with competing traffic showed a different behavior then without competing

H1 Smart Hub

AP1

Sniff

STA

AP2

Figure 4.15: testbed layout with competing traffic.

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS

Case 1 2 3 4 5 6

2 2 1 7 1 2

# Handover Early search Long flush Late search Odd (13%) x (13%) x x (7%) x x x (47%) x x x (7%) x (13%) x x

Table 4.3: Characteristics of handover attempts for Lucent STA sending upstream data while facing competition at the new STA. 12 out of 15 attempts led to handover.

traffic. There are three different actions that commonly appear when the STA is faced with competing traffic: Early search phase An early search phase is a search phase at the old AP (AP1 in figure 4.15) that is not followed by any execution phase, i.e., it does not lead to a handover to the new AP (AP2). They are often followed by a new search phase leading to a handover. Actually, early search phases were already observed in some of the tests without competing traffic, but this was rare (once for “D-Link Upstream”, and twice for “Lucent Downstream”); here they occur more often. Long flush phase In the “normal” handovers a Lucent STA (sending upstream traffic) sends one packet in the flush phase. In these tests there were several handovers (especially in the upstream case) when the STA sends/receives multiple packets between the search and the execution phases. We denote this a long flush phase, and it differs from the early search phase described above in that it actually leads to an execution phase. Late search phase A late search phase is a search phase that the STA initiates at the new AP, some time after the handover has occurred. This happened for all cases where the handover contained a long flush phase, but was also observed on one other occasion. Since these three actions affect the delay and packet loss of the audio data, measuring their characteristics and frequency are important. Also, the mere existence of the long flush phase is interesting, since it demonstrates that the search and execution phases in reality can occur more independently than one might expect. Section 4.5.2.1 discusses the result when a Lucent STA is sending upstream traffic while faced with competing traffic at the new AP and section 4.5.2.2 covers the corresponding case when the STA is receiving downstream traffic. 4.5.2.1

Upstream traffic

The test-run consisted of 15 handover attempts, and as shown in table 4.3 only 12 of the attempts led to a handover. It was more common that a handover contained a long flush phase (case 4) than that the handover was “normal” (cases 1-3). We will start out by describing the common case (handover with

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

long flush phase), and thereafter cover the “normal” handover as well as other cases. Handover with long flush phase In about half (47%) of the handover attempts the handover contained a long flush phase and was followed by a late search phase (case 4 in table 4.3). The upstream traffic will in this case have three distinct delay spikes: one in the search phase of the handover (figure 4.16), a smaller one (including the loss of a packet) in the execution phase of the handover (figure 4.17), and about 2 seconds later a final delay spike caused by the late search phase at the new AP (figure 4.18)6 . During the first delay peak (figure 4.16) 5 packets are affected; the first packet is delayed 95 ms on average, and the average delay had an approximately linear decay of 19 ms for the following 4 packets. The packets were buffered during the search phase and transmitted during the following long flush phase. The length of the flush phase varied from about 12 ms to 900 ms and the number of packets sent in the flush phase varied from 6 to 51. The delay caused by the execution phase is less (figure 4.17), although not at all negligible. The first packet sent by the Lucent STA after execution is retransmitted and dropped for the same reasons as noted before, and the delay caused by this seems to be roughly in-line with the upstream “post-ho2” delay of the handovers in table 4.2. If the first packet after the execution phase would have been sent with the BSSID of the new AP (AP2), the delays shown in figure 4.17 would of course have been lower. The late search phase commonly occurred around 2 seconds after the execution phase finished. Its delay characteristics are shown in figure 4.18; the average delay of the first packet was 94 ms, which is similar to the previous search phase, but the average delay decreases only by roughly 16 ms per packet causing 6 packets to be affected. ”Normal” handovers - no long flush phase In one third of the handovers (cases 1-3) we have a handover without a long flush phase, thus in that aspect they behaved much like the handovers without competing traffic. However, except for the flush phase, these handovers proved to have quite different delay characteristics as shown in figure 4.20. Some of these handovers were preceded by an early search phase (figure 4.19) and one of them also had a late search phase (figure 4.18), i.e., these 5 normal handovers had between 1 and 3 delay peaks. The behavior during the actual handover is of special interest. Since these handovers have a flush phase similar to the tests without competing traffic table 4.2 presents the measured handover delays (table 4.2) in the same way as for the previous tests (see “Lucent Upstream” in table 4.1). As one can see in table 4.2 the search phase is very long and it has a high standard deviation. It turns out that the duration of the search phase for these 5 handovers is distributed into two groups. This can be seen by observing the upstream delay for the first packet in figure 4.20; for three of the handovers the first packet is delayed in the order of 100 ms while it is about 190 ms for the remaining two 6 The results in figure 4.18 is based on the late search phase in case 3 (in table 4.3), and six of the seven search phases in case 4 – the reason for excluding one of the late search phases in case 4 was that it had a quite different characteristic (the delay increased for the 2nd and 3rd packet).

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS

[ms] ✻ . 100 ... .... 80

....

[ms] ✻ 100 ....

....

80 ....

....

60 ....

....

60 40 20 0

.....

60 .....

.....

40 .....

.....

20 .....

✲ 1 2 3 4 5 6 7 pkt Figure 4.18: Measured upstream delay (mean ± σ) during late search phase for Lucent STA with competing traffic. (upstream data at 20 ms interval; 7 handovers). -20

......

✲ 1 2 3 4 5 pkt Figure 4.17: Measured upstream delay (mean ± σ) during execution phase of handover with long flush phase for Lucent STA with competing traffic. (upstream data at 20 ms interval; 7 handovers).

80 .....

......

-20

[ms] ✻ 100 ..... .....

......

✲ 1 2 3 4 5 6 pkt Figure 4.16: Measured upstream delay (mean ± σ) during search phase of handover with long flush phase for Lucent STA with competing traffic. (upstream data at 20 ms interval; 7 handovers).

.....

......

-20

......

40 ....

[ms] ✻ 100 .....

.....

✲ 1 2 3 4 5 6 7 pkt Figure 4.19: Measured upstream delay (mean ± σ) during early search phase of handover for Lucent STA with competing traffic. (upstream data at 20 ms interval; all early search phases: 6 handovers). -20

“normal” handovers (the associated search phases according to figure 4.6 were in the order of 120 and 210 ms respectively). We do not know the reason for this behavior. In addition to the strange search phase, the execution and post-handover phases are also interesting. The execution phase is relatively long (22.5 ms) and has a large variation. One reason for this is that some of the messages occasionally had to be retransmitted. The upstream delay for the packets transmitted via the new AP are also affected by the retransmission of the incorrectly addressed data packet (datak+2 ). The long delay involved to retransmit datak+2 (about 45 ms on average) not only affects the delay of the

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

[ms] ✻ 220 200

❛

180

❛ ❛

160

100

❛

140 120

q Case 1 ❛ Case 2 Case 3

q ❛q

❛ q q

❛ ❛

❛ q q

❛ ❛ q q

❛ ❛ qq

❛ ❛ q q

0 -20 1

❛ q q

❛ q

❛ ❛ qq

❛ q❛

❛ qq ❛

❛ q ❛q

❛qq

❛q

✲ 9 10 11 12 13 14 15 16 17 pkt

Figure 4.20: Measured upstream delay for Lucent STA with competing traffic. Individual data points shown. (upstream data at 20 ms interval; 5 handovers). The 2nd packet is dropped. following handover data packets; it also means that at least two upstream data packets scheduled for transmission after the handover procedure finishes were delayed as well. Other cases The remaining fifth of the handover attempts (cases 5 and 6) did not lead to a handover, although some of them contained significant upstream delay spikes for the data. The two handovers of case 6 both showed behavior that differed significantly from the other cases. Both had an early search phase, and their results are included in figure 4.19. In both of these handover attempts the early search phase was later followed by a new, relatively long search phase affecting the delay for 16 and 19 packets respectively. In the former case (affecting 16 packets) the maximum delay was 276 ms, and there was no execution phase. In the latter case (affecting 19 packets) the maximum delay was 338 ms. In the latter case the STA and AP performed the whole execution message exchange, but for some reason the handover never took effect. 4.5.2.2

Downstream traffic

The test-run when the STA received downstream data when facing competition at the new AP also consisted of 15 handover attempts, and their characteristics are summarized in table 4.4. Of the 12 attempts that led to a handover, 5 had “normal” handover message exchanges (case 1 in table 4.4), i.e., except for the delays involved the handover proceeded as shown in figure 4.9. Another 5 attempts had an early search phase followed by a “normal” handover (case 2).

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS 10

Handovers 7

0 0

9 10 Number of packets

Figure 4.21: packet all−sched : Distribution of the number of packets sent by old AP during handover when Lucent STA is subject to competing traffic (downstream data at 20 ms interval, 10 handovers).

The remaining two handovers (case 3) had long flush phases, and there were three handover attempts that did not lead to any handover (cases 4 and 5). Handovers without long flush phase In two thirds of the handover attempts in this test-run we observed handovers similar to the handovers without competing traffic, although the involved delays (table 4.2) were longer as well as having greater packet loss (figures 4.21 and 4.22). The perceived packet loss (packetobserved ) during the handover was typically 6 packets (median). Half of these handovers were preceded by an early search phase causing packet losses as shown in figures 4.23-4.25. Thus, during those handovers the STA would first experience a packet loss (packetobserved ) of typically of 4 packets (median) during the early search phase and then 6 packets (median) during the handover. Although the delays are significantly higher than for the corresponding measurement without competing traffic, the performance degradation is not as large as for the upstream case. The average search phase is about 124 ms (almost 50 ms worse than without competing traffic), which is about the same order of magnitude as “the best three” handovers measured when sending upstream data subject to competition. Another interesting result was that the time before the first packet was received through the new AP (Tpost−h1 = 21.5 ms) was rather large compared to half the transmission interval (10 ms), and that the average interval before the second packet arrived (Tpost−h2 = 15.2 ms) was less than the transmission interval (20 ms). We do not know the reason for this behavior. Case 1 2 3 4 5

5 5 2 2 1

# Handover Early search Long flush Late search Odd (33%) x (33%) x x (13%) x x x (13%) x (7%) x x

Table 4.4: Characteristics of handover attempts for Lucent STA receiving downstream data while facing competition at the new STA. Only 12 out of 15 attempts led to handover.

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS 10

Handovers 5

0 0

9 10 Number of packets

Figure 4.22: packetobserved and packetmax−cons : Distribution of perceived handover data (from first lost to last lost) for Lucent STA subject to competing traffic, which in this case equals the distribution of the longest consecutive loss burst (downstream data at 20 ms interval, 10 handovers).

Figure 4.21 shows the distribution of packets sent by old AP during the handover (packet all−sched ) for cases 1 and 2. For those handovers where lucky packets managed to get through during the handover (8 out of 10 handovers), there was only a single lucky packet at the beginning of the handover. Thus, the distributions for the perceived packet loss (packetobserved ) and maximum consecutive packet loss (packetmax−cons ) were the same, and they are shown in figure 4.22. Figures 4.23-4.25 present the distributions of packets sent from the old AP (packet all−sched ), the perceived handover data (packetobserved ) and the maximum consecutive loss burst (packetmax−cons ) during the early search phase. These results are based on the early search phases of cases 2, 4, and 5 (the two handover attempts in case 4 had two early search phases each).

Handovers with long flush phase Two of the handovers in table 4.4 had a long flush phase (case 4), and about two seconds after the handover finished the STA initiated a new search phase (i.e., a late search phase) at the new AP. During the handover the search phase caused a packet loss of 4 and 5 packets respectively (no lucky packets), and the execution phase caused a packet loss of 2 packets for both handovers. Losing 2 packets during the execution phase was a bit surprising, and it is not clear why it did not perform better (in one of the two handovers the 2nd packet loss in the execution phase actually occurred just after the execution had finished). In one of the flush phases 15 packets were sent (duration roughly 300 ms) and in the other 52 packets were sent (duration roughly 1 s). In the late search phase following the handover for both these cases, most of the data sent by the old AP reached the STA, i.e., there were a lot of “lucky” packets. In one of the handovers 5 packets were sent (packetall−sched = 5) and only the last packet was lost (packetobserved = packetmax−cons = 1); in the other case 3 packets were sent (packetall−sched = 3) and all packets managed to get through (packetobserved = packetmax−cons = 0)!

Other cases The remaining three handover attempts (20%) did not lead to a handover, but contained one or two loss bursts of the order of 4-7 packets.

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS 10

Early search phases 5

4 1

0 0

9 10 Number of packets

Figure 4.23: packet all−sched : Distribution of packets sent by old AP during early search phase when Lucent STA is subject to competing traffic (downstream data at 20 ms interval, 10 early search phases).

Early search phases 4

5 1

0 0

9 10 Number of packets

Figure 4.24: packetobserved : Distribution of of perceived handover data (from first lost to last lost) for Lucent STA subject to competing traffic (downstream data at 20 ms interval, 10 early search phases).

Early search phases 6 4

5 0 0

9 10 Number of packets

Figure 4.25: packetmax−cons : Distribution of longest consecutive loss burst during early search phase when Lucent STA is subject to competing traffic (downstream data at 20 ms interval, 10 early search phases).

4.5.3

Measurement summary and analysis

As observed in the measurements the handover procedure does not simply consist of a search and an execution phase; we also see flush and a posthandover phases, and when a mobile STA faces competing traffic we occasionally had additional search phases at the old and new APs. Although the mobile STA has difficulties to exchange traffic during both the search and execution phases, it is the search phase which is the longest and affects the handover performance the most. Additionally, the duration of the search phase differs considerably between models of WLAN cards. Upstream data scheduled for transmission during the handover is buffered at the mobile STA and transmitted to the AP during the flush or the posthandover phase. The upstream packets will experience a delay spike with

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

roughly linear decrease. In the case of competing traffic additional early and late search phases may lead to multiple delay spikes a few seconds apart. As opposed to upstream data, downstream data are commonly lost during the handover. 4.5.3.1

Search phase

The search phase is by far the largest contributor to handover interval. The Lucent STA had a significantly shorter search phase (∼80 ms) than the D-Link STA (∼190 ms). Another interesting observation was that the D-Link STA utilized what we refer to as the Power-Save mode trick. With the Power-Save mode trick it would be possible to avoid losing any downstream handover packets if the STA would wait for the AP to transmit buffered packets to the STA during the flush phase, i.e., the downstream packets would experience a similar delay pattern as shown for the upstream packets. Perhaps the most surprising observation was that the Lucent STA was generally lucky enough to receive one of the downstream packets during the search phase. This reduced the median size of the burst containing lost packets from 4 (packet all−sched ) to 3 (packetobserved ). With proper FEC and/or loss concealment algorithms the impact would be reduced even further (e.g. if single packet losses could be masked the median remaining loss would be 1 packet, i.e., figure 4.13 shifted 1 step to the left). The lucky downstream packets were received when the STA was searching for candidate APs on the channel where the old AP was located. An idea worth exploring further would be to allow the STA to flush the upstream packets buffered so far at (about) the same time. This would improve the performance for those packets experiencing the highest delay, but would require additional firmware support to coordinate the data transmission and AP search functions. When introducing competition most handovers experienced roughly a 50% search phase increase (average ∼80 ms and ∼120 ms respectively), while a few “upstream handovers” had an even longer search phase (about 210 ms). We do not know the reason for this grouping in the duration distribution. An interesting question is whether the usage of the PS mode trick is beneficial for real-time voice applications or not. The effect on upstream packets would be negligible (at best), since these packets would be flushed anyway. Downstream packets would be delayed rather than lost, but on the other hand we would not have any lucky packets, since the AP would not transmit any packets to the STA. My belief is that the use of the PS mode trick may unnecessarily add to the complexity. With longer search phases one risks buffering and sending data in vain (since many of the oldest packets will be delayed too much. Another risk with buffering and flushing packets is the additional network congestion that may occur when several users move together. With the PS-mode trick correlated traffic peaks from different users may occur not only for the upstream, but also for the downstream packets. This deficiency is probably out-weighted by the fact that the AP will not need to send and resend downstream data to the mobile STA during the search phase.

4.5. WLAN HANDOVER TESTS AND MEASUREMENTS

An alternative approach to limit the effects of the search phase would be to search one or a few channels at a time (when roaming in environments where the user has been before the “adjacent AP caching” method suggested by Shin et al.[156] could be used). By alternating between searching and listening to the old AP, an appropriate CODEC may be able to mask the effect of these single losses[95]. A less drastic approach would be to first search on half of the channels, then tune to the channel of the old AP to exchange buffered packets, and finally search on the remaining channels. Furthermore, if these approaches are done in combination with the PS-mode trick no packets need to be lost at all. A drawback with these approaches is that the IEEE 802.11 standard[68] specifies that all channels should be searched at once7 . In addition, it may have some negative effects on the AP performance if it must deal with lots of PS messages. 4.5.3.2

Flush phase

Both the Lucent and the D-Link STA had a flush phase, but their behavior differed somewhat. The Lucent STA sent one of its buffered packets to the old STA, while the D-Link STA sent two. As already mentioned, the D-Link STA would also be able to receive packets buffered by the AP if it would just have extended its flush phase. Thus, the STA could use a (short) timer, which it resets every time it receives a packet from the old AP, and when the timer goes off the STA initiates the execution phase. The most interesting aspect of the presence of a flush phase is that it demonstrates that it is practical to decouple the search and execution phases. When the Lucent STA is faced with competing traffic we see that it commonly extends the flush phase (between 60 ms and 1 s), which gives the STA time to flush buffered upstream packets via the old AP, given that the connectivity is still acceptable. By sending the packets via the old AP they will not experience the extra delay introduced by the execution phase, thus we recommend this behavior to used more often. As proposed in the next chapter the flush phase could also be used to perform IEEE 802.11i pre-authentication. 4.5.3.3

Execution phase

There was no significant difference between the Lucent and D-Link STAs with respect to the execution phase - both had an average execution phase of around 7 ms, and surprisingly both STAs (incorrectly) sent a reassociation message to the new STA before authenticating. The values presented here are somewhat higher than the measurements presented in [178], but the execution phase is still small compared to the search phase. The delay caused by this false reassociation message exchange (2-3 ms) may account for some of the difference. As observed in measurements with the Lucent STA, the execution phase will take more time when faced with competing traffic, with an average duration of about 20 ms, making it even more beneficial to send buffered data during the flush phase. 7 However,

higher layer protocols (such as Mobile IP) need not observe this MAC limitation.

4.5.3.4

CHAPTER 4. HANDOVER IN IEEE 802.11 NETWORKS

Post-handover phase

Once the execution phase is over, the STA in our setup was able to send and receive data. For upstream traffic this means that buffered traffic will be sent to the AP in a burst, while downstream packets will start to arrive as usual once the link-layer update message has “taken effect” in the distribution system. A surprising observation for the upstream packets was that the Lucent STA sent its first packet in the post-handover phase addressed to its old AP. The packet was lost, and due to the associated retransmissions the subsequent packets experienced an additional delay. Figure 4.8 shows the average delays for the Lucent STA if the first packet would have been addressed correctly. As described above, one could reduce the latency of post-handover data even further by either avoiding the false reassociation messages (3 ms) or sending the packets via the old AP, avoiding the whole execution phase delay (7 ms), however these changes are not included in figure 4.8. The penalty for miss-addressing by the Lucent STA is higher when there is competing traffic (∼45 ms), thus correcting this error (or sending them via the old AP) would be even more beneficial for this case.

Chapter 5

Secure public WLAN infrastructures 5.1

Introduction

In the previous chapter we studied the IEEE 802.11 handover procedure and its effect on ongoing voice sessions, when no access control or other security features were activated. In this chapter we will expand the layer-2 handover scenario, by introducing the security services that we find relevant for public WLAN communication. The system studied will be extended further by taking into account two more design aspects of public WLANs: the ability to centralize the management of WLAN APs and the ability for operators to share access networks to lower infrastructure costs and achieve wide-spread coverage. As multiple ISPs will provide services over the same access network, multiple IP subnets will have to co-exist over the same physical LAN. The traffic for the different ISPs should be logically separated and the mobile stations should see the access network as a single LAN with a single IP subnet (the subnet they are attached to). Thus, from a user’s perspective we are still considering layer-2 mobility, where the handover occurs between APs serving the same LAN.

5.1.1

Security requirements in public WLAN networks

In general a system providing public WLAN access must have a mechanism to ensure that only authorized users can access the network, i.e., access control. This means that the network operator should be able to control which users have access to the network, not only on a session level, but even on a packet by packet level. By introducing and verifying message integrity codes (MICs)1 or (less likely) digital signatures for each packet, the operator will be able to: • Block traffic from unauthorized users. operator to:

This will in turn enable the

– Block authorized users with infected machines from continuing to spread viruses once such a user is detected. 1 The term message integrity code (MIC) is preferred over the more common term message authentication code, since we use the acronym MAC for layer-2 medium access control in this thesis.

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

– Ensure that the capacity in the network (access network as well as back-bone connections) is devoted to their customers instead of War-Chalking[17]. – Guard against attacks on (unprotected) servers in the network, e.g., if the WLAN is an extension to a corporate network. • Utilize charging models based traffic consumption in (addition to time) with more safety than without MICs or digital signatures. To enforce access control, a user (Alice) should establish a security association with the network access server (NAS) in the WLAN access network using some appropriate authenticated key exchange (AKE) mechanism based on a long-term secret. She would then be able to put a MIC in every packet she sends, and upon successful verification the authenticator will forward the packet, and if the authentication is mutual it will be possible to do the same procedure for packets in the other direction (from authenticator to Alice). Another desirable security service is WLAN link data encryption. Although we believe confidentiality is better handled end-to-end rather than hop-by-hop many user applications lack appropriate end-to-end security support and are particularly vulnerable to eavesdropping over a wireless link. However, security conscious users should not consider WLAN link security sufficient, perhaps except for when the WLAN access network is part of their corporate network (i.e., they can trust the infrastructure on the fixed network). In a more general situation a nomadic user may attach to various public access networks, where end-to-end encryption should be adopted to ensure confidentiality. Link encryption is therefore considered a desirable security feature, but not strictly necessary as opposed to access control, which is necessary. There is no contradiction between these two services; solutions that can provide per-packet authentication over the WLAN link should easily be able to provide per-packet encryption and vice versa. Despite this, some of the PPP based solutions we will examine provide encryption but not per-packet authentication. Although such systems do not contain explicit per-packet authentication, they would implicitly contain a simple integrity check; spoofing messages would be more difficult since the end decrypting the messages would hopefully throw away messages that look like garbage. Still, adding a MIC to each message would be superior. In addition to access control and confidentiality there are other security services of interest to public WLAN networks, such as replay protection. However, to limit the scope of this thesis such services are not emphasized for the various access network solutions covered here.

5.1.2

Extensions to access network topology

In the previous chapter we studied WLAN handover performance in a simple WLAN setup. In this chapter we will examine different public WLAN access network solutions that aim to provide security (as discussed in the previous section) while at the same time being feasible to both deploy and manage. To make a public WLAN network deployable and manageable we add two

5.1. INTRODUCTION

Backbone network Backbone network AC

WTP

H a)

Figure 5.1: (a) Centralized WLAN solution using AC/WTP. (b) Decentralized solution using stand-alone APs.

concepts of major importance for the network design, referred to as open access networks and centralized APs. It is important to study these concepts in order to understand how the access network design and, in the end, how the handover mechanism and thus the handover latency will be affected. • Centralized APs: A current trend in WLAN network deployments is to use centralized solutions, where the WLAN AP functionality is shared between a wireless termination point (WTP) and the back-end access controller (AC)[185], see Fig. 5.1. WLAN access control and confidentiality could be handled by the AC, while the WTP has the radio interface part of a WLAN AP and also manages IEEE 802.11 control messages (beacons, ACKs etc.) By placing security functions in the AC the WLAN system would be more secure, since the AC can be put in a locked server room and would be more difficult to bypass than a regular AP. By introducing the AC/WTP model, as opposed to the simple AP solution used in chapter 4, the handover latency may increase somewhat even if there would be no authentication processing - IEEE 802.11 management messages may experience longer network delays if they are exchanged between Alice and a (possibly distant) AC (Fig. 5.1a) instead of the AP (Fig. 5.1b). However, unless the network delay between the AC and WTP is significant this additional delay could likely be ignored. • Open access networks: It is unlikely that a single wireless ISP (WISP) will be able to achieve city wide WLAN coverage by itself. In addition to the costs involved, it may be difficult to even get permission to put up WLAN APs at all crucial positions, especially if some other WISP is

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Internet

ISP1

ISP2

ISPN

Figure 5.2: Multiple ISPs providing services over a shared access infrastructure

already present at this location or if the organization (or person) at this location already has a private WLAN access network in place. To provide good coverage for the end-users it would therefore be desirable if the access infrastructure could be shared. The reasons for ISPs to make use of shared access infrastructures lie not only in the desire to lower deployment and permission costs, but do also originate from the demand of housing companies and municipalities who may contribute to the deployment of broadband access networks with the requirement that ISP and application services provided on that network should be open for competition[17]. Until now such initiatives have mainly targeted wired broadband access networks, however, if WLAN APs are added to these access networks the same ideas can be applied to wireless broadband access as well. A matter that will complicate the design further is the desire to allow for various service providers, such as a video rental service provider, to establish their services locally within the access network, enabling them to reach users without depending on any ISP. In this class of services we may find “free” information pages, e.g., user information about how to connect or direct communication between the users, which could be used to make free phone calls or for file sharing. Although the opportunity to support introduction of such local services may be beneficial to certain access network business models, providing local service may contradict the goals of guarding and reacting against virus spreading, etc.. If support for local services where a strict requirement it may significantly increase the design complexity for some approaches. We therefore consider support for local services to be a bonus, rather than a primary design goal, and for the different solutions we offer hints about how (and if) local services could be realized.

5.1.3

Solution alternatives considered

There are several possible approaches to achieve a secure open WLAN access network. In this chapter we will focus on two classes of solutions which we

5.1. INTRODUCTION

believe will be commonly used. One class contains work based on the development of enhanced security within the IEEE 802.11 Task Group I (IEEE 802.11i) and the corresponding WiFi Protected Access (WPA) standards of the Wi-Fi Alliance. In this family of solutions we also find other access control solutions based on the IEEE 802.1x standard for port based access control. In these solutions the communication is still designed based on LAN concepts, i.e., the access network commonly appears as a single layer-2 broadcast domain, or as multiple broadcast domains (if IEEE 802.1Q virtual LAN techniques are used). The entity enforcing access control on the data packets, i.e., the IEEE 802.1X authenticator, is integrated into one of the layer-2 devices in the data path, e.g., the AP or a back-end access controller. Solutions using IEEE 802.11i will be examined in section 5.3. In the other class of solutions considered, the mobile station uses PPP to establish a point-to-point tunnel to some device (normally) located in the access network. To establish the PPP tunnel in a LAN environment techniques such as the low-level PPP over Ethernet (PPPoE) protocol, or the higher level Point-to-Point Tunneling Protocol (PPTP) or Layer-2 Tunneling Protocol (L2TP) can be used. These techniques already have good support in several MS Windows versions, thus systems based on them should be relatively easy to deploy. Solutions based on PPP will be examined in section 5.2. In addition to these two solution classes, there are other potential approaches which are not covered further here, e.g., • Web-login approaches: The approach probably most commonly used by WISPs today is to use a (captive) web-portal where a customer (Alice) can enter her username and password[112, 162, 63]. When Alice has associated with the AP she can use, e.g., DHCP to acquire and IP address. A firewall (or prison-wall as called in [129]) is used to block traffic from unauthorized users, except for traffic to/from the web-portal and possibly also some other servers such as the local DNS server. The communication between Alice and the web-portal could be secured by TLS, i.e., a web form sent over HTTPS can be used to transport Alice’s information from her host to the web server. Once Alice has given her credentials, the web-portal will notify the firewall, which in turn can add a firewall rule to allow passage for all traffic from her IP-address (and possibly also MAC-address). In these solutions there is commonly no per-packet authentication of the data traffic (HTTPS is only used to secure the login information), thus, there is always a risk that an attacker can use the IP/MAC-addresses of an authorized user to gain access to the network. Furthermore, these solutions generally will not provide confidentiality over the WLAN link, enabling attackers to easily retrieve clear-text passwords or other sensitive application information sent over the WLAN link. A nice property of using a web-interface to retrieve user information is that it only requires a SSL/TLS-enabled browser on Alice’s host software which is available on all common platforms. But using weblogin requires Alice to acquire an IP-address before being able to enter her login information and in particular the information about which ISP

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

she belongs to. This would not constitute a big problem in the roaming solution (single ISP present) covered in this section2 , however, if Alice is to use web-login to choose among a set of present ISPs the matter becomes more complex. Alice would then like to be assigned an address of her ISP, but before she can select an ISP the host needs a temporary IP address to reach the web-portal and select an ISP. The OASIS system[63] uses a DHCP relay agent which initially relays DHCP messages to a common DHCP server (short lease time), and after ISP selection future DHCP messages from Alice are relayed to the DHCP server of her ISP. • IP-IPSec tunnels as NAS solution: Instead of tunneling a PPP session to a NAS enforcing access control, one could use IPSec in tunneling mode as NAS solution. That is, an “IP in IPSec” tunnel can be setup between Alice and an IPSec-gateway in the local network. This is a promising approach and access network solutions based on IPSec tunnels are currently being developed by the IETF PANA WG[118]. The reasons why we have not considered IP-IPSec as NAS solution further in this thesis are: – One of the PPP based solutions, L2TP with IPSec, gives a similar service as the IP-IPSec solution. Although the overhead for L2TP/IPSec is larger, some of the results would be valid also for an IP-IPSec approach. For example, both solutions require Alice to acquire an IP address on the local network and establish an IPSec connection to the NAS. – As opposed to L2TP/IPSec, the IP-IPSec solution is not (yet) available by default on common platforms. Still, with the advancement of IKEv2[79] and the work being done within the IETF PANA WG, IP-IPSec tunneling may become a valid NAS alternative in public WLANs. Dutta et al. present an architecture where PANA/IP-IPSec is used as NAS solution for mobile users[42]. • Mobile-IP Foreign Agents as NAS solution: In chapter 6 Mobile IP (MIP) and other mobility management schemes will be examined. In MIPv4 the foreign agents (FAs) can enforce access control[50], thus MIPv4 with FAs can be used as NAS solution. The drawbacks with this approach are: – It requires the use of MIPv4 with FAs as mobility management scheme. Although extensions enabling optimal routing with MIPv4 have been proposed, it would require support for route-optimization in the remote host, which can not generally be assumed. – This will not provide a NAS solution for IPv4 hosts lacking support for Mobile IP. Thus other alternatives will be needed anyway, resulting in overlap in functionality. Similarly, it does not provide a NAS solution to IPv6 hosts. 2 Although there may be some denial of service attacks based upon unauthenticated/unauthorized users using up the IP address space of the local ISP.

5.2. SOLUTIONS UTILIZING PPP TUNNELS

– To enable multiple ISPs to share a WLAN access network this solution allows ISPs to share a common MIP FA, e.g., the ISPs could establish a roaming agreement with the access network operator who operates the FA. In section 5.4.3 we present access network solutions for “native operator neutrality”. We have not studied whether native operator neutrality is possible using MIPv4 with FAs as NAS solution.

5.2

Solutions utilizing PPP tunnels

For point-to-point modem connections PPP has gained wide-spread usage as a data link protocol. Since PPP provides access control features independent of network or higher layer protocols, and since it is a mature protocol with support on all major platforms it is also a good candidate for implementing a NAS in a shared WLAN environment. In this chapter we are primarily interested in handovers within a LAN, and for PPP this has two important implications. First, in order for PPP to be utilized in a LAN environment additional functionality will be needed to carry the PPP frames. We will consider three such alternatives: PPPoE (section 5.2.4), PPTP (section 5.2.5), and L2TP (section 5.2.6). Secondly, when Alice performs a handover between APs on the same LAN, she will be able to keep the same PPP connection without any further message exchange, except for the signalling needed to verify that she really is attached to the same LAN. Thus, the message exchange performed when bringing up a PPP connection would only have to occur when she performs a handover between LANs, not within a LAN. Still, we will describe the procedure since it is closely related to WLAN access network infrastructure design. Before we go into the details of PPPoE, PPTP, and L2TP, the message exchange needed to establish a PPP connection over a serial link is described (section 5.2.1) followed by a section describing the authentication and confidentiality features that are available for PPP (section 5.2.2). Some of the authentication mechanisms described will also be applicable for the IEEE 802.11i approach described in section 5.3.

5.2.1

General PPP connection establishment

To examine the handover performance in a WLAN network when using PPP as a NAS solution, we need to describe the message exchange required to bring up a PPP connection. We start out by examining the message exchange necessary to establish a PPP connection over a (regular) serial connection. Although the end-devices are referred to as peers in PPP terminology (RFC 1661[157]), we will call them the PPP client and the PPP server (or simply client and server). The PPP server will act as the network access server (NAS) and it resides inside the fixed infrastructure, while the PPP client runs in the host of the user (Alice) wishing to connect to the network via the PPP server. A simple PPP connection establishment is shown in Fig. 5.3. First a set of link control protocol (LCP) messages (messages 1-4) are exchanged to configure options independent of any network layer protocol. Once the link is

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice PPP "client"

NAS PPP "server" 1: PPP LCP Conf Req 2: PPP LCP Conf Req 3: PPP LCP Conf Ack

Link Establishment Phase (1.5 effective round−trips)

4: PPP LCP Conf Ack 5: PPP IPCP Conf Req 6: PPP IPCP Conf Req 7: PPP IPCP Conf Nak

Network Layer Protocol Configuration Phase (2 effective round−trips)

8: PPP IPCP Conf Ack 9: PPP IPCP Conf Req

(Link testing could be done in parallel)

10: PPP IPCP Conf Ack Critical path: 3 roundtrips Figure 5.3: Example of a simple PPP connection establishment

declared open, various network control protocols (NCPs) exchange messages to configure options relevant for their respective network protocol – messages 5-10 are IP Control Protocol (IPCP[102]) messages where the client acquires IP parameters such as IP address, default router, and DNS. Unfortunately, the PPP option negotiation has been designed for interoperability and functionality rather than for performance optimization, thus, it is not possible to negotiate network layer parameters (IPCP) in parallel with the network independent parameters (LCP)3 . We can also see that the client is required to submit two IPCP Configuration Requests before getting an IPCP Configuration Acknowledgement from the server. The reason is that the client is unable to specify a correct IP address, etc. (message 5) before the server has assigned such parameters to it (message 7). In PPP the client and server negotiate options in parallel and in Fig. 5.3 we have introduced the term effective round-trip to denote the number of sequential network round-trips needed finish a certain phase. If we examine the sequence of messages in Fig. 5.3, the critical path would include three network round-trips between the client and server: 3 However, as stated in Fig. 5.3, some link testing messages can be exchanged in parallel with NCP messages.

5.2. SOLUTIONS UTILIZING PPP TUNNELS

1. Messages 1-3: At the time the client initiates the connection, the server is waiting for a client to connect. Upon receiving the LCP Configuration request, the server sends both a LCP Configuration Request and LCP Configuration Acknowledge back to the client. 2. Messages 4-7: The client acknowledges the server’s Configuration Request, and subsequently sends an IPCP configuration request. The server replies with a IPCP configuration Request (stating its own IP address), and an IPCP Configuration NACK containing information about the IP address, etc. to be assigned to the client. 3. Messages 8-10: The client acknowledges the server’s IPCP Configuration Request (message 8 can actually occur before message 7, but there is no dependency between them and changing their order would not affect the number of round-trips in the critical path). In addition the client will send a new IPCP Configuration Request containing the IP parameters provided by the server, finally this request is acknowledged by the server. The message exchange shown in Fig. 5.3 was verified using Paul’s PPP package[133] on two Linux machines connected via a serial cable4 . The actual message exchange may differ between configurations, but Fig. 5.3 should show a minimum message exchange when Alice uses a serial PPP connection to acquire an IP address. To represent the delay involved to acquire network access, we will only consider the number of sequential messages required to be exchanged. Thus, in these symbolic expressions we ignore the impact of processing in the endnodes. Although the delay imposed processing is occasionally significant, its impact will decrease with improved hardware. We introduce the term local one-way trip time (LOTT ) as the time it takes for a message to go from Alice to an entity within the (local) access network or in opposite direction. Thus, a LOTT involves a WLAN link traversal. The link establishment phase effectively requires 3 LOTT s (equation 5.1) and IPCP requires 4 LOTT s (equation 5.2). Since message 4 and 5 are sent in the same direction, the critical path to establish this simple PPP connection is one less than the sum of NLCP and NIPCP (equation 5.3). NLCP

3 LOTT

(5.1)

NIPCP

= =

4 LOTT NLCP + NIPCP − 1 LOTT = 6 LOTT

(5.2) (5.3)

NPPP,simple

A note on the use of IPv6: Parameters for IPv6 can be negotiated with IPV6CP[59] in parallel with IPCP. In IPV6CP the client and server will exchange information about their respective IPv6 link-local address in two independent local round-trips. That is, IPV6CP would finish in one effective round-trip, which is one less than IPCP. However, IPV6CP will not provide Alice with a global IPv6 address, thus another round-trip for Router Solicitation/Advertisement would be necessary later on. 4 The

Linux PPP daemons (pppd) were configured not to use any compression.

5.2.2

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

PPP with authentication and confidentiality

PPP specifies an optional authentication phase between the link configuration and network configuration phases. A peer can request the remote end to authenticate it by adding an authentication option to its LCP Configuration Request, specifying which authentication protocol to use. The actual authentication message exchange will occur before any network configuration protocol messages are exchanged, thus further delaying the connection establishment time. The number of messages exchanged will depend on the authentication protocol in use. These authentication messages are generally relayed by the NAS to a back-end authentication server such as RADIUS, and are likely to experience significantly longer network delays than other setup messages exchanged between Alice and the NAS. We will describe the message exchange for some common authentication protocols : MS-CHAPv2 in section 5.2.2.1, and some EAP[2] authentication methods in section 5.2.3.2. There is no standard specifying a PPP format or mechanisms to add a MIC to a PPP packet in order to achieve per-packet authentication. However, there are methods available to encrypt a PPP connection, such as Microsoft’s MPPE protocol[117] as well as DES ([159, 88]). Of these two, only MPPE seems to be used in practice. MPPE is negotiated by the PPP compression control protocol (CCP[140]), and the corresponding message exchange takes place when the connection has reached the network layer protocol phase. The negotiation primarily concerns whether MPPE should be used and at what session key length. The negotiation may take one but generally two round-trips between the client and server (depending if one or more key lengths are supported), see Fig. 5.4 (the exact order of the CCP messages may differ somewhat, however, there would only be two round-trips for the negotiation in each direction). NMPPE = 4 LOTT 5.2.2.1

(5.4)

MS-CHAPv4 authentication

Microsoft’s MS-CHAP-v2[101] is one of the most popular methods to perform user authentication in PPP. With MS-CHAPv2 two entities can be mutually authenticated using a 3-way message exchange. The use of authentication is specified during the link establishment phase, and the authentication itself takes place just after the link has come up. From Fig. 5.5 we can see that there are 7 network round-trips between the client and server5 . Message 1 contains the challenge for the client. Message 2 contains the client’s response as well as the server challenge. The server verifies the client’s response and sends back a Success indication in message 3 as well as a response to the server challenge. When a RADIUS server is used as a back-end authentication server, messages 2 and 3 will be ”forwarded”6 to and from the RADIUS server in RADIUS Access Request and Accept messages respectively[142]. We introduce the term remote one-way trip time (ROTT ) as the time it takes for a message to go from an entity within the (fixed part of) access network to a remote entity over the Internet. 5 The PPP message exchange (excluding RADIUS) in Fig. 5.5 was verified using Paul’s PPP package for Linux[133] 6 More precisely, the relevant content of the PPP messages will be mapped to the corresponding fields in the RADIUS messages.

5.2. SOLUTIONS UTILIZING PPP TUNNELS

Alice

NAS PPP "server"

PPP "client"

Link Establishment Phase (1.5 effective round−trips) Authentication Phase (variable nb of round−trips)

Some messages relayed to backend AAA server (Link testing could be done in parallel)

1: PPP CCP Conf Req (40/104) 2: PPP CCP Conf Req (40/104) 3: PPP CCP Conf Nak (104)

Compression Control Protocol Configuration Phase (2 effective round−trips)

4: PPP CCP Conf Nak (104) 5: PPP CCP Conf Req (104) 6: PPP CCP Conf Req (104) 7: PPP CCP Conf Ack (104) 8: PPP CCP Conf Ack(104) Network Layer Protocol Configuration Phase (2 effective round−trips) Figure 5.4: PPP connection establishment negotiating MPPE for confidentiality support. The numbers 40 and 104 refers to key length negotiation.

Equation 5.6 shows the number of messages required when using MS-CHAPv2/MPPE:

NMSCHAP

3 LOTT + 2 ROTT

NtotMSCHAP/MPPE

= =

NLCP + NMSCHAP + NMPPE + NIPCP (3 + 3 + 4 + 4) LOTT + 2 ROTT

14 LOTT + 2 ROTT

(5.5)

(5.6)

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice PPP "client" (MS−CHAPv2 authentication requested) Authentication phase (1.5 local and 1 remote round−trip) (Link testing can be done in parallel)

NAS PPP "server"

AAA RADIUS server

Link Establishment Phase (1.5 effective round−trips) 1: PPP CHAP CHALL 2: PPP CHAP Response

3: PPP CHAP Success

RADIUS Access Request RADIUS Access Accept

MPPE negotiation (CCP) (2 effective round−trips) Network Layer Protocol Configuration Phase (2 effective round−trips) Critical path: 7 local and 1 remote round−trip Figure 5.5: PPP connection establishment with MS-CHAP-v2 authentication .

5.2.3

EAP authentication

The extensible authentication protocol (EAP[2]) is not an authentication protocol itself. Instead it constitutes a mechanism to negotiate what authentication protocol, i.e., what EAP method, to use, as well as a mechanism to pass these authentication messages. EAP allows the authentication to take place between the client (EAP peer) and an EAP server. The EAP server can be co-located with the NAS (EAP authenticator), but the NAS could also act in pass-through mode and relay the authentication messages to a back-end authentication server. From a delay perspective, the EAP authentication process can be viewed as consisting of two phases: the initial EAP identity handshake and the EAP authentication handshake. The EAP identity handshake has a relatively small and static effect on the handover latency and will be described further in section 5.2.3.1. Section 5.2.3.2 examines the actual authentication handshake including some desirable EAP authentication method alternatives. 5.2.3.1

EAP identity handshake

The EAP authentication starts by an EAP-Request message, where the NAS requires the client to provide information about its (EAP) identity. The client informs the NAS about its identity in an EAP Response message. As shown in

5.2. SOLUTIONS UTILIZING PPP TUNNELS

Fig. 5.6, the NAS commonly forwards the EAP Response message to a backend (RADIUS) AAA server, also referred to as an authentication server (AS). NEAP,id = 2 LOTT + 1 ROTT

(5.7)

The EAP identity handshake in Fig. 5.6 is unprotected7 . For most usecases this would not constitute a problem, but users with privacy concerns may find it unsatisfactory to transmit their identity in clear-text and thereby expose it to passive eavesdroppers. However, there is no need for Alice to send her full identity in the EAP-Response message; instead the user could limit the identity information to simply the provider part (ispA.com) of her network access identifier ([emailprotected]), as suggested in [2]. Although the provider information could be used for some traffic analysis, this improvement limits exposure of the user’s identity.

5.2.3.2

EAP Authentication handshake

The EAP authentication handshake will result in a delay which is relatively large and which will vary depending on what EAP authentication method is negotiated. • Authentication messages will be exchanged between Alice and her EAP server, which we assume will be located in a back-end AS, i.e., the (RADIUS) AAA server of her ISP ([emailprotected], or simply AAAH A ). These messages will experience a longer network delay than those exchanged between Alice and the local NAS. • As part of the EAP authentication handshake the AS will inform the client which EAP authentication method to use. Different authentication methods will result in different numbers of network round-trips. Furthermore, EAP is a “lock-step” protocol with limited support to handle large packet sizes efficiently. EAP authentication methods with large messages may result in many additional round-trips between the client and AS[2]. • Different authentication methods will differ in the amount of cryptographic processing required. Although cryptographic processing may constitute a significant part of the authentication delay, it would decrease with improved system performance. The symbolic delay equations we present only consider network delays. Several authentication methods have been proposed for EAP. IEEE 802.11i requires the usage of EAP methods supporting mutual authentication between the supplicant and the AS, thus methods such as EAP-MD5[2] cannot be used. The EAP authentication protocols we will describe further are: • EAP-TLS: EAP-TLS[3] enables Alice and the EAP server to mutually authenticate using certificates via TLS. One of its advantages is that it is deployed on MS Windows and can be used both with PPTP and 802.11i. 7 Subsequent

EAP identity handshakes with the same NAS can be protected.

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

• EAP-AKA: EAP-AKA[8] is an EAP authentication method based on the authentication and key agreement (AKA) mechanism used by UMTS and CDMA-2000. As mobile handsets may be equipped both with WLAN and 3G interfaces, using the subscriber identity module (SIM) card for WLAN authentication is an attractive concept. Another EAP method of interest is the protected EAP protocol (PEAP[116]). In PEAP Alice first uses EAP to establish a TLS tunnel to the EAP server, whereby the EAP server is authenticated. This TLS tunnel is then used to protect a subsequent EAP authentication method, e.g., EAP-MSCHAPv2[78] or even EAP-TLS. A major benefit with EAP-PEAP is that it provides identity hiding. A similar EAP-method is EAP-TTLS[47]. Thus for PEAP and EAP-TTLS the number of messages will be similar to EAP-TLS plus an additional set of messages for the tunneled authentication protocol. RFC 3748[2] presents a list of security threats which can be used to further compare different EAP methods from a security perspective, and RFC 4017 provides information on the use of EAP methods together with IEEE 802.11i. One of properties of interest is whether a given EAP authentication method reveals user identity information, i.e., its privacy characteristics. Still, our main interest is in low-latency handovers, thus the focus will be on evaluating these different EAP methods based on their delay characteristics.

EAP-TLS EAP-TLS can be used to achieve certificate based mutual authentication between the EAP client and EAP server using the TLS protocol. Fig. 5.6 shows the required message exchange for a successful EAP-TLS handshake (a corresponding figure can be found in RFC 2716[3]). Upon receiving the EAP Response/Identity message, the EAP Server will inform the client that EAPTLS should be used for authentication (message 3). Messages 4-7 constitute the regular TLS 4-way handshake. Unless TLS session resumption is used, messages 5 and 6 contain server and client certificate (or certificate chain). A drawback with EAP-TLS is that the client certificate is sent in the clear, and since Alice’s NAI [emailprotected] (or some other identifier which could be mapped to Alice) is part of the certificate, her identity would be revealed. When examining the number of messages exchanged with EAP-TLS we have three cases: • No EAP fragmentation: If message 5 and 6 each would contain a single certificate it may fit in a single EAP message (default minimum EAP MTU is 1020 bytes) leading to the number of network traversals shown in equation 5.8. • Certificates too large: Since the certificate (or chain of certificates) carried in messages 5 and 6 easily could be too large, messages 5 and 6 could each necessitate multiple round-trips. Equation 5.9 represents the number of messages exchanged if message 5 and 6 each requires two packets, i.e., 1.5 round-trip each. This is probably a common scenario and was verified in a simple test setup8 . 8 The

EAP-TLS scenario with fragmentation of message 5 and 6 as in equation 5.9 was verified

5.2. SOLUTIONS UTILIZING PPP TUNNELS

Alice PPP/EAP "client" (EAP Auth− entication requested)

EAP Iden− tity phase

NAS PPP "server"

AAA RADIUS/ EAP server

Link Establishment Phase (1.5 effective round−trips) 1: PPP EAP Request/ID 2: PPP EAP Response/ID

RADIUS Access Request

3: PPP EAP Request (TLS Start)

RADIUS Access Chall. (TLS Start)

4: PPP EAP Response (TLS Client Hello)

EAP Auth− entication phase (TLS)

RADIUS Access Request (TLS Client Hello)

5: PPP EAP Request (TLS Server Hello, Cert.)

RADIUS Access Chall. (TLS Server Hello, Cert.)

6: PPP EAP Response (TLS Cert., Finished)

RADIUS Access Request (TLS Cert., Finished)

7: PPP EAP Request (TLS Finished)

RADIUS Access Req. (TLS Finished)

8: PPP EAP Response (TLS)

RADIUS Access Request (TLS)

9: PPP EAP Success

RADIUS Access Accept

MPPE negotiation (CCP) (2 effective round−trips) Network Layer Protocol Configuration Phase (2 effective round−trips) Figure 5.6: PPP connection establishment using EAP-TLS authentication handshake with back-end AAA server.

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

• TLS session resumption: Improved performance would be achieved if TLS session resumption could be used. With TLS resumption no public key cryptographic processing would be required, and the handshake would finish in one round-trip less than shown in Fig. 5.6 (see RFC 2716[3] for further details). Equation 5.10 shows the number of messages exchanged. The equations below show the number of messages exchanged for the EAP identity and EAP authentication handshakes for the EAP-TLS scenarios described above. NEAP-TLS,nofrag NEAP-TLS,frag NEAP-TLS,SR

= =

NEAP,id + 7 LOTT + 7 ROTT 9 LOTT + 8 ROTT

(5.8)

= =

NEAP,id + 11 LOTT + 11 ROTT 13 LOTT + 12 ROTT

(5.9)

= =

NEAP,id + 5 LOTT + 5 ROTT 7 LOTT + 6 ROTT

(5.10)

When Alice turns on her IP phone she may have to issue a full EAP-TLS handshake (equations 5.8 or 5.9. However, when she connects to a new NAS as part of a handover, we will assume that she can utilize TLS session resumption (equation 5.10). RFC 3536 introduces a “TLS server name”, which may prove to be useful to enable TLS resumption in load balancing setups. There is ongoing work to enable stateless TLS session resumption, thus reducing the risk for denial of session resumption due to session cache limitations at the server[150]. To validate a chain of certificates Alice should consult a reasonably fresh certificate revocation list (CRL). We recommend Alice to regularly download a fresh a CRL, thereby avoiding the additional complexity and delay required if a CRL is to be downloaded during a handover procedure. If no valid CRL is available and if Alice does not have Internet connectivity, we suggest that she checks for CRL information after the connection has been established as recommended in [3] . As an outcome of the EAP-TLS handshake the EAP client and server will each possess a primary master key (PMK), which can be used to derive necessary session keys for the security protocols in use to protect the data stream between Alice and the NAS, e.g., MPPE for PPP solutions (see Fig. 5.6), and TKIP or CCMP for IEEE 802.11i (see section 5.3). For example, Microsoft Windows’ PPTP VPN solution can use EAP-TLS with MPPE.

EAP-AKA If Alice handset has a SIM card slot/reader she could use EAPAKA[8] or EAP-SIM[60] as EAP authentication method. Although we focus on roaming in public WLAN environments, these authentication methods are attractive since they enable easier roaming between WLAN and 3G, or WLAN and GSM/GPRS networks respectively. We limit the further description to EAP-AKA. EAP-AKA uses shared keys to achieve mutual authentication in a Ethernet environment by my colleague Khurram Jahangir. Client machine: 802.1x client in Windows XP, Authenticator: HP 2524 switch and Authentication server: FreeRADIUS 1.0.1

5.2. SOLUTIONS UTILIZING PPP TUNNELS

Alice PPP/EAP "client"

NAS PPP "server"

AAA RADIUS/ EAP server

1: PPP EAP Request/ID EAP Iden− tity phase

2: PPP EAP Response/ID

RADIUS Access Request

EAP Auth− entication phase (AKA)

3: PPP EAP Request (AKA Chall, MIC)

RADIUS Access Chall. (AKA Chall, AUTN, MIC)

Verify AUTN and MIC Compute RES and MIC

4: PPP EAP Response (AKA Chall, RES, MIC) 5: PPP EAP Success

Acquire AUTN and MIC

RADIUS Access Request (AKA Chall, RES, MIC) RADIUS Access Accept

Verify RES and MIC

Figure 5.7: EAP-AKA authentication message exchange.

between Alice and the EAP server in a single round-trip in addition to the EAP identity handshake, see Fig. 5.7. When the EAP server receives the RADIUS Access Request containing the user identity, it will contact an “Authentication Center” to obtain an “authentication vector” to use in the subsequent AKA Challenge (not shown in Fig. 5.7 or equation 5.11). EAP-AKA has a fast reauthentication mode, where this additional communication between the EAP Server and the “Authentication Center” is avoided. NEAP-AKA = NEAP,id + 3 LOTT + 3 ROTT = 5 LOTT + 4 ROTT

(5.11)

EAP-AKA provides a mechanism for identity hiding, and as it requires relatively few messages to be exchanged upon a handover, it is an attractive candidate as authentication method for public WLANs. Drawbacks with this approach are that it requires a SIM card slot/reader in the handset, and that it primarily target ISPs which are also GSM/3G operators.

5.2.4

PPP over Ethernet (PPPoE)

With PPP over Ethernet (PPPoE[97]), a point-to-point connection is established directly over a broadcast LAN such as Ethernet or IEEE 802.11. PPPoE is wellsuited for open access networks. For example, each ISP could have a PPPoE server in the layer-2 access network, and the customer could select which ISP to use by setting a proper Service-Name during the PPPoE server discovery procedure. PPPoE discovery mechanism works similar to DHCP[40], and is shown in Fig. 5.8. The client broadcasts a message (PADI), which multiple PPPoE servers may reply to (PADO). The client then indicates which of the offers it selects (PADR) and this message is acknowledged by the selected server (PADS). After this the regular PPP setup (LCP etc.) takes place. Thus,

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice PPPoE "client"

NAS PPPoE "server"

AAA RADIUS server

1: PPPoE Initiate (PADI) PPPoE discovery phase

2: PPPoE Offer (PADO) 3: PPPoE Request (PADR) 4: PPPoE Confirm (PADS)

PPP Establishment LCP, authentication, etc.

Figure 5.8: PPPoE discover mechanism

a PPPoE solution would require two additional round-trips between the client and server as compared to the regular PPP setup presented in the previous sections, plus any additional delay at the client for collecting multiple PADO packets. RFC 2516[97] does not specify any such delay, and we recommend a PPPoE client to pick the first PADO it gets with the correct Service-Name. Motivations for this are given below: • Multiple PPPoE servers, one replies: If an ISP has more than one PPPoE server on a LAN configured for a specific “Service-Name”, it seems reasonable that the ISP (and not the customer) decides which PPPoE server to be used. Thus, only one PPPoE server ought to reply. • Multiple PPPoE servers reply: Even if more than one PPPoE server responds for the “Service-Name” specified by Alice, she can react immediately after receiving the first offer. – At start-up: When Alice turns on her IP phone and connects using PPPoE she could pick the first offer given, but record subsequent offers in a cache. In the rare cases when there is a problem with the selected PPPoE server (e.g., a misconfigured or fake PPPoE server) the client could disconnect from that server and pick one of the others. – After handover: Alice should initiate a PPPoE discover after performing a handover. If the handover is between APs on the same LAN, she could simply abort the PPPoE discovery and continue

5.2. SOLUTIONS UTILIZING PPP TUNNELS

using her prior PPPoE server, even if another PPPoE server on the LAN replies first. Making the PPPoE client act this way should not be a problem. If she records the offerings from the prior discovery, she should realize/guess that she is on the same LAN if any of the recorded servers replies first. The message exchange shown in Fig. 5.8 was verified using the Linux Roaring Penguin PPPoE software (RP-PPPoE9 ). In these tests, the PPPoE server seemed to be slow to transit from PPPoE discovery to PPP link state establishment state, resulting in loss of the first LCP request from Alice causing a timeout delay of 3 seconds. However, the PPPoE server in the RP-PPPoE package is included primarily for testing PPPoE clients and not for commercial use. The additional delay for using PPPoE as compared to a regular PPP setup should therefore correspond to two round-trips between Alice and the local NAS. NPPPoE = 4 LOTT

5.2.5

(5.12)

Point-to-Point Tunneling Protocol (PPTP)

Alice’s host could be configured to setup a “layer-2” tunnel to a point-to-point tunneling protocol (PPTP[55]) server of her ISP. In PPTP terminology Alice’s host would be a PPTP access concentrator (PAC) and the NAS would be a PPTP network server (PNS). Here we assume that the ISP has a PNS located in the access network, but in principle it would be possible to tunnel the traffic across the Internet to a PPTP server at the ISP’s home premises (see also section 5.4.4). As shown in Fig. 5.9 the PPTP connection setup would result in 3 roundtrips between Alice (PAC) and the NAS (PNS), but also results in 4 roundtrips between the PAC and some other entities. Below the steps of the PPTP connection establishment are explained further. • When Alice has associated with an AP, she can use DHCP to acquire an IP address for her WLAN interface and other relevant IP configuration information (default router, DNS server, etc.). This IP address does not necessarily need to have global significance; it could be a private IP address not routable from the Internet. The time to acquire an IP address using DHCP is implementation dependent and may include random waiting times, however, here we will assume that DHCP clients and servers use optimizations as those we suggested in [177, 172] (see also section 6.3). • Once Alice has configured her IP address etc. she could use this information to reach local servers (video servers, public information, etc.), but also a PNS of an ISP with a local presence in order to gain access to the global Internet. The steps of this PPTP connection establishment are shown below: 1. DNS lookup of PNS : To resolve the domain name of her PNS (e.g., local-pns.ispA.com) she contacts the local DNS server. This lookup 9 Roaring Penguin PPPoE, see http://www.roaringpenguin.com/penguin/open source rppppoe.php

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice PPTP client (PAC)

Router

NAS (DHCP/ PPTP server (PNS) DNS)

AAA RADIUS server

1: DHCP Discover 2: DHCP Offer 3: DHCP Request

DHCP addr. conf.

4: DHCP Ack 5: ARP Request 6: ARP Reply 7: DNS Request PPTP establish− ment

8: DNS Reply 9: TCP SYN 10: TCP SYN, Acknowledge 11: PPTP Start Ctl Conn Request 12: TCP Acknowledge 13: PPTP Start Ctl Conn Reply 14: PPTP Outgoing Call Request 15: PPTP Outgoing Call Reply PPP Establishment LCP, authentication, etc.

Figure 5.9: PPTP connection setup

should be relatively fast, since we assume the DNS server keeps this address mapping locally. Before the DNS lookup message can be sent, the PAC needs to resolve the IP/MAC mapping of the “next hop”. (As we pointed out in [177], this local round-trip could be avoided if this mapping was learnt during the DHCP procedure. However, such optimizations require integration/adaption of client

5.2. SOLUTIONS UTILIZING PPP TUNNELS

IP packet Link Hdr

IP Hdr

GRE Hdr PPP Hdr

PPP payload Encrypted (MPPE)

Figure 5.10: PPTP data encapsulation.

processes.) 2. PPTP control connection establishment: The PAC establishes a separate control connection to the PNS. Since TCP is used for this connection, an additional round-trip is required before the Connection Request message (message 11) can be transmitted. After receiving a Connection Reply message, an Outgoing Call Request/Reply handshake follows, resulting in 3 round-trips for the actual PPTP connection setup (messages 9-15) or 7 round-trips including DHCP, ARP and DNS handshakes. 3. PPP handshake: Before actual data messages can be sent over any PPTP session, the PPP connection establishment handshaking, as described in section 5.2.1, needs to be carried out. Since PPTP does not include any security services itself, MPPE would be negotiated during the PPP setup. NPPTP = 14 LOTT

(5.13)

Fig. 5.10 shows the PPTP packet encapsulation. In verification tests carried out10 , the overhead between Alice and the NAS was 20 bytes IP header, 12 bytes GRE header and 1 byte for a compressed PPP header.

5.2.6

Layer-2 Tunneling Protocol (L2TP)

An alternative similar to the PPTP solution above would be to utilize L2TP[168] to setup a connection between Alice and the NAS. As for PPTP, L2TP is used to establish a PPP connection over an IP network. The major differences concern: • Data encapsulation format: With L2TP the data packets are sent using UDP transport (see Fig. 5.11), while PPTP uses a GRE header on top of IP. The total overhead for L2TP in a conducted test was 20 bytes IP header, 20 bytes ESP header/trailer, 8 bytes UDP header, 8 bytes L2TP, and 2 bytes PPP header (58 bytes in total). • Control channel: L2TP uses UDP transport for control messages, while PPTP uses TCP. 10 Verification tests were http://www.poptop.org/.

carried

out

using

the

Poptop

PPTP

Server

for

Linux,

100

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

IP packet Link Hdr IP Hdr ESP Hdr UDP Hdr L2TP Hdr PPP Hdr

PPP payload

ESP Trailer

Encrypted Integrity protected

Figure 5.11: L2TP data encapsulation.

• Security: Secure L2TP connections are commonly achieved by use of IPSec[119]. Although the same approach would be possible for PPTP, common PPTP implementations rely solely on the PPP security mechanisms to protect the data. In L2TP terminology Alice’s host would be a L2TP access concentrator (LAC) client and the server would be a L2TP network server (LNS). As with PPTP we assume that Alice’s ISP has a LNS located in the access network. Fig. 5.12 illustrates the procedure to bring up a L2TP connection. Many of the steps are the same as for PPTP: • DHCP handshake: Alice needs to acquire an IP address, e.g., by using DHCP. • DNS lookup: Alice needs to do a DNS lookup to resolve the LNS domain name (e.g., local-lns.ispA.com). • IPSec handshake: If additional security is desired, an IPSec tunnel should be established between the mobile station (LAC) and the LNS[119]. By using IPSec to protect the L2TP connection, we could utilize IPSec’s security services for user authentication, confidentiality, per-packet authentication/integrity, and replay protection. To establish this IPSec tunnel, IKE[58, 79] or any other appropriate keying protocol needs to be executed between the LAC and LNS. Fig. 5.12 assumes that IKEv1[58] with main mode is used in IKE phase 1 (provides identity hiding). Use of aggressive mode would lead to a shorter IKE phase 1. IKEv2[79] is an attractive alternative to IKEv1, however IKEv2 is not yet standardized. When IKEv2 becomes widely deployed an access network solution based on IKEv2 and IP-IPSec tunnels, as designed by the IETF PANA WG, would probably be more desirable than the L2TP/IPSec approach described here. IP-IPSec implies less overhead, and in case Alice reconnects to the same NAS after a handover, IPSec tunnel reestablishment may be skipped according to work being done within the IETF MOBIKE WG. • L2TP tunnel establishment: Alice and the LNS will first need to establish a tunnel and control connection using a 3-way handshake (start control connection “request” (SCCRQ), “reply” (SCCRP), and “connected” (SCCCN)). During the tunnel establishment, an end-point may require the

5.2. SOLUTIONS UTILIZING PPP TUNNELS

Alice

Router

L2TP client (LAC)

101

NAS

(DHCP/ L2TP server DNS) (LNS)

AAA RADIUS server

DHCP Exchange (2 round−trips)

ARP/DNS (2 round−trips)

IKE Phase 1 handshake (3 round−trips)

L2TP establish− ment

IKE Phase 2 (1.5 round−trip) 1: L2TP Control (SCCRQ) 2: L2TP Control (SCCRP) 3: L2TP Control (SCCCN) 4: L2TP In Call Req (ICRQ) 5: ZLB Ack 6: L2TP Control (ICRP) 7: ZLB Ack 8: L2TP Control (ICCN) 9: ZLB Ack PPP Establishment LCP, authentication, etc.

Figure 5.12: L2TP/IPSec connection establishment procedure.

102

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

remote side to authenticate itself using a CHAP-like mechanism, where the authentication messages would be included in this 3-way handshake; as we assume the use of IPSec to secure the L2TP connection, this optional authentication would not be needed. • L2TP session establishment: Once the L2TP tunnel is up, Alice would initiate the establishment of a L2TP session to the LNS, using another 3-way handshake (incoming call “request” (ICRQ), “reply” (ICRP), and “connected” (ICCN)). Fig. 5.12 also shows additional acknowledgement messages (zero length body (ZLB)), as seen when making a verification test setup. (The L2TP/IPSec message exchange in Fig. 5.12 was verified in a test setup using the built-in IPSec support in Linux 2.6.10, Openswan 2.3.011 , L2TPd 0.6712 and pppd 2.4.3[133], by help of my colleague Johan Bilien.) • PPP handshake: Before actual data messages can be sent over any L2TP session, the PPP connection establishment handshaking, as described in section 5.2.1, needs to carried out. If IKEv2 had been used to establish the IPSec connection, Alice could have authenticated to her AAA server (with EAP) during the IKEv2 handshake. In Fig. 5.12 we instead assume that Alice will authenticate with her AAA server during PPP connection establishment. Since IPSec protects the data no MPPE negotiation is necessary. The number of network traversals required to establish the L2TP tunnel is shown in equation 5.14. (5.14) NL2TP = 22 LOTT When the PPP connection has come up data packets can start to be exchanged via the LNS (issues regarding IP level mobility will be examined in the next chapter).

5.3

Solutions using IEEE 802.11 security enhancements

IEEE developed the IEEE 802.1X standard for port-based network access control of LANs and MANs[72]. IEEE 802.1X has later been utilized in the standard for WLAN security enhancements defined by the IEEE 802.11 Task Group I (IEEE 802.11i[70]). In IEEE 802.1X terminology the user’s station is called a supplicant and the NAS enforcing access control is called an authenticator. In order to gain access, the supplicant needs to authenticate itself to an authentication server (AS), which may reside inside or “behind” the authenticator from the supplicant’s point of view. The authenticator would typically be integrated in an Ethernet switch, thus no additional network devices would be necessary. For each access port an authenticator would associate two logical ports: a controlled port where only traffic from an authorized user may pass and an uncontrolled port which would be used to pass EAP[2] authentication messages 11 Openswan,

http://www.openswan.org/

12 http://www.l2tpd.org/

5.3. SOLUTIONS USING IEEE 802.11 SECURITY ENHANCEMENTS

103

between the supplicant and the AS. Once the supplicant is successfully authenticated (and authorized) the AS will notify the authenticator, which in turn will open up the associated controlled port. IEEE 802.11i makes use of IEEE 802.1X in its Robust Security Network (RSN) framework. IEEE 802.11i further specifies that for RSN both the supplicant and the authenticator should implement the controlled/uncontrolled port model and accordingly only EAP methods able to perform mutual authentication can be negotiated, e.g., EAP-TLS[3]. In addition to this, the usage of IEEE 802.11 WLAN and in particular the IEEE 802.11i standard implies some further differences to IEEE 802.X, which are of interest to us.: • AP as authenticator: The WLAN AP is used as authenticator instead of, e.g. an Ethernet switch. Port access control is performed for a logical port - the association between the mobile station and the AP - rather than for a physical (Ethernet) port. • Data protection over the wireless link: IEEE 802.11i specifies algorithms and encapsulation formats required to provide confidentiality, per-packet authentication/integrity, and replay protection over the wireless link (between supplicant and authenticator). Two alternatives exist: CCMP which is more secure but requires devices capable of performing AES processing, and TKIP which was designed to run on legacy equipment originally designed for WEP processing. • Key hierarchy and management: The supplicant and the authenticator require session keys for securing the WLAN link. A master session key is created at both the supplicant and the AS as a side-effect of their mutual authentication, and this master session key is transported (securely) to the authenticator from the AS. The supplicant and the AS perform a 4-way handshake based on this key, and each create the necessary encryption and authentication session keys to protect transmission of data packets. • IEEE 802.11 (re)association: An AP provides information about its security capabilities in its beacon and probe response messages. • Pre-authentication option: In order to speed-up handovers a mobile station could establish a master session key with a candidate new AP before disassociating with its current AP. Once the mobile station has reassociated with the new AP, only the 4-way handshake needs to be carried out. Fig. 5.13 presents an overview of the IEEE 802.11i handover procedure when pre-authentication is not used. Before any of the authentication messages can be exchanged, the IEEE 802.11 (re)association process needs to be carried out, as described in the previous chapter. The only difference in the IEEE 802.11 reassociation process would be the inclusion of enhanced security capability information in some of the messages - no additional messages would be needed to the procedure outlined in the previous chapter. The authentication phase may require several round-trips between the Alice and the AS, depending on the authentication scheme negotiated and the size of the messages to be carried by EAP, as described in section 5.2.3.

104

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice 802.1X supplicant

NAS/AP 802.1X authenticator

AAA RADIUS

IEEE 802.11 association (Includes RSN capability info) EAPoL Request/ID EAPoL Response/ID EAP Auth− entication

Authentication handshake EAPoL Success

4−way handshake create RSN security association between AP and Alice

RADIUS Access Request

RADIUS Access Accept

1: EAPoL Key Msg 2: EAPoL Key Msg 3: EAPoL Key Msg 4: EAPoL Key Msg

Figure 5.13: Overview of IEEE 802.11i handover.

Following the authentication phase is the 4-way handshake used to establish the necessary encryption and authentication/integrity keys. Section 5.3.1 will examine this 4-way handshake in more detail. Section 5.3.2 will consider the impact of the IEEE 802.11i pre-authentication feature on the handover latency. In section 5.3.3 we will examine how the concept of splitting the AP functionality into wireless termination points (WTPs) and access concentrators (ACs) may affect the IEEE 802.11i security framework.

5.3.1

4-way handshake

The 4-way handshake is used to perform mutual authentication between Alice and the authenticator/AP, and to derive “session keys” and negotiate security protocols to protect the data traffic between Alice and the AP. The authentication is based on the primary master key (PMK) created by Alice and the AS during EAP authentication. The PMK is (securely) transferred to the AP in the Access Accept message. Two security protocols can be used to protect the data: the temporal key

5.3. SOLUTIONS USING IEEE 802.11 SECURITY ENHANCEMENTS

105

integrity protocol (TKIP) and the “CTR with CBC-MAC protocol” (CCMP). TKIP has been designed with the constraint to work on legacy “WEP-based” WLAN equipment. New WLAN equipment should implement support for CCMP, which uses AES for encryption and is more secure. As an outcome of the 4-way handshake Alice and the AP will have encryption and integrity/authentication session keys to use with CCMP or TKIP. The AP will also transfer a group key to Alice used for multicast traffic from the AP. For details on the 4-way handshake we refer to the IEEE 802.11i[70] standard and the security analysis conducted by He and Mitchell[61]. Although obvious, equation 5.15 shows the number of messages in the 4-way handshake. However, one should note that the first message of the 4-way handshake can be sent back-to-back to the last message of the EAP authentication exchange (EAPoL Success, see Fig. 5.13). Similarly, the first message of a subsequent message exchange (e.g., a DHCP Discover message) can be sent in the same direction as the last message in the 4-way handshake. Thus, in practice the 4-way handshake may only add 2-3 messages to the number of sequential exchanges. N80211i,4-way = 4 LOTT

5.3.2

(5.15)

Pre-authentication

If the message exchange shown in Fig. 5.13 has to be carried out every time Alice performs a handover, the interruption in communication may be significant. The component that will involve the largest delay would be the EAP authentication handshake, since it may involve network delays corresponding to several round-trips to a (likely) distant authentication server and possibly extensive cryptographic processing. One option to remedy this issue would be to transfer “the cryptographic context” from the “old AP” to the “new AP” upon a successful 802.11 reassociation, e.g., by utilizing the Inter-Access Point Protocol (IAPP) designed by the IEEE 802.11 Task Group F (IEEE 802.11F[69]). However, since the use of IEEE 802.11F to transfer security context has not been standardized, and since IEEE 802.11i, provides a mechanism known as pre-authentication addressing the issue of fast handover support, we will assume the use of IEEE 802.11i pre-authentication for this purpose. With IEEE 802.11i pre-authentication the EAP Authentication handshake would be decoupled from the handover procedure. Once Alice learns about a candidate AP she would be able to exchange the necessary EAP messages with it via its current AP. Thus, Alice and the candidate AP would establish a common PMK while she is still associated with the “old AP”. Alice will include the identifier of the negotiated PMK (PMKID) in her reassociation request. If the AP finds that PMKID in its PMK cache, it will immediately initiate the “4way handshake” instead of the full EAP authentication, see Fig. 5.14. Thus, with pre-authentication support handovers within an ESS could be handled efficiently. An issue for Alice is to find out what APs to pre-authenticate with. One alternative is to search for APs using IEEE 802.11 scanning. Another approach

106

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice 802.1X supplicant

NAS/AP 802.1X authenticator

IEEE 802.11 reassociation (Includes RSN capability info) 4−way handshake create RSN security association between AP and Alice

1: EAPoL Key Msg 2: EAPoL Key Msg 3: EAPoL Key Msg 4: EAPoL Key Msg

Figure 5.14: IEEE 802.11i handover when PMK is acquired via preauthentication

would be for Alice to ask some entity within the infrastructure about APs in the vicinity. We will describe these approaches further below: • Scanning: A straightforward approach would be for Alice to perform IEEE 802.11 scanning to find out about APs within her vicinity supporting IEEE 802.11i pre-authentication. However, as we saw in chapter 4 searching for APs leads to loss or delay of packets, something we like to avoid during an ongoing call. To limit the impact of AP scanning several approaches can be tried: – Audio processing in end-nodes: Alice and Bob could utilize ideas presented in chapter 2. Some of these ideas require that Alice gets a hint about an upcoming scanning procedure (the difference compared to a handover situation is that now the scanning is planned): ∗ Use of FEC and PLC: In chapter 2 we described how Alice and Bob could use forward error correction and packet loss concealment techniques to recover from packet loss. Using these methods would make loss of downstream packets due to scanning less noticeable. Note that the tests in chapter 4 showed median consecutive packet losses of 2 packets without competing traffic (Fig. 4.13) and 4 packets with competing traffic (Fig. 4.25)13 . ∗ Trigger handover during silence: Alice could try to trigger handover during periods of mutual silence, or at least when she is 13 These are values from the early search phase when facing competing traffic. The search phase of the actual handovers lasted 124 ms on average (Table 4.2) affecting 6-7 packets. Most handover had an initial “lucky” packet, thus only 5-6 packets were generally lost during the search phase of the actual handover.

5.3. SOLUTIONS USING IEEE 802.11 SECURITY ENHANCEMENTS

107

silent herself. ∗ Increase play-out delay: Both Alice and Bob can increase their play-out delay temporarily. Bob would be able to play more of the packets Alice buffers during scanning, and Alice could recover from longer loss bursts if Bob increases his FEC lag. – Pre-authenticate with APs learnt during previous handover: Alice could pre-authenticate with the APs learnt during the search phase leading to her (re)associating with her current AP. This is a good approach which should be used; however, it will not enable her to pre-authenticate with APs located far away from the point where she last scanned/(re)associated. (If she is moving in one direction she is likely to enter and leave cells in opposite direction.) – Pre-authenticate with APs learnt during next handover: Alice could postpone scanning until a handover is about to occur and pre-authenticate between scanning and handover execution, relying on the assumption that handover can be triggered before losing connectivity with her current AP. It is only time critical to preauthenticate with the AP she intends to make handover to. Preauthentication with other APs can be done after handover, as described above. • Using other mechanism via current AP: Instead of scanning, mechanisms based on communication via the current AP can be used: – Alice asks entity in infrastructure: Alice could use another protocol, such as CARD (presented in the next chapter), to learn about neighbor APs through the current AP. Use of CARD can also enable cross-ESSID handover as suggested in section 6.2.1. – Candidate APs contacts Alice: Another opportunity is to use IAPP (IEEE 802.11F[69]). With IAPP APs can dynamically learn about their neighbor APs. Unfortunately IAPP does not specify a method to convey this information to Alice. However, IAPP enables an AP to notify other APs in the distribution system that Alice has (re)associated with it, hence the neighbor APs would be able to initiate pre-authentication, by sending an EAPoL-start frame to Alice with appropriate “Ethertype”. Although this approach may be possible, it would not only require additional support in the APs, but also in the mobile stations, which makes this solution less attractive. Furthermore, deploying IAPP on the APs adds to system complexity.

5.3.3

Centralized authenticator service

A common trend when building larger WLAN access networks is to put some of the traditional AP functionality in a switch or router placed further inside the access network infrastructure. There are both security and management reasons behind this approach[113]: • Security: When introducing IEEE 802.11i with regular (stand-alone) APs, the authenticator is put in the AP. APs are often located in public

108

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

environments, which are difficult to physically secure. An intruder could bypass the 802.11i security functions and gain unauthorized access to the network by simply connecting directly via the AP’s wired backbone connection. By placing the authenticator functionality in a back-end switch located in a locked wiring closet, the risk for such attacks is reduced significantly. • Management: A centralized solution can be easier to configure, operate and upgrade. It may also simplify tasks such as coordination of radio spectrum between neighbor APs. In this distributed AP architecture the IETF CAPWAP WG denotes the device containing the radio interface a wireless termination point (WTP) and the back-end device an access concentrator (AC). The CAPWAP WG has described three main architecture alternatives of how to split the functionality between the WTP and the AC[185]: • Local MAC: Both the IEEE 802.11 PHY and MAC layers functionality are implemented in the WTP, while the AC handles the IEEE 802.11 management MAC messages. The authenticator generally resides in the WTP. • Split MAC: The IEEE 802.11 PHY and some of the IEEE 802.11 MAC layer functionality (control messages) is implemented in the WTP, while the AC handles the IEEE 802.11 management MAC messages. The authenticator generally resides in the AC. • Remote MAC: Only the IEEE 802.11 PHY is located in the WTP. The IEEE 802.11 MAC and other functions are located in the AC. The use of this centralized AP model are of interest here for two reasons. If some of the MAC protocol IEEE 802.11i messages are exchanged between the mobile station and a possibly distant AC (as opposed to the WTP) this may have a negative impact on the handover performance. The second reason is that this model may make the design of an operator neutral network more complex. Although the centralized AP model is commonly associated with division of IEEE 802.11i features, the PPP based solutions described in section 5.2 can also be considered as an approach within this model; as the NAS containing the PPP server would act as AC.

5.4

Achieving a secure operator neutral access network

In order for ISPs to deploy WLAN access networks with sufficient coverage, infrastructure sharing becomes an attractive approach. At some locations networks may even be owned by an organization, such as a housing company, requiring solutions where the customers can choose their upstream provider from a set of competing ISPs. The way to design such an operator neutral access network may differ for different sites. In this section we will describe various architectures supporting secure operator neutral access networks. We

5.4. ACHIEVING A SECURE OPERATOR NEUTRAL ACCESS NETWORK

109

Alice’s ISP

Visited network AAAF H

NAS

Internet

AAAH

Alice Figure 5.15: Roaming architecture

start out by presenting general concepts and issues for operator neutral access networks (section 5.4.1). Two key alternatives exist to implement operator neutral access: solutions based on roaming agreements and native solutions where each ISP has a point-of-presence (POP) in the access network. Although it can be questioned whether roaming solutions are to be considered as neutral, these approaches are relatively simple to deploy, thus likely to gain widespread use. Sections 5.4.2 and 5.4.3 describe roaming and native solutions respectively, and section 5.4.4 describes hybrid solutions where roaming and native approaches are mixed.

5.4.1

General concepts

In [17] Battiti et al. describe and motivate the use of operator neutral access networks. By establishing shared access networks marker barriers are lowered, since ISPs and other service providers can connect without high investment costs. This will in turn enable competition between service providers, resulting in innovative services and attractive prices for the customers. When Alice connects via an operator neutral access network, she first needs to select what ISP to use. In sections 5.2 and 5.3 we have described NAS solutions based on PPP and IEEE 802.11i. Both these approaches have the desirable property that network selection and AAA can be performed before Alice acquires a global IP address from the selected ISP.

5.4.2

Single ISP with POP - Roaming

The simplest approach to share WLAN infrastructure between ISPs would be to utilize roaming. That is, only one ISP would have a point-of-presence (POP) at a particular WLAN access network, and only end-users that are customers of that ISP, or of another ISP with a roaming agreement with this ISP, would be authorized to connect. Fig. 5.15 shows the layout of such a roaming solution. Alice will gain access to the Internet via the NAS, which could be implemented using any of the technologies described in sections 5.2 and 5.3 (i.e., the NAS could be a PPPoE, L2TP, or PPTP server, or IEEE 802.11i authenticator). The required message exchange for these protocols has been described earlier; however, those messages which involve user authentication would be forwarded by the NAS to a local AAA server (AAAF) and from there proxied to the AAA server of the customer’s ISP - the home AAA server (AAAH).

110

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Scheme PPPoE PPPoE SR PPTP PPTP SR L2TP IPSEC L2TP IPSEC SR 802.11i 802.11i SR 802.11i PA

Encr Y Y Y Y Y Y Y Y Y

MIC N N N N Y Y Y Y Y

IP Y Y Y Y Y Y N N N

In-LAN LOTT ROTT 0 0 0 0 0 0 0 0 0 0 0 0 15 12 9 6 3 0

Cross-LAN LOTT ROTT 24 12 18 6 38 12 32 6 42 12 36 6 15 12 9 6 NA NA

Table 5.1: Comparison of various roaming approaches

Assumptions when computing resulting message exchanges in Table 5.1. • We assume that the AAA servers are RADIUS servers, however the newer Diameter is more secure and may become the new de-facto standard for AAA servers (Diameter can use TCP or SCTP for transport, possibly affecting the number of network round-trips). The AAAH may in turn need to consult some other server where user data and credentials are stored, such as LDAP servers or SQL databases. This additional delay has been ignored. • When comparing the delay imposed by the various approaches we use the same terminology as in the previous sections where we distinguish between messages traversing the WLAN link (a local one-way trip time (LOTT ), the Internet back-bone (remote one-way trip time (ROTT ), and messages between (wired) entities within a local domain (ignored). • We assume that only messages involving the AAAH lead to a ROTT , i.e., only authentication messages resulting in a RADIUS exchange between the AAAF and AAAH. The DNS lookup done by the AAAF to find the AAAH is not considered to cause any delay, since we assume that the local DNS server will commonly have this mapping cached. • If two messages are sent back-to-back in the same direction, only one of them is counted. This means that the first message in an EAP identity handshake will not be counted when using 802.11i, since it follows the last message in the 802.11 handover execution. The same goes for the first message of an IEEE 802.11i 4-way handshake. • Without loss of generality, we have assumed the use of EAP-TLS for authentication when applicable. We consider two alternative scenarios when using EAP-TLS: (1) when the certificates included in the TLS Server Hello and Client Finished messages require 1.5 LOTT each (equation 5.9), and (2) when TLS session resumption (SR) is used (equation 5.10). • PPP based solutions:

5.4. ACHIEVING A SECURE OPERATOR NEUTRAL ACCESS NETWORK

111

– PPPoE: PPPoE could easily be used as NAS in this environment. PPPoE’s feature with a Service-Name to distinguish between ISPs would not be necessarily be used; unless different ISPs need to be managed differently they could all use the same PPPoE server. Multiple PPPoE servers could be used to avoid performance bottlenecks. As long as the handovers are done between APs serving the same LAN, there will no impact on the handover performance. For handovers between LANs, the number of messages exchanged are based on equations 5.1, 5.2, 5.4, 5.12, and 5.9 or 5.10 if TLS session resumption (SR) is used or not. NtotPPPoE

NPPPoE + NEAP−TLS, f rag + NMPPE + NIPCP

NtotPPPoE,SR

= =

24 LOTT + 12 ROTT (5.16) NPPPoE + NEAP−TLS,SR + NMPPE + NIPCP

18 LOTT + 6 ROTT

(5.17)

To allow local services several approaches could be used: ∗ The service providers could simply attach their servers somewhere in the access network, but in a subnet “behind” the PPPoE server from the mobile station’s point of view. Packets to/from the local servers will be routed thru the PPPoE connection just as any other traffic. ∗ Additional PPPoE servers could be put up for the various local servers. A user interested in watching a movie from a local service provider could open a new PPPoE connection with Service-Name “videostore”. This PPPoE connection should not update the default route. ∗ The local servers could be put on the same LAN as the mobile stations. Since the mobile station utilize DHCP to acquire an address on the same subnet as these servers, traffic will be send directly over the WLAN interface instead of through the PPPoE connection. The PPPoE connection should still be used for the default route. Although traffic to/from the PPPoE servers is protected by MPPE, various attacks can be launched within the access network. To some extent these threats can be defeated by adding appropriate filters in APs and L2 switches in the network, e.g., one might want to block mobile stations from replying to PPPoE discovery messages. One may also like to force all traffic (even between two mobile stations within the access network) to go via the PPPoE server. That would provide better possibilities to block an infected host from spreading viruses to other hosts within the local network. – Solutions based on L2TP or PPTP: The NAS could also be an L2TP or PPTP server. The access network could be a routed network with multiple IP subnets using the same NAS. Whether or not Alice connects to the same L2TP/PPTP server after a layer-3 handover, she has to reestablish the L2TP/PPTP tunnels and setup

112

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

the PPP connection. However, in case she connects to the same NAS after a handover, could use the PPP-multilink option[158], thereby avoiding IPCP renegotiation; she would be able to keep the same IP address (see also section 6.6). Below we show the total number of sequential messages exchanged after a handover across IP subnets for PPTP and L2TP, without considering the PPP-multilink option. The equations for PPTP are based on equations 5.1, 5.2, 5.4, 5.13, and 5.9 or 5.10 if TLS session resumption (SR) is used or not. For L2TP equations 5.1, 5.2, 5.9, 5.10, and 5.14 have been used. NtotPPTP

= =

NPPTP + NLCP + NEAP−TLS, f rag + NMPPE + NIPCP 38 LOTT + 12 ROTT (5.18)

NtotPPTP,SR

= =

NPPTP + NLCP + NEAP−TLS,SR + NMPPE + NIPCP 32 LOTT + 6 ROTT (5.19)

NtotL2TP

= =

NL2TP + NLCP + NEAP−TLS, f rag + NMPPE + NIPCP 42 LOTT + 12 ROTT (5.20)

NtotL2TP,SR

= =

NL2TP + NLCP + NEAP−TLS,SR + NIPCP 36 LOTT + 6 ROTT

(5.21)

Alice needs DHCP and DNS services to reach the L2TP/PPTP server, as well as local services. One could either use a single domain name for the L2TP server, or multiple (ISP specific) aliases, such as local-lns.ispA.com. Local services could be achieved, either by putting them on the same subnet as the mobile stations, or by requiring Alice to open another L2TP/PPTP connection to each service. • Solution using IEEE 802.11i: When using IEEE 802.11i in the roaming solution, the AP (or AC in a WTP/AC design) would act as NAS, which forwards authentication messages to the AAAH via the AAAF. For IEEE 802.11i we will have fewer local messages exchanged for cross-LAN handovers (as compared to the PPP-based approaches), but more local messages for handovers within the LAN. We consider three cases for EAP authentication: TLS with fragmentation, TLS with session resumption (SR), and pre-authentication (PA). As we assume that the first message in the EAP identity handshake and the IEEE 802.11i 4-way handshake are sent back-to-back in the same direction as the message before them equations have been reduced with the corresponding LOTT s. Ntot80211i,L2

NEAP−TLS, f rag + N80211i,4−way − 2 LOTT

= =

15 LOTT + 12 ROTT NEAP−TLS,SR + N80211i,4−way − 2 LOTT

(5.22)

Ntot80211i,L2,SR Ntot80211i,L2,PA Ntot80211i,L3

= = =

9 LOTT + 6 ROTT N80211i,4−way − 1 LOTT = 3 LOTT Ntot80211i,L2 = 15 LOTT + 12 ROTT

(5.23) (5.24) (5.25)

Ntot80211i,L3,SR

Ntot80211i,L2,SR = 9 LOTT + 6 ROTT

(5.26)

5.4. ACHIEVING A SECURE OPERATOR NEUTRAL ACCESS NETWORK

5.4.2.1

113

Advantages and disadvantages of the roaming model

It can be discussed if a roaming solution can really be called operator neutral as the local ISP may, e.g., favor its own customers in terms of prices or quality of service. If such considerations are of concern it may still be possible to use a model based on roaming by introducing certain policy rules. An example would be if the local ISP was run by some neutral organization (e.g., on a contract by the municipality or a housing company) which would not be allowed to have any end-customers itself. That is, the local ISP would provide IP addresses and upstream connectivity to customers of other ISPs. Advantages of the roaming model are: • Standardized solutions exist: AAA protocols and implementations for roaming have been available for a long time. Today RADIUS is the most widely used protocol, while its successor Diameter has recently been standardized by the IETF. • Simplicity: The solution is very simple to understand and to implement. The main effort concerns the establishment of roaming agreements and to deploy/configure the related servers. • Cost: There is no need for each ISP to have a point of presence at every access network. • Responsibility/control: The operator in control of the NAS is also the one carrying the data traffic. With the native approaches described in section 5.4.3 this is not always the case. • Local servers/services: In this model it is easy for a local application service provider (e.g., a video store, or service provider with content specific to a certain location) to hook up their server to the wired side of the access network. Since all end-users have an IP configuration assigned by the local ISP there would not be any issues related to routing - all endusers would be able to reach the local services without having to go via some external ISP. The main drawbacks of the routing model would be: • ISPs and other service providers will be dependent on the local ISP, which makes this solution less neutral and less open to competition. • The local ISP may not have enough public IP addresses to serve end-users from all other ISPs. (With IPv6 this would not be a problem; today’s lack of public IP addresses are commonly handled by use of NAT gateways, an approach that brings its own set of problems.) • Establishment of roaming agreements may be cumbersome.

5.4.3

Multiple ISPs with POP - native operator neutral access

In contrast to the roaming model where only one ISP is present, the native operator neutrality model requires every ISP to have a POP in the access network. The native model becomes more complex in several aspects:

114

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

• The customer needs a mechanism to select (and change) which ISP to use as their upstream. Since the selection of ISP will affect what (global) IP address the mobile station will get, this ISP selection is best handled by mechanisms not relying on IP transport14 . • The traffic stream associated with different ISPs should be separated15 . Thus, if one ISP has problems with users running DHCP servers on the hosts, this should not cause any problems for the other ISPs. • Due to isolation of traffic streams, enabling local services of independent service providers in the access network becomes more complex, and so does optimized peer-to-peer networking between customers of different ISPs. In the following sections we describe mechanisms to select the ISP without depending on a (global) IP address being assigned by the ISP. For each method, a way to isolate traffic streams will be described as well as possibilities to provide local services. The required message exchange to establish a secure connection is also commented. Section 5.4.3.1 describes a simple method where each AP announces multiple ESSIDs. Section 5.4.3.2 covers how ISP selection can be accomplished with PPPoE while section 5.4.3.3 examines the use of PPTP and L2TP. Section 5.4.3.4 demonstrates approaches based on IEEE 802.11i. 5.4.3.1

ISP selection based on ESSID/BSSID

It is possible to enable each physical AP to act as multiple (virtual) APs, by assigning it multiple ESSIDs and BSSIDs, where each ESSID/BSSID pair could correspond to a specific ISP[4, 15, 36]. This low-level solution is relatively simple to implement and configure, but requires the deployment of special APs. A user selects their ISP by simply entering the appropriate ESSID configuration on their host. For an experienced user this is a simple procedure. For a beginner this may seem cumbersome; however, entering an ESSID is generally required even for non-shared access networks to avoid undesired attachment to other WLAN networks deployed in the same vicinity. A user can change ISP by changing the ESSID configuration on the local host. To isolate traffic for different ISPs the APs must be able to distinguish which ISP a certain packet (on the wired and on the wireless side) is associated with. On the wireless side we assume that each AP is assigned a BSSID per ESSID, i.e., the AP can use MAC address information on the packets it receives on the WLAN side to find out which ISP the packet should be forwarded to16 . 14 PPTP and L2TP are still ok, since the IP address used for the PPTP/L2TP tunnel is independent of the global IP address later assigned by the selected ISP. 15 Solutions with operator neutral access networks optimized for peer-to-peer traffic have recently started to appear[134]. In these solutions IP addresses from different ISPs are routed locally, i.e., without using BGP or other inter-domain routing protocols. Although interesting, such solutions have not been considered here. 16 There are some products on the market that use different WEP keys to separate the traffic “over the air”, however, this is not an appropriate solution, since it is not transparent to ISP customers. (Imagine that Alice occasionally attach via a network only serving customers of her ISP; unless this network also use WEP keys, Alice would need to switch to another “user profile” than in the shared

5.4. ACHIEVING A SECURE OPERATOR NEUTRAL ACCESS NETWORK

115

On the wired side the AP can be configured to forward/receive the data to/from the appropriate ISP using various tunneling techniques. Today IEEE 802.1Q (VLAN) is commonly used for this purpose, but in principle other tunneling techniques such as MPLS would also be possible. Using multiple ESSID/BSSID pairs will make the solution transparent to the end-user, i.e., the user will not see the difference between associating with an AP attached to a shared access network or one of its ISPs “private” access networks. The ISP selection does not require the use of an IP address and the mechanism to change ISP is simple. The same NAS mechanisms as described for the roaming approach would apply here as well, with the same number of message exchanges required as shown in Table 5.1. The major drawbacks of this ISP selection approach are: • Difficulty to provide local services: The customer traffic will be tunneled via the customer’s ISP by the AP. There is no straight-forward way to enable local service providers to attach to the access network and provide their services directly to the users, and this has multiple potential drawbacks: – Less competition for local services. – Increased complexity to provide local content or services to users without an ISP. – Network capacity consumption. A video server on the local network could be used for video-on-demand services directly instead of sending it over the Internet. To improve network capacity somewhat one could place Internet Exchange points close to the access network, however, the traffic would still have to go via the ISP’s routers instead of going directly to the end-users. The difficulty with delivering local services is not unique to the multiple ESSID/BSSID solution. The same situation will occur for IEEE 802.11i solutions (section 5.4.3.4). • Need for specific (non-standard) APs: This may make the APs somewhat more expensive to purchase, and it makes it more difficult for private persons (and others) to expand the network if that is desired. • Beacon and Probe Response overhead: With multiple ESSIDs per AP, more overhead for IEEE 802.11 Beacon and Probe Response messages will be required. This makes this solution less scalable. 5.4.3.2

ISP selection using PPPoE

When using PPPoE in a shared access network ISP selection can be accomplished based on the PPPoE Service-name. The number of messages exchanged upon handover would be the same as in the roaming approach (Table 5.1). The traffic from each user will be tunneled through the selected ISP, which affects the possibilities to provide local services. One alternative to enable Alice access network.) There are also problems about how to handle broadcast traffic as experienced in [16].

116

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

to access local services independent of her ISP is to let Alice open multiple “PPPoE tunnels”, one for her ISP and one (or more) to reach the local services. 5.4.3.3

ISP selection using L2TP and PPTP

When multiple ISPs have their own L2TP or PPTP server in the shared access network we suggest that ISP selection is accomplished using DNS. After acquiring her IP address Alice will contact the local DNS to resolve the name of her ISP’s NAS, e.g., local-lns.ispA.com (this DNS mapping can be configured in the local DNS). Thus the procedure to acquire network access would be as shown in Fig. 5.9 and 5.12. The number of messages exchanged upon handover would be the same as in the roaming approach (Table 5.1). To provide local services independent of the selected ISP one could either put the local services on the same subnet as the customers, or have Alice establish additional L2TP/PPTP tunnels to reach the local services. 5.4.3.4

ISP selection using IEEE 802.11i/EAP

When using IEEE 802.11i as NAS solution the EAP Response/ID sent from Alice during the EAP handshake can be used for ISP selection. Once Alice is authorized to access the network all data traffic could be mapped (by the AP) to that ISP, e.g., using VLAN techniques. However, using IEEE 802.11i in a shared access network adds new challenges and there are multiple ways in which it can be used. We distinguish the approaches based on which actor that is in control of the authenticator (i.e., the NAS) as described below. The number of messages exchanged upon handover would be the same as in the roaming approach (Table 5.1). Authenticator managed by access network operator The simplest approach would to accomplish an operator neutral network using IEEE 802.11i as NAS solution is let the access network operator control the authenticator. That is, the authenticator can be put in the APs (or ACs if a WTP/AC solution is used) managed by the access network provider. As proposed in [175] the APs could forward all authentication messages to a common authentication server (AS), i.e., a local AAA server (AAAF). The AAAF could act as a RADIUS proxy and forward the authentication messages to the AAA server of the appropriate ISP (AAAH), see Fig. 5.16. As a side-effect of a successful authentication/authorization RADIUS primitives could be used to inform the AP to map the user’s data traffic to a VLAN associated with the ISP, see Fig. 5.16. Alternatively the APs could be configured to dispatch the EAP authentication messages to the appropriate AAAH directly, thereby taking over the role of the AAAF. The major drawback of these solutions is that ISPs have no control of what traffic is entering their network. Thus, even if Alice’s ISP can authenticate Alice during the EAP handshake, the ISP relies on the access network operator to correctly enforce the access control. The ISPs may find such a solution unsatisfactory, however, the trust relation between an ISP and a local operator is not much different here than in an ordinary roaming situation.

5.4. ACHIEVING A SECURE OPERATOR NEUTRAL ACCESS NETWORK

117

Alice’s ISP (ispA.com)

Internet (and ISP backbones)

AAAH

Local IX Router of of Alice’s ISP R ISP1

VLAN (data)

R ISP2

AAAF AP

Authenticator

Alice

Figure 5.16: Access network operator in control of authenticator

ISPs enforcing access control Instead of locating the authenticator in the APs or a common AC, it could be located with each ISP. This solution could be viewed as an WTP/AC solution where each ISP runs its own AC. The EAP authentication messages may still be directed via a common AAA server (AAAF), but the PMK created during the EAP authentication exchanged should only be sent to the ISPs AC, not the AAAF. After the EAP success has been delivered to Alice, the subsequent 4-way handshake should be carried out between Alice and her ISP’s AC. This will require specific support in the WTPs and ACs, in order for the 4-way handshake to be transparent to Alice. In particular the AC should be able use the MAC address of the WTP (i.e., the BSSID) as source address when exchanging packets with Alice. Some appropriate tunneling technique should be used between the WTP and the AC.

5.4.4

Hybrid solutions

In addition to the pure roaming and native approaches to accomplish a shared access network as described in sections 5.4.2 and 5.4.3, one can consider using hybrids of these two approaches: • A shared access network could have multiple ISPs present (native operator neutrality). Other ISPs could establish roaming agreements with these ISPs. • An ISP which does not like to be “physically present” in the access network could still be allowed to serve its users remotely. For example, instead of placing a L2TP server in the shared access network, Alice could be allowed to tunnel her packets to a remote L2TP server in the ISP’s home network.

118

CHAPTER 5. SECURE PUBLIC WLAN INFRASTRUCTURES

Alice’s ISP (ispA.com)

Internet (and ISP backbones)

AAAH

Local IX Router of of Alice’s ISP R/AC ISP1 "Tunnel" (data)

Authenticator

R/AC ISP2

AAAF WTP

WTP

Alice

Figure 5.17: WTP/AC solution where each ISP has its own AC acting as IEEE 802.1X authenticator.

In the former approach there is a demand for a “dynamic roaming” protocol to be exchanged by the local AAA proxy (AAAF) and the AAA servers of the present ISPs. This roaming protocol would inform the AAAF about the roaming agreements between “present” ISPs and “non-present” ISPs, and could work similar to a dynamic routing protocol. Alternatively, this roaming information could be configured manually into AAAF. The design of such a dynamic roaming protocol is left to future work.

5.5

Conclusions of secure public WLAN infrastructures

In this chapter we have examined solutions to provide secure WLAN access in operator neutral networks. The focus has been on solutions based on PPP and IEEE 802.11i. In the following chapters we will limit the scope to IEEE 802.11i and L2TP/IPSec, since both meet the security requirements we have proposed. An issue with the L2TP/IPSec approach is that users may have difficulties to use L2TP/IPSec as NAS solution at the same time as they wish to use L2TP/IPSec as VPN solution to their company. Such “VPN in VPN” situations would not become a problem when IEEE 802.11i is used as NAS solution.

Chapter 6

IP Mobility support Although a majority of the handovers a user will make during a session can be handled by link layer mobility mechanisms (as presented in the previous chapters) we would also like our system to support handovers that occur across IP subnet borders. There are several situations in which a user may perform such a handover: • An ISP may have segmented its WLAN access networks into multiple smaller LANs instead of one big LAN to limit the amount of broadcast and multicast traffic. When Alice roams between two APs attached to different LANs this usually means that she needs to acquire a new IP address. • Since each ISP by itself is unlikely to provide all the WLAN coverage desired, Alice will sometimes need to roam between APs associated with different ISPs, i.e., ISPs with roaming agreements with Alice’s own ISP. • If Alice’s terminal is equipped with multiple interfaces (or a single physical interface able to associate with multiple APs simultaneously) a handover may occur between the different interfaces, and such a handover generally requires the use of a new IP address, although these addresses need not necessarily belong to different subnets. If the handover involves two different link technologies, e.g., WLAN and UMTS, we often refer to this as vertical handover. In this dissertation we have limited the scope of IP layer handover to the case where the handover occurs between WLAN APs and where the user terminal only has a single WLAN interface. Terminals with multiple WLAN interfaces are likely to be rare compared to the number of single interface devices. Vertical handovers between, e.g., WLAN/UMTS or WLAN/Bluetooth are likely scenarios, which can be seen as useful complements to this study. As part of a layer-3 handover Alice first needs to detect that she is actually connected to a new IP subnet. Opportunities and issues with respect to detecting layer-3 mobility are examined in section 6.2. The next step in a layer-3 handover procedure is to acquire a new careof IP address (COA) on the new subnet. For some of the PPP based access

120

CHAPTER 6. IP MOBILITY SUPPORT

control solutions described in the previous chapter, IP address assignment is an integral part, but for the IEEE 802.11i approach the IP address assignment process is normally handled separately. Section 6.3 examines various issues regarding address assignment, to a large extent based on the results of two of my papers[172, 177]. After Alice has acquired a COA she will be able to redirect the data flow of the ongoing voice call, both for incoming and outgoing data traffic. However, Alice cannot simply continue ongoing communication sessions after changing her IP address without appropriate mobility support, since the IP address is often part of what identifies these connections. In section 6.4 we describe and analyze the two main competitors for layer-3 macro-mobility support (Mobile IP and application layer mobility using SIP) as well as some layer-3 micro-mobility support schemes, with respect to their impact on the end-to-end delay and handover latency. Parts of this are based on another of my publications[173].

6.1

Assumptions

When a user moves to another IP subnet there may be additional IP layer issues to face in addition to redirection of data flows and avoid breaking ongoing sessions: Header compression To improve performance by better bandwidth utilization it is common to use data compression techniques over low-speed or error-prone links. Koodli and Perkins[85] present pro-active context transfer mechanisms enabling header compression state to be established at the new router in advance of the handover. In this dissertation, however, we have ignored handover effects due to header compression, since we target high-speed WLAN access where use of header compression is less important, and handover is more likely to occur than in a WMAN or WWAN. Bandwidth reservation/QoS Several studies have examined issues related to QoS for mobile Internet users, for example[135, 13, 48, 85]. As explained in section 2.5 we do not consider QoS in the context of RSVP[27] or Diffserv[22] in this dissertation. Availability of global IP addresses IPv6 addresses are 128 bits long, thus we consider the availability of global IPv6 addresses practically unlimited. With IPv4 the situation is different. The limited availability of routable IPv4 addresses have lead to the use of NAT gateways and private (nonroutable) IPv4 addresses in many access networks. In Mobile IPv4 Alice can either acquire an address of her own (a co-located COA) on the visited subnetwork, or use the IP address of a foreign agent. If Alice uses a foreign agent COA or a “private” co-located COA IPv4 addresses can be preserved. However, providing Alice with a “routable” co-located COA simplifies her ability to use optimal routing. In IPv6 networks we will assume Alice is provided with a routable address on the network she visits. In IPv4 networks we will focus on the case when Alice can acquire a routable co-located COA on the visited network, however, we will also consider the use of NATs and MIPv4

6.2. DETECTING LAYER-3 MOBILITY

121

FAs, since such solutions are likely to exist in access networks until IPv6 becomes widely deployed. Use of firewalls We will not consider the use of firewalls in the access network except for the “firewall function” of the NAS. Optimal routing Some layer-3 mobility management protocols require that packets between Alice and Bob are sent via their respective home networks. Although such approaches may be used as “fall-back” solutions we assume that optimal routing is critical to achieve good performance for the voice call between Alice and Bob. In IPv6 networks there are different ways to achieve optimal routing to mobile hosts, however, in IPv4 networks we assume that the lack of mobility support in deployed end-systems and the use of ingress filtering routers limit Alice to the use of “SIP mobility” to achieve optimal routing.

6.2

Detecting layer-3 mobility

Using information from the link layer to trigger layer 3 handover mechanisms is important. The alternative would be to use different layer 3 mechanisms to detect movement across IP subnets such as listening for periodic Router Advertisements from a Foreign Agent or ordinary router. Although the MIPv4[120] and MIPv6[77] standards relax the requirements on minimum router advertisement intervals for FAs or a MIPv6 router (MIPv6 routers are allowed to send unsolicited advertisements as often as every 50 ms on average), such frequent advertisements may burden the capacity of the link. Thus, we believe it is better for clients with ongoing real-time sessions to actively probe for routers after a WLAN handover, and we therefore assume that the mobile stations can utilize layer-2 triggers in their movement detection process. When Alice performs a handover between WLAN APs she may not know whether she still resides on the same IP subnet, or if she has made a layer-3 handover. With IEEE 802.11, APs which logically reside on the same network are configured with the same Extended Service Set Identifier (ESSID), i.e., all APs serving the same LAN would announce the same ESSID. However, in many WLAN access networks the ESSID has become an operator ID instead of a LAN ID. A major reason for this is simplicity for users; many users find it non-trivial to configure an ESSID, and requiring them to configure an ESSID for every LAN they may end up on would not be realistic. If the AP beacon messages had contained two separate identifiers, one LAN ID and one operator ID the task of detecting and managing layer-3 handovers would have been simplified. Although it would be possible to modify the beacon messages (as done in [86]), such an approach is unlikely to gain wide acceptance for IEEE 802.11 WLANs. Instead we limit the further discussion to the common cases when an ESSID is used to identify a LAN (section 6.2.1), or an operator (section 6.2.2).

122

6.2.1

CHAPTER 6. IP MOBILITY SUPPORT

Using the ESSID as a LAN identifier

If a single ESSID was configured only on APs serving the same LAN from Alice’s perspective1 , detecting a layer-3 handover would easily be accomplished without any additional layer-3 functionality. As soon as a handover is conducted between APs with different ESSIDs, Alice would immediately trigger her desired IP address assignment mechanism (section 6.3). However, supporting handover between different ESSIDs is a non-trivial task, since the problem of configuring which ESSIDs Alice should associate with would become complex. Furthermore, even if Alice was pre-configured with a list of ESSIDs, probing various ESSIDs until the right one is found (if any) extends the scanning phase dramatically. To address the issue of providing fast cross-ESSID handover some different approaches could be tried: • Alice could ask some entity within her current access network about information on APs in the vicinity that are able to provide access to her if a handover would become necessary. One possibility would be utilize the candidate access router discovery (CARD[91]) protocol, earlier under development within the IETF Seamoby WG. Here Alice would post a question such as “Hi, I’m [emailprotected]. Provide me a list of candidate access routers (CARs) which both have APs in the vicinity and a roaming agreement with my ISP. Along with each CAR, provide a list of BSSIDs/ESSIDs for these WLAN APs”2 . Alice could then manage a dynamic list of APs (BSSIDs/ESSIDs) to look for. In addition, if the response from her access router (AR) contains information about which channel these APs reside on, then the WLAN handover search phase (see chapter 4) could be significantly decreased. The drawbacks of this approach are that mobile stations would need to be upgraded to support these feature, and that servers (ARs and others) need to be installed/upgraded and configured within the access infrastructure. An interesting (and challenging) issue concerns how to handle handovers between different operators, e.g., it is not obvious why an AR in one operator’s access network would inform Alice that she could conduct a handover to an AP associated with one of its competitors. However, this is a “higher level” issue and less relevant to handover performance. Exploring the idea of using CARD for roaming purposes is left to future work. • An operator could utilize a small set of ESSIDs, and reuse them for different LANs in a similar way as frequencies are reused in a cellular network. Although Alice would need to scan for multiple ESSIDs (leading to longer search time) this may be acceptable if the list of ESSIDs is short. One could also consider optimizations where the search is limited to the “current” ESSID as long as such an AP is found. Drawbacks of this approach are the extended search time, and that users may find it cumbersome to enter multiple ESSIDs. Nevertheless, 1 Note that this case would also apply to situations where all APs serve a set of VLANs, as long as Alice always ends up on the same VLAN. 2 I posted this suggestion on the IETF Seamoby WG Mailing list Nov 25 2003 (Subject: Using CARD to find CARs with roaming agreement with my ISP?).

6.2. DETECTING LAYER-3 MOBILITY

123

this alternative is probably relatively easy to introduce, since many of the deployed WLAN hosts can be configured with multiple ESSIDprofiles, and would not require upgrading unless fast handover support is desired. • Avoiding cross-ESSID handover by either building a large layer-2 WLAN infrastructure3 or using the same ESSID for different LANs (section 6.2.2). The former approach would have drawbacks due to scalability of broadcast traffic, and the latter approach would not solve the cross-ESSID issue totally, since one may like to provide handovers between access networks of different operators.

6.2.2

Using the ESSID as an operator identifier

If the ESSID is used as an operator identifier host configuration is simplified, but as a consequence Alice would not know if she has made a L3- or only a L2handover when associating with a new AP. Support for cross-ESSID handover (as described in the previous section) would still be necessary to support handover between access networks run by different operators, since one can not generally assume that they will use the same ESSID. To address the case when Alice performs a handover between LANs (even if the same ESSID is announced) Alice can perform some kind of test after every handover, e.g, if PPPoE is used as NAS solution, sending a new PPPoE PADI message could be used to find out whether a layer-3 handover was performed or not (see section 5.2.4). For IEEE 802.11i NAS solutions, an ICMP Router Solicitation/Advertisement exchange would be a suitable method to check for layer-3 mobility4 . Note, since we are using IEEE 802.11 WLAN in infrastructure mode we can assume that two APs are either serving or not serving the same LAN, thus the appearance of a single new Router Advertisement (or PPPoE PADO) would suffice to indicate the occurrence of a layer-3 handover. Being “aggressive” we could allow the appearance of a new Router Advertisement to take precedence over earlier Router Advertisements, even though they may have remaining “lifetime”. This should be the default behavior (see also mobility detection support in MIPL[169, 108]). In addition to these re-active approaches the following pro-active mechanisms could be tried to predict the type of handover (layer-2 or layer-3) in advance of handover execution: • AP MAC/subnet caching: In-line with ideas of Shin et al.[156] Alice could cache information on AP/subnet mappings in addition to AP/channel information (see section 4.2), which would be beneficial when Alice roams within her commonly visited environments. • IEEE 802.11i pre-authentication: In section 5.3.2 we describe how Alice can pre-authenticate with another AP on the same LAN via her current AP. 3 E.g.,

as done in http://www.stockholmopen.net/ layer-3 mobility schemes even provide support to detect mobility across “domains”[52,

4 Some

171]

124

CHAPTER 6. IP MOBILITY SUPPORT

In case the “new AP” does not respond to the pre-authentication attempt, this indicates the AP resides on another LAN.

6.2.3

Summary of layer-3 mobility detection

Enabling mobility across WLANs with different ESSIDs is a non-trivial task, however, in the rest of the analysis we assume that this will not constitute a hindrance for those layer-3 mobility scenarios mentioned in the beginning of this chapter. We will assume that the layer-3 mobility support can utilize lower-level indications when a handover between APs has occurred and whether the handover was conducted between APs ”announcing” the same or different ESSIDs. If the handover is to a new ESSID, layer-3 mobility support mechanisms will immediately be invoked after finishing the access control handshakes (chapter 5). If the new AP instead announced the same ESSID, the mobile station will anyway initialize the layer-3 movement detection mechanism, primarily to check that it is still on the same network (or not).

6.3

Acquiring a care-of IP address

When Alice moves to a new IP subnet she generally has to acquire a new IP address. This is due to the dual nature of the IP addressing scheme, where an address is used both to uniquely identify an interface of a host and to identify the link to which interface is attached by applying the associated netmask/prefix. In section 6.5 macro-mobility support schemes such as Mobile IP (MIPv4[120], MIPv6[65]) and application layer mobility using SIP (”SIP mobility”[181, 155]) will be examined. When Mobile IP is used as a mobility support scheme, Alice is assigned a permanent home IP address, related to a (possibly virtual) home network. When Alice visits a foreign IP subnetwork, she will be identified by an additional, temporary address on the visited network, a care-of IP address (COA). We will use the term care-of IP address to denote the address Alice acquires on the new subnet, even though we note that one of the major mobility support schemes, application level mobility using SIP, normally does not use this term. This COA could be the address of a dedicated agent on the foreign network, i.e., a foreign agent (FA). The alternative is for the Alice to acquire a COA of her own (a co-located COA) on the visited network, e.g., by using DHCP[40]. Using foreign agent COAs allows multiple MNs to share the same COA (the address of the FA). This saves IP addresses compared to the co-located COA approach, where a pool of addresses on the foreign subnet must be reserved for visiting MNs. On the other hand, there exist several arguments for using colocated COAs, e.g, each MN will have more control of implementing its own routing policy[14] and FAs may become bottlenecks as they have to process each packet to every served MN. Furthermore, for Mobile IPv6 (MIPv6[65] and for SIP mobility the notion of FAs does not exist. In this section we will evaluate different COA assignment schemes, focusing on minimizing the associated delay (Tcoa ). Fig. 6.1, 6.2 and 6.3 describe the messages exchanged to acquire a COA in three interesting cases: MIPv4

6.3. ACQUIRING A CARE-OF IP ADDRESS

125

with FA, MIPv4/SIP with DHCP, and MIPv6/SIP with stateless address autoconfiguration. For the PPP based NAS solutions presented in the previous chapter Alice will acquire a co-located or foreign-agent COA as part of the access control handshaking. Thus, the task of acquiring a care-of IP address after NAS handshaking primarily applies to the case when IEEE 802.11i is used as NAS solution. Still, some of the mechanisms discussed here would apply for the other approaches too (e.g., PPTP, L2TP and PANA), since they involve steps to acquire an IP address before being able to contact their NAS. We have defined Tcoa , as the time from when Alice decides to acquire a new COA after having detected that she has entered a new cell, until she could send a Binding Update or SIP re-INVITE in order to redirect data flow of the ongoing voice session5 . As described in section 6.2 we assume link layer support to detect movement, i.e., in these three cases Alice is able to detect movement without waiting for unsolicited Agent Advertisements or Router Advertisements, or DHCP lease expiration. Processing and transmission times are not critical to achieve low Tcoa , as these times decrease with improved hardware performance and wireless link capacity. Instead, what may cause problems is that the involved entities may be hindered from reacting quickly by different timers. These timers are introduced by functionality for synchronization avoidance and duplicate address detection.

6.3.1

Synchronization Avoidance

Synchronization of processes on different machines may give rise to bursty traffic[46] and is thus considered undesirable. To avoid congestion, a node that decides to transmit a Router Solicitation to detect the presence of routers is recommended[39][109] to delay this transmission a random amount of time6 . For MIPv4 with FA (Fig. 6.1) and MIPv6 (Fig. 6.3) that would mean a delay in the interval 0-1 second[39][109] before Alice should transmit its solicitation. We admit that there may be situations where a set of users enter a cell about the same time and decide to transmit a Router Solicitation, however, we doubt that this will lead to considerable congestion. We suggest that the recommended random delay interval is decreased (or even skipped) to support low latency handover. Furthermore, the response from the router can also be delayed to avoid synchronization between routers. According to [39] the FA may delay a unicast and must delay (random value in interval 0-2 seconds) a multicast response to an Agent Solicitation. We have assumed that an FA responds with a unicast Agent Solicitation, thus this optional random delay is not shown in Fig. 6.1. In MIPv6, however, the router is required to delay the response (random 5 The issue of redirecting an ongoing data flow is described further in section 6.4, however, as shown in Fig. 6.1 and 6.2 Alice may need an additional WLAN round-trip for ARP resolution of her default router. In [177] we mention the possibility for avoiding this ARP check. Since the default router is commonly the same node as the FA or DHCP server (or relay), Alice could learn the MAC address of the router from earlier messages. 6 The transmission of a Router Solicitation (or Router Advertisement) may also be delayed if a Router Solicitation (or Router Advertisement) has recently been sent out on that interface.

126

CHAPTER 6. IP MOBILITY SUPPORT

Foreign Agent

Alice

Alice detects movement

Random Waiting Time

Care−of address retrieval (T coa )

Agent Solicitation Agent Advertisement GW

ARP Request Alice ready to use address

ARP Reply Binding Update

Figure 6.1: Acquiring a care-of address in MIPv4 with foreign agent

Alice detects movement

DHCP Server

Alice DHCP Discover

Duplicate Address Detection (by server)

DHCP Offer Care−of address retrieval (T coa )

DHCP Request

Duplicate Address Detection (by client)

DHCP Reply

ARP Request Alice ready to use address

ARP Reply Binding Update/re−INVITE

Figure 6.2: Acquiring a care-of address using DHCPv4

Alice detects movement Care−of address retrieval (T coa )

Alice

IPv6 Router Duplicate Address Detection/Random Waiting Time Router Solicitation Router Advertisement

Random Waiting Time

Binding Update/re−INVITE Alice ready to use address Figure 6.3: Acquiring a care-of address using IPv6 stateless address autoconfiguration

6.3. ACQUIRING A CARE-OF IP ADDRESS

127

value in interval 0-0.5 seconds) irrespective of the use of unicast or multicast. We question if this delay is relevant on links with few (usually only one) routers and argue that this delay interval should be decreased for high speed links. If synchronization of periodic (unsolicited) Router Advertisements is still of concern, one should avoid resetting the corresponding timer just because a triggered Router Advertisement is transmitted[46].

6.3.2

Duplicate Address Detection

When co-located COAs are used on multi-access networks, Alice or some other entity should verify the uniqueness of the assigned address to avoid address conflicts. There is always a risk that some user grabs an IP address without first checking with the system administrators or without using for example DHCP. To cope with such situations, DHCP and IPv6 stateless autoconfiguration use a feature known as Duplicate Address Detection (DAD)7 . To check whether an address is already in use, a node can transmit, e.g., one or more ICMP Echo Requests[132] and wait some reasonable amount of time to verify that no corresponding ICMP Echo Reply is received. In DHCP, it is recommended that DAD is performed by a DHCP server before sending a DHCP Offer and by a DHCP client after having received a DHCP Reply[40] (some DHCP client implementations perform DAD already after the receiving the DHCP Offer[177]), see Fig. 6.2. DAD may also be needed in IPv6, as Alice must make sure that her interface identifier is unique8 on each subnet she visits, see Fig. 6.3. The methods to address the issue with random waiting times due to DAD differs in IPv4 and IPv6 networks: • IPv4 networks: In IPv4 networks Alice could either acquire a co-located COA or use the address of a FA: – Co-located COA: In [177, 172] we proposed that the responsibility for DAD is left to the DHCP server (i.e., Alice does not have to deal with this), and that the DHCP server could do this as a background process (the same idea has later been proposed by McAuley et al. in the dynamic registration and configuration protocol (DRCP[100]). The DHCP server could regularly check the addresses in its “freelist” (or a subset thereof) and then immediately hand an address to a host when requested. This would lead to a reasonable level of robustness, while the time consuming “wait to see that nothing happens procedure” is left out of the time critical COA assignment process. To cope with the rare occasions when a DHCP server fails to detect an address conflict, the host could perform DAD reactively. Equations 6.1 and 6.2 show the delay for DHCP (in terms of network traversals and random wait times) before and after the suggested optimizations. In [177] we presented measurements 7 DAD is also used in dynamic address assignment schemes of other network protocols such as Appletalk and IPX[127]. 8 More precisely, addressed based on the interface identifier are tested for uniqueness.

128

CHAPTER 6. IP MOBILITY SUPPORT

for DHCP address assignment in an Ethernet environment using different DHCP client and server software. Tcoa,dhcp varied between approximately 2-16 seconds for the different combinations of clients and servers tested, where the client and server DAD mechanisms by far constituted the majority of the delay. After removing DAD from the address assignment process (assuming that the server could do it in the background) the remaining delay Tcoa,dhcp,opt was measured to roughly 100 ms on average. (We later found that this delay could have been reduced significantly, by using appropriate hardware on the DHCP server or modifying the server software. The DHCP server wrote information to the hard-disk before sending the DHCP Reply, and on the 100 MHz laptop used in this study disk I/O was slow.) Schulzrinne and Wedlund[155] suggest a further optimization of the DHCP latency, where Alice would be able to initiate the redirection of data already after receiving the DHCP Offer, thus achieving a Tcoa,dhcp,opt of 2 LOTT . This approach would be in-line with dynamic address assignment in DRCP[100]. – Foreign agent COA: Equations 6.3 and equation 6.4 show the delay of FA COA assignment with and without random wait times. In [172] I presented a FA COA assignment delay of 3 ms using CMU MIP 1.1.09 . CMU MIP did not do any random wait time, which is in-line with our recommendations. • IPv6 networks: In IPv6 networks it is more difficult to perform DAD in advance. Below we describe three different alternatives to remove the impact of DAD in IPv6: – Skip DAD: In [172] we suggested that DAD is removed from the time critical address assignment mechanism. As we interpret [166] the use of DAD is a recommendation rather than a requirement. Note that it is possible to construct a globally unique identifier according to the IEEE EUI-64 format[64], given that the interface is assigned a global identifier, e.g., an IEEE 48 bit MAC address (and given that all attached nodes follow this convention). The probability of having an address conflict is minimal, and could be resolved reactively, i.e., Alice could perform DAD after she has started to use the address (see also encapsulation suggestion by Koodli and Perkins below). Equations 6.5 and 6.6 show the delay for IPv6 address auto-configuration before and after the suggested optimizations. In [172] I measured the IPv6 address auto-configuration delay (Tcoa,ipv6 ) for INRIA’s IPv6 implementation to about 3 seconds. DADclient , which we would like to skip, took about 2 seconds. The Router Solicitation was delayed a random time in the interval 0.5 to 1.5 seconds (not 0 to 1.0, but the code could easily have been changed). The (unicast) Router Advertisement was transmitted immediately, without any random delay. 9 Mobile IPv4 implementation http://monarch.cs.cmu.edu.

developed

the

Monarch

research

group,

see

6.4. IP LAYER MOBILITY ISSUES AND APPROACHES

129

The impact of DAD on handover performance have later been studied by Nakajima et al.[108]. They present measurement results in-line with ours and they also suggest skipping DAD in the fast path. – Pro-active DAD using new AR: Koodli and Perkins describe a mechanism to perform DAD in advance even for IPv6[85]. Given that Alice is able to contact her new AR before executing the handover, the new AR would be able to test Alice’s new address, however, instead of “probing” the address they suggest the new AR to consult its neighbor cache. Koodli and Perkins also present an encapsulation mechanism which Alice could use on the new link in case she needs to send data before DAD has been confirmed successful. The concept of pro-active DAD is further explored in [84]. – DAD using new AR after handover: The proposal of Koodli and Perkins assumes Alice is able to contact the new AR in advance, e.g., using CARD. However, their proposal of having the new AR perform DAD by looking in its neighbor cache, and the use of a specific encapsulation format before DAD is confirmed successful, is useful even if Alice is unable to contact the new AR in advance. After the handover Alice would get an immediate response from the new AR, which is faster than waiting for an answer not to appear.

6.4

Tcoa,dhcp

4 LOTT + DADserver + DADclient

(6.1)

Tcoa,dhcp,opt Tcoa, f a

= =

4 LOTT R[0, 1] + 2 LOTT

(6.2) (6.3)

Tcoa, f a,opt Tcoa,ipv6

= =

2 LOTT max(DADclient , R[0, 1]) + R[0, 0.5] + 2 LOTT

(6.4) (6.5)

Tcoa,ipv6,opt

2 LOTT

(6.6)

IP layer mobility issues and approaches

When Alice connects to a new IP subnet she generally has to acquire a new IP address, e.g., using any of the techniques described in the previous section. Once the address has been assigned, she needs to take further actions in order for ongoing sessions to proceed successfully, as well as ”announce” her new location to enable future “incoming” connections. Here we are primarily interested in the issues and approaches related to support mobility to ongoing real-time sessions such as an IP voice call. An IP address has multiple purposes: it is used to uniquely identify an interface of a host, it identifies where (on what link/subnet) the interface is attached, and it may be used to identify certain higher layer sessions. As described in the introduction above, these properties of the IP address raise two major issues with respect to mobility support: how can (1) higher layer sessions be maintained after Alice has acquired a new address, and (2) how

130

CHAPTER 6. IP MOBILITY SUPPORT

can Alice make the traffic from Bob be directed to her new location. In order to solve these mobility issues there are several possibilities: Support for portability only Nomadic users may be primarily interested in getting network access at the different locations they visit, but may not care about communicating while moving. To meet the demands of such users it would be sufficient to provide solutions for portability rather than mobility, i.e., there is no requirement to keep ongoing sessions while moving. Examples of this include when Alice either turns off her device (e.g., a laptop) while moving, or when she does not have any long term sessions; an interruption in the middle of a web (browsing) download could easily be resumed by clicking the “reload” button in the browser. A solution using DHCP and dynamic DNS is likely to serve users demanding only portability. Alternatively, a SIP Registration would also suffice to establish Alice’s new IP address. Separating session and location identification (Mobile IP) In Mobile IPv4 (MIPv4[120]) and Mobile IPv6 (MIPv6[65]) the mobility issues have been addressed by using two IP addresses; a fixed home address that is used to identify the sessions, and a temporary COA that is used to identify the mobile node’s (Alice’s) current location. In general all traffic to Alice will be sent towards her home address. When Alice is away from home, she needs to acquire a COA on her current link and inform a dedicated agent on her home network, known as a home agent (HA). The HA will intercept all traffic destined to Alice, look up her current COA in its binding cache and tunnel/forward the packet towards Alice’s current location. On the reverse path, i.e., between Alice and her correspondent node (Bob), Alice can either send packets to Bob directly, or via her HA. These two schemes are known as triangular routing and reverse tunneling respectively, see figure 6.4. Both these mechanisms imply nonoptimal routing (in particular when both Alice and Bob are away from home). To enhance the end-to-end delay performance there have been route optimization extensions suggested for MIPv4[124, 74], but one of the problems is that this is not transparent to the already deployed base of MIPv4 nodes; e.g., Bob needs a binding cache. In MIPv6 support for route optimization is easier to deploy, as all IPv6 nodes should support binding updates. Mobile IP is examined further in section 6.5. Application layer mobility support (SIP mobility) While mobile IP (MIP) can handle IP mobility for all communication, it would also be possible to handle mobility within individual applications. Of particular interest for this dissertation is the ability to utilize the SIP’s capabilities to handle mobility for ongoing RTP sessions[181, 155]. When Alice acquires a new IP address, she could redirect the session by sending a SIP re-INVITE message to Bob. The communication would continue using her new IP address; route optimization will occur by default and no overhead in terms of tunneling is necessary. VPN tunnels to home network When visiting a remote network it is common for users to setup a VPN tunnel to a security gateway on their company network, e.g., using layer-2 (L2TP or PPTP), or layer-3 (IPSec) VPN

6.5. MACRO-MOBILITY SUPPORT SCHEMES

131

MN a)

Figure 6.4: Mobile IP with (a) triangular routing and (b) reverse tunneling.

solutions. Each time Alice connects to a network she would establish this secure tunnel, and if she is always assigned the same IP address on her home network (perhaps by using the PPP multi-link option) Bob would be able to continue sending traffic to her even after a layer3 handover. This approach shares several properties with the reverse tunneling scheme in Mobile IP, see section 6.5.4, except perhaps that with a VPN solution it is more likely that data will be encrypted twice between Alice and her security gateway if end-to-end confidentiality is desired. In section 6.6 we will analyze the impact of Mobile IP and SIP mobility on an ongoing voice session. Section 6.6 concerns mobility schemes able to optimize micro-mobility, i.e., mobility between subnets which are close in the network topology.

6.5

Macro-mobility support schemes

To manage layer-3 mobility during an ongoing call two main alternatives exist, mobile IP (MIPv4[120] and MIPv6[77]) which handles mobility at the IP layer, and SIP mobility[181, 155] which takes care of mobility at the application layer. We refer to these methods as macro-mobility support schemes as they are able to handle mobility between arbitrary IP subnets. MIPv4 and MIPv6 include several flavors of mobility schemes, and the macro-mobility MIP variants we will examine (in addition to SIP mobility) are: • MIPv6 with route optimization[77]: This is our primary MIP alternative, since optimal routing is desirable for real-time services. • MIPv6 with reverse tunneling[77]: Reverse tunneling approaches enable Alice to hide her current location to Bob. • MIPv4 with reverse tunneling[105]: Does not suffer from problems with ingress filtering routers, and is able to do NAT traversal[90]. Although reverse tunneling approaches inherently lead to non-optimal routing the impact of this can be reduced if Alice can select a HA close to her from a

132

CHAPTER 6. IP MOBILITY SUPPORT

set of available HAs, as suggested by Thubert et al.[167] or Mao et al.[98]. This type of dynamic home agent discovery differs from the currently standardized approaches[120, 77]. Still, we prefer mobility management schemes such as MIPv6 and “SIP mobility”, which provide route optimization natively. MIP variants not considered include: • MIPv4 with triangular routing[120]: We disregard this “common” mobility management schemes due to its problem with ingress filtering routers[45]. • MIPv4 with route optimization[124]: Although this proposal enables optimal routing in IPv4 networks, correspondent nodes need to be upgraded to support binding caches, etc. For the same reason we disregard MIP with location registers (MIP-LR[74]), another route optimization proposal. With SIP (terminal) mobility the data packets will always take the optimal route, and the mechanisms would be the same whether IPv4 or IPv6 is used. The aim of this section is to describe the necessary message exchange required for these macro-mobility schemes when a layer-3 handover occurs. However, before examining that we present some of the security issues of layer-3 mobility (section 6.5.1), primarily based on work related to MIPv6 security design[110]. Then we start out by looking at the route optimized schemes; MIPv6 with route optimization in section 6.5.2 and SIP mobility in section 6.5.3. Section 6.5.4 examines the schemes based on reverse tunneling.

6.5.1

Some security concerns for layer-3 mobility schemes

In Mobile IP Alice needs to have a security binding with her MIP service provider in order to authenticate Binding Update (BU) requests to her HA. In route optimization schemes (e.g., MIPv6 and SIP mobility) Alice would also need a security binding with the correspondent node (Bob). Generally there does not have to be any security binding between the visited ISP and Alice’s MIP or SIP service providers, since we rely on the NAS solutions described in the previous chapter to handle AAA issues between Alice and the visited ISP. An exception to this is when Alice wants to make use of micro-mobility management schemes, as will be discussed in section 6.6. In [110] the security design background for the MIPv6 route-optimization support is provided. [10] contains a taxonomy and further analysis of MIPv6 route-optimization and proposed enhancements. Although these documents primarily concern MIPv6, the issues they examine are also relevant to other mobility management schemes. Issues of particular relevance to this thesis are described below: No global authentication infrastructure: When Alice moves and wants to inform Bob about her new COA, this BU message needs to be authenticated in order to defeat attackers from redirecting traffic from Bob to themselves or some other address. In MIPv6 route optimization design the BU to Bob is protected without relying on the existence of a global authentication infrastructure. The Binding management key (Kbm ) used to

6.5. MACRO-MOBILITY SUPPORT SCHEMES

133

authenticate the BU is therefore created by some other means (see “return routability” below). Verifying “ownership” of home address: When Alice sends a BU to Bob with a new home/care-of address mapping, this means that she likes Bob to insert a source routing entry in his binding cache. However, Bob should verify that Alice is able to receive data to the home address she claims to have. That is, although Bob would accept phone calls from Alice, this does not necessarily mean that he trusts her to implicitly insert a source route entry in his host for an arbitrary address on the Internet. The approach MIPv6 route optimization uses to address this issue is to perform a home address test. In the home address test, Bob will send a Home Test packet (HoT) containing a home address token to Alice. This token will be part of Kbm , which is used to authenticate the subsequent BU. The HoT packet will reach Alice if she is either at home, or it is tunneled (securely) to her current COA by her HA, thus it gives Bob at least some assurance that Alice really has the claimed home address. There is still a chance that an attacker on the path between Bob and Alice’s home network could intercept the HoT packet, thus fooling Bob that it has access to Alice’s address. However, such spoofing attacks could be launched even without mobility support, thus MIPv6 with route optimization does not give degraded security from that aspect. Verifying access to COA: There is also a risk that attackers try to launch denial of service (DOS) attacks, by redirecting large traffic streams towards some address on the Internet. To defeat such attacks MIPv6 lets Bob send a care-of test packet (CoT) to Alice’s claimed COA, containing a COA token. The COA token is used together with the home address token when forming the Kbm . No multiplication of traffic: To avoid certain DOS attacks where an attacker can send one packet to a node, triggering that node to respond with multiple packets, such multiplication features should be avoided in a protocol design. Therefore, Alice will need to send two separate packets Home Test Init (HoTI) and Care-of Test Init (CoTI)) to Bob to trigger him to send the corresponding HoT and CoT packets. Fig. 6.5 shows the message for the return routability process[77]. After receiving both the HoT and CoT packets Alice can form the Kbm and transmit her BU to Bob. The BU will contain enough information for Bob to create the Kbm “on the fly”, thus avoiding him to keep unnecessary state until a valid BU is received (for details of how the Kbm is formed and how Bob is able to dynamically create the Kbm , see [77]). Note that the home test and care-of test can be done in parallel, and not necessarily sequentially as shown in Fig. 6.5. Further optimizations will be discussed in section 6.5.2.

6.5.2

MIPv6 with route optimization

After acquiring a new COA, Alice would send a BU to her HA and all correspondent nodes with which she is currently communicating using route optimization. Fig. 6.5 shows the message exchange normally needed upon a

134

CHAPTER 6. IP MOBILITY SUPPORT

Alice

HA_Alice

Bob

1:Binding Update 2:Binding Acknowledgement 3:Home Test Init

3:Home Test Init

4:Home Test (home keygen token) 4:Home Test (home keygen token) 5:Care−of Test Init 6:Care−of Test (care−of keygen token) 7:Binding Update 8:Binding Acknowledgement Figure 6.5: Binding update message exchange upon Alice performing a handover. Messages with dashed lines need not affect the handover latency.

handover in order to inform Bob that Alice has a new COA. The BU to the HA is secured using IPSec. The required IPSec SA and IPSec policies can be established at MIPv6 initialization, thus no additional IPSec setup messages need to occur as part of the handover. The BU to the correspondent node (Bob) uses the Kbm acquired via the return-routability mechanism. It should be noted that if the Alice already has a valid home keygen token she could use that when forming the new Kbm after a handover. Therefore only messages 5-7 in Fig. 6.5 need to affect the handover performance, as I described in [175]10 . This and other optimization proposals for return-routability latency are discussed in [10]. This would result in a packet loss during the period corresponding to one round-trip time for the upstream traffic (Alice does not have to wait for the Binding Acknowledge (BA) from Bob before starting to transmit, see equation 6.7) and 1.5 round-trip times for the downstream traffic. Since there is already data in-flight from Bob to Alice’s previous COA at the time message 5 is transmitted, the amount of data loss for the downstream traffic corresponds to two roundtrips, see equation 6.8 below11 . Tmipv6,up Tmipv6,down 6.5.2.1

= =

4 LOTT + 2 ROTT 8 LOTT + 4 ROTT

(6.7) (6.8)

Utilizing existence of security infrastructure

One of the motivations for using the “return routability” mechanism to secure binding updates for route optimization was that one then does not rely on 10 As pointed out by Arkko[11], to do things “legally” Alice has to transmit the BU to its HA (message 1) before the CoTI (message 5), however, we assume that the associated impact on handover delay is insignificant. 11 There are more L OTT s is than ROTT s since Bob is also mobile. For definitions of LOTT and ROTT , see sections 5.2.1 and 5.2.2.1.

6.5. MACRO-MOBILITY SUPPORT SCHEMES

135

the existence of a global authentication infrastructure. But in our case we are assuming that Alice and Bob already utilize such a security infrastructure to establish a secure VoIP call, as described in chapter 3. Thus, in cases like this Alice’s BU to Bob could be authenticated without relying on the “return routability” message exchange, as I suggested in [175]. The ability to use alternate authentication mechanisms are now being investigated with the IETF MIPv6 WG[122]. Thus, if we could use a Kbm created as a side-effect of the SIP call setup, the MIPv6 impact on the handover delay would be reduced. There would be no additional delay for upstream packets, since they could be sent immediately after the BU. For the downstream packets, an interval of packets corresponding to the delay between Alice’s old location and Bob (traffic heading towards Alice’s old COA) plus the delay from Alice’s new location to Bob (the time it takes for the BU to reach Bob). Tmipv6,up,pre−kbm Tmipv6,down,pre−kbm

= =

0 4 LOTT + 2 ROTT

(6.9) (6.10)

When analyzing the security impacts of using a pre-computed Kbm , we find that the home test is of less importance here than the care-of test. Note that the attacks the home test and care-of test are addressing, could still occur, but this time the attacks are auditable in a more controlled way; if Alice tries to trick Bob he will have better chances to take suitable actions afterwards. If Bob wants to take further measures to ensure Alice’s BU is legitimate, other actions can be taken without affecting the handover delay: • Home Test: The home test should not need to affect the handover, as already discussed earlier in section 6.5.2. If Bob wants to do it, it can be done at the time route optimization is agreed, and then on a regular basis before the lifetime of the home address token expires. • Care-of Test: If Bob is afraid of letting an arbitrary user (be it that Alice is authenticated, and Bob has accepted the call from her), it would be possible for him to only authorize the use of a pre-computed Kbm to people he knows, e.g., the ones in his phone book (see also chapter 3 for further discussion on authorization of incoming calls.) Arkko and Vogt provide further analysis on these issues[10] . 6.5.2.2

Securing the user data

In chapter 3 the methods to establish a secure VoIP call were described, with SRTP and IPSec as alternatives for protecting the actual user data. Use of MIPv6 with route optimization would not put any significant restrictions on either alternative. • SRTP: I proposed the use of mobile IPv6 for mobility and SRTP in [175]. Alice would use her home address as end-point of the SRTP session, thus a change of COA would be transparent to upper layers and not affect SRTP.

CHAPTER 6. IP MOBILITY SUPPORT

Bob’s SIP provider

SIP server

Alice

2: 200 OK

3: ACK

Bob

1: re−INVITE

Bob’s SIP provider

SIP server

SIP server Internet

Alice’s SIP provider

SIP server Internet

2: 200 OK

Alice’s SIP provider

3: ACK

136

Alice

Bob b)

Figure 6.6: SIP mobility signalling where Alice sends re-INVITE (a) directly to Bob, and (b) via her SIP server.

• IPSec: With MIPv6 Alice and Bob can use IPSec without having to renegotiate the IPSec SA after a handover, since Alice’s home address is used as IPSec selector[77]. However, it will lead to some additional overhead, since Alice’s home address has to be carried within each data packet12 . In case both Alice and Bob are mobile this results in 4 IPv6 addresses per packet.

6.5.3

SIP mobility

Schulzrinne and Wedlund[181, 155] present a mechanism for providing terminal mobility for RTP sessions using SIP (the method is standardized in RFC 3261[145] and RFC 3264[145]). Although this approach does not constitute a general solution for IP layer mobility, it manages mobility for the realtime applications of main interest for this dissertation. With SIP, terminal mobility can be implemented at the application layer; a property which ease deployment across various platforms and operating systems. The idea of SIP terminal mobility is that Alice, upon performing a layer-3 handover, informs Bob about her new location by sending a new INVITE message (referred to as a re-INVITE message). The re-INVITE message would use the same identifier as the original call setup, and put the new address (1) in the SIP Contact header (to inform Bob where she wants to receive future SIP messages), and (2) in the SDP media description to redirect the data stream(s). The basic message exchange is shown in Fig. 6.6a). The impact on the downstream and upstream handover delays will differ depending on when Alice and Bob are allowed to redirect their data streams. In this analysis we assume that Alice is allowed to transmit the re-INVITE as soon as she has acquired her new IP address; RFC 3261[147] mentions the use of a random wait-time before sending a re-INVITE, but the risk for peak loads due to synchronization effects should be low for a single packet compared to the media streams exchanged between Alice and Bob (see also section 6.3.1). 12 For packets from Alice to Bob her home address is carried in the Home Address option of a Destination Options header, and in the reverse direction it will be carried in a Routing header (type 2).

6.5. MACRO-MOBILITY SUPPORT SCHEMES

137

• Upstream delay: Alice could either start to transmit data to Bob immediately after sending the re-INVITE, or she could wait for the 200 OK. Schulzrinne and Wedlund[181, 155] are not explicit about this, although the figures they use indicate that Alice should wait for the 200 OK. Politis et al.[130] let Alice wait for the 200 OK from Bob and optionally also for 200 OK sent by Alice’s SIP server in reply to her re-REGISTER SIP message. In section 2.4 we described that the RTP session from Alice to Bob should be independent of Alice’s IP address, but that implementation matters (related to UDP sockets) may cause Bob to drop packets from Alice’s new address. By proper implementations13 we believe Alice would be able to continue sending data to Bob without any interruption, leading to a zero upstream delay (equation 6.11). However, if she has to wait for the re-INVITE to reach Bob, and perhaps also for the 200 OK to come back the situation would be different. For example, if Alice has to wait for the 200 OK upstream traffic will interrupted while these messages traverse the path between Alice and Bob (Fig. 6.6a) or via their SIP servers (Fig. 6.6b). As we believe TLS should be used to protect SIP signaling, the resulting interruption may become significant. – Sending re-INVITE directly: We assume that Alice and Bob established a TLS session during call establishment, and that this session can be resumed14 . If the first TLS message can be sent along with the last message of the TCP 3-way handshake, and the SIP re-INVITE can be sent immediately after the 3rd message in the TLS resumption, the number of round-trips to receive the 200 OK would be as shown in equation 6.1215 . – Sending re-INVITE via proxies: Assuming that the TLS session between Alice and her SIP server can be resumed and TLS connection between other entities can be reused the number of round-trips would be as shown in equation 6.1316 . These values would differ when other transport protocols are used for SIP signalling or when the mentioned assumptions do not hold. Still, we propose that Alice continues to transmit data immediately, without waiting for the 200 OK to arrive (equation 6.11).

Tsip,up,A−B,quick Tsip,up,A−B,200OK

= =

0 12 LOTT + 6 ROTT

(6.11) (6.12)

Tsip,up,proxy,200OK

8 LOTT + 10 ROTT

(6.13)

If Alice and/or Bob is located behind a NAT the situation would be even more complex. If only Alice is behind a NAT she should be able 13 See

ideas by Stevens[161]. pointed out by Erik Eliasson (private communication, May 2005) this assumption breaks if Bob pools connections with a key including the destination address. 15 4L OTT /2ROTT for TCP; 4LOTT /2ROTT for TLS; 4LOTT /2ROTT for SIP. 16 2L OTT /2ROTT for TCP; 2LOTT /2ROTT for TLS; 4LOTT /6ROTT for SIP. 14 As

138

CHAPTER 6. IP MOBILITY SUPPORT

to continue transmitting audio as before (equation 6.11), but she would have to use STUN[148] or a similar mechanism before she can send the re-INVITE. If Bob is behind a NAT packets from Alice may be dropped by his NAT until Bob starts to transmit data to Alice’s new address (after he receives the re-INVITE). Use of full-cone NATs[148], would provide best performance. To enable the re-INVITE to pass through the NAT it would be safest to send it via the proxies. • Downstream delay: Once Bob receives the re-INVITE from Alice, he will redirect his data stream(s) to Alice’s new address, as stated in the SDP message. The interruption will correspond to the time it takes for the re-INVITE to reach Bob, plus the time it takes for the data packets to travel from Bob to Alice’s new location. Based on the assumptions made for the re-INVITE/200 OK exchange in equations 6.12 and 6.13 the downstream delay would correspond to network delays as shown in equations 6.14 17 and 6.15 18 . Tsip,down,A−B

12 LOTT + 6 ROTT

(6.14)

Tsip,down,proxy

8 LOTT + 8 ROTT

(6.15)

As with the upstream delay, the downstream delay would be affected when other transport protocols or NATs are used. Schulzrinne and Wedlund[155] state that the location update takes a one-way delay, but do not mention that the packets already in-flight to Alice are also lost. Politis et al.[130] do not explicitly state when Bob redirects his packets, however, a figure provided indicates (possibly unintentionally) that Bob redirects the packets after receiving the ACK from Alice. Dutta et al.[42] mention both options; redirecting after the re-INVITE took 150 ms and after the ACK took 500 ms in their setup. 6.5.3.1

Securing the redirection signalling

In the description of SIP mobility above we assumed that TLS was used to protect the SIP signalling hop-by-hop between Alice, Bob and their SIP proxies. If some other transport protocol than TLS is used, e.g., UDP or TCP, or if Alice and Bob require end-to-end protection of re-INVITE messages other measures need to be taken. We will also discuss whether the reasons for doing home test and care-of test (section 6.5.1) also apply to SIP mobility. Authentication of re-INVITE Just as for the MIP Binding Update messages, the SIP re-INVITE messages need to be authenticated in order to hinder an attacker to redirect a data stream to itself or someone else. Several alternatives exist and their use would have an impact on the handover delay. Schulzrinne and Wedlund[181, 155] refer to the authentication mechanisms available in SIP[147] such as HTTP digest and S/MIME. If MIKEY[7] is used to authenticate the initial INVITE, it is natural also to use MIKEY to authenticate a re-INVITE message, as described by Bilien[20]. (Some papers investigating handover performance of SIP mobility [108, 130] do not consider 17 4L 18 4L

OTT /2ROTT OTT /2ROTT

for TCP; 4LOTT /2ROTT for TLS; 2LOTT /ROTT for SIP; 2LOTT /ROTT for data. for TCP; 2LOTT /2ROTT for TLS; 2LOTT /3ROTT for SIP; 2LOTT /ROTT for data.

6.5. MACRO-MOBILITY SUPPORT SCHEMES

Alice

139

Bob 1:re−INVITE 2:401 Unauthenticated (CHALL) 3:re−INVITE (Auth. hdr.) 4:200 OK 5:ACK

Figure 6.7: Authentication of re-INVITE using HTTP Digest

this authentication at all.) Below we describe the impact of these alternatives (HTTP Digest, S/MIME and MIKEY) on the handover performance: • HTTP Digest: Usage of HTTP Digest would require Alice and Bob to share a common secret. Bob would challenge Alice’s re-INVITE as shown in Fig. 6.7. Compared to the non-authorized re-INVITE, this would add an Alice-Bob round-trip for the re-INVITE to reach Bob (equation 6.16. Since we assume Alice can continue sending upstream data without waiting for the 200 OK (equation 6.11), this will only affect the interruption of downstream data (equation 6.14). There are some additional concerns regarding the use of HTTP Digest: – As always, if the re-INVITE is sent via SIP servers the loss interval increases (equation 6.17). – One issue with the HTTP Digest authentication is that it does not protect the Contact header (or the SDP), which enables some spoofing attacks19 . One idea to improve the security would be to let Bob encode the relevant data, such as the Contact header into the challenge. This would be in-line with methods web server can use to improve HTTP Digest authentication security, e.g., encoding things such as the clients IP address, time of day etc. into the challenge[3]. – It would be possible to get rid of the additional round-trip in Fig. 6.7 if Bob has challenged Alice at some earlier occasion. Alice could then reuse that challenge (increasing the nonce-value variable to avoid replay attacks) and send the Authentication header already in message 1. However, if Bob has encoded a prior Contact header into the challenge, reusing the challenge after movement would not work. In this case, the number of messages required would still be the same as shown in Fig. 6.7. • S/MIME: The re-INVITE message can be authenticated by adding a S/MIME signature covering relevant parts of the message. In our case there are relevant parts both within the SIP message (e.g., To, From, Call-ID and Contact headers) as well as in the carried SDP 19 If

we can assume TLS transport such attaches will be substantially more difficult to launch.

140

CHAPTER 6. IP MOBILITY SUPPORT

message (in particular the new IP address). Since the SIP header may be legitimately updated by intermediate SIP servers, Alice may need to attach a copy of the protected parts of the original SIP message[147, 128]. Although the message becomes a bit larger, no additional round-trips will be required (equation 6.18), unless the packet becomes too large for the transport protocol in use). Thus, an advantage of S/MIME is that it can be used to protect the SIP Contact header, the SDP media description and (as mentioned in section 3.4.1.3) even the MIKEY messages. Dutta et al.[42] do not explicitly say how (or if) they protect the re-INVITE messages, however, S/MIME is a likely choice, since they suggest S/MIME for protecting the transfer of SRTP parameters. • MIKEY: Use of MIKEY to establish a secure VoIP call was described in chapter 3. Bilien provides a suggestion of how MIKEY can be used to secure re-INVITE for terminal mobility[20] where the credentials exchanged during the initial MIKEY handshake can be reused rather than resent. Bob would only have to verify validity of the new time-stamp and the MIC/signature. As for the S/MIME approach, MIKEY messages are carried within the SIP re-INVITE and 200 OK messages, no additional round-trips will be required (equation 6.19). However, there are some uncertainties regarding the use of MIKEY to protect the re-INVITE. The MIKEY protocol is primarily designed to protect the MIKEY messages itself, not the Contact header or the IP address in the new SDP body. If MIKEY is used to carry IPSec parameters for the media stream (see [115] and section 3.4.1.1), the IP address would implicitly be protected within the MIKEY message. If instead SRTP is used for media protection, one could consider adding an appropriate General Extension Payload to MIKEY carrying Alice’s new IP address. However, using S/MIME to protect MIKEY and other parts of the SIP message seems like a better choice (see similar comment in the paragraph on S/MIME above, and section 3.4.1.3). Tsip,auth,http,A−B Tsip,auth,http,proxy Tsip,auth,smime

= = =

4 LOTT + 2 ROTT 4 LOTT + 6 ROTT 0

(6.16) (6.17) (6.18)

Tsip,auth,mikey

(6.19)

Applicability of home and care-of address tests A major difference between MIP and SIP mobility is that in SIP mobility there is no notion of a home address. Thus, when Alice asks Bob to redirect his flow of data to her new address, she does not claim access to some arbitrary IP address on the Internet, and Bob does not have to keep any binding cache to enable source routing in the same way as for MIPv6 with route optimization. Although the home test does not apply to SIP mobility, the care-of test is relevant. The issue of attackers sending spoofed INVITE messages to trick

6.5. MACRO-MOBILITY SUPPORT SCHEMES

141

Bob into sending media to a victim is brought up in [35], which points out that this problem applies to SIP call establishments based on the SDP Offer/Answer model in general. Camarillo and Schulzrinne[35] state that Bob should check whether the “owner of the transport address” in the SDP body is willing to receive traffic, “before sending a large amount of data”. As examples of how to conduct this test Camarillo and Schulzrinne[35] mention the use of “a connection oriented transport protocol”, use of STUN in an end-to-end fashion, or by the key exchange in SRTP”. In these and similar types of tests Bob only tests the address in the Contact header in the SIP header, not the actual transport address given in the SDP body. • Connection-oriented transport: Our primary interest is real-time services, which utilize RTP/UDP transport. Thus, testing the new “transport address” by establishing, e.g., a TCP connection does not really apply. One could, of course, require Alice to open a corresponding TCP socket for each UDP port specified in the SDP media lines, but then one might as well invent a new protocol. What can be done is to use a connection-oriented protocol for the SIP signalling (re-INVITE/200 OK), but as mentioned this would not test the transport address used for media. • Key exchange for SRTP: A suitable candidate for SRTP key exchange is MIKEY[7] even though other proposals exist, e.g. [5]. The MIKEY messages are sent within the SIP messages and would therefore not test the transport address. Furthermore, since MIKEY is only a twoway handshake, Bob cannot be certain that Alice is really located at the address she claims in the SIP Contact header either. • HTTP Digest authentication: If Bob uses the HTTP Digest test above to test the authenticity of the re-INVITE he (in contrast to the MIKEY test) will gain some certainty that she is reachable on the address in the SIP Contact header. Although we are more concerned about checking the transport address in the SDP body, testing reachability of Alice’s claimed Contact address is not a bad idea. If this is used in combination with authentication verification Bob would at least be able to log this information and take necessary actions reactively if an attack would occur. The same arguments and possibilities as when using a pre-configured key and skipping the care-of test for MIPv6 (section 6.5.2.1) apply here. Furthermore, for mobile IP-telephony we believe that Alice will commonly use the same IP address in the SIP Contact header as for media transport. In order to test the transport address an idea of possible interest is to have a special “echoing CODEC”, so that Bob could use that to probe the actual transport address. That is, in addition to the regular CODECs used to encode and decode the audio data, Alice and Bob could use SDP to negotiate the use of a loop-back CODEC to test the transport address (alternatively one could consider using the loop-back media attribute proposed in [62]). If SRTP/IPSec is used to protect the media stream there would be no easy way for an attacker to spoof the echoed RTP data from Alice, thus Bob would be assured

142

CHAPTER 6. IP MOBILITY SUPPORT

that the media stream is setup using the correct transport address. The impact on the handover latency would depend on Bob’s policy; he could be opportunistic/aggressive and send regular data in parallel with the ’echo tests’ (and stop after a ’suitable timeout’ if no correct data is echoed back) or he could wait a round-trip and verify the ’echo reply’ before he redirects the data. We leave the concept of using an “echoing CODEC” to future work, noting that its design should be able to borrow ideas from the “Concurrent IP-Address Tests” described in [10] as a means to enhance MIPv6 with route-optimization. 6.5.3.2

Securing user data

Use of SIP mobility does not have any major consequences on the possibilities to support end-to-end data protection with either IPSec or SRTP. Further details on the use of SIP mobility with IPSec and SRTP are given below. SIP mobility and IPSec The approach of using SIP for mobility support and IPSec to protect the media flow seems a little odd at first. One of the advantages of SIP mobility is that it can be implemented at the application layer without depending on the underlying operating system, a property which is more or less lost if the SIP user agents rely on IPSec for media protection. On the other hand, if a UA already has implemented support for managing media protection by IPSec[115], adding mechanisms to support mobility ought to be a comparably small extension. What Alice needs to do when she has acquired a new IP address is to send a new MIKEY message with new IPSec parameters along with the re-INVITE, as described in section 6.5.3.1. The new IP address is included in IPSec parameters, which are protected by MIKEY (or S/MIME). Thus Bob could use the IP address carried in MIKEY to verify that no-one has tampered with the IP address in the SDP media description. SIP mobility and SRTP When Alice changes her IP address this will only affect the SRTP cryptographic context for the session from Bob to Alice[18], thus Alice and Bob need to have appropriate support to adapt to this change. To protect Alice’s new IP address in the re-INVITE methods described in section 6.5.3.1 should suffice.

6.5.4

MIPv4 and MIPv6 with reverse tunneling

In MIPv4 with triangular routing, Alice would use her home IP address as source address, even if she is currently attached to another network. This may lead to problems, since security conscious routers may drop packets, which do not have a topologically correct source address[44]. One way to address this problem is to let the FA (or Alice) tunnel the packets to Bob via the HA. Reverse tunneling is possible both for MIPv4[105] and MIPv6[77] and Fig. 6.8a) shows the data path from Alice to Bob when both use reverse tunneling. The major drawback with reverse tunneling is that the end-to-end delay is increased, which makes it less attractive for real-time applications such as voice. Nevertheless, the reverse tunneling concept is of interest, since it can

6.5. MACRO-MOBILITY SUPPORT SCHEMES

Alice HA

Bob’s HA

143

Alice HA

Bob’s HA

Internet

3 Internet 2

FA/R

FA/R 1

Alice

Bob a)

FA/R 4

Alice

Bob b)

Figure 6.8: MIP with reverse tunneling: (a) data paths and (b) signaling paths

provide a VPN-like solution to mobile business users if the tunnel is protected. After acquiring a COA upon handover, Alice will need to send a Binding Update to her HA, which in turn will reply with a Binding Acknowledgement, see Fig. 6.8b). The time to redirect the upstream and downstream data flows is described separately for MIPv4 and MIPv6. • With MIPv4 Alice can either send the BU via her FA or directly to the HA if she has acquired a co-located COA. In both cases redirection of the downstream data will correspond to the delay for the BU to reach the HA plus any data in-flight between the HA and Alice’s old location at the time the BU is sent, see equation 6.20. The upstream redirection delay may differ for the two cases: – FA COA: The tunnel from the FA to the HA will not be available before the FA receives a positive BA from the HA, thus sending data from Alice before receiving the BA makes little sense, since the FA is likely to drop them. Equation 6.21 shows the resulting redirection delay. – Co-located COA: With co-located COAs Alice has the possibility to be opportunistic and send data immediately after transmitting the BU, or to wait for the BA as in the FA COA case. We suggest Alice utilize the former approach, at least when she has ongoing real-time sessions. There is of course a risk that Alice’s HA of some reason will send back a negative BA. This risk should be small, since the HA had accepted the tunnel on the previous subnet, and even if this situation would occur, our major problem would rather be that the session to Bob will be broken. Thus, for co-located COAs the upstream redirection delay would be zero (equation 6.22). Reverse tunneling can also be used by MIP users to traverse NAT gateways[90]. Data will then be tunneled on top of UDP leading to

144

CHAPTER 6. IP MOBILITY SUPPORT

additional overhead. Since it can be difficult for Alice to predict if UDP tunneling is necessary before she receives the BA, it could be wise to wait for the reception of the BA even for co-located COAs. However, if the additional overhead is acceptable Alice could force the use of UDP tunneling by default, and then send data immediately. This would give the same upstream redirection delay (”zero”) as when co-located addresses are used without NAT equation 6.22. • With IPv6, the BU/BA signalling (and optionally also the data) sent between Alice and her HA is protected by IPSec. The MIPv6 IPSec protection has been defined so that the same SA can be used even if the COA changes (Alice’s home address is used as IPSec selector rather than her COA). Thus, Alice can send data either immediately after the BU, or wait for the reception of the BA. For real-time applications we recommend the former alternative, providing a “zero” redirection delay (equation 6.24). The downstream redirection delay is the same as for MIPv4 (equation 6.24).

6.6

Tmipv4,rev,down

2 LOTT + 2 ROTT

(6.20)

Tmipv4,rev,up, f a Tmipv4,rev,up,co−loc

= =

2 LOTT + 2 ROTT 0

(6.21) (6.22)

Tmipv6,rev,down Tmipv6,rev,up

= =

2 LOTT + 2 ROTT 0

(6.23) (6.24)

Micro-mobility support schemes

If mobile users frequently conduct layer-3 handovers this leads both to annoying interruptions for the users and extensive signalling to home agents and correspondent nodes. To reduce the impact of layer-3 handovers there have been several proposals to optimize mobility within a topological region. We refer to these mobility management schemes as micro-mobility management protocols and the type of layer-3 handover as a regional handover. The effectiveness of these schemes are based on the assumptions that: • ISPs will divide their access networks into IP subnets, rather than using bridged topologies where mobility is handled at layer-2. • Users will frequently move between subnets of the same ISP, as opposed to mobility within a subnet (layer-2) or between access networks run by different ISPs. We will briefly describe a set of alternative categories of micro-mobility management schemes. When examining these micro-mobility management protocols we will in particular consider whether they enable optimal routing or not. The ability to provide optimal routing generally depends on whether users are assigned a globally routable co-located COA or not. We are also interested in the impact on the handover delay for upstream and downstream data. Micromobility protocols generally improve the downstream delay the most, leading

6.6. MICRO-MOBILITY SUPPORT SCHEMES

145

to interruption for a couple of LOTT . Most of the micro-mobility support schemes we describe rely on Mobile IP for macro-handover. In these schemes Alice will send the equivalent to a BU to some “domain gateway” when performing a regional handover, and like any other BU it should be authenticated to avoid certain security attacks. This requires Alice to establish a security binding with this “domain gateway” and there are multiple alternatives to accomplish this: • As Alice already has a security binding with an entity within the access network (the NAS) it should be possible to create a similar security binding for micro-mobility support. An issue here is that her identity used with the NAS ([emailprotected]) differs from her identity for mobility ([emailprotected]). • If the visited ISP has a security binding with Alice’s MIP service provider, the security binding between Alice and the “domain gateway” could be established during the initial BU/BA exchange when she enters the domain. This is proposed in the MIPv4 regional mobility scheme[53]. • In MIPv6 hierarchical mobility management[160] IPSec is used to protect the BU between Alice and the “domain gateway”. The security binding could be established by an IKE exchange between Alice and the “domain gateway”, possibly using certificates for authentication. The visited ISP needs a trust relationship with the issuer of Alice’s certificate, which could be her MIP service provider or her ISP. It may also be sufficient for Alice to use a self-signed certificate, since the main purpose of this binding ought to be to ensure that only the user who creates the binding can send valid BUs, not to verify the identity of this user. Generally we will assume that the necessary security binding is established during the initial BU/BA exchange when Alice enters the domain, and that this will not have any impact on this (global) handover. In section 6.6.1 we examine micro-mobility protocols based on “host based routing”. Section 6.6.2 concerns approaches based on a local tunnels, and in section 6.6.3 other micro-mobility approaches are described.

6.6.1

Host based routing

In host based routing (HBR) schemes Alice can keep her IP address if she moves between LANs within the same “domain”. Examples of micro-mobility protocols based on HBR include Cellular IP[171], HAWAII[136, 137] and MMP[41]. A “non-IP” protocol providing micro-mobility is CLNP: • Cellular IP (CIP): In CIP[171] all traffic to and from Alice will be sent via a domain gateway acting as her foreign agent, i.e., Alice will use Mobile IP for macro-mobility and CIP for micro-mobility. Alice will not be assigned any address in the foreign domain; instead she continues to send data using her MIP home address. Routers in the path between her and the CIP domain gateway will learn about her location as soon as she transmits data, and they install a host specific route for her address

146

CHAPTER 6. IP MOBILITY SUPPORT

in their routing tables. Alice will receive information about her current domain (Cellular IP network identifier and gateway address) via beacons transmitted by her neighbor router. By using MIPv4 for macro-mobility it is difficult for Alice to achieve optimal routing with CIP (as explained in section 6.5 we only consider reverse tunneling for MIPv4). To address the issue of route optimization a set of approaches can be tried: – Use dynamic home agent assignment as mentioned in section 6.5. – Use CIP and MIP for non-time critical traffic, and use SIP mobility for time-critical traffic. Alice could be assigned a private address in the foreign domain, and rely on techniques such as STUN for NAT traversal. This idea was proposed by Politis et al.[130] (see section 6.6.3). – Let Alice acquire a global IP address, which it could keep while staying in the domain. This is what is done in MMP (see paragraph below). Cellular IP claims to have fast handover support. After a handover Alice can immediately continue to send data (or a dedicated route update packet), and thereby update routers in the path towards the domain gateway. The upstream delay for a regional handover would be zero (equation 6.25, and the downstream delay corresponds to the time it takes for the packet to reach the domain gateway, plus the packets in-flight to Alice’s old location (equation 6.26). TCIP,regional,up

(6.25)

TCIP,regional,down

2 LOTT

(6.26)

It is not described in [171] if CIP make use of neighbor discovery protocols such as ARP. Here we assume that no further exchange delays a regional handover, however, for a global handover we assume that Alice sends a solicitation to immediately receive a beacon from the router (see also sections 6.3.1 and 6.3.2), and sends a registration to her HA (via the domain GW) if necessary. As opposed to the reverse tunneling with FAs described in section 6.5.4 we here assume Alice needs not wait for the BA from her HA before sending data. Equations 6.27 and 6.28 show the assumed delay for a global handover using CIP and MIPv4 with reverse tunneling20 . TCIP,global,up TCIP,global,down

= =

0 2 LOTT + 2 ROTT

(6.27) (6.28)

It is not obvious to me if CIP is an improvement over bridged access networks. Similar to a bridged network CIP learns the location of Alice by the source address (an IP address instead of a MAC address), but while bridges are transparent to end-nodes CIP requires special support. 20 Here we have not included the local round-trip to trigger a beacon, since this is part of the movement detection delay rather than the redirection delay.

6.6. MICRO-MOBILITY SUPPORT SCHEMES

147

• Micro-mobility management protocol (MMP): MMP[41] is referred to as an extension to cellular IP[182]. In MMP Alice would be assigned a co-located COA (e.g., by DHCP) when entering the “MMP domain”. The same mechanisms as in cellular IP is used to enable Alice to keep the address when moving. If the COA is a global IP address Alice can use SIP mobility to achieve optimal routing. Wong et el.[182] suggest a hybrid mobility management scheme using MMP for micro-mobility, SIP mobility for macro-mobility for RTP traffic, and MIP-LR[74] as macro-mobility scheme for other traffic[182]. The access networks in MMP could consist of routers as well as layer2 switches[41], thus MMP should be possible to use with bridging APs. Assuming Alice can send data immediately after a regional handover the impact on handover delay would be the same as for CIP. As in CIP it is not clear how MMP make use of “neighbor greeting” protocols such as ARP, but we assume a global handover will involve an additional solicitation/beacon exchange followed by a DHCP handshake (see also equation 6.2) and a registration to her HA. (In equations 6.31 and 6.32 we have excluded the local round-trip to trigger a beacon and the DHCP exchange, since these are part of the movement detection and care-of address assignment delays rather than the redirection delay.) TMMP,regional,up TMMP,regional,down

= =

0 2 LOTT

(6.29) (6.30)

TMMP,global,up

= =

0 2 LOTT + 2 ROTT

(6.31) (6.32)

TMMP,global,down

As for CIP it is not obvious how MMP improves over a bridged access network. • Handoff-Aware Wireless Access Internet Infrastructure (HAWAII): HAWAII shares several properties with MMP: Alice will acquire a colocated COA when entering a “HAWAII domain”, which she can keep while moving within the domain, and HAWAII also relies on Mobile IP for macro-mobility. The difference between HAWAII and MMP is the mechanisms to implement host based routing. (In HAWAII Alice will notify her previous access router upon a handover, while she would inform her domain gateway in MMP.) Garcia-Macias et al.[48] propose a micro-mobility protocol for IPv6, which is similar to HAWAII, and include additional support for QoS. We make similar assumptions for the handover delays in HAWAII as for MMP. TH AWAI I,regional,up TH AWAI I,regional,down TH AWAI I,global,up TH AWAI I,global,down

= =

0 2 LOTT

(6.33) (6.34)

= =

0 2 LOTT + 2 ROTT

(6.35) (6.36)

148

CHAPTER 6. IP MOBILITY SUPPORT

• Connectionless Network Layer Protocol (CLNP): CLNP is the ISO protocol for connectionless networks[127], and was once an “IPng candidate” before the IETF decided to design what has become IPv6. Although CLNP is not widely used, it has some properties of interest for micromobility management. A CLNP address has an area and a host part. The area part is used for routing between areas using longest prefix matching as in the Internet. Within an area routers use exact matching on the host part of the address (which is commonly the MAC address of one of Alice’s interfaces), enabling Alice to roam within the domain without changing her address. Hosts and routers use a neighbor discovery protocol known as ES-IS where hosts learn which area they are in and routers learn which hosts are attached to their links. The router then propagates this information to all other routers using a link-state protocol known as IS-IS (an interior gateway protocol also used in the Internet). CLNP handles micromobility only, thus some other protocol such as MIP or SIP mobility would be needed for macro-mobility. The major differences with CLNP compared to the other HBR schemes described above are the way mobility information is propagated, and that CLNP enables optimal routing also within the area.

6.6.2

Local tunnels

While roaming within a domain Alice could maintain a tunnel to a local gateway within the domain, acting as her local “anchor”. Two examples of local tunnels are the use of MIP hierarchical FAs, and L2TP/PPTP tunnels to a local NAS. • Hierarchical FAs: Gustafsson et al.[53] present a micro-mobility scheme with a hierarchy of foreign agents to handle regional mobility. Alice will register to a FA on her subnet, which in turn will relay the registration to a Gateway Foreign Agent (GFA), possibly via some intermediate FAs. Thus, Alice will use GFA address as COA and as long as she roams within the region her BU will be handled locally. Packets towards Alice will reach the GFA who will tunnel them to the next FA in the hierarchy and so on. The handover delay for the upstream and downstream data is shown below (see similar discussions in section 6.5.4 or my analysis in [173]): THFA,regional,up

2 LOTT

(6.37)

THFA,regional,down THFA,global,up

= =

2 LOTT 2 LOTT + 2 ROTT

(6.38) (6.39)

THFA,global,down

2 LOTT + 2 ROTT

(6.40)

In MIPv6 there are no foreign agents, however, the MIPSHOP WG are working on a proposal with Mobile Anchor Points (MAPs) to enable hierarchical mobility management in MIPv6[160]. Alice can dynamically learn the address of the MAP even if the MAP resides on some other subnet within the region. To handle regional mobility Alice will use two

6.6. MICRO-MOBILITY SUPPORT SCHEMES

149

COAs, an on-link COA associated with her current subnet, and a regional COA associated with the subnet of the MAP. When moving within the region the MAP will act as Alice’s “local” HA. For global mobility we use MIPv6 with route optimization. The BU to the MAP should be protected by IPSec (ESP or AH), thus as she enters a new domain she may need to run IKE to establish the necessary security binding with the MAP. This may have a significant impact on global handover performance, and to remedy this issue we suggest that Alice first send a BU to Bob using her on-link COA. As the IKE handshake finishes she could send a new BU user her regional COA. The handover delays for hierarchical MIPv6 is shown below (see similar discussions in sections 6.5.4 and 6.5.2.1): THMIPv6,regional,up

(6.41)

THMIPv6,regional,down THMIPv6,global,up THMIPv6,global,down

= = =

2 LOTT 0 4 LOTT + 2 ROTT

(6.42) (6.43) (6.44)

• L2TP/PPTP tunnels: If L2TP or PPTP is used as NAS technology (as described in the previous chapter), Alice would be able to keep the same IP address after a handover. To accomplish this we suggest the use of the PPP multi-link option, avoiding IPCP renegotiation. Still, as compared to other micro-mobility support schemes the use of L2TP/PPTP leads to extensive message exchange, see Table 5.1. Thus, even if L2TP/PPTP is used as NAS solution use of a separate micro-mobility solution could be considered. As mentioned in chapter 5, IP-IPSec tunneling will be an interesting NAS solution once it becomes widely deployed. With the work in progress within the MOBIKE WG Alice would be able to roam within a network without IKEv2 renegotiation, thus IP-IPSec tunnels would also become an attractive micro-mobility solution.

6.6.3

Other micro-mobility approaches

In addition to the described micro-mobility management schemes other approaches have been proposed, e.g., approaches based on multicasting ([49]). We also note that access networks based on layer-2 bridges can handle mobility to reasonable network sizes, reducing the need for layer-3 micro-mobility. C´aceres and Padmanabhan[31] present a scheme where AP routers attached to the same subnet use link-layer broadcasting and gratuitous ARP to support handover without having to update the HA. There are also micro-mobility management solutions which apply specifically for VoIP traffic. Dutta et al.[43] present SIP micro-mobility management scheme, where a local RTP translator is used as indirection point. In a proposal by Politis et al.[130] RTP traffic is sent via a NAT gateways in the access network. The advantage of this approach is that it enables

150

CHAPTER 6. IP MOBILITY SUPPORT

optimal routing (with SIP mobility) while preserving IPv4 address space. To discover her “external” IP/port mappings Politis et al.[130] suggest the use of STUN[148] adding a local round-trip (2 LOTT ) to the redirection delay (we believe Alice commonly needs to contact a STUN server at her SIP provider, leading to a larger delay (2 LOTT +2 ROTT ). To enable Alice to keep her (private) IP address while roaming within a region this scheme needs to be combined with, e.g., MMP. One could also consider dedicated NAT support enabling Alice to keep her “external” IP/port mappings even if she changes her local IP address. The equations below are made based on the following assumptions: • MMP is used for regional handover. Thus, within a region handover delays are equivalent to equations 6.29 and 6.30. • Alice contacts a STUN server located at her SIP provider (sipA.com) after a global handover. Although STUN involves several round-trips before Alice knows what type of NAT she is behind, we assume she can send her SIP re-INVITE after the first round-trip. • Alice can send data to Bob immediately after a global handover (upstream delay as in equations 6.11 and 6.31), and she can send the re-INVITE directly to Bob using TLS transport (downstream delay as in equations 6.14 and 6.32). TSIP- N AT,regional,up TSIP- N AT,regional,down TSIP- N AT,global,up TSIP- N AT,global,down

6.7

= =

0 2 LOTT

(6.45) (6.46)

= =

0 16 LOTT + 10 ROTT

(6.47) (6.48)

Summary of layer-3 mobility management

To accomplish layer-3 mobility we have focused our analysis to MIPv6 and SIP mobility, since these protocols enable optimal routing between Alice and Bob. Both MIP and SIP mobility are likely to become widely used layer-3 mobility, since both have their individual advantages. The choice of mobility management scheme will also depend on the mobility support in the remote system. In this chapter we have also examined the use of micro-mobility management protocols and their impact on handover performance. Still, some of the benefits of micro-mobility protocols can be achieved by access network designs based on layer-2 switching. Use of micro-mobility schemes may also require additional security relationships to be established. Table 6.1 provides a summary of handover delays caused by layer-3 handover for some of the mobility management schemes described in this chapter. Below we describe the schemes considered in the table. • IPv6: – MIPv6: In MIPv6 we assume the use of route optimization and hierarchical mobility support as in equations 6.41-6.44. Alice will acquire her on-link COA and regional COA during an initial router solicitation/advertisement handshake (equation 6.6).

6.7. SUMMARY OF LAYER-3 MOBILITY MANAGEMENT

IPv6 SIP MIPv6 IPv4 SIP SIP-NAT MIPv4

Regional Up Down 2L 4L 0 2L 4L 4L

151

Global Up Down 2L 14L+6R 2L 6L+2R 4L 16L+6R 6L 22L+10R 4L+2R 4L+2R

Table 6.1: Summary of layer-3 handover delays. (L = LOTT , R = ROTT )

– SIP mobility: For SIP mobility in IPv6 we have only considered global handover. (To support regional handover Alice could either use MIPv6, or try methods described by Dutta et al.[43].) Alice will first acquire an IPv6 COA (equation 6.6). We then assume she can send data to Bob immediately (upstream delay as in equation 6.11), and send the re-INVITE directly to Bob using TLS transport (downstream delay as in equation 6.14). • IPv4: For IPv4 we assume Alice acquires a COA via DHCP or from a foreign agent. This would not be necessary when she uses PPP-based schemes as NAS solution. Since Alice may either receive a global or a private IPv4 address we treat these cases separately. – Global IP address: If Alice is assigned a global IP address we assume she will use SIP mobility to achieve optimal routing. Here we have only considered global handovers (To support regional handover Alice could, e.g., use MMP as done in SIP-NAT below, or try methods as described Dutta et al.[43].) Alice will first acquire an IP address using DHCP (equation 6.2). We then assume she can send data to Bob immediately (upstream delay as in equation 6.11), and send the re-INVITE directly to Bob using TLS transport (downstream delay as in equation 6.14). – Private IP address: When Alice is assigned a private IP address we suggest she use the SIP-NAT mobility solution described in section 6.6.3. We also include the alternative to use MIPv4 with reverse tunneling and hierarchical foreign agents. ∗ SIP-NAT: The SIP-NAT solution described in section 6.6.3 use MMP for regional mobility, leading to handover delays as shown in equations 6.45 and 6.46. For global handovers we have assumed Alice will first probe her router for a beacon (2 LOTT ), then acquire an address through DHCP (equation 6.2) and finally redirect the traffic according to equations 6.47 and 6.48. ∗ MIPv4: MIPv4 with reverse tunneling is useful as fall-back solution even though it leads to non-optimal routing. In table 6.1 we show the handover delays when using hierarchical foreign agents. Alice will acquire a COA as in equation 6.4, and then redirect the data according to equations 6.37-6.40.

Chapter 7

Putting it all together In this chapter we will describe the full system by putting together those components found to be best suited to address the issues described in the previous chapters. In section 7.1 we give an overview of the system and specify which components were selected. Section 7.2 summarizes the actions that take place before, during, and after a handover, then discusses what impact this will have on the IP telephony application.

7.1

System overview

Fig. 7.1 presents the overall system and its selected components. The system consists of: • Access network: The access network is operator neutral and we consider two alternate approaches to implementing access control: “IEEE 802.11i with authenticator managed by access network operator” and “L2TP/IPSec”. The reasons for suggesting these two approaches are: – IEEE 802.11i authenticator managed by access network operator: IEEE 802.11i will be available on all major platforms, thus deployment will not be a major issue. It provides the necessary mechanisms to enforce access control and provides confidentiality and replay protection over the wireless link. We suggest a WTP/AC model, where the authenticator (i.e., the NAS) is either put in a switch just “above” the WTP or in the common AS. By using a WTP/AC model management is simplified and the problem of physically securing APs in a public environment is addressed. The system does not dictate what authentication mechanism to use; but usage of EAP provides flexibility to ISPs and their customers. A minor drawback with this system is that ISPs do not have the ability to enforce access control themselves. For simplicity this role has been given to the access network operator. A malicious, hacked, or misconfigured access network operator would be able to map users to the wrong ISP or launch various attacks on the ISP networks. Section 5.4.3.4 provides more information on an alternate

AAA

Alice’s ISP (ispA.com)

SIP

Bob’s SIP provider (sipB.com)

Bob’s ISP (ispB.com)

AAAH

AAA

Figure 7.1: Overview of the proposed system

7.1. SYSTEM OVERVIEW

Alice’s SIP provider (sipA.com)

Alice’s MSP (mspA.com)

Bob’s MSP (mspB.com)

SIP

AAA

Internet (and ISP backbones)

Visited Network i

Visited Network j

Local IX

AAAF

AAAF R ISP1

AAAF

Local IX

AAAF R ISP2

AAAF R ISP1

Visited Network l

Local IX

AAAF R ISP2

AAAF AC

WTP

Visited Network k

AAAF LNS ISP1

DHCP

Local IX

AAAF LNS ISP2

AAAF LNS ISP1

DHCP

DNS

LNS ISP2

DNS

AC WTP

WTP

Shared access networks using L2TP/IPSec

153

Shared access networks using IEEE 802.11i with common AAA server

154

CHAPTER 7. PUTTING IT ALL TOGETHER

architecture where access control is enforced by the ISPs, in case this property is considered crucial. – L2TP with IPSec: L2TP can use IPSec to enable per-packet authentication and confidentiality, and this solution is also available on the major platforms. Access control is enforced by each ISP using the LNS as NAS. This reduces the requirements on the APs, thus simplifying deployment in a legacy WLAN access network. However, APs or the switches/routers just behind the APs should have functionality to filter traffic or “block” users for the purpose of avoiding local virus spreading or abuse. Alternatively the access network could force all traffic (even local) to be routed via the LNS of each user’s operator. The major drawbacks with this approach are: (1) the extensive message exchange required each time Alice moves to a new subnet, (2) the amount of overhead due to encapsulation by several protocols, and (3) the issues related to using a back-end authentication server for IKEv1 authentication. The upcoming IKEv2 enables the use of EAP and would simplify the third matter; however, it will take time before IKEv2 is supported on all major platforms, and by the time it is, IP-IPSec tunneling (PANA) is probably a better NAS candidate. Each ISP will run AAA servers, e.g., RADIUS or Diameter to grant user access (in addition the ISP could let the RADIUS/Diameter server use, e.g., Active Directory or LDAP as back-end servers). For the IEEE 802.11i solution this is straightforward; Alice would use EAP to exchange authentication messages with the AAA server of her ISP, via the local (proxying) AAA server and possibly also via another (proxying) AAA server of a roaming partner to her ISP. For L2TP/IPSec the situation would be different whether IKEv1 or IKEv2 is in use: – IKEv1: a separate method is used to enable authentication between Alice and the LNS during the IKE exchange, followed by EAP authentication between Alice and her home AAA server as part of the PPP establishment. – IKEv2: with IKEv2 EAP can be used for authentication between Alice and her home AAA server during the IKE exchange. Authentication during PPP establishment is not necessary. To enable efficient routing between users located in the same access network, but associated with different ISPs, we suggest that an Internet exchange point is established in association with each access network. • Layer-3 mobility management: To achieve low end-to-end delay mobility management schemes enabling optimal routing are preferred. The schemes we suggest are “SIP mobility” and in the case of IPv6 networks “MIPv6 with route optimization”. Both “SIP mobility” and Mobile IP solutions will be available on the hosts to handle terminal mobility and which solution will be used for IP telephony will be a policy/configuration matter for the users and ISPs. Our belief is that SIP mobility will be the default choice on IPv4 networks, while SIP mobility and MIPv6 with route optimization will be used on IPv6 networks.

7.1. SYSTEM OVERVIEW

155

– We believe that many SIP UAs will want to add functionality for terminal mobility, since (1) it would be necessary to enable mobility on hosts lacking Mobile IP, and (2) it would be in-line with other mobility services provided by SIP UAs, such as session mobility and personal mobility. However, adding terminal mobility to a SIP UA is a relatively small task, but it requires support from and interaction with lower layers to detect layer-3 mobility. – MIP is able to handle layer-3 mobility in a more general way, thus users who desire sessions such as TCP connections to survive after a handover will install MIP. MIP is also useful when the remote SIP UA does not implement support for “SIP mobility”. To improve MIP handover performance the BU sent to Bob can be authenticated by a pre-configured key derived in association with the SIP call establishment (see section 6.5.2.1). Layer-3 handovers may imply a shift of IEEE 802.11 ESSID, which in turn may require deployment of protocols such as CARD to facilitate dynamic discovery of appropriate ESSIDs (see section 6.2.1). • Layer-3 micro-mobility vs Layer-2 mobility: To handle mobility between subnets close in the network topology, systems can make use of micro-mobility protocols. Although these protocols improve handover performance and reduce signalling overhead as compared to macromobility protocols, it is not obvious if such solutions are significantly advantageous as compared to bridging access network designs. In general we aim for mobility solutions where Alice can handle mobility without relying on dedicated mobility support from the access network (except for fast IP address assignment). Although the requirement to introduce protocols such as CARD breaks this design goal to some extent, we still aim to provide access network solutions as simple as possible. Bridged access networks would be transparent to mobile devices, while micro-mobility solutions will be harder to deploy. • SIP security: SIP security involves both securing SIP signalling and securing the media streams (audio and/or video). To protect media streams we believe SRTP will the default choice, since SRTP can be handled by applications independently of the operating system. Use of IPSec would involve interaction between the application and IPSecfunctions (normally) located in the operating system, making it more difficult to run on different systems. On the other hand, SIP UAs would to some extent depend on the system it runs on to receive movement detection hints to support SIP mobility management. Still, the number of SIP UAs using IPSec for media protection will be fewer, and most of them will likely support SRTP as well. To secure SIP signalling we suggest that Alice and Bob use TLS transport between them an their respective SIP provider (section 3.2). Signalling between SIP providers could be secured either with TLS or IPSec. If Alice and Bob would like to hide information about whom they are talking to, then all signalling messages should be sent via their SIP proxies.

156

7.2

CHAPTER 7. PUTTING IT ALL TOGETHER

Overall handover performance

In this section we will describe the handover performance using a symbolic expression of the number of local and backbone message exchanges necessary during a handover in the proposed system. In order to explain the handover mechanisms, we will first describe what happens before handover, i.e., how Alice and Bob acquire their network access and establish the call (section 7.2.1), what happens when Alice is about to do a handover (section 7.2.2), and finally what happens during and after the handover (section 7.2.3).

7.2.1

Before the handover

Before we describe the message exchange necessary during a handover we explain the steps to establish a call in the proposed system. These mechanisms are not as time critical as the mechanisms occurring during a handover, however, the mechanisms used before the handover implicitly affect the performance during a handover. For each step we will state what longterm security bindings are required to conduct that step, and what temporary security bindings are created as a result of that step. 1. Acquiring network access: Alice (and similarly Bob) acquires network access via a NAS in her visited network and receives a care-of IP address. Security bindings required: Alice needs a security binding with her ISP. Additionally, her ISP needs a roaming agreement with at least one ISP in the network Alice visits, and security bindings are to protect the associated AAA signalling. Temporary security bindings: A security association will be created between Alice and the NAS in her visited ISP, which is used to protect data over the WLAN link and to enforce access control. Alice may also create a security association with the AAA server of her ISP, e.g., in the form of a TLS session (if EAP-TLS is used for authentication), which could be reused after a future handover. 2. Registration of care-of address (MIP): When MIP is used for mobility management, Alice registers her care-of address by sending a BU to her HA. When micro-mobility schemes are used Alice would register with some kind of domain gateway in the visited domain, perhaps as part of the regular BU/BA exchange. Security bindings required: Alice needs a security binding with her MIP service provider to protect the BU messages to the HA. MIPv6 uses IPSec to protect MIP signalling, and IKEv2 enables the use of EAP for authentication with a back-end AAA server. The use of micro-mobility schemes may require additional security bindings between the visited ISP and Alice’s MIP service provider, or perhaps her ISP (such a binding already exists). Temporary security bindings: IPSec security associations will be created between Alice and her HA. This security association can be reused after a handover without need for IKE renegotiation.

7.2. OVERALL HANDOVER PERFORMANCE

157

For micro-mobility protocols a similar security association will be created between Alice and the local “domain gateway”. 3. SIP Registration: Alice sends a SIP REGISTER message to her SIP server (SIP Registrar), using either her “home address” (if MIP is used), or her “care-of address” in the SIP Contact header. Alice will use TLS transport to protect the signalling to her SIP servers. When MIPv6 is used Alice may use either reverse tunneling or route-optimization to her SIP server, however, this would not have any significant impact on the performance of an ongoing call. Security bindings required: Alice needs a security binding with her SIP service provider. The server will use a certificate to authenticate during the TLS handshake. Alice will have a certificate issued by the SIP provider to be used for secure call establishment. Although she could use this certificate to authenticate in the TLS handshake, she would commonly authenticate using HTTP Digest (shared secret) through the TLS tunnel. Temporary security bindings: Alice creates security associations in terms of a TLS session and possibly a HTTP Digest authentication context with her SIP server. 4. Call establishment: Alice and Bob establish a secure phone call using MIKEY/Diffie-Hellman as keying protocol and SRTP (or IPSec) for media protection. The SIP signalling can be protected by TLS as in the previous step. On “the hop” between the SIP proxies an additional TLS (or IPSec) connection would be established, unless such a connection is already available. If the SIP ACK is sent directly between Alice and Bob another TLS session is required. (Unfortunately such a TLS session may expose their identities to eavesdroppers, since the TLS certificates are sent in the clear.) During call establishment Alice and Bob use SDP to specify used CODECs, transport addresses, etc. We propose they use media independent FEC with lag one. In section 6.5.3.1 we also mention the possibility for an “echoing CODEC” to test the specified transport addresses. Security bindings required: Alice and Bob authenticate using certificates. They could manually exchange fingerprints of these certificates, but for larger systems a trust model facilitated by an adequate authentication infrastructure is desirable, preferably including the SIP service providers as trusted intermediates1 . Alice’s and Bob’s SIP providers also require a security binding to bring up the TLS (or IPSec) connection between them. The same authentication infrastructure as above could be used. Temporary security bindings: To protect the SIP INVITE the TLS sessions created during SIP registration can be reused on the first and last hop2 . Alice’s and Bob’s SIP servers would establish security associations for their TLS (or IPSec) connection. 1 More precisely, it would be the organization in control of the domain name portion of Alice’s and Bob’s SIP URIs. See section 3.5 for more details. 2 Reusing the TLS session on the last hop may prove difficult in practice[96, 21].

158

CHAPTER 7. PUTTING IT ALL TOGETHER

The MIKEY handshake will provide Alice and Bob with master keys to protect their media traffic. It may also be possible to create temporary keys to protect MIPv6 BUs between Alice and Bob. 5. MIPv6 route optimization: When MIPv6 is used for mobility, Alice and Bob will each establish address bindings for route optimization, i.e., the first few media packets will be sent via the HAs while future packets are routed directly between Alice and Bob. Security bindings required: Alice and Bob need a security binding to protect the BU. Here we assume the MIPv6 Kbm is created as a side-effect of the (MIKEY) authentication during call establishment, see step 4. (Alternatively they can use the the return-routability mechanism.) Temporary security bindings: Alice and Bob will have a “pre-configured” Kbm to protect the BU. Alternatively (or complementary) they could have care-of address and home address key generation tokens based on return-routability. 6. Preparing for a future handover: After associating with an AP Alice could prepare for a possible future handover. When IEEE 802.11i is used as NAS solution this could include initiating IEEE pre-authentication with candidate handover targets (section 5.3.2). When CARD is used this includes contacting a local AR, which in turn may contact “adjacent” ARs. Additional “pro-active” handover mechanisms could be used, although we have not considered that here. Required security bindings: Pre-authentication will not require any additional bindings to those needed to gain network access (section 7.2.1 step 1). The CARD protocol requires trust between adjacent ARs, which can be run by different ISPs or access network operators. Temporary security bindings: With pre-authentication Alice will create security associations with candidate APs.

7.2.2

Hints about an upcoming handover

When Alice is moving away from her AP the SNR will eventually drop below some pre-defined threshold. Before Alice performs a handover she could take some additional actions related to the capabilities of her SIP UA. Chapter 2 contained a few suggestions of what Alice could do when she is about to make a handover: • Alice should if possible trigger a handover during a period of mutual silence. • She should notify Bob about the possibility of an upcoming handover. – Bob could then temporarily skip adaptive play-out buffering and instead increase buffering to a larger, but still acceptable value. – He could also adjust his FEC lag accordingly, and if Alice temporarily increases her play-out buffer more packets may be recovered.

7.2. OVERALL HANDOVER PERFORMANCE

159

– Bob can use a stateless CODEC to avoid additional ’synchronization losses’ after a possible packet loss. Alternatively, he could put multiple (old) RTP payloads in every packet. A drawback with both these approaches is the increased overhead, but only for the interval between possible handover and actual handover or the decision that there will not be a handover.

7.2.3

Performing the handover

Table 7.1 summarizes the number of messages exchanged when performing a handover in the proposed system, starting from IEEE 802.11 reassociation message exchange with the new AP. Before handover execution a search phase (∼40-100 ms) and a long flush phase (possibly including IEEE 802.11i preauthentication) have occurred. The values in Table 7.1 were computed as follows: • IEEE 802.11 handover execution: All handovers include 4 LOTT for IEEE 802.11 reassociation. • EAP-TLS authentication during NAS handshakes: EAP-TLS is used as authentication method for both IEEE 802.11i and L2TP/IPSec, see also Table 5.1. For IEEE 802.11i we assume Alice can use pre-authentication for in-LAN handovers (3LOTT ). For other handovers we assume the use of TLS session resumption both for IEEE 802.11i (9LOTT +6ROTT ) and L2TP/IPSec (36LOTT +6ROTT ). • Layer-3 mobility: Additional message exchange for layer-3 handovers is based on values from Table 6.1. – IEEE 802.11 4-way handshake: The last message of 4-way handshake is sent in the same direction as the first message in the layer3 mobility schemes. A LOTT is therefore withdrawn for layer-3 handovers when IEEE 802.11i is used as NAS. – L2TP/IPSec address assignment: In L2TP/IPSec Alice is assigned a COA during NAS handshaking. The values in Table 6.1 include COA assignment, thus for L2TP/IPSec the values are reduced accordingly. Additional explanations of the steps to perform the handover is provided below. 1. Layer-2 handover: The layer-2 handover involves multiple steps. (a) Search phase: When Alice decides to initiate the handover she will first scan for candidate APs. This could be carried out as a full scan with delays and losses as described in chapter 4 or using some selective scanning method, e.g., based on AP caching as described by Shin et al.[156]. (b) Flush phase: Assuming Alice is still able to communicate via her current AP she could postpone the execution of the handover for a brief time. This will enable her (1) to flush buffered outgoing data via the current AP, and (2) pre-authenticate with the target (new) AP, unless this was already done in step 6 of section 7.2.1.

160

CHAPTER 7. PUTTING IT ALL TOGETHER

802.11i MIPv6 MIPv4 SIP L2TP MIPv4 SIP

In-LAN Up Down 7L 7L 7L 7L 7L 7L 4L 4L 4L 4L

Regional Up Down 14L+6R 16L+6R 16L+6R 16L+6R 42L+6R 42L+6R -

Global Up Down 14L+6R 18L+8R 16L+8R 16L+8R 16L+6R 28L+12R 42L+8R 42L+8R 40L+6R 52L+12R

Table 7.1: Summary of handover message exchange and delays. Before handover execution a search phase (∼40-100 ms) and a flush phase occur (possibly including IEEE 802.11i pre-authentication). (L = LOTT , R = ROTT )

(c) Execution phase: Exchanging the IEEE 802.11 authentication and reassociation messages (4LOTT ) should only constitute a minor delay (chapter 4). 2. Acquire network access: As shown in Table 5.1 the required message exchange will be different if IEEE 802.11i or L2TP/IPSec is used, and will also differ if the handover is performed within or across subnet borders. L2TP/IPSec: If Alice has performed a L2 handover she will be able to continue without any further interruption in the data flow. However, if she has moved to a new subnet she needs to reestablish the PPP/L2TP connection to the appropriate LNS in the network. If Alice does not know whether she has performed a L3 handover or not, she could continue communicating as if she was still on the same LAN in parallel with sending a DHCP discover message to acquire a new IP address as if she had moved. If the DHCP Offer indicates that she is still on the same subnet, then further L3 handover mechanisms would be aborted. In Table 7.1 we have not considered the combination of L2TP/IPSec as NAS solution and MIPv6 as mobility management protocol. Although L2TP can certainly be used to assign Alice an IPv6 address, we believe the use of IPv6 will be more common for IEEE 802.11i than for L2TP setups. IEEE 802.11i: If Alice has performed a L2 handover she would only need to perform a new 4-way handshake, given that IEEE 802.11i preauthentication was successful. Otherwise she will perform an EAPTLS authentication with her home AAA server (using TLS session resumption). 3. Further actions in case of Layer-3 handover (a) Acquiring a new IP address: This step only occurs when IEEE 802.11i is used as the NAS solution. Alice needs to be configured with a new COA, which requires handshaking and delays as explained in chapter 6. Some micromobility management mechanisms enable Alice to keep her COA while roaming within a region of the network. Table 7.1 only show

7.2. OVERALL HANDOVER PERFORMANCE

161

values for regional handover for MIPv6 (assuming “hierarchical MIPv6”) and MIPv4 (assuming “hierarchical FAs”) as described in section 6.6.2. To avoid additional delay for MIPv6 global handovers we assume that Alice first registers her on-link COA and after necessary handshaking registers her regional COA. Micro-mobility schemes can also be used with SIP mobility, see chapter 6 for further discussions. (b) Redirecting data flows: The procedure to redirect the incoming and outgoing data streams will differ depending on whether SIP mobility or MIPv6 with route optimization is used. SIP mobility: Upon a layer-3 handover Alice will send a re-INVITE informing Bob of her new IP address. We have assumed she sends it directly to Bob using TLS transport (resuming TLS session created in step 4 of section 7.2.1). As described in chapter 6 we assume Alice can send upstream data immediately, while the stream from Bob will be redirected first when he receives the re-INVITE. MIPv6 with route optimization: After a global handover Alice would immediately transmit BUs to her HA and to Bob, with the BU to Bob protected with the pre-configured Kbm created in step 5 in section 7.2.1. Upstream data could be sent immediately after the BU to Bob, while downstream data would first be redirected when the BU reaches Bob. After a regional handover the downstream data could be redirected faster.

Chapter 8

Conclusions and Future Work 8.1

Conclusions

In this thesis we have examined the implications of providing secure IP telephony to mobile users, both from the user’s and operator’s perspectives. Below we give concluding remarks for the various aspects of the given problem: • Security of voice call: Media sessions established with SIP should be protected by default. In this thesis we have examined the use of SRTP and IPSec of which the former (SRTP) is preferred, since it makes the VoIP applications less dependent on the IPSec support in the end-device. To establish the call we recommend the use of MIKEY/Diffie-Hellman as authenticated keying protocol (possibly protected by S/MIME), since it provides perfect forward secrecy and integrates well with the SIP call setup signalling. Two issues which need further research concern authentication infrastructures (for scalability) and call policy management (for spam control etc.). Trust models for secure call establishment presented in this thesis generally involve the SIP service providers as trusted intermediates. • WLAN access networks: To enable wide-spread WLAN coverage the use of shared access networks is proposed and examined. As network access server solutions we have focused on the use of IEEE 802.11i and L2TP/IPSec, since both enable per-packet authentication and are supported in modern operating systems. Of these two we prefer IEEE 802.11i, since it requires less handshaking during layer-3 handovers, adds less per-packet overhead, and does not constrain the use of VPN solutions. L2TP/IPSec can easily be introduced in a legacy WLAN environment. However, a user wishing to setup a L2TP/IPSec VPN tunnel to their home network may have difficulties to also use L2TP/IPSec as NAS solution, both in terms of configuration and overhead. Another promising NAS alternative is IP-IPSec tunneling for which work is in progress in the PANA and MOBIKE IETF working groups. • Layer-3 mobility: Mobility across LAN borders is more complex and has a worse impact on the handover performance than mobility within

8.1. CONCLUSIONS

163

a LAN. As a consequence WLAN access networks should be designed using layer-2 switching (bridging) to the extent scalability allows, thus avoiding layer-3 handovers to frequently occur. For layer-3 mobility we have primarily evaluated the use of SIP mobility and MIPv6, which both enable optimal routing of the media streams. Both MIP and SIP mobility are likely to get wide-spread use and the choice of which solution to use will depend both on individual preferences and the mobility support implemented by the remote end. We have also examined the use of micro-mobility management protocols to enhance mobility within a region of the network topology. Although such approaches improves handover performance when users roam between subnets of an operator, micro-mobility schemes add to system complexity, and require additional security relationships. Thus, it is not obvious if the benefits of micro-mobility support schemes motivate their use as compared to only using layer-3 macro-mobility and layer-2 handover support. One of the hardest issues with layer-3 mobility in WLAN access networks relates to limited capabilities to roam between APs announcing different ESSIDs. This problem is not solved in this thesis, but we propose the use of protocols such as CARD (earlier under development within the IETF Seamoby working group). Unfortunately this adds to the access network complexity and requires additional security relationships between access network operators. Although we generally aim for less dependency on infrastructure services (leaving as much control to end-users as possible), the introduction of protocols such as CARD may motivate the use of other services such as micro-mobility support, QoS facilities, etc. • Handover performance: As long as handovers can be handled at layer2 the performance implications can be kept within reasonable limits. In this thesis we present own ideas as well as other proposals of how the impact of IEEE 802.11 WLAN handovers can be reduced, and if these suggestions are combined with appropriate VoIP application support (packet loss recovery and play-out buffer management) impairments due to layer-2 handover are likely to be insignificant. Handling layer-3 mobility is more complex. Many mechanisms involve random waiting times, primarily for the purposes of synchronization avoidance and duplicate address detection. We suggest that these random wait times are avoided as part of the time critical handover path, either because the are unnecessary or because they could be handled by other means. Layer-3 handovers lead to relatively long handover delays, because they commonly require messages to be exchanged to remote entities over the Internet backbone, and more extensive signalling between Alice and entities within the visited network. For example, the PPP based solutions examined requires several round-trips between Alice and the local NAS, leading both to increased delay and increased sensitivity to loss of signalling packets (with associated timeouts to follow). Some of the delay

164

CHAPTER 8. CONCLUSIONS AND FUTURE WORK

issues with layer-3 handover can be addressed through the use of micromobility protocols, however, layer-2 access network solutions may be a more adequate approach as earlier mentioned. Layer-3 handover can also be improved by relaxing the security constraints somewhat, e.g., by using UDP rather than TLS transport for SIP re-INVITE messages, or skipping/postponing care-of address tests in MIPv6. Appropriate end-node support improves overall as well as handover performance. Efficient play-out buffer implementations give shorter endto-end delay, and increase the ability to use longer buffers during times of handover. Integration of VoIP and link layer support may assist the VoIP application to adapt to an upcoming handover, and perhaps also to control the timing of the handover execution. Ability to notify the remote VoIP user agent about an upcoming handover may also prove beneficial. • Security relationships: In a general solution Alice would have an identity and a security relationship with an ISP, a SIP service provider and (if MIP is used) also a MIP service provider. In reality a single provider will offer multiple services, i.e., an ISP may offer MIP and SIP services just like they commonly offer electronic mail services today. Of course SIP providers may expand their services and become “virtual ISPs”, thus the border between actors will blur. While the a` la carte model makes it easier for new actors to enter the market and leads to increased competition, users may prefer to receive all services from a single provider. Below we list the security relationships required in a general model. – General security relationships for Alice: ∗ Alice and ispA.com: Alice needs to sign-up with a (possibly virtual) ISP in order to acquire network access. Alice would commonly have an identity associated with her ISP ([emailprotected]). ∗ Alice and sipA.com: Alice needs to sign-up with a SIP service provider, which operates the necessary SIP servers (possibly including a SIP/PSTN gateway). Alice would commonly have an identity associated with her SIP provider ([emailprotected]), but one could also consider solutions where the SIP provider hosts SIP services for another actor, e.g., Alice’s ISP or if Alice has registered a domain of her own. ∗ Alice and mipA.com: If Alice uses Mobile IP for mobility management she needs to sign-up with a MIP service provider. Commonly she would need an identity associated with her MIP service provider ([emailprotected]). – Additional security relationships: ∗ Secure VoIP call establishment: When establishing a secure call between Alice and Bob they will mutually authenticate during call setup. As Alice and Bob commonly will use SIP URIs associated with their respective SIP service provider ([emailprotected] and [emailprotected]) we suggest their SIP providers act as trusted intermediates (if Alice uses another SIP URI the organization in

8.2. FUTURE WORK

∗

8.2

165

charge of that domain would be used as trusted intermediate; this could happen if the SIP service provider is hosting SIP services for another organization). Remote network access: To acquire access in WLAN networks run by other ISPs a roaming agreement (and security relationship) is needed between Alice’s ISP and the visited ISP, either directly of via some intermediate roaming actor. In networks with native operator neutrality there is also a need for security relationships between the local access operator and the connected ISP, e.g., to protect RADIUS messages. Use of CARD to facilitate layer-3 mobility: CARD could be used to facilitate roaming between IP subnets (cross-ESSID), either within the network of an operator or between operator networks. In the latter case security relationships need to be established between access network operators. Layer-3 route optimization: Mobility management protocols enabling optimal routing provide lower end-to-end delay and are therefore desirable for IP-telephony, however, route-optimization requires security relationships between Alice and Bob to protect the redirection signaling. The situation differs somewhat if mobility support is provided via MIPv6 or SIP, however, the authentication infrastructure used during the SIP call establishment could be used to generate keys to protect even MIPv6 binding updates. Layer-3 micro-mobility: When micro-mobility management protocols are used to improve mobility within a domain, Alice generally needs to establish a security association with a local “domain gateway”. To establish this security association additional security relationships may be needed, e.g., between Alice’s MIP service provider and the visited ISP.

Future work

Enabling mobile IP users to communicate securely using VoIP brings together several research areas within communication. This thesis aims at addressing security aspects of interest to end-users and system operators and to study the handover performance when mobile users perform layer-2 and layer-3 handovers in a public WLAN environment, but several of the ideas proposed here remains to be explored. Some areas where this thesis may trigger future work include: • Overall performance: We have presented symbolic expressions of handover performance, where the number of local (WLAN) network traversals and backbone network traversals have formed the basis for comparison. Performing real tests with all system components configured is an important extension to this work. • Secure IP telephony: In chapter 3 we give several alternatives of how a secure VoIP call can be established. A few of these methods have been

166

CHAPTER 8. CONCLUSIONS AND FUTURE WORK

implemented in SIP user agents such as minisip, but this area is under development additional research is required to find good and deployable solutions. Two topics pointed at concern authentication infrastructures suitable for IP telephony and methods to efficiently block VoIP spam. • VoIP applications and mobility: In chapter 2 we propose several ideas how VoIP applications should behave to handle the loss and delay characteristics related to user mobility. Some of these ideas require support from the link layer to indicate an upcoming handover and perhaps even primitives for the application to control the timing of the handover. In other methods a SIP user agent notifies the remote side that it is about to perform a handover and that suitable actions should be taken. Design of a such protocol and evaluation of its impact on handover performance is left to future work. • Layer-3 mobility: In chapter 6 the issues with layer-3 handover and the IEEE 802.11 ESSID is described. To facilitate roaming between WLAN access networks announcing different ESSIDs we have suggested the use of protocols such as CARD. Exploring this idea is left to future work.

Acronyms and abbreviations A/D AAA AAAH AAAF AES AES-CM AH API AR AS ASCII BA BSS BSSID BU CA CARD CCP CLNP CN COA CODEC CRL D/A DAD DHCP DRCP Diffserv DMA EAP EAPoL ESP ESS ESSID FA FEC FQDN

Analog/Digital Authentication, Authorization, and Accounting Home AAA server Foreign AAA server Advanced Encryption Standard AES Counter Mode Authentication Header Application Programming Interface Access Router Authentication Server American Standard Code for Information Interchange Binding Acknowledge Basic Service Set BSS Identifier Binding Update Certificate Authority Candidate Access Router Discovery Compression Control Protocol (PPP) Connectionless Network Layer Protocol Correspondent Node Care-of IP Address Coder Decoder Certificate Revocation List Digital/Analog Duplicate Address Detection Dynamic Host Configuration Protocol Dynamic Registration and Configuration Protocol Differentiated Services Direct Memory Access Extensible Authentication Protocol EAP over LAN Encapsulation Security Payload Extended Service Set ESS Identifier Foreign Agent (Mobile IP) Forward Error Correction Fully Qualified Domain Name

HA HAWAII HBR IAPP IEEE IETF IP IPCP IPSec IPv4 IPv6 ISP KINK L2TP LAC LAN LBR LNS MAC MIC MIKEY MIP MIP-LR MIPv4 MIPv6 MMP MN MOS MSP NAS PBX PCM PEAP PKI PLC PMK PMKID POP PPP PPPoE PPTP PSTN QoS RADIUS RSVP RTCP RTP

Home Agent (Mobile IP) Handoff-Aware Wireless Access Internet Infrastructure Host Based Routing Inter-Access Point Protocol Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Protocol Internet Protocol Control Protocol Internet Protocol Security IP version 4 IP version 6 Internet Service Provider Kerberized Internet Negotiation of Keys Layer-2 Tunneling Protocol L2TP Access Concentrator Local Area Network Low Bit-rate Redundancy L2TP Network Server Medium Access Control Message Integrity Code Multimedia Internet Keying Mobile IP Mobile IP with Location Registers Mobile IPv4 Mobile IPv6 Micro-mobility Management Protocol Mobile Node Mean Opinion Score MIP Service Provider Network Access Server Private Branch Exchange Pulse Code Modulation Protected EAP Public Key Infrastructure Packet Loss Concealment Primary Master Key Primary Master Key Identifier Point-Of-Presence Point-to-Point Protocol PPP over Ethernet Point-to-point Tunneling Protocol Public Switched Telephone Network Quality of Service Remote Authentication Dial In User Service Resource Reservation Protocol RTP Control Protocol Real-time Transport Protocol

S/MIME SCTP SIM SIP SRTP TCP TLS UA UDP URL VAD VLAN VoIP WISP WLAN WPA WTP XOR

Secure/Multipurpose Internet Mail Extensions Stream Control Transmission Protocol Subscriber Indentity Module Session Initiation Protocol Secure RTP Transmission Control Protocol Transport Layer Security User Agent User Datagram Protocol Uniform Resource Locator Voice Activity Detection/Detector Virtual LAN Voice over IP Wireless ISP Wireless LAN Wi-Fi Protected Access Wireless Termination Point eXlusive OR

Bibliography [1] D. Eastlake 3rd and C. Kaufman. Extensions, January 1997. RFC 2065.

Domain Name System Security

[2] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, and Ed. Extensible Authentication Protocol (EAP), June 2004. RFC 3748. [3] B. Aboba and D. Simon. PPP EAP TLS Authentication Protocol, October 1999. RFC 2716. [4] Bernard Aboba. Wireless LANs: The 802.1X Revolution. Internet World Wireless West, December 2001. Available online at http://www.drizzle.com/˜aboba/IEEE/BAWUG.ppt. [5] Flemming Andreasen, Mark Baugher, and Dan Wing. Session Description Protocol Security Descriptions for Media Streams. IETF draft , February 2005. Work in progress. [6] Flemming Andreasen and Dan Wing. Security Preconditions for Session Description Protocol Media Streams. IETF draft , February 2005. Work in progress. [7] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman. MIKEY: Multimedia Internet KEYing, August 2004. RFC 3830. [8] J. Arkko and H. Haverinen. Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). IETF draft . Work in progress, 2004 dec. [9] J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, and T. Haukka. Security Mechanism Agreement for the Session Initiation Protocol (SIP), January 2003. RFC 3329. [10] J. Arkko and C. Vogt. A taxonomy and analysis of enhancements to mobile ipv6 route optimization. IETF draft , January 2005. [11] Jari Arkko. Email discussion, subject ’Sending data to CN after handoff?’. Discussion on IETF MIP6 Mailing list, March 2005.

[12] Jari Arkko, Elisabetta Carrara, Fredrik Lindholm, Mats Naslund, and Karl Norrman. Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP). IETF draft , March 2005. Work in progress. [13] B.R. Badrinath and Anup Talukdar. IPv6 + MOBILE-IP + MRSVP = Internet Cellular Phone? In Proceedings of the 5th IFIP International Workshop on Quality of Service (IWQoS ’97), May 1997. Columbia University, New York, USA. [14] Mary G. Baker, Xinhua Zhao, Stuart Cheshire, and Jonathan Stone. Supporting Mobility in MosquitoNet. In Proceedings of the 1996 USENIX Technical Conference, January 1996. San Diego, CA, USA. [15] A. Barbot, A. Damola, V. Kulkarni, P. Li, J. Ordeberg, and T. Wu. Hotspot Laponia Design Report Draft. Student project in Communication Systems Design Course, KTH, Stockholm, Sweden, March 2004. Available online at http://csd.ssvl.kth.se/˜csd2004team18/Delivers/HL design report.pdf. [16] A. Barbot, A. Damola, V. Kulkarni, P. Li, J. Ordeberg, and T. Wu. Hotspot Laponia Final Report. Student project in Communication Systems Design Course, KTH, Stockholm, Sweden, May 2004. Available online at http://csd.ssvl.kth.se/˜csd2004-team18/Delivers/HL final report.pdf. [17] Roberto Battiti, Renato Lo Cigno, Fredrik Orava, and Bjorn Pehrson. Wireless LANs: from WarChalking to Open Access Networks. In 1st ACM international workshop on Wireless mobile applications and services on WLAN hotspots, pages 19–28, 2003. San Diego, CA, USA. [18] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman. The Secure Real-time Transport Protocol (SRTP), March 2004. RFC 3711. [19] J. Bilien, E. Eliasson, and J-O. Vatn. Call establishment delay for secure VoIP. In Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks (WiOpt’04), March 2004. Cambridge, UK. [20] Johan Bilien. Key Agreement for Secure Voice over IP. Master’s thesis, Royal Institute of Technology (KTH), Sweden, December 2003. Available online at ftp://ftp.it.kth.se/Reports/DEGREE-PROJECTREPORTS/031215-Johan-Bilien-report-final-with-cover.pdf Accessed March 2005. [21] Johan Bilien, Erik Eliasson, Joachim Orrblad, and Jon-Olov Vatn. Accepted for the 2nd Workshop on Securing Voice over IP, June 2005. Washington DC, USA. [22] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Service, December 1998. RFC 2475. [23] L. Blunk and J. Vollbrecht. PPP Extensible Authentication Protocol (EAP), March 1998. RFC 2284.

[24] J-C Bolot. Characterizing End-to-end Packet Delay and Loss in the Internet. Journal of High-Speed Networks, 2(3):305–323, December 1993. [25] J.-C. Bolot, C. Hugues, and A.V. Garcia. Analysis of Audio Packet Loss in the Internet. In International Workshop on Network and operating System Support for Digital Audio and Video (NOSSDAV), April 1995. [26] Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting Mobile Communications: The Insecurity of 802.11. In Seventh Annual International Conference on Mobile Computing And Networking, July 2001. Also http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html. [27] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification, September 1997. RFC 2205. [28] Paul T. Brady. A technique for investigating on-off patterns of speech. Bell System Technical Journal, 44(1):1–22, January 1965. [29] Paul T. Brady. A statistical Analysis of On-Off Patterns in 16 Conversations. Bell System Technical Journal, 47(1):73–91, January 1968. [30] Israel Abad Caballero. Secure Mobile VoIP. Master’s thesis, Department of Microelectronics and Information Technology, Royal Institute of Technology, June 2003. ´ C´aceres and Venkata N. Padmanabhan. Fast and Scalable [31] Ramon Handoffs for Wireless Internetworks. In Proceedings of ACM MobiCom ’96, November 1996. Rye, NY, USA. [32] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. Diameter Base Protocol, September 2003. RFC 3588. [33] Pat R. Calhoun, Tony Johansson, Charles E. Perkins, Tom Hiller, and Peter J. McCann. Diameter Mobile IPv4 Application. IETF draft , August 2004. Work in progress. [34] G. Camarillo, Ed., W. Marshall, Ed., and J. Rosenberg. Integration of Resource Management and Session Initiation Protocol (SIP), October 2002. RFC 3312. [35] G. Camarillo and H. Schulzrinne. Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP), December 2004. RFC 3960. [36] H. Cheng, S. Iino, and S. Govindan. Functionality Classifications for Control and Provisioning of Wireless Access Points (CAPWAP). IETF draft Work in progress., July 2004. [37] R.G Cole and J.H. Rosenbluth. Voice over IP Performance Monitoring. Computer Communication Review, ACM Sigcomm, 31(2):9–24, April 2001.

[38] S. Dahlberg, G. Grandfils, Y. Zhou, A. Mahdavi, and K. Chen. Oasis open access server in subnets, final report. Project of CSD-course, Royal Institute of Technology, Sweden, may 2002. Available online at http://csd.ssvl.kth.se/˜csd2002-openaccessserver/Final report.pdf, Accessed April 2004. [39] Stephen E. Deering. Internet RFC 1256, ICMP Router Discovery Messages, September 1991. [40] R. Droms. Dynamic Host Configuration Protocol, March 1997. RFC 2131. [41] Ashutosh Dutta, James Burns, K. Daniel Wong, Ravi Jain, Ken Young, and Henning Schulzrinne. Multilayered Mobility Management for Survivable Network. In IEEE MILCOM’01, October 2001. [42] Ashutosh Dutta, Subir Das, Peter Li, Anthony McAuley, Yoshihiro Ohba, Shinichi Baba, and Henning Schulzrinne. Secured Mobile Multimedia Communication for Wireless Internet. In ICNSC, 2004. Taipei, Taiwan. [43] Ashutosh Dutta, Sunil Madhani, H. Schulzrinne, Onur Altintas, and Wai Chen. Optimized Fast-handoff Schemes for Application Layer Mobility Management. MC2R, November 2002. [44] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, January 1998. RFC 2267. [45] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, May 2000. RFC 2827. [46] Sally Floyd and Van Jacobson. The synchronization of periodic routing messages. IEEE/ACM Transactions on Networking, April 1994. ftp://ftp.ee.lbl.gov/papers/sync 94.ps.Z. [47] Paul Funk and Simon Blake-Wilson. EAP Tunneled TLS Authentication Protocol (EAP-TTLS). IETF draft . Work in progress, July 2004. [48] J. Antonio Garcia-Macias, Franck Rousseau, Gilles Berger-Sabbatel, Leyla Toumi, and Andrzej Duda. Quality of Service and Mobility for the Wireless Internet. Wireless Networks, 9, 2003. [49] Rohit Ghai and Suresh Singh. An Architecture and Communications Protocol for Picocellular Networks. IEEE Personal Communications Magazine, 1(3):36–46, 1994. [50] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP Authentication, Authorization, and Accounting Requirements, October 2000. RFC 2977. [51] John G. Gruber and Leo Strawczynski. Subjective Effects of Variable Delay and Speech Clipping in Dynamically Managed Voice Systems. IEEE Transactions on Communications, COM-33(8), August 1985.

[52] Eva Gustafsson, Annika Jonsson, and Charles Perkins. Mobile IPv4 Regional Registration. IETF draft , Work in progress, November 2003. [53] Eva Gustafsson, Annika Jonsson, and Charles Perkins. Mobile IPv4 Regional Registration. IETF draft , Work in progress, November 2004. [54] Olof Hagsand, Ian Marsh, and Kjell Hanson. Sicsophone: A Low-delay Internet Telephony Tool. In 29th Euromicro Conference, September 2003. Belek, Turkey. [55] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. Pointto-Point Tunneling Protocol, July 1999. RFC 2637. [56] M. Handley and V. Jacobson. SDP: Session Description Protocol, April 1998. RFC 2327. [57] Vicky Hardman, Angela Sasse, Mark Handley, and Anna Watson. Reliable Audio for Use over the Internet. In International Networking Conference (INET’95, June 1995. Honolulu, Hawaii. [58] D. Harkins and D. Carrel. The Internet Key Exchange (IKE), November 1998. RFC 2409. [59] D. Haskin and E. Allen. IP Version 6 over PPP, December 1998. RFC 2472. [60] H. Haverinen and J. Salowey. Extensible Authentication Protocol Method for GSM Subscriber Identity Modules (EAP-SIM). IETF draft . Work in progress, December 2004. [61] Changhua He and John C. Mitchell. Analysis of the 802.11i 4-Way Handshake. In ACM WiSe ’04, 2004. Philadelphia, Pennsylvania, USA. [62] K. Hedayat, P. Jones, A. Roychwdhury, C. SivaChelvan, and N. Stratton. An Extension to the Session Description Protocol (SDP) for Media Loopback. IETF draft Work in progress., December 2004. [63] Martin Hedenfalk. Access Control in an Operator Neutral Public Access Network. Master’s thesis, Royal Institute of Technology (KTH), Sweden, june 2002. [64] R. Hinden and S Deering. Internet RFC 2373, IP Version 6 Addressing Architecture, July 1998. [65] S. Hollenbeck. Generic Registry-Registrar Protocol Requirements, September 2002. RFC 3375. [66] Linux hostap driver. http://hostap.epitest.fi. [67] R. Housley. Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP), January 2004. RFC 3686.

[68] IEEE Std 802.11, 1999 Edition (ISO/IEC 8802-11: 1999) IEEE Standard for Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Network Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. [69] IEEE Std 802.11F, IEEE Trial-Use Recommended Practice for MultiVendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation, June 2003. [70] IEEE Std 802.11i-2004, IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements, June 2004. [71] IEEE Std. 8021D, 1998 Edition, IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Common specifications Part 3: Media Access Control (MAC) Bridges, 1998. [72] IEEE 802.1X-2001, IEEE Standards for Local and Metropolitan Area Networks: Port-Based Network Access Control, June 2001. [73] International Telecommunication Union Telecommunication Standardization Sector (ITU-T). Recommendation G.114, Transmission Systems and Media, General Characteristics of International Telephone Connections and International Telephone Circuits, One-Way Transmission Time, February 1996. [74] Ravi Jain, Thomas Raleigh, Danny Yang, Li Fung Chang Charles Graff, Michael Bereschinsky, and Mitesh Patel. Enhancing Survivability of Mobile Internet Access Using Mobile IP with Location Registers. In IEEE Infocom, March 1999. [75] Wenyu Jiang and Henning Schulzrinne. Analysis of On-Off Patterns in VoIP and Their Effect on Voice Traffic Aggregation. In Ninth Conference on Computer Communications and Networks (ICCCN), October 2000. Las Vegas. [76] Wenyu Jiang and Henning Schulzrinne. Comparison and Optimization of Packet Loss Repair Methods on VoIP Perceived Quality under Bursty Loss. In 12th International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), May 2002. Miami Beach, Florida, USA. [77] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6, June 2004. RFC 3775. [78] Vivek Kamath and Ashwin Palekar. Microsoft EAP CHAP Extensions. IETF draft . Work in progress, April 2004.

[79] Charlie Kaufman. Internet Key Exchange (IKEv2) Protocol. IETF draft , September 2004. Work in progress. [80] S. Kent and R. Atkinson. IP Authentication Header, November 1998. RFC 2402. [81] S. Kent and R. Atkinson. November 1998. RFC 2406.

IP Encapsulating Security Payload (ESP),

[82] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol, November 1998. RFC 2401. [83] T. Kivinen, B. Swander, A. Huttunen, and V. Volpe. Negotiation of NATTraversal in the IKE, January 2005. RFC 3947. [84] Rajeev Koodli. Fast Handovers for Mobile IPv6. IETF draft , Work in progress, October 2004. [85] Rajeev Koodli and Charles E. Perkins. Fast handovers and context transfers in mobile networks. ACM SIGCOMM Computer Communication Review, 31(5), October 2001. [86] Michael E. Kounavis, Andrew T. Campbell, Gen Ito, and Giuseppe Bianchi. Supporting Programmable Handoff in Mobile Networks. In 1999 IEEE International Workshop on Mobile Multimedia Communications (MoMuC’99), November 1999. San Diego, CA, USA. [87] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication, February 1997. RFC 2104. [88] H. Kummert. The PPP Triple-DES Encryption Protocol (3DESE), September 1998. RFC 2420. [89] N. Long Le. Development of a loss-resilient internet speech transmission method. Master’s thesis, GMD Fokus, Berlin, Germany, May 1999. [90] H. Levkowetz and S. Vaarala. Mobile IP Traversal of Network Address Translation (NAT) Devices, May 2003. RFC 3519. [91] Marco Liebsch, Ajoy Singh, Hemant Chaskar, Daichi Funato, and Eunsoo Shim. Candidate access router discovery. IETF draft ,, December 2003. Work in progress. [92] Helger Lipmaa, Phillipe Rogaway, and David Wagner. CTR-Mode Encryption. NIST. Available online at http://csrc.nist.gov/encryption/modes/workshop1/papers/lipmaactr.pdf. [93] J. Loughney, M. Nakhjiri, and C. Koodli Perkins. Context Transfer Protocol. IETF draft , January 2004. Work in progress. [94] C. Madson and R. Glenn. The Use of HMAC-SHA-1-96 within ESP and AH, November 1998. RFC 2404.

[95] Gerald Q. Maguire Jr. Technology, May 2003.

Private communication, Royal Institute of

[96] R. Mahy. Connection Reuse in the Session Initiation Protocol (SIP). IETF draft , October 2004. Work in progress. [97] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, and R. Wheeler. A Method for Transmitting PPP Over Ethernet (PPPoE), February 1999. RFC 2516. ¨ [98] Yun Mao, Bjorn Knutsson, Honghui Lu, and Jonathan M. Smith. DHARMA: Distributed Home Agent for Robust Mobile Access. In IEEE INFOCOM 2005, March 2005. Miami, Florida. [99] Ian Marsh. Quality aspects of audio communication, May 2003. TRITAIMIT-LCN AVH 03:01, ISSN 1651-4106, ISRN KTH/IMIT/LCN/AVH03/01 SE. [100] Anthony McAuley, Subir Das, Sunil Madhani, Shinichi Baba, and Yasuro Shobatake. Dynamic Registration and Configuration Protocol (DRCP). IETF draft Work in progress., July 2000. [101] K. McCloghrie, D. Perkins, and J. Schoenwaelder. Textual Conventions for SMIv2, April 1999. RFC 2579. [102] G. McGregor. The PPP Internet Protocol Control Protocol (IPCP), May 1992. RFC 1332. [103] D. Mills. Network Time Protocol (Version 3) Specification, Implementation, March 1992. RFC 1305. [104] Arunesh Mishra, Minho Shin, and William Arbaugh. An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process. Technical Report CS-TR-4395 UMIACS-TR-2002-75, University of Maryland, 2002. Available at http://www.cs.umd.edu/˜mhshin/paper/ACMCCRMishra.Shin.Arbaugh.ps (Accessed January 2003). [105] G. Montenegro and Ed. Reverse Tunneling for Mobile IP, revised, January 2001. RFC 3024. [106] Warren Montgomery. Techniques for Packet Voice Synchronization. IEEE Journal on Selected Areas in Communications, 6(1):1022–1028, December 1983. [107] Sue B. Moon, Jim Kurose, and Don Towsley. Packet audio playout delay adjustment: performance bounds and algorithms. Multimedia Systems, (6):17–28, 1998. Springer Verlag. [108] Nobuyasu Nakajima, Ashutosh Dutta, Subir Das, and Henning Schulzrinne. Handoff Delay Analysis and Measurement for SIP based mobility in IPv6. In IEEE 2003 International Conference on Communications (ICC’03), May 2003. Anchorage, Alaska, USA.

[109] Thomas Narten, Erik Nordmark, and Susan Thomson. Internet RFC 2461, Neighbor Discovery for IP Version 6 (IPv6), December 1998. [110] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark. Mobile IP version 6 Route Optimization Security Design Background. IETF draft . Work in progress., October 2004. [111] The Secure Hash Algorithm (SHA-1). National Institute of Standards and Technology, NIST FIPS PUB 180-1, ”Secure Hash Standard,”, U.S. Department of Commerce, April 1995. [112] NoCatAuth home page. http://nocat.net. [113] B O’Hara, P. Calhoun, and J. Kempf. CAPWAP Problem Statement. IETF draft , August 2004. Work in progress. [114] L. Ong and J. Yoakum. An Introduction to the Stream Control Transmission Protocol (SCTP), May 2002. RFC 3286. [115] Joachim Orrblad. Alternatives to MIKEY/SRTP to secure VoIP. Master’s thesis, Royal Institute of Technology (KTH), Sweden, March 2005. Available online at ftp://ftp.it.kth.se/Reports/DEGREE-PROJECTREPORTS/050330-Joachim-Orrblad.pdf Accessed March 2005. [116] Ashwin Palekar, Dan Simon, Joe Salowey, Hao Zhou, Glen Zorn, and S. Josefsson. Protected EAP Protocol (PEAP) Version 2. IETF draft . Work in progress, October 2004. [117] G. Pall and G. Zorn. Microsoft Point-To-Point Encryption (MPPE) Protocol, March 2001. RFC 3078. [118] IETF Working Group on Protocol for carrying Authentication for Network Access (PANA). http://www.ietf.org/html.charters/panacharter.html. [119] B. Patel, B. Aboba, W. Dixon, G. Zorn, and S. Booth. Securing L2TP using IPsec, November 2001. RFC 3193. [120] C. Perkins and Ed. IP Mobility Support for IPv4, August 2002. RFC 3344. [121] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, and S. Fosse-Parisis. RTP Payload for Redundant Audio Data, September 1997. RFC 2198. [122] Charles Perkins. Precomputable Binding Management Key Kbm for Mobile IPv6. IETF draft , Work in progress, October 2004. [123] Charles Perkins and David B. Johnson. Route optimization in mobile ip , February 1999. Internet draft. Work in progress.

[124] Charles Perkins and David B. Johnson. Route Optimization in Mobile IP. IETF draft , Work in progress, September 2001. [125] Colin Perkins, Orion Hodson, and Vicky Hardman. A Survey of Packet Loss Recovery Techniques for Streaming Audio. IEEE Network, pages 40–48, Sep/Oct 1998. [126] Radia Perlman. An Overview of PKI Trust Models. Magazine, Nov/Dec 1999.

IEEE Network

[127] Radia Perlman. Interconnections. Addison-Wesley, 2 edition, 1999. [128] J. Peterson. Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format, September 2004. RFC 3893. [129] Elliot Poger and Mary Baker. Secure Public Internet Access Handler (SPINACH). In USENIX Symposium on Internet Technologies and Systems, December 1997. [130] Christos Politis, Kar Ann Chew, Nadeem Akhtar, Michael Georgiades, Rahim Tafazolli, and Tasos Dagiuklas. Hybrid multilayer mobility management with AAA context transfer capabilities for all-IP networks. IEEE Wireless Communications, August 2004. [131] J. Postel. User Datagram Protocol, August 1980. RFC 768. [132] Jon Postel. Internet RFC 792, Internet Control Message Protocol, September 1981. [133] Paul’s PPP package for Linux and Solaris, http://www.samba.org/ppp. [134] Rubayat Abu Rahat, Tarun Varma, Madan Krishna Adhikari, Zahid Hasan, and Jih-Farn Chen. Peer to Peer Communication. Peer to Peer Communication, Mid Term Presentation Slides (MidTerm Presentation.pdf), Project in CSD-course, Royal Institute of Technology, Sweden, 2005. Available online at http://csd.ssvl.kth.se/˜csd2005-team12/archive.htm, Accessed April 2005. [135] Bala Rajagopalan. Mobility and Quality of Service (QoS) in the Internet. In 3rd International Workshop on Mobile Multimedia Communications, September 1996. Princeton, NJ. [136] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, and L. Salgarelli. IP micro-mobility support using HAWAII. IETF draft , Work in progress, June 1999. [137] R. Ramjee, K. Varadhan, L. Salgarelli, S. Thuel, S. Wang, and T. La Porta. Hawaii: A domain-based approach for supporting mobility in wide-area wireless networks. IEEE/ACM Transactions on Networking, 2002.

[138] Ramachandran Ramjee, Jim Kurose, Don Towsley, and Henning Schulzrinne. Adaptive Playout Mechanisms for Packetized Audio Applications in Wide-Area Networks. In 13th IEEE Conference on Networking for Global Communications (INFOCOM 1994), volume 2, pages 680–688, June 1994. Toronto, Canada. [139] B. Ramsdell and Ed. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, July 2004. RFC 3851. [140] D. Rand. The PPP Compression Control Protocol (CCP), June 1996. RFC 1962. [141] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS), April 1997. RFC 2138. [142] C. Rigney, S. Willens, A. Rubens, and W. Simpson. Remote Authentication Dial In User Service (RADIUS), June 2000. RFC 2865. [143] Luigi Rizzo. The FreeBSD Audio Driver. In COST 237 Workshop’97, December 1997. Lisbon, Portugal, Available at http://info.iet.unipi.it/˜luigi/cost237.ps.gz, Accessed July 2003. [144] J. Rosenberg and H. Schulzrinne. An RTP Payload Format for Generic Forward Error Correction, December 1999. RFC 2733. [145] J. Rosenberg and H. Schulzrinne. An Offer/Answer Model with Session Description Protocol (SDP), June 2002. RFC 3264. [146] J. Rosenberg and H. Schulzrinne. Reliability of Provisional Responses in Session Initiation Protocol (SIP), June 2002. RFC 3262. [147] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol, June 2002. RFC 3261. [148] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy. STUN Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), March 2003. RFC 3489. [149] Jonathan Rosenberg, Lili Qiu, and Henning Schulzrinne. Integrating Packet FEC into Adaptive Voice Playout Buffer Algorithms on the Internet. In 19th Annual Joint Conference of the IEEE Computer and Communication Societies (INFOCOM 2000), volume 3, pages 1705–1714, March 2000. Tel Aviv, Israel. [150] J. Salowey, H. Zhou, P. Eronen, and H. Tschofenig. IETF draft . Work in progress, February 2005. [151] Henning Sanneck. Packet Loss Recovery and Control for Voice Transmission over the Internet. PhD thesis, GMD Fokus, Berlin, Germany, October 2000. [152] H. Schulzrinne. Voice communication across the internet: A network voice terminal. Technical Report TR-92-50, Dept. of Computer Science, University of Massachusetts, Amherst, Massachussets, July 1992.

[153] H. Schulzrinne and S. Casner. RTP Profile for Audio and Video Conferences with Minimal Control, July 2003. RFC 3551. [154] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport Protocol for Real-Time Applications, July 2003. RFC 3550. [155] Henning Schulzrinne and Elin Wedlund. Application Layer Mobility Using SIP. ACM SIGMOBILE Mobile Computing and Communications Review, 4(3):47–57, 2000. [156] Sangho Shin, Anshuman Singh Rawat, and Henning Schulzrinne. Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs. In ACM MobiWac’04, oct 2004. Philadelphia, Pennsylvania, USA. [157] W. Simpson and Ed. The Point-to-Point Protocol (PPP), July 1994. RFC 1661. [158] K. Sklower, B. Lloyd, G. McGregor, D. Carr, and T. Coradetti. The PPP Multilink Protocol (MP), August 1996. RFC 1990. [159] K. Sklower and G. Meyer. The PPP DES Encryption Protocol, Version 2 (DESE-bis), September 1998. RFC 2419. [160] Hesham Soliman, Claude Catelluccia, Karim El Malki, and Ludovic Bellier. Hierarchical Mobile IPv6 mobility management (HMIPv6). IETF draft , December 2004. [161] R. Stevens. Unix Network Programming, volume 1. Prentice Hall, 2 edition, 1998. [162] Stockholmopen.net home page. http://www.stockholmopen.net. [163] L.F. Sun, G. Wade, B. M. Lines, and C. Ifeachor. Impact of Packet Loss Location on Perceived Speech Quality. In 2nd IP-Telephony Workshop, pages 114–122, April 2001. New York, USA. [164] M. Thomas. Requirements for Kerberized Internet Negotiation of Keys, June 2001. RFC 3129. [165] S. Thomson and T. Narten. December 1998. RFC 2462.

IPv6 Stateless Address Autoconfiguration,

[166] Susan Thomson and Thomas Narten. Internet RFC 2462, IPv6 Stateless Address Autoconfiguration, December 1998. [167] P. Thubert, R. Wakikawa, and V. Devarapalli. Global HA to HA protocol. IETF draft , Work in progress, October 2004. [168] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, and B. Palter. Layer Two Tunneling Protocol ”L2TP”, August 1999. RFC 2661. [169] A. J. Tuominen and H. Petander. MIPL Mobile IPv6 for Linux in HUT campus network MediaPoli. In Ottawa Linux Symposium 2001, June 2001. Ottawa, Canada.

[170] F. Vakil, A. Dutta, J-C Chen, S. Baba, N Nakajima, Y. Shobatake, and H. Schulzrinne. IETF draft Work in progress, December 2000. [171] A. Valko, A. Campbell, and J. Gomez. Cellular IP. IETF draft , Work in progress, May 1999. [172] Jon-Olov Vatn. Long Random Wait Times for Getting a Care-of Address are a Danger to Mobile Multimedia. In 1999 IEEE International Workshop on Mobile Multimedia Communications (MoMuC’99), November 1999. San Diego, CA, USA. [173] Jon-Olov Vatn. End-to-end and redirection delays in IP based mobility. In IFIP Conference on Personal Wireless Communication (PWC’2000), September 2000. Gdansk, Poland. [174] Jon-Olov Vatn. End-to-end and redirection delays in ip based mobility. Technical Report TRITA-IT R 00:01, ISSN-1103-534X, ISRN KTH/IT/R– 00/01–SE, Telecommunication Systems Laboratory, Department of Teleinformatics), Royal Institute of Technology (KTH) Stockholm, Sweden, 2000. [175] Jon-Olov Vatn. A roaming architecture for IP based mobile telephony in WLAN environments. In Mobility Roundtable 2003, May 2003. Stockholm, http://www.hhs.se/cic/roundtable2003/papers/S13Vatn.pdf. Accessed May 2003. [176] Jon-Olov Vatn. An experimental study of IEEE 802.11b handover performance and its effect on voice traffic. Technical Report TRITA-IMITTSLAB R 03:01, Telecommunication Systems Laboratory, Department of Microelectronics and Information Technology (IMIT), Royal Institute of Technology (KTH) Stockholm, Sweden, July 2003. Available at http://www.imit.kth.se/˜vatn/research/handover-perf.pdf. [177] Jon-Olov Vatn and Gerald Q. Maguire Jr. The effect of using co-located care-of addresses on macro handover latency. In 14th Nordic Teletraffic Seminar, August 1998. Lyngby, Denmark, http://www.it.kth.se/˜vatn/research/nts-coloc.pdf. [178] H´ector Velayos and Gunnar Karlsson. Techniques to Reduce IEEE 802.11b MAC Layer Handover Time. Technical Report TRITA-IMIT-LCN R 03:02, ISSN 1651-7717, ISRN KTH/IMIT/LCN/R-03/02–SE, KTH, Stockholm, Sweden, April 2003. [179] Jesse Walker. Developer Services - 802.11 Security Series. Part I: The Wired Equivalent Privacy (WEP). Available at http://cedar.intel.com/media/pdf/security/wired.pdf. Accessed January 2003. [180] Jesse Walker. Unsafe at any key size; An analysis of the WEP encapsulation, October 2000. http://www.drizzle.com/˜aboba/IEEE/0362.zip, Accessed March 2002.

[181] Elin Wedlund and Henning Schulzrinne. Mobility Support using SIP. In 2nd ACM/IEEE International Conference on Wireless and Mobile Multimedia (WoWMoM), August 1999. Seattle, Washington. [182] K. Daniel Wong, Ashutosh Dutta, Jim Burns, Ravi Jain, Kenneth Young, and Henning Schulzrinne. A Multilayered Mobility Management Scheme for Auto-Configured Wireless IP Networks. IEEE Wireless Communications, October 2003. [183] Wi-Fi Protected Access Media Briefing. NIST 802.11 Wireless LAN Security Workshop. http://csrc.nist.gov/wireless/. [184] Maya Yajnik, Sue Moon, Jim Kurose, and Don Towsley. Measurement and Modelling of the Temporal Dependence in Packet Loss. In 18th Annual Joint Conference of the IEEE Computer and Communication Societies (INFOCOM 1999), volume 1, pages 345–352, mar 1999. New York. [185] L. Yang, P. Zerfos, and E. Sadot. Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP). IETF draft , November 2004. Work in progress.

TRITA-IMIT-TSLAB AVH 05:01 ISSN 1651-4114 ISRN KTH/IMIT/TSLAB/AVH-05/01--SE

[PDF] IP telephony: mobility and security JON-OLOV VATN - Free Download PDF (2025)

References