Securing Voice Traffic Over Wireless Packet Networks
Ross Rehart Network Engineer & Operations Manager February 20, 2006
10717 Sorrento Valley Road SanDiego, CA 92121 858.450.1180 www.networkinsight.com
TABLE OF CONTENTS
Executive Summary........................................................................................................................................1 The Case for Securing Voice over Wireless Packet Network ........................................................................2 IP and Network Security .................................................................................................................................3 Telephony and Voice over IP (VoIP) ..............................................................................................................3 Voice Quality ...............................................................................................................................................4 Delay, Packet Loss and Jitter .....................................................................................................................4 Voice Coders (codecs)................................................................................................................................5 QoS Support for VoIP over Wireless ..........................................................................................................5 Call Admission Control................................................................................................................................6 Wireless Networks ..........................................................................................................................................7 Security and Wireless Networks..............................................................................................................7 Secure Voice over Wireless Packet Network .................................................................................................8 Sample Voice over Wireless Packet Network Implementations...................................................................10 Internal office WiFi connection..................................................................................................................10 Remote user to office connection .............................................................................................................11 Conclusion ....................................................................................................................................................11 Glossary........................................................................................................................................................12 References ...................................................................................................................................................14
Executive Summary
With new technology making working remotely an option for many employees, corporations are driven to find cost-effective, technological solutions that provide constant connectivity. Wireless networks have become increasingly popular as they meet the needs of both employees and corporations. While the implementations of wireless networks have rapidly accelerated in recent years, so too have the security risks associated with these networks. When working remotely, it is imperative that employees have access to electronically stored data, voice communications and be able to exchange information electronically (e-mail). Advances in Wireless technology and Voice over Internet Protocol (VoIP) can be used to facilitate communication and meet the needs of employees and corporations alike. While both solutions promise low return on investment (ROI), easy access to data and voice, and higher employee productivity, organizations must consider the associated security risks. Internal and external security breaches may cause severe degradation of service and/or catastrophic failure of the systems or network. Hackers and ill-intentioned organizations have been around much longer than “the Internet” and their methods of causing havoc or stealing data have advanced as quickly as technology has allowed. The convergence of networking, wireless technology, and voice is inevitable. These vital services will be provided to both corporations and end-users via a single connection. Businesses will find themselves challenged with securing this connection and the data that travels over it. This paper will explore the challenges associated with securing telephony over wireless packet networks, the issues that distinguish it from other traditional voice or VoIP applications, the factors that lead to the risk and steps that should be taken to secure voice and network traffic while providing for the needs and demands of the corporate users.
1
The Case for Securing Voice over Wireless Packet Network
Wireless access points are being installed and made available everywhere from coffee shops, airports, financial institutions, and retail establishments, to the home and office. With this proliferation of wireless networks, the security risks to the network increase exponentially. With the advent of 802.11 (WiFi), 802.16 (WiMAX), and the upcoming 802.11n and 802.20 standards, VoIP over wireless networks is the next step in the evolution of the wireless world. Companies such as Cisco Systems and Avaya are already developing telephony strategies and devices that take advantage of existing and upcoming wireless technologies, and are working to enable wireless access points for QoS and VoIP applications via Internet Operating System (IOS) code upgrades. This fast moving technological growth demands that requirements keep up, and fit into, what is here now, and what is coming down the road. Standards such as 802.16, 802.11i (which WPA2 will be fully compliant with), and the upcoming 802.11n (with theoretical throughput maximums up to 540 Mbps) are all being developed to meet both the demands of the wireless world and the security concerns that go with them. Keeping pace with the demand for wireless connectivity is the demand for Voice over IP (VoIP). Voice over IP has moved from the lab to the mainstream, and is quickly becoming the main communications infrastructure of large corporations both domestically and internationally. The fact that Voice over IP can now be implemented with ‘cookie cutter’ solutions, thereby lowering implementation costs, is making it even more attractive to businesses. With the rise of the Internet and the maturity of VoIP standards, Voice over packet networks is quickly becoming as ubiquitous as traditional telephony. However, many organizations remain leery of VoIP, mainly because of security concerns. Each of the prevalent VoIP protocols (SIP, H.323, MGCP, and RTP) contains inherent security vulnerabilities and the security standards for each are still being developed. In fact, the IEEE recently put out a call for comment on VoIP security and intends on publishing the findings by mid-year, 2006. The introduction of VoIP in the wireless network raises many additional security concerns. Combining the complexities of securing a wired network with that of securing a wireless implementation, then placing the need for secure voice over the entire architecture is a daunting task. Existing vulnerabilities are compounded through the combination of differing protocols, applications, and hardware types. Businesses recognize the security issues that both wired and wireless networks pose to their organizations, and are becoming aware of the security concerns surrounding VoIP. These concerns have come into the forefront of business and organizations, such as the IEEE, have been concentrating their efforts on implementing standards to address them. Nevertheless, wired, wireless, and VoIP networks are still far from being secure. As fast as wireless technology has grabbed a foothold in corporations around the world, so to will the desire to provide wireless voice services. Ultimately, network administrators and CIOs will be driven to implement wireless VoIP based on the potential cost savings it promises as well as by user demand. This will likely expose organizations to previously unforeseen security vulnerabilities that, in turn, may cause the dissemination of confidential information. For example, it is relatively simple to hack into an improperly secured wireless access point and cause a DoS or other type of malicious attack, as will be shown below. Adding VoIP on top of these wireless connections only exposes voice traffic to would-be hackers. Unlike credit card fraud or identity theft (both of which are prevalent on the Internet today) people do not consider the chance that their calls will be ’hacked’, or the potential consequences to the corporation if confidential information is exposed. After all, with traditional telephony, a hacker would have to access a circuit physically in order to ‘tap’ the call. Now he or she need only be in the parking lot with the right software and a wireless network card.
2
IP and Network Security
The need for Internet Protocol and network security was first identified in RFC 1108 (U.S. Department of Defense: Security Options for the Internet Protocol), in 1991 and later ratified in RFC 1825 (1995) and RFC 2401 (1998). Frankly, hackers have been around longer than the modern Internet, and the threat of the network being compromised is very real. To address these ongoing threats, the IPSec (Internet Protocol Security) architecture was developed and published by the IEEE alliance. The IPSec protocol is designed to apply interoperable, high-quality, cryptographic encoding of packets at the IP layer of IPv4 and IPv6 data networks. As described in RFC2401, IPSec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. It does so by using its components in any number of combinations, as described below. While the IPSec RFC does not specify any single algorithm to be used to provide the security association, typical algorithms used in conjunction with IPSec are AES, DES, 3DES, HMAC-MD5, and SHA. The IPSec architecture contains the following components: • • • • Security Protocols - Authentication Header (AH) and Encapsulating Security Payload (ESP) Security Association (SA) – This is a secure connection between two endpoints that applies a security policy and keys to protect information. SAs are applied separately for IKE and IPSec. Key Management - The administration and use of the generation, registration, certification, deregistration, distribution, installation, storage, archiving, revocation, derivation and destruction of key certificates when used for Internet Key Exchange (IKE) Algorithms for station/stream authentication and encryption
Authentication Header (AH) and Encapsulating Security Payload (ESP) are vehicles for access control and can be applied individually or in combination with either IPv4 or IPv6 to provide the desired level of security. Key management (IKE) is introduced (either by automatic or manual key generation) for the main purpose of providing a security association (SA) between the endpoints. Security services are provided to the SA via either the AH or ESP (not both), on a per stream basis. Since SAs are simplex (unidirectional), two streams are required to provide bidirectional communication between endpoints. Security Associations (SAs) can either be classified as transport (between two hosts), or tunnel (between tunnel endpoints). Together, these components provide the means to secure traffic at the IP layer (Layer-3)of the OSI model. Typically, the use of IPSec introduces little if any delay into a network connection. SAs typically take five round-trips to establish a connection and two round-trips for re-key. The ESP and AH protocols typically add 50 bytes to the data stream. However, in low-capacity links, such as radio transmissions used in military applications, the additional overhead of IPSec may cause unacceptable link congestion, or link failure. In these circumstances, where bandwidth is at a premium, an encryption algorithm such as AES should be considered, as it tends to be less bandwidth intensive than others (such as DES) are.
Telephony and Voice over IP (VoIP)
For over a century, businesses and the private sector alike have come to depend on the telephone as a means of fast, effective, and reliable method of communication. Telephones have become so ubiquitous, that individuals and businesses take for granted that a phone will be available to them whenever and where ever it is needed. The evolution of the phone has taken it from a rudimentary mechanical device to DTMF, Cellular, Digital Voice, and now VoIP. In the mid 1990’s researchers began working on the possibility of utilizing existing IP infrastructures to carry voice traffic. By 1998, small companies such as Dynamic Soft, Selsius, and Vocaltec began the process of bringing VoIP to the consumer, and larger companies like Cisco Systems, Avaya, and others
3
started to enter the market as well. By early 2000, it became evident that VoIP was here to stay, with many early adopters working with vendors to make the solution work. Nevertheless, Voice over IP is still not without its problems. As with any technology in its infancy, VoIP vendors are still in the process of working out the bugs and developing industry wide standards to ensure uniformity and compatibility between systems. Below, we discuss a few of the issues surrounding VoIP, how they influence the network, and what is being done to better the standard.
VOICE QUALITY
Typical telephone users have come to expect a certain level of reliability and voice quality from their telephones. The expectation is that one should be able to pick up the phone, dial another party, and be able to speak and hear the person on the other end as if they were standing in the same room. End users are used to, and have come to expect, the “quality” and comfort level that comes with traditional phone systems. The challenge that comes with VoIP is to be able to replicate the same quality, while sharing the network with the day-to-day data that it was built to accommodate. Through the infancy of VoIP, vendors have worked tirelessly to get their products to match the quality and expectations of traditional circuit switched telephony. While great strides have been made in this area with better hardware, chipsets, and overall architectural improvements, providing the end-user expected quality remains an on-going struggle. Factors such as end-to-end distance, hardware, inherent latency (delay), and bandwidth constraints all play into the degradation of voice quality over the network. Within the scope of this paper, factors such as encryption algorithms, Radio Frequency Interference (RFI), and design limitations of wireless infrastructure will also be shown to play into the degradation of quality as well. The simple fact is businesses have come to expect reliability from their phone systems. Nothing less than 100% uptime and good quality is acceptable.
DELAY, PACKET LOSS AND JITTER
Ultimately, three key performance measures must be taken into consideration when designing, implementing, and managing a VoIP network – wired or wireless – as each can act to degrade voice quality. Delay (latency), packet loss, and jitter are inherent to IP packet transfer over both wired and wireless networks. Factors such as those discussed in the section above can each play a part in adding delay, packet loss, and jitter into the network. However, each can be mitigated to minimize the effect on traffic. By adding bandwidth, processing power, layer 2 divisors such as VLANs, and/or QoS protocols, into the network, these factors can be reduced. Further, when applying security and protective measures (such as placing access points in a DMZ) to wireless networks, administrators need to be sensitive to the amount of potential overhead they are adding to the network and balance that with the need for security. In the case of a VoIP network, any latency greater than 150 to 200 msec, 1 – 3% packet loss, and/or jitter greater than 20 - 40 msec will affect voice and audio quality to a degree that is noticeable to the user. Therefore, when adding any packet manipulation into the network (discussed below), end-to-end overhead must be taken into consideration. As stated above, there are limiting factors in a VoIP implementation that, in many cases, cannot be controlled (such as manufacturer’s chipsets). Nevertheless, voice quality over wired or wireless networks can be controlled to some degree. Mechanisms such as Call Admission Control (CAC), Quality of Service (QoS), and Voice Coder (codec) types can each be used on its own, or in conjunction with one another to provide a reasonable facsimile of circuit-switched telephony. Although exhaustive explanations of these mechanisms are beyond the scope of this document, a brief explanation of each is necessary so the reader may understand the factors that must be considered when designing a VoIP over wireless implementation.
4
VOICE CODERS (CODECS)
With bandwidth at a premium, companies must consider how VoIP traffic will affect normal data traversing the network. To deal with this, the ITU-T has developed several voice coders (or codecs) designed to compress the normal voice stream, which is typically 64 Kbps in traditional circuit switched telephone networks. In VoIP networks, G.729 and G.723.1 are the preferred methods of compression. Each allows maximum use of bandwidth while minimizing the effects of compression on the call. Regardless, while G.729 and G.723.1 both provide a high compression rate over the traditional G.711. This compression comes with the costs of longer delay due to the processing power needed to compress the audio stream, and the potential for lower voice quality due to the coding and decoding techniques used. In the case of wireless networks today, compression algorithms are not added to the call until well after the access point. This is due to the current chipsets on wireless devices not yet being able process the algorithms, as is required by the IEEE.
QOS SUPPORT FOR VOIP OVER WIRELESS
Typically, wired and wireless networks work on a “best-effort” basis. Specifically, packets are passed through the network on a first-in, first-out (FIFO) basis to their intended destination. Whether the packet gets to its destination, or not, or if it is trumped by another set of data is irrelevant to the forwarding device. However, the introduction of such QoS centric protocols as RSVP, DiffServ, and MPLS, into mainstream networking have greatly increased the control that can be given to packet prioritization. The goal of QoS is to guarantee bandwidth for voice streams, minimize packet loss, and place an upper boundary on packet jitter. Packets traversing the network can now be prioritized so time or integrity sensitive applications such as voice and video can be put to the head of the line without the concern of being affected by other packets. In wired networks, this works almost seamlessly. In wireless networks, however, applying QoS is somewhat more complex, given the differing variables discussed below. Wireless networks cannot allocate dedicated bandwidth to a given link, and therefore must take traffic direction (upstream/downstream) into consideration when applying QoS. In the case of VoIP over wireless, the wireless network device has no way of knowing whether a VoIP (telephone) or end-user (PC) device is transmitting packets upstream, and therefore cannot apply QoS in the upstream direction (see figure 1 below). Rather, QoS can only be applied once the packets have traversed a QoS (VoIP) aware router, gatekeeper, or other such device.
Figure 1: QoS Application Currently, the IEEE is working on the 802.11e standard that will address QoS in wireless applications, allowing the sending device to designate its packet type to the AP. The upcoming Wireless Media Extensions (WME) protocol for QoS will include parts of the forthcoming 802.11e standard that deal with
5
traffic prioritization from the client. However, advanced features of the 802.11e standard such as bandwidth provisioning by the AP (deemed WiFi Scheduled Media (WSM) by the IEEE alliance), are still a year or two off. Some basic differences between applying QoS on wireless vs. wired networks are: • • • • • Wireless network devices do not classify packets; they prioritize packets based on Differentiated Services Code Point (DSCP) value, client type (such as a wireless phone), or the priority value in the 802.1q or 802.1p tag. Wireless network devices do not construct internal DSCP values; they only support mapping by assigning IP DSCP, Precedence, or Protocol values to Layer-2 CoS values. Wireless network devices carry out Enhanced Distributed Control Function (EDCF) like queuing on the radio egress port only. Wireless network devices do only FIFO queuing on the Ethernet egress port. Wireless network devices support only 802.1Q/P tagged packets.
CALL ADMISSION CONTROL
Call Admission Control (CAC) is a very close cousin to QoS, and is actually considered a QoS mechanism by some. However, QoS mechanisms such as queuing, policing, and traffic shaping differ from CAC in three ways: • • • They are designed to protect/segment voice traffic from data traffic contending for the same resources. They are designed to deal with traffic already present on the network. Queuing mechanisms have no way of distinguishing which IP packet belongs to which voice call.
However, like QoS, CAC can be used to help limit the affect delay, packet loss, network congestion, and other limiting factors of the network have on call quality. It does so by means of limiting the number of calls allowed on a given link based on pre-configured limiters and/or decisions that are based on the state of the node or network. CAC mechanisms include the following: • • Local CAC – Functions on the outgoing gateway, and makes admission decision based on the state of the outgoing LAN or WAN link, or pre-configured limiters such as the Administrator configuring the gateway to disallow more than ‘n’ calls on a given link. Measurement based CAC – Looks ahead to gauge the state of the network by sending probes to the far-end gateway that returns information such as loss and delay characteristics. The measurement based CAC then uses this information to determine whether a call should be allowed onto the network. This method adds overhead to the network and may result in delaying the start of a call. Resource based CAC – This can either (a) calculate the resources needed and/or available for a call, or (b) reserve (via RSVP) resources for the call, based on the state of the network. As with measurement based CAC, this adds overhead to the network by the use of probes, and may result in delaying the start of a call. Further, to be fully topology aware, this must be configured on every interface along the path the call will take. Security/User based CAC – This asks the question, “Is this a legitimate device/user on the network?” Protocols such as H.235 and methods such as Personal Identification Number (PIN) or Calling Line Identification (CLID), typically done via authentication server (RADIUS, TACACS+, etc...), can be used to verify authorization. This method should be strongly considered when implementing a VoIP over wireless implementation.
•
•
Although each of the above methods can be used to help voice quality, in the case of VoIP over wireless, Local CAC and Security/User based CAC should be the two primary considerations due to there inherently low overhead. In any scenario, to implement CAC into a VoIP network successfully, administrators should have a clear understanding of exactly how much bandwidth is required per call.
6
Wireless Networks
Wireless networks are nearly omnipresent in the modern world today. New wireless standards are constantly being developed and revised. New hardware and technologies are being developed and sent to market at such a high rate that trying to keep up has become an exercise in futility. This makes it is easy to see the demand for wireless connectivity is growing exponentially, with no end in sight. To cope with the demand, the IEEE alliance has developed many standards that allow multiple manufacturers’ devices to communicate with one-another with little or no configuration needed. The 802.11(x) set of standards cover everything relating to Wireless Fidelity (or WiFi) networks. Each revision of the standard (802.11a, b, e, g, i, etc…) deals with a given specification for the standard. For instance, 802.11a specifies standards for WiFi in the 5 GHz (SHF) band, while 802.11i specifies standards for securing WiFi access. The 802.16(x) set of standards covers the Worldwide Interoperability for Microwave Access (WiMAX). As with 802.11, 802.16 also contain revisions such as 802.16a, which adds support for the 2 – 11 GHz range (UHF – SHF) of frequencies to interoperate with the native 802.16 10 – 66 GHz (SHF – EHF) frequencies. When seeing the promises and advantages inherent to WiFi and WiMAX, why would a company not want to invest in the technology? The number one reason is security, or lack thereof. Wireless networks are not secure. Although the wireless security has come a long way from what it was just two years ago, standards are still being developed to deal with the problem. Part of the problem is that the IEEE requires that encryption be hardware based in order to minimize the impact on data transfer rates. This makes implementing new standards an expensive and time-intensive process, requiring the development of new chipsets each time new standards are adopted. Cisco, LinkSys (now owned by Cisco), Foundry, Intel, and others have all dedicated significant research and development dollars into further advancing the standards. Considering the ever increasing investment in the technology, and market demand, we can, with near certainty predict that other technologies such as VoIP will be forced to work on wireless technology in the not so distant future.
Security and Wireless Networks
Is the IPSec suite of applications the answer to securing wireless networks? No. IPSec is not without its limitations, and in a wireless implementation, these limitations are easily exploited. How are the limitations exacerbated on wireless networks? First, IPSec has no means of authenticating individual users, or knowing what/who is connected. IPSec only authenticates machines. Since IPSec works at Layer-3, it can only serve to secure the actual connection between the host and endpoint. This can easily be exploited by the use of rudimentary wireless hacking tools available on the Internet. For example, by using these tools, a would-be hacker can create DoS attacks that originate from a host workstation that IPSec is powerless to stop. This tainted data is then passed though the secure connection, as would be any other data to the core network, effectively originating the attack from within the network. However, this factor can be limited by use of Security/user based CAC mechanism as discussed above. Simply put, if the end-user system is not secure, implementing IPSec only creates a secure tunnel through which compromised data may pass. In order for IPSec over wireless networks to be truly useful, it must be used in conjunction with other methods of security. These might include: • End user machines, and/or IP telephony equipment must be required to have all of the latest firmware and software patches applied. Most IP telephones are nothing more than ‘dumb’ hardware utilizing XML code to provide functionality, and therefore should be checked for vulnerabilities and available patches, as would any other application. Patch management is
7
especially important with SoftPhone users (or users who transmit voice via software loaded on their workstation). A possible solution to this is automated patch management via software such as Microsoft’s Operation Manager or Cisco’s “Clean Access” solution. • Wireless network connections (access points) should be routed through a DMZ prior to allowing traffic into the network. No direct connection to the internal network should exist. However, while this strategy is prudent, in the case of connecting VoIP devices wirelessly, such architecture would require a VoIP aware firewall in order to provide proper port availability to VoIP devices and software. Further, the routing of traffic via a DMZ through a firewall or VPN gateway will likely add latency into the traffic flow. All devices connecting via wireless connections should be required to connect with two-fold security measures of IPSec and user authentication via an authentication server. This requirement will likely add little overhead to the overall latency of the data stream while providing greater robustness to your security solution. Wireless access points should be configured so that they never broadcast SSIDs, and require strong authentication requirements such as WiFi Protected Access (WPA) with Temporal Key Integrity Protocol (TKIP). WPA is a partial implementation of 802.11i (using RC4 encryption), with WPA2 (using AES), forthcoming, being fully compliant. Weak security protocols such as WEP should never be used.
•
•
Secure Voice over Wireless Packet Network
Considering all of the factors of time sensitive applications such as voice, and the inherent nature of wireless networks, one might ask, “How can they possibly be made to work together?” The simple answer is there is no simple answer. Designing, implementing, managing, and securing a wireless network, or a wireless voice network against ill-intentioned persons or organizations, are each complex tasks onto themselves. Combined, the complexity of implementation is compounded. Regardless, there are solid methodologies and tools in place that can help businesses get where they are going securely and effectively. In order to plan, execute, and manage a secure wireless VoIP solution, businesses must take a methodical approach to the project. Understanding the needs, alternatives, costvs.-benefit, pros and cons of each possible solution, gaining executive buy-in, and developing policy around the planned network are each a critical step in attaining the goal of a secure, robust wireless VoIP solution. Typically, companies will contract with outside vendors who have expertise in one or more of the needed areas to assist with implementation of a solution. Below, we detail some of the steps and possible architecture of such a network. Cost vs. benefit This is always the number one step in gaining management buy in of a new solution. If the ROI is not compelling, management will be less likely to commit resources and dollars to a solution. A few questions that need to be considered include: 1. Is there a need for wireless VoIP, and what are the benefits? 2. What are the security risks involved with a wireless and wireless VoIP implementations? 3. What are the risks, from an operational cost standpoint, of not implementing a wireless VoIP solution? 4. What technology is currently being used by local and remote users for voice services? a. Is that technology still within its useful lifespan? 5. What are the alternatives to wireless VoIP? 6. What network equipment may need to be upgraded or replaced in order to make a wireless VoIP solution feasible?
8
Usage Policy Inevitably, the question will be asked, “Can/should this solution be deployed company wide?” A good usage policy can answer that question before it is ever asked. Usage policies should be comprehensive enough to cover the majority of usage scenarios, but flexible enough to allow for future/unforeseen events and growth. Some of the items that should go into an effective usage policy include: 1. Who are the target users of the wireless VoIP solution? 2. What are the minimum software requirements (OS version, patch level, anti-virus, etc..) for a user of the system? 3. When/how, can a user connect to the system? 4. How will the users be required to secure their connections? 5. How are users added and/or removed from the system? 6. How often are the users of the solution audited for policy compliance, and what is the overhead associated with auditing them? Design Requirements Once the questions above, among others, have been satisfactorily answered, and management buy-in has been gained, a design based on the above should be drafted. Design considerations should include, but not be limited to: 1. What new equipment is to be used and what equipment to be reused from the existing network? 2. How will the wireless and wireless VoIP networks be joined (at layers 2, 3, and 4) to the wired network? 3. How users will connect to access points? 4. What security measures are to be applied (physical, biometric, and electronic) to wirelessly connected users, devices, and telephony equipment? 5. What security algorithms are to be used? 6. How much bandwidth is to be made available to wireless, VoIP, and wired network traffic? 7. What is the projected latency between the end user device, the telephony control device(s), and the edge network? 8. What codec will be used (G.711, G.729)? 9. What VoIP protocol (SIP, H.323, etc…) is to be used? 10. How and where will QoS and/or CAC be applied to IP packets? 11. Will end-to-end QoS be implemented?
9
Sample Voice over Wireless Packet Network Implementations
Below are two possible wireless VoIP implementations that meet the above requirements. These are only two of many possibilities, and many internal and external factors may play a part in what an organization may ultimately implement. The two implementations below place maximum emphasis on securing the VoIP and wireless traffic.
INTERNAL OFFICE WIFI CONNECTION
Figure 1: Internal office design
10
REMOTE USER TO OFFICE CONNECTION
Figure 2: Remote office design
Conclusion
At an almost inconceivable pace, wireless technology is advancing, bringing with it new possibilities and threats to businesses. Business must be prepared for these challenges, many of which will only be brought to light once wireless solutions are implemented. Security threats to an organization’s network are real. When considering the need to implement cost effective, robust, and secure wireless, and/or wireless VoIP solutions, these threats must also be considered. Each aspect must be planned for when considering implementation of such solutions. Many facets of VoIP over wireless have been discussed (VoIP coders, IPSec, QoS, WiFi, WiMAX, delay, packet loss and jitter), and each one must be taken into consideration when designing an effective, secure wireless VoIP solution. Further future advances in technology should also be considered, so as not to lock a company into a solution that may be ineffective or obsolete before its useful life and or full ROI has been realized. Ultimately, ROI, ease of use, strong security, and ease of management of any potential solution should each be carefully considered before any solution is implemented.
11
Glossary
G.711: G.711 encodes non-compressed speech streams running at 64 Kbps. G.711 encoded voice is the format for digital voice delivery in the public phone network or through private branch exchanges (PBXs). G.726: G.726 describes ADPCM coding at 40, 32, 24 and 16kbps – ADPCM voice may also be interchanged between packet voice and public phone or PBX networks which have ADPCM capability. G.728: G.728 describes a 16-kbps low-delay variation of CELP voice compression – CELP voice coding must be transcoded to a public telephony format for delivery to or through public telephone or PBX networks. G.729: G.729 describes CELP compression that enables voice to be coded into 8-kbps streams – Two variations of this standard (G.729 and G729 Annex A) differ largely in computational complexity, and both generally provide speech quality as good as that of 32-kbps ADPCM. Today, this is the preferred compression algorithm over IP networks. G.723.1: G.723.1 describes a compression technique that can be used for compressing speech or other audio signal components of multimedia service at a very low bit rate, as part of the overall H.324 family of standards. Bit rates associated with this coder are; 5.3 and 6.3 kbps; the higher bit rate is based on MPMLQ technology and has greater quality; the lower bit rate is based on CELP. WiFi: WiFi (or Wireless Fidelity) is defined by IEEE 802.11 set of standards. Devices complying with these standards operate in either the 2.4 GHz (802.11b, 802.11g) or the 5 GHz frequency range. Each has its advantages and disadvantages, but 802.11g seems to be becoming the de facto standard, with its signal robustness, fairly good range (500 – 1000 feet), relatively low cost, and high data speeds (up to 54 Mbps). WiMAX: WiMAX (or Worldwide Interoperability for Microwave Access) is defined by the IEEE 802.16 set of standards, approved in June 2004. Devices complying with these standards operate in a range of 10 – 66 GHz with the 802.16a standard adding support for the 2 – 11GHz range. With a non-line of site range of up to 15 miles without significant loss, encryption/security standards much greater than that of WiFi, and increased bandwidth, WiMAX is expected to take over as the de facto “last mile” connector for Internet to the home and Internet to the business. Further, because WiMAX uses the same Logical Link Controllers (LLC as defined by IEEE 802.2), it can be directly connected and routed to existing WANs and LANs. Delay (or Latency): The amount of time (in msec) it takes one packet to get from point A to point B in a network. This is typically measured in round trip time (RTT). In a typical LAN/WAN, a routing device typically accounts for a 10 msec delay. Physical link layer (layer-1) factors, as well as distance to the next point (or hop) also factor into the delay. Further, encryption algorithms and coder compression techniques, will introduce latency into a network. In wireless networks, delay can also be added by decrementing the strength of signal from the sender to the access point or vice-versa (often referred to as signal loss). This signal loss can be mitigated by many factors including environmental (a physical structure), weather, power to/from the transmitting station, and in-band interference, among others. Packet Loss: is typically caused by high network volume and/or buffer overflow. In wireless networks, this is challenging to mitigate. Wireless access points in a typical corporate environment are constantly being bombarded by requests to connect or pass traffic. Each request must be taken in and dealt with individually. Therefore, typically deployed wireless access points become extremely vulnerable to DoS attacks. Jitter: is the difference in latency from point A to point B and point B to point A within a network. For instance, if voice traffic is received by point B in 10 msec and the return traffic takes 18 msec to get to point A, the jitter is 8 msec. VoIP applications are extremely jitter sensitive, and typically VoIP devices contain “jitter buffers” to mitigate the effect of jitter on a the overall sound quality. In wireless networks,
12
jitter can be caused by many factors including electromagnetic interference (EMI) signal cross-talk, and environmental factors. AES: Advanced Encryption Standard - Provides strong encryption in various environments: standard software platforms, limited space environments, and hardware implementations using the Rijndael algorithm. DES/3DES: Data Encryption Standard - Applies a 56-bit key to each 64-bit block of data. It provides encryption based on symmetric cryptography, ie both the sender and receiver must know the same secret key. This key is used for both encryption and decryption. DES is sometimes used with 3 keys, in which case it is known as "triple DES" or 3DES. HMAC: Hash Method Authentication Code - HMAC is not a hash function but rather a cryptographically strong way to use a specific hash function such as SHA or MD5 for MAC calculation. MD5: Message Digest Algorithm (v5) - A type of message algorithm that converts a message of arbitrary length into a 128-bit message digest. This algorithm is used for digital signature applications where a large message must be compressed in a secure manner. SHA: Secure Hash Algorithm - A one-way hash function that creates a 20-byte (160-bit) hash or message digest to authenticate packet data. SHA is more resistant to attacks than MD5, but slower to compute. AH: Authentication Header - An IPSec protocol that provides data integrity, data origin authentication, and optional anti-replay services to IP. AH does not encrypt any portion of the protected IP datagram, nor does AH provide confidentiality. ESP: Encapsulating Security Payload - An IPSec protocol that provides data confidentiality (encryption), anti-replay, and authentication. ESP encapsulates data in the IP packet and may be applied alone or in combination with AH. IKE: Internet Key Encryption - Authenticates each peer in an IPSec transaction, negotiates security policy, and handles the exchange of session keys. XML: Extensible Markup Language - A simple, flexible text format derived from SGML (ISO 8879) RFI: Radio Frequency Interference - This interference in the operation of a device is caused by incompatibility with ambient RF signals.
13
References
Cisco Systems. “Configuring QoS for Wireless LANs.” Cisco Systems. 2005. 04 August 2005. Cisco Systems. “VoIP Call Admission Control.” Cisco Systems. 2004. 10 August 2005. Institute of Electrical & Electronic Engineers. Various RFCs cited. IEEE Wireless Standards Zone. 2005. 12 August 2005. Marjalaakso, Mika. “Security Constraints of Voice Over IP.” Helsinki University of Technology. 2003. 08 August 2005. Mitchiner, Mark (CCIE #3958). Personal Interview. 12 August 2005. Sasaki, Kazuo, et al. “A Wireless IP Phone System for Rural Applications.” International Telecommunications Union. 2005. 10 August 2005.
14