Chapter 11 Setting Up Skype in the Workplace

A Word about SIP and H.323

Skype does not use SIP or H.323, but we thought we would cover these two protocols so that you could understand two of the main VoIP protocols used and how they differ from Skype. Session Initiation Protocol, or SIP, is a text-based protocol that uses port 5060 on both UDP and TCP for call setup and teardown. Version 2.0 of SIP has been codified in RFC 3261, where the various details of SIP are included. SIP is a signaling protocol very much like the telco SS7 protocol suite, but unlike SS7, which is very centralized and requires a private network, SIP was designed with the Internet and TCP/IP in mind and the use of many different media types such as voice and video. SIP is also a peer-to-peer type of architecture, similar to Skype. But whereas Skype does not use any central servers aside from the user authentication, SIP does use centralized servers for authentication. Since SIP is a signaling protocol, it offers features such as call waiting, call transfer, and call hold, among many others:

• Call forwarding, including the equivalent of 700, 800, and 900-type calls
• Call forwarding, no answer
• Call forwarding, busy
• Call forwarding, unconditional
• Other address-translation services
• Callee and calling “number” delivery, where numbers can be any (preferably unique) naming scheme
• Personal mobility, which is the ability to reach a called party under a single location-independent address, even when the user changes terminals
• Terminal-type negotiation and selection, in which a caller can be given a choice of ways to reach the party, such as Internet telephony, mobile phone, or an answering service
• Terminal capability negotiation
• Caller and callee authentication
• Blind and supervised call transfer
• Invitations to multicast conferences

Along with the RFC standard, SIP is an official standard of the Internet Engineering Task Force (IETF).

In the following packet sample of a SIP INVITE packet, we can see SIP’s basic packet structure:

We can see the destination UDP port of 5060 as well as the request for the invitation, with the caller’s information. We can see that the entire request is in plain text, much like traditional HTTP or SMTP.

Understanding the Basics … VoIP

There are many different flavors of Voice over Internet Protocol (VoIP) client, such as Skype, Gizmo, and more, but they all work relatively the same way. In the simplest terms, they run your voice through a codec (coder/decoder) to digitize it, and then they packetize it so that your voice can be sent over the Internet or other network using TCP/IP instead of telephone lines. In the old days and even many times today, the telephone is an analog device and uses dedicated lines that run back to a central office in a star-like pattern. The central offices are tied together using a signaling protocol like SS7, which gives the mechanism access to trunk voice lines and provides the switching of voice circuits around the cloud to make the virtual connection between you and the person you are calling. VoIP gets around all that overhead and equipment requirements by relying on TCP/IP and User Datagram Protocol (UDP) for the transport of your voice. To use a VoIP application like Skype, all you need is an Internet connection, a compatible computer, a speaker, a microphone, and the Skype software.

SIP is the carrier for the encoded data stream that is generated by the codec. This encoded data is carried by the Real-Time Transport Protocol (RTP) stream. RTP carries several key pieces of information for the call. These pieces are like the header that carries the information on how to recombine the codec packetized data. Also included in the RTP data are sequence numbers, payload identification, source identification, and intermedia synchronization. The intermedia synchronization is how the two data streams, video and audio, stay synchronized. SIP has trouble crossing a Network Address Translation (NAT) boundary because it uses RTP and carries the IP address and port information. The details of RTP are covered in RFC 1889. In the following figure, we see the basic SIP signaling at work:

The SIP sessions are considered “peer-to-peer,” much like Skype, and do not require a soft PBX (private branch exchange) to function. The two end points can set up their own session by themselves. But to get advanced features and integration with the telephone system, SIP has a high level of support in the Open Source arena with major soft PBXes such as Asterisk, sipX, Yet Another Telephone Engine (YATE), and SIP Express. SIP is also supported as an end point with software such as MSN Messenger, Apple’s iChat, and AOL’s AIM instant messenger application.

