340 Chapter 8
www.newnespress.com
parties, although everyone must support 32 and 64 is recommended. The idea of the
window is that the receiver keeps the highest sequence number that it has seen from a
packet that has been successfully authenticated. (Forgeries may try to push the window
around, and so must be ignored for setting the window.) Any packet received with a
sequence number older than the current receive one, minus the window size, is dropped
right away. That leaves the packets in the middle of the window. For those packets, a list of
sequence numbers already seen is kept. If the packet with the same sequence number comes
in twice, the second one is dropped. Otherwise, the packet is allowed in and its sequence
number recorded.
IPsec is flexible enough to allow for a number of different encryption and authentication
protocols to be negotiated. Common encryption protocols are 3DES-CBC and AES-CBC. A
common authentication protocols is HMAC-SHA1. Recall that an HMAC is a special type
of signature that requires a private key to validate. If a message is received, the key and
the packet data together produce the signature, which is then compared to the one on the
packet. If they match, the sender has the right key. So the possession of the key by the
sender is proof of the authenticity of the packet.
8.3.1.1 IPsec Key Negotiation
Because IPsec is only a transport, there must be a protocol to set up the tunnels. The
simplest protocol allowed is to use none, and IPsec connections are allowed to be set up on
both sides manually. However, it is usually far simpler for management of the connections
to use some sort of user authentication and negotiation protocol.
The Internet Security Association and Key Management Protocol (ISAKMP) is used
between devices to negotiate the type of IPsec connection and to establish the security
association. The two endpoints decide on the type of tunnel, the type of encryption or
authentication algorithm to use, and other parameters using this protocol. ISAKMP is
defined in RFC 2408 and uses UDP port 500 for its communication. Related to ISAKMP is
the key exchange protocol itself, the Internet Key Exchange protocol (IKE). IKE takes care
of the key exchange portion of the setup, and thus piggybacks with ISAKMP as a part of
the setup.

ISAKMP has similar message exchanges as the other security negotiation protocols do,
including certificate requests and responses, nonce exchanges, and capabilities exchange.
ISAKMP is a complex protocol; it would not be useful to go into the same level of detail
for ISAKMP here as it was for TLS. However, let us take a look at the basic exchange.
The first phase for ISAKMP is for one endpoint—usually a VPN client—to reach out to the
authenticating server. The first message sent contains a significant amount of information.
When using Aggressive mode, which is common because it reduces the amount of messages
that have to be exchanged, the first message contains nearly everything needed in one shot
Securing Voice 341
www.newnespress.com
to set up the connection. The first major piece of information in this message is the proposal
list for the algorithms to use for authentication or encryption, for the ISAKMP/IKE
exchange itself. This list is an ordered set of the combinations of encryption and
authentication payloads methods that the client wishes to request, as well as the
authentication methods and the expected key lifetimes. The next important set of
information kicks off the key exchange. This key exchange starts off the key negotiation,
using Diffie-Hellman keys to create a session key. A nonce is included, followed by the
identification of the endpoint, and a number of options.
The next phase, in aggressive mode, comes back from the server. This selects the IPsec
encryption and authentication that will be used, and how the user is to authenticate.
Following this is a nonce, then the server’s identity. Options conclude the packet.
At this point, the ISAKMP/IKE session can be encrypted. The third phase involves the two
endpoints establishing the IPsec security association proper. The two endpoints select what
IPsec authentication and encryption mechanism they will use.
After this has completed, the information is pushed down to set up the IPsec connections
themselves.
User (not packet) authentication can occur one of a couple of ways. Each side can have a
preshared key, which is then used in the validation of the ISAKMP session. Or, each side
can use certificates. The certificate-based scheme is undoubtedly more secure, but is harder
to manage. This is precisely the same tradeoff that is experienced on link protection, such as