H.323 is a suite of protocols that was designed to move multimedia data streams over a LAN. It has since evolved into of the standards for VoIP and, like SIP, H.323 is an official standard of the IETE Let’s look at how H.323 works:

When in use, H.323 references other specifications, such as H.225, which lays out the call signaling and the stream packetization; H.245, which is the control protocol used to open and close logical channels; and H.450, which describes supplemental services. The original specification was based on the ISDN Q.931 specification; thus, it works well at interconnecting IP and ISDN clouds. The H.323 protocol is older and more mature than SIP, but to a large extent, SIP has surpassed H.323. H.323 tends to be a vendor-specific protocol, so although your Meridian H.323 will work fine for all your Meridian equipment, if you bring in a second brand, the odds of it working correctly are low. This incompatibility has been one of the prime reasons, if not the reason, that SIP is overtaking H.323 in the marketplace. H.323 is supported by Microsoft’s NetMeeting and GnomeMeeting. GnomeMeeting uses an open source version called OpenH323, which can be found at openh323.org.

In deciding between SIP or H.323, you will often find that regarding commercial software, that choice has been made for you already based on the completeness of the support for the protocols. In the case of Cisco, for example, SIP does not have good support, because Call Manager uses a private protocol. By comparison, when you use an open source

soft PBX such as Asterisk, you can have very good support for SIP along with the phone-line integration that you have with commercial products.

The difference between protocols like SIP and Skype is that Skype is not open, so you are limited in your understanding of how Skype works by exploring and reverse-engineering the protocol or just using the Skype API calls, as we discuss in Chapter 14 of this book. In the following sections we attempt to document as much as we can about the Skype architecture and how the protocol works.

NOTE

For a much more detailed discussion and list of resources for SIP and H.323 and more VoIP details, try the VoIP wiki at www.voip-info.org/tiki-index.php.

Skype Architecture

The architecture of Skype is very much like Kazaa; some of the same people are involved in Skype that designed Kazaa, so that makes sense. In simplest terms, Skype is a giant peer-to-peer network without data centers or file servers per se. We say “per se” because Skype does use certain servers called supernodes, which are described in some detail later in this section. When Skype starts, it opens a random listening port on both TCP and UDP that was chosen during the Skype installation. Skype also uses port 80 (HTTP) and port 443 (HTTPS), unlike SIP, for which there is a given port used for the protocol.

Since Skype is an overlay peer-to-peer network, there is a table of reachable nodes on each client. This table is called the host cache and has the IP addresses and port number of a supernode. The supernode is a Skype client that has several criteria to meet:

• Public IP address
• Sufficient bandwidth
• Sufficient CPU power
• Sufficient memory

The idea and use of supernodes have been directly borrowed from Kazaa. The supernode acts as a router for Skype calls and for the client’s authorization to have before it is allowed to use the Skype network. If the Skype client cannot make a connection with the supernode, Skype will report a login failure. The Skype client also has to connect to the Skype login server, which keeps track of usernames and passwords on the Skype network. This is the one constant server in the Skype network. The Skype client cannot “opt out” from becoming a supernode if the client meets the requirements to be a supernode. This is spelled out in the fine print of the end-user agreement that you have to click through to install Skype. Here is an example of the overall Skype architecture:

Understanding the Basics … Avoid Becoming a Supernode

For home users and small businesses to avoid being supernodes, just add a P2P-friendly DSL/cable router to your network. For business users to avoid being a supernode, simply make sure you are behind a true firewall device that provides NAT capabilities.

The supernodes play a very important part in the Skype network, since if the Skype client cannot see a supernode, the login will fail after several attempts on the client’s part.

Opening Connection

When a Skype client first tries to authenticate to the Skype network, the client opens a connection using HTTP (port 80) to http://iu.skype.com and checks to see if the client is current or not. Here are the results of that HTTP connection attempt:

Once the Skype client has been verified to be using current software and the user has been authenticated, the Skype client attempts several different methods of placing any requested call. Skype does not use a standard port for listening; the port choice evolves from a random port choice made during the installation. The actual communication will depend on whether the Skype client has an open connection to the Internet or has to traverse a NAT-enabled firewall. The use of NAT causes Skype to try a variety of methods to get around it. These methods are partially based on the Simple Traversal of User Datagram Protocol (STUN).

Skype uses the TCP flag called PSH. This flag is used when you need to ensure that all the data submitted to TCP was actually sent. And with VoIP, having all the bits is a real plus for quality. The Ethereal trace file shown in the following screenshot shows the TCP side of a Skype connection using the PSH flag.

Dealing with NAT

In the traditional VoIP model using SIP or H.323, NAT will break the connection. Skype appears to use a form of STUN, which is detailed in RFC 3489 and is a method of getting past NAT using UDP packets. The use of a STUN-like protocol has proven very effective for Kazaa in the past and has been migrated to Skype to allow use even behind corporate firewalls. When testing Skype, we were able to make a connection through our Cisco VPN concentrator and then out the Cisco PIX firewall to the United Kingdom without a problem. This ease of use, however, gives corporate system administrators heartburn, since we could conduct a voice call and IM session or even video, and the company has zero visibility into the contents because of use of encryption.

Even if the NAT firewall blocks outbound UDP or restricts outbound UDP, Skype can work around this restriction by using the supernodes as a “relay” point. More on NAT and firewalls are covered in Chapter 13.

Encryption

Skype recently released a Security White Paper by Tom Berson of Anagram Laboratories that outlines exactly how Skype uses encryption. This paper may be found at the following URL: www.skype.com/security/.

Skype uses 256-bit AES encryption for its data stream. The use of encryption also makes it difficult to log the use of Skype, or more precisely, what is being used on Skype or who may be talking using Skype. The use of encryption works for the voice call, any file transfers, and instant messaging.

A potential issue for Skype and virtually any other VoIP messaging application is a set of new rules called the Communications Assistance for Law Enforcement Act (CALEA), which goes into effect in 2007. These rules make it easier for the government to have wiretap access to the media stream. The rules say that any VoIP protocol or company must be wiretap ready, and the list includes SkypeOut, Vonage, Packet 8, and many others. There are crossover worries for other groups offering Internet access, and the Federal Communications Commission (FCC) promises a set of regulations clarifying the first set of rules. The rules can be found at www.askcalea.net.

We highly recommend that any people considering Skype for business use read the upcoming rules and regulations to better understand any impacts these regulations might have on their businesses.

Security

Security on any VoIP network is of considerable importance, given the forensic importance of a phone call. On a conventional VoIP network, as well as on a traditional telephone network, the following information is logged:

• The phone number that was dialed
• When the number was dialed
• When the call was connected
• The duration of the call
• When the call was disconnected

Skype does log some of the preceding information, but only the last 10 records, and a history is not kept as you might see in other VoIP solutions. This raises legal questions if business is conducted over a Skype connection. You need to decide what your security policy is on and whether logging call information is required. Some situations may require logging; others may not. Unauthorized use of Skype on a network can bring the following problems to the network administrator:

• Skype file transfers can cut both ways: unauthorized flow of company data out or the download of files that could be compromised with worms, viruses, and the like that have bypassed your firewalls and scanners.
• Skype file transfers will be caught by an antivirus solution that has an “auto-protect” capability.
• Skype users could consume a considerable amount of bandwidth if unchecked on the network. A large company with a T3 would not notice it right away, but a smaller company with a single T1 or a slower DSL circuit could easily have its WAN link overloaded by excessive VoIP traffic from Skype if all the users performed Skype calls.
• Skype may take over private resources to act as a supernode, even if the user is not actively using the Skype client. This is mitigated by a corporate firewall or DSL/cable router or other NAT device.
• The encryption of instant messaging can lead to exposure of private company data or other legal issues that cannot be monitored by a proactive staff.