using 802.1X verses pre-shared key for Wi-Fi.
8.3.2 Application-Specific Encryption: SIPS and SRTP
The difficulty of using end-to-end encryption is that all of the endpoints must support it,
which may not be the case. Instead, protocol-based security can be used.
For SIP, one option is to use SIP over TCP, protected by a TLS session. This is identical to
the approach HTTP uses for protection, by using TCP and requiring a TLS negotiation first.
The advantage to doing this is simplicity, as TLS is a well-understood technology, and
vendors do not have a difficult time implementing it. Furthermore, using TLS allows the
voice mobility administrator to enable the built-in SIP authentication system, based on
WWW digests, without fear of eavesdropping. Using SIP authentication greatly decreases
the complexity of an authentication-based network, because SIP clients are far more likely
to support it out of the box. The major issue with SIPS, or SIP with TLS, is that the
processing requirements on the PBXs go up significantly, which may affect the scale that
the PBX can operate at.
Protecting SIP does nothing to protect the payload. To protect the bearer channel, SRTP is
an option. SRTP uses a AES (and only AES) encryption to encrypt each RTP packet. The
342 Chapter 8
www.newnespress.com
AES encryption is used in a stream setting, by running in counter mode, which ensures that
AES can be restarted if intervening packets are lost. SRTP is effective, in that it protects the
packets from eavesdropping and modification.
8.3.3 Consequences of End-to-End Security
There is a major consequence of using end-to-end security. Devices that may not have
been built for fast cryptographic operation, such as PBXs and media gateways, will be
forced to use computationally expensive protocols on the real-time voice path to ensure
privacy. The protocols themselves are not ubiquitously supported. For example, IPsec is
common for VPNs, and can be used from router to router or even laptop to laptop, but
phones are unlikely to have a VPN client at all, let alone one that is fast enough to be
appropriate for real-time voice traffic. PBXs are less likely to support IPsec. Using
application specific security makes more sense in this case, but even then, the protocols are

relatively new, and are not commonly deployed. For this reason, it is usually far easier to
dispense with end-to-end security, and instead to focus on protecting the mobile, exposed
portion of the network.
8.4 Protecting the Pipe
The pipe, in voice mobility networks, can be a number of things. When the mobility
network is heavily wireline, the problem becomes authenticating over Ethernet. (Encryption
for wireline networks is considered less necessary.) When voice mobility uses Wi-Fi, the
problem transforms into finding the right WPA2 settings for both authentication and
encryption. When traffic is coming in from the outside world, using fixed-mobile
convergence solutions or remote access clients, the pipe that needs protecting crosses
the Internet.
The advantage of protecting the pipe, and not the entire path, is that the part of the path
most vulnerable can be addressed using specific, dedicated security infrastructure, whereas
the less vulnerable parts can be placed in physically or logically secure networks. This
allows “legacy” voice mobility equipment to have a high chance of operating with strong
security.
For wireline networks, especially dedicated wireline voice networks that have exposed
jacks, one of the major concerns is that someone might plug into the voice network rather
than the data network, either by mistake or to cause mischief. To preserve the sanctity of the
voice wireline network at the edge, one solution available is to use 802.1X on the wireline
ports. 802.1X works on wireline in almost the same way as it does for Wi-Fi. (See Chapter
5 for details.) The major difference is that the end of the 802.1X EAP exchange does not
lead to a continuation into any sort of key exchange or encrypted session. Rather, the edge
Securing Voice 343
www.newnespress.com
switch, acting as authenticator, unlocks the port for use for more than just authentication.
The issue with using 802.1X authentication for wireline networks is that the desktop phones
may not support it. In that case, a practical, though not terribly secure, alternative is to
implement MAC address filtering on the switch. This can be done per port, or better,
switch-wide. The goal is to only let phones onto the network, and ensure that any traffic