Skype is up front about using your computer, or as up front as an end-user license agreement (EULA) can be. What is buried in the fine print of the EULA is the following article:

Article 4 Permission to Utilize

4.1 Permission to utilize Your computer. In order to receive the benefits provided by the Skype Software, You hereby grant permission for the Skype Software to utilize the processor and bandwidth of Your computer for the limited purpose of facilitating the communication between Skype Software users.

4.2 Protection of Your computer (resources). You understand that the Skype Software will use its commercially reasonable efforts to protect the privacy and integrity of Your computer resources and Your communication, however, You acknowledge and agree that Skype cannot give any warranties in this respect.

(© Copyright Skype ELUA August 2005)

Please pay attention to these two sections of the EULA. The first one, Section 4.1 of the EULA, says that to use Skype, you give Skype right to use your computer, processor, and bandwidth to help facilitate communication between Skype users. In other words, you give approval to be one of those supernodes that we discussed earlier in this chapter. Your computer can be a supernode only if you are an open client on the Internet and do not have NAT protection.

The next section is also very important to administrators or anyone else with an interest in security. Section 4.2 of the EULA basically says that Skype will use reasonable efforts to protect your privacy and the integrity of your computer. This might be acceptable to the average home user, but most chief technology officers (CTOs) or other company management will not be very happy to see an application like Skype sitting on their networks with this type of license in play.

Several key properties are important to any discussion of security with respect to Skype. These properties are:

• Privacy How secure is your conversation using Skype?
• Authenticity Are you are reaching the person you think is at the other end?
• Availability Are Skype users always available when they are listed?
• Survivability If the Skype network takes a hit, can Skype keep working.
• Resilience Can the Skype user reconnect quickly when there is an outage?
• Conversation integrity Does Skype lose bits of the conversation?
• System integrity Does Skype work well with other applications?

These points are covered in detail in a security analysis paper written by Simson Garfinkel and available at www.tacticaltech.org/files/Skype_Security.pdf. This paper is highly recommended for anyone with concerns about Skype’s VoIP security model and methods.

The privacy of Skype is due to the encryption method Skype uses. Both voice calls using Skype and any instant messaging are encrypted, so there is a high level of privacy. This may change with government agencies looking to have the ability of monitoring traffic in a solution like Skype.

Most of the time, Skype is available when it should be. But Skype and many other VoIP vendors have ongoing issues with availability compared with the “old” telephone service. The telephone routinely has an uptime of 99.999 percent; people have become very used to this reliability, and they depend on this kind of uptime. Even under very adverse conditions, your POTS has a good chance of being up and working.

This is very unlike VoIP, where the connection can fail in a multitude of places. The gateway can fail, servers can fail, the ISP can fail—the list goes on. The telephone companies have had many years to work out how to build a redundant network, and the technology, although old style, is very robust. The VoIP companies are still working out standards, bugs, and billing issues as well as building a robust infrastructure. Being mostly decentralized, Skype has some advantages in terms of robustness, but Skype still has some weaknesses that administrators and users need to be aware of. The primary weakness at this point is the use of Skype servers for the username and password authentication. Without those, the Skype system fails.

VoIP systems such as Skype and others have a distinct advantage in the category of resilience. If the building or location in which you are using Skype loses its Internet connectivity, just go somewhere else with an Internet access point, and you are back in business. No mess, no fuss, Skype will simply work again. This is in contrast to the traditional phone system, where the numbers are generally not portable, so if the building phone system fails, you lose your phone connectivity on that number until the phone company can reprogram switches and their network or you can forward the phone number to a new number somewhere else. Larger companies and corporations may have multiple and redundant Internet connections and allow for rerouting adding to the reliability of a Skype type of solution.