that ends up on the network that comes from an accidentally connected device is dropped
before it starts consuming resources. One of the biggest concerns on that front is that a
client may come in and exhaust the phones’ DHCP address space. This can happen when
the accidentally connected laptop is looking for an IP address in a specific range, and gets a
completely different one from the DHCP server. If the client ends up rejecting that address
for being in, say, a private address range that it has been configured not to use, there is a
chance that the device will try again. If this happens enough times, the DHCP server will
lose all of its addresses, and any phones that get plugged in or introduced to the network
wirelessly will not be able to gain basic connectivity.
Wi-Fi security is a must. Chapter 5 went into significant detail on how preshared keys work,
compared to usernames or certificates. The advantage of using Wi-Fi’s own security, rather
than an end-to-end piece, is that the phone is likely to have a high-performance security
function built into the Wi-Fi chip, just for WPA2. This is because Wi-Fi certification
requires that every device support WPA2, and every Wi-Fi chipset manufacturer embeds
just that process into the chips that they make. Phone manufacturers need only turn on those
features; there is no heavy lifting that needs to be done. Compare this to SRTP, for example,
which requires that the voice coder engine, which is usually an optimized engine for
producing real-time payloads, must also either know how to encrypt the traffic by itself or
must pass it along to a slower software process to encrypt. This can cause significant battery
drain on the phone, if such a configuration is even supported.
FMC solutions beg the use of a remote security product. Again, the physical and resource
capabilities of the phone come into play here. Some phones do, in fact, have VPN clients,
which can be used for access into the enterprise. These VPNs terminate long before
enterprise server infrastructure is reached. Running voice protocols, using FMC soft clients,
over the VPN can make sense, although the common mode of operation is for voice to
remain on the mobile operator’s network and for data to go through the VPN. One
interesting twist, however, is that voice devices that have VPN capabilities must have the
VPN logged into when the user is on the road. They can sometimes be configured to log in
by themselves, but more often than not, they must be enabled manually. This is especially
important for converged, dual-mode phones that also operate within the enterprise. When in

the enterprise, associated to the corporate Wi-Fi network, there is no need or benefit for
enabling the VPN link. In fact, the VPN server may not even be accessible from within the
network, as its major interface is meant to point outside, to the Internet. Because the VPN
should be on for some uses of the Wi-Fi network and not others, it can stand in the way of
344 Chapter 8
www.newnespress.com
convincing users to access the enterprise network on the road, reducing the productivity
gains that the FMC solution was looked at for in the first place. One option that many Wi-Fi
infrastructure vendors offer, which takes advantage of the concept of protecting the pipe and
not the end-to-end application, is for remote users to be offered remote access points. These
access points are similar to the campus access point, and yet are designed for operation
when on the road. The remote access point is essentially a VPN client and a normal access
point combined. The access point’s VPN client tunnels through the Internet to the corporate
network, where it terminates at the wireless controller. Once connected to the controller, the
access point pulls the same enterprise configuration down as it would if it were in the office,
and provides it to the remote user. This way, the remote user can use the same cellphone as
on campus, with the same WPA2 security policies, without having to be bothered with the
VPN. This does provide a measure of privacy from the phone to the physically protected
office.
8.5 Physically Securing the Handset
The handset itself is still a weak link. Handsets are designed to be portable, so in that
sense, they are also designed to be transported away from their rightful owners. Many
converged handsets are quite impressive in their capabilities, and so they make for an
interesting target for thieves. Furthermore, busy, high-productivity enterprise users are
unlikely to set up a complicated, strong phone lock password. It is simple to imagine a
hospital on-call attending physician not wanting to be bothered with typing an eight-
character, letter, number, and punctuation-mark password on a phone with itself no more
than 16 buttons.
The problem becomes, then, how to prevent phones from being stolen in the first place, and
how to take care of the problem once they have left the building.

8.5.1 Preventing Theft
There are many practical considerations for preventing the theft of a voice mobility handset.
Unfortunately, limiting the network access is not one of them. Take Wi-Fi-only handsets as
an example. It is pretty clear to the voice mobility administrators that a Wi-Fi-only handset
will not be of much use at a person’s home, or a hotspot, or even another office. Most
phones provide tight administrative privilege requirements to change the Wi-Fi network and
SSID that the phone uses. Even if someone can accomplish the feat of penetrating those
restrictions, the phone will work only with the PBX it was configured for, unless someone
changes it. They do not perform well over the Internet, and are not going to be useful as a
personal wireless voice phone for someone’s house. However, the devices do look like
cellphones, and the people who might take one such phone are not likely to know or care
about the difference until they have the phone securely in their possession.
Securing Voice 345
www.newnespress.com
Some common-sense approaches can work. Sticking labels onto phones that state just the
fact that they will not work outside can have a slight deterring effect, much the same that
which restaurant pagers’ warnings have on their patrons. A more workable approach is to
use telephones that do not look like telephones. In the limited environments where voice
mobility can be conducted without outdoor support, such as warehouses or hospitals,
specialized devices like two-way communicator badges or ruggedized handsets can
discourage some amount of theft. For environments where devices have specialized
chargers, a daily checkout policy and a central charging station can at least keep track of the
phones that do exist and strongly discourage users from taking devices with them to places
where they might get stolen. A good example of this is with nursing—the nurses’ station
makes an acceptable location to place the chargers.
But, ultimately, if someone wants to take the phone, they can. A better way to protect
against theft is to detect theft. Theft detection can be performed somewhat readily on
converged, dual-mode phones or Wi-Fi-only phones using location tracking. Location
tracking is a feature of Wi-Fi networks or of overlay systems that use Wi-Fi for monitoring,
where the rough positions of each device are recorded within the system. Location tracking

systems can be built with automated policies, such as email alerts that are sent when
devices enter or exit certain positions. There are a number of networks that use the location
tracking system to monitor the exits to the buildings, to send alerts if a device passes
through there when it should not. This can send an email out to the person who owns the
phone, informing them of its activity, and gently reminding them that the phone is not to
leave the building. Such as system seems like it may do nothing for people who intend to
steal the device and already have it within their possession, as removing the battery or
powering down the device will disable the location tracking. Another option is for the
system to then send a message if the phone is taken off the air. In many of these
environments, phones are generally kept on 24 hours a day, and so it is possible to come up
with the right set of rules to make a deterrent useful.
Unfortunately, there is no foolproof way to prevent theft of voice mobility devices. Making
sure that the devices do not look like high-end cellphones, unless the users need those
high-end features, and a stronger educational campaign about locking phones and keeping
track of them, are likely to be the most effective.
The second half of the discussion is what to do when the device is stolen. This question is
either more simple or less simple than it looks, depending on whether the device has a
cellular radio. If the device does have a cellular radio, then the options are wider.
Cellular phones, even dual-mode phones, connect to the mobile network. Once connected,
a phone that was reported stolen can be disabled remotely by the mobile operator or
administrator, and even potentially tracked, if the phone is being used in the commission of
a serious crime. On the other hand, if the phone does not have a cellular radio, then there is
346 Chapter 8
www.newnespress.com
a good chance that the thief will not be able to use the phone for much of anything, so it
may already be in a state that is close enough to disabled for the comfort for the
administrator.
This is a reminder for voice mobility administrators to explore the encryption options for
smartphones that may be used with the enterprise network. Phones set up for encryption
may find that the information locked up in the stolen phone will be lost, but it is better than