We now know through the analysis by Tom Berson of Anagram Labs that Skype ensures the integrity of the voice call. Administrators or engineers can now compare Skype to products from other vendors to see who provides the best solution.

Skype is a closed protocol, but there has been some documentation on a few parts of the process by which Skype makes connections. Skype’s supernodes carry media stream traffic at times, which has the possibility of being a security risk, since the call is traversing an unsecured server. Remember, the supernode is any computer with sufficient RAM, CPU, and a public IP address not protected behind a NAT device.

Understanding the Basics …
Avoid Skype Call Relays and File Transfer Relays

If you do not want to relay your Skype calls or Skype file transfers, configure your network to avoid this.

Blocking Skype

To block Skype on their networks, administrators will, at best, find it difficult, since Skype, like Kazaa, was designed to intentionally get around the normal network security blocks. One of the few ways is to look at HTTP traffic and make sure that the headers and information are really HTTP traffic and not something like Skype just using port 80 to take advantage of the open port on most networks. Some vendors, such as BlueCoat and Verso, claim they can block Skype traffic. BlueCoat and Verso are enterprise-level solutions and therefore very expensive security appliances that are designed for large networks. BlueCoat recommends blocking Skype by preventing download of the Skype application and using protocol filters on the BlueCoat proxy appliance. BlueCoat provides a free white paper titled “Best Practices for Controlling Skype within the Enterprise” available for download from its Web site, www.bluecoat.com/resources/resourcedocs/whitepapers.html.

Verso attempts to block Skype by matching Skype communication patterns referred to as signatures. The Verso appliance has an active client that can receive updates to the appliance’s “black list” and algorithms used to block internet traffic, such as Skype. Additional technical information on blocking Skype will be discussed in Chapter 13.

Firewalls

A security best practice to start with is to block the use of the high-numbered ports on your firewall. Also, taking the approach of blocking everything outbound and allowing only what you need is highly recommended, with the understanding that it will mean more work for the security or network administrator. This approach is becoming much more common on firewalls, so if you have problems with your Skype connection, check your firewall to make sure it is not configured to block all traffic unless explicitly allowed on the outbound side.

Downloads

If you have the capability to block certain downloads, you can block the Skype executables (skype.exe) from being downloaded. Using group policies can help prevent the installation of the Skype application on an Active Directory domain or prevent the execution of the executable. Of course, on a non-Microsoft client such as Apple’s OS X, Active Directory control is pretty much a nonstarter, so you would need to find another way to lock down the OS X operating system.

We cannot suggest strongly enough that you have a policy in place at the company detailing acceptable software use, spelling out definitions of “good” software and “bad” software. Such a policy provides some cover for the company in case legal issues arise with the unauthorized use of Skype.

Software Inventory and Administration

Another method to block the use of Skype is to use a software inventory solution that is typically found in larger organizations. Companies often scan the systems looking for specific software packages like port scanners and other potentially malicious tools and delete them as a part of a good security plan. You could do the same to control the use of Skype inside a corporation with a software inventory and distribution solution like SMS, Radia, and others.

You could also use a script that attaches to all your remote machines, log on as an administrator, scan for unapproved applications, and delete or disable those applications. This practice would work for smaller companies and those with non-Windows operating systems that may not have a software distribution solution.

Firewalls

Skype uses a modified form of the STUN protocol to deal with security like NAT on a firewall. Restricted ports are dealt with using random ports during the installation and use of HTTP and HTTPS. Between the use of ports 80 and 443 and the random ports, Skype can work around restricted firewalls.

To see if you can pass through your firewall with Skype, you can use a free program called NAT Check, which can be found at http://midcom-p2p.sourceforge.net/. This NAT checking program is not from Skype, but Skype suggests its use to verify your network capability with Skype. The following NAT Check screen is from a typical home network showing a good result:

The following NAT Check test was over a public wireless access point and using a Cisco VPN SSL client showing a good result:

You can also use the Display technical call info option to help troubleshoot your Skype connection to see if it is being relayed or not. For more information on how to Display technical call info, see Chapters 6 and 13.

Proxy Servers

As we touched on in Chapter 6 and will again in Chapter 13, if you have implemented a proxy server on your medium-sized to enterprise network, you can configure Skype to use the proxy server to gain access to the Internet. The address of the proxy server may not be easily determined by setting Internet Explorer’s Connection LAN Settings option to Automatically detect settings. If you would like to determine the actual proxy server name to enter in the Skype configuration dialog, simply type netstat – v at a command prompt. You will notice many Internet connections through the same port, most likely 8080 or 8088, from a machine on your network. That machine is most likely to be your proxy server. If you have more than one proxy server on your network, every time you log in, you may get a different proxy server with the automatic configuration. Manually defining the proxy server allows a network administrator to configure a single proxy server for Skype traffic and have more control over Skype traffic. See Chapter 13 for more information on configuring Skype to use a proxy server.

Embedded Skype

Skype has signed contracts with some vendors to embed its client software into various products. These products are phone sets, small office/home office (SOHO) routers, and other network devices. Skype-enabled devices can have adverse effects on the security of your network if you do not know that “hidden” clients are in various pieces of hardware. So the administrator must not only manage the network side but also be aware of the hardware being brought into the network. Be sure to understand the devices on your network and what they do to prevent unauthorized devices being used on your network.

Performance Considerations

Peer to peer is rarely the best choice for VoIP performance owing to potential latency issues. This is not to say that Skype cannot work well because it’s peer to peer, but Skype can be impacted easily by network or even computer latency issues. Everything about Skype is propriety and closed to tinkering with the exception of the published API calls. Skype’s proprietary design makes it difficult to tweak or to tune Skype, and given that Skype works on a P2P model, there is very little you can do to optimize the routing between the nodes. Skype normally uses UDP as its transport of choice, which makes for a low overhead and good performance, but the trade-off is on how much you can optimize it.

The reality of using Skype is that all the user can adjust is the environment that Skype is running in. For example, Windows can kick off the speech recognition engine when a call using Skype is dialed. This results in heavy CPU utilization, upward of 100 percent. So turning off the voice recognition can have a tangible effect on how well Skype can work. By the same token, avoid running any application that utilizes the CPU heavily when you’re trying to use Skype or another VoIP application. You can monitor applications that may be using a large amount of bandwidth or CPU by using a bandwidth-monitoring application such as Net-Peeker or Windows Task Manager to watch for CPU utilization. This requires a bit of work on your part to identify Skype and the port being used, but it can help. Placing a firewall between the Internet and your PC with NAT enabled will also disable your system from being a Supernode.

Tweaking the Technology … Bandwidth Requirements

When you decide which encoder to use, remember that Ethernet adds about 32Kbps to the overall amount of bandwidth required for a given data stream. For example, if you use G.711, which compresses your audio stream to 64Kbps, the addition of Ethernet will add 31Kbps for a total bandwidth stream of 95Kbps.

Skype, on the other hand, uses approximately 5Kbps to 25Kbps of bandwidth each direction as long as you are properly protected with a NAT or firewall device, thus eliminating becoming a supernode. This low-bandwidth requirement and the relatively high quality of the voice conversation are among the main attractions of Skype. There have been reports of users becoming supernodes and experiencing impacted performance. These users were on a broadband connection and a cable modem but no firewall or DSL/Cable router. This setup met the requirement of a public IP and apparently included enough CPU and RAM on the users’ home computers. These reports point out some of the dangers of using Skype without understanding how to protect yourself and the potential impact on your network.

If you have a firewall in place, and you do not open up ports to allow Skype to communicate effectively, then you will incur more network overhead because of the TCP traffic and relayed calls and file transfers. You can rapidly approach network saturation if a large portion of the enterprise decides to use Skype at the same time. See Chapter 13 for performance tuning information.