the information being exposed.
8.6 Physically Protecting the Network
Physically protecting a voice mobility network is a very strong way to preventing
unauthorized access. People may be tempted to leave voice mobility networks more
exposed than their data counterparts, because the only traffic flowing across them is real
time call data, and not, say, highly sensitive corporate strategies. Nonetheless, it is important
that voice mobility networks be given the necessary physical security to prevent problems
with direct intrusions.
The wireline portion of the voice mobility network should be treated with the same level of
concern as the service network for data usage would. Most IT organizations are good at
ensuring that email servers are locked up, if not for security, then at least to prevent
accidental disruption. The same goes for IP PBXs and gateways. However, there has been a
historically different way of thinking about voice networks compared to data. Data networks
invariably terminate in a switch that is placed in a locked switching closet. Voice lines,
however, used to terminate in a series of punch blocks, which had been placed in locations
convenient for the wire-pullers. If a network is subsequently upgraded to voice over IP,
those same locations may be used for placing the Ethernet switches that concentrate the
desk ports and send them to the voice network, towards the PBX. Clearly, those areas
should be kept locked with the same scrutiny.
Another area of concern is with the accidental confusion of voice and data network services.
Voice networks should always be kept physically separate and distinctly marked from data
networks. Before wireline voice over IP, the phone port was never electrically like a data
port. A user making an error in reconnecting the devices on his desk would have found that
the phone and computer would both not work if the machines were plugged in the wrong
way. But, unfortunately, with voice-over-IP services, it is possible for the user to get it
wrong and still have the appearance that everything is working correctly—that is, at least,
until he tries to place a call. This is a different aspect of physically protecting the network.
Previously, we saw an example of how a misconnected device can exhaust network
resources, such as with accidental DHCP exhaustion. Physically protecting the port of the
network would also solve that problem. The simplest way to do that is not necessarily to

Securing Voice 347
www.newnespress.com
secure the jack but to place a wall plate over it that makes it difficult to unplug the phone.
This serves as a potential deterrent to accidental swapping.
On the wireless side, however, real physical security is a necessary. Again focusing on
Wi-Fi deployments, the fact that the signals do pass through walls and outside the building
requires that the network be well planned for security.
Depending on the nature of the environment, even strictly followed WPA2-Enterprise
security with certificate exchanges using TLS can reveal information about the caller that
should not be exposed. Given that a reasonable number of voice mobility devices use
preshared keys, and not WPA2-Enterprise, and a physical security approach can help
provide an additional layer of protection. Furthermore, there are a few environments where
it is important that the very fact that a user places a phone call should be hidden. Voice
traffic over Wi-Fi is designed to be distinctive, with a regular pattern of fixed-rate, fixed-
length frames coming on high-priority services tipping any observer off that a call has been
initiated.
Here, the concern is the exposure to the outside areas of the building of the in-building
voice mobility network. Physical layer Wi-Fi firewalling solutions have recently been
introduced that use RF activity to mask the presence of the network and its traffic to
different physical regions. By deploying these physical layer blocking systems on the
outside walls of the building, the systems can provide a curtain that separates the inside,
where the network is accessible, from the outside, where the network is not even recordable.
This is an inherently different solution from attempting to use specialized antennas and
beam technologies to concentrate the Wi-Fi network towards the inside of the building.
Doing the latter does not prevent an attacker from recording the voice traffic. It requires
only that the attacker get a slightly bigger antenna, with a dB gain improvement for every
dB of isolation that the network installer was able to provide. Using RF firewalling instead
blocks the signal from being intelligible past the curtain of coverage, preventing
eavesdroppers from having useful access to the leaked signals from within the building. Be
careful that some products may be labeled “RF firewalls” if they simply use the location of

the device to influence the firewall policies of the network. These are not true RF firewalls,
since they do not provide any security at the RF layer itself, and thus are completely
vulnerable to the passive leakage attacks mentioned here.
349
CHAPTER 9
The Future: Video Mobility and Beyond
9.0 Introduction
This entire book has so far been looking at the present day, with voice mobility taking
center stage. But mobile devices have begun the dramatic transition from voice-only phones
to multipurpose, “converged” systems that fit in the pocket but perform the work that a
laptop computer would have just a couple of years ago.
The main difference is that the type of applications that these devices run has expanded.
From a quality-of-service perspective, voice is no longer alone as the main application.
Video is here, in the form of webcasts, corporate events, and videoconferences.
In this chapter, we will look at video mobility, building upon the concepts already covered.
Then we will look towards the future, and try to see where mobility may be going, in the
enterprise.
9.1 Packetized Video
Video is an interesting thing. Besides that it contains voice as a proper subset, video also is
responsible for carrying quite a bit more information. Whereas voice recording and
playback technology was perfected in miniature form decades ago, video is always a work
in progress, needing bigger and bigger screens with higher resolutions and more sharpness.
In some senses, it’s hard to imagine how video and mobility go hand in hand, or simply in
your hand, as video requires watching on a device that is not constantly shaking and
jiggling, and requires nearly constant attention, whereas voice can be used on the run.
However, video has the ability to connect with the user in a way voice can never. If a
picture is worth a thousand words, a moving picture should be worth at least a thousand
times more again. More practically speaking, videoconferencing and webcasting has become
increasingly attractive, as travel budgets constrain companies from hosting large fly-in
gatherings, and video technology has improved in concert. In the end, voice and data have

already been able to make the transition from wires, but as video becomes more prevalent
as a part of networking in general, the video must naturally follow the user, and thus
become wireless as well.
©2010 Elsevier Inc. All rights reserved.
doi:10.1016/B978-1-85617-508-1.00001-3.
350 Chapter 9
www.newnespress.com
Let us look into some of the fundamental differences between voice and video. The first
difference is the most obvious: video requires significantly more throughput than voice.
Video has to carry the moving picture along with the same voice stream as before, and so
the overall content must be quite a bit larger. In voice mobility, the throughput of voice is
usually not the constraint except in very large voice aggregation centers. Instead, voice
makes its presence known by its increase in the number of packets over the network. Video,
on the other hand, is bandwidth constrained from the outset. The second difference is that
video requires synchronizing multiple media streams. This impact is felt especially when
loss rates rise or bandwidth constraints are hit, and some part of the video must be
sacrificed. In the ideal case, the software on the endpoints keeps everything in
synchronization, but this can often slip when poor network quality or lack of capacity
begins to challenge the ability of the video client to find its way without all of the
appropriate information. The third difference has more to do with how video is used today.
For the most part, video is one-way. The user watches a video that is being streamed.
Because of this, video can build up reasonable latency, and so video is not as latency-
constrained as voice is. This may change, as mobile devices are given more sophisticated
cameras and videoconferencing on a mobile device becomes possible. But, as of today,
video is still fundamentally a broadcast mechanism. And for this reason, video also differs
from voice at a fundamental network level, because it can be effectively multicast over the
network. The final difference is that video can be significantly more sensitive to loss than
voice. Without the two-way conversation, lost information may not be covered up by asking
the other side to repeat, and the user may end up with a poorer opinion on the quality of the
network.

9.1.1 Video Encoding Concepts
As mentioned earlier, video has many more dimensions (quite literally) of information to it
than voice does. Video is nothing more than a series of still pictures, whereas voice is a
series of nothing more than still point-in-time readings of sound pressure: just one small
number at a time. Where voice has just this one sample at any given time, video has the
entire picture at that time. This picture, itself, is made of two dimensions of pixels, or small
areas that possess the same color.
Let’s dig into this a bit more deeply. A picture, or still image, has hundreds of thousands of
pixels, or picture elements, arranged in a rectangular grid. Each pixel has some fixed
dimension, often measured in millimeters, with the most important aspect being the ratio of
the width to the height of the pixel. The entire screen is made of hundreds or thousands of
pixels in each of the horizontal and vertical directions, resulting in images with a given
resolution. Common resolutions are the small 640×480, meaning 640 pixels wide by 480
pixels high; 1280×720, used in 720p high-definition; and 1920×1080, used in 1080p and
1080i high-definition video. Resolution can also be a function of the actual number of