Centrex or PBX

Public Key Cryptography Concepts

2012-01-26T01:58:00.000-08:00

Within the PKI framework, who you are is defined by the private keys you possess. From the point-of-view of PKI authentication authorities, you are your private key. In order to understand PKI, you will first have to understand some basic cryptological concepts. In Figure 1 the concept of a secret key is presented. Alice and Bob often are used as examples of the two parties engaged in a secure communications channel, and we will use them here. In this case, Alice and Bob both possess the same secret key. This can be a password, a token, or some other form of secret. Alice encrypts the plaintext that she wishes to send to Bob using her secret key. After Bob receives the ciphertext, he decrypts it using the same secret. The fact that the same key is used for both encryption and decryption determines that this is a symmetric exchange.

Figure 1: Symmetric Key Cryptography

PKI relies on a public/private key combination. The public and private keys are mathematical entities that are related. One key is used to encrypt information and only the related key can decrypt that same information; however, if you know one of the keys, it is computationally unfeasible to calculate the other. Your public key is something that you make public. It is freely distributed and can be accessed by everyone. A corresponding (and unique) private key is something that you keep secret. It is not shared with anyone. Your private key enables you to prove, unequivocally, that you are who you claim to be.

In Figure 2, Alice uses public key cryptography to send a ciphertext to Bob. She first locates Bob’s public key (normally from some type of directory service or from a previous secured document that Bob has sent to her) and encrypts the plaintext with Bob’s public key. She sends the encrypted text to Bob. Only Bob has the corresponding private key that can be used to decode the ciphertext.

Figure 2: Public Key Cryptography

Note that in normal practice, for performance reasons, the actual ciphertext is encrypted using a secret key algorithm as shown in Figure 1. Symmetric algorithms are much faster than public/private key algorithms (asymmetric cryptography). A random key (the session key) is generated, and it is used with the symmetric algorithm to encrypt the information. The public key is then used to encrypt that key and both are sent to the recipient. The private key is then used to decrypt the session key, and the resulting session key is used to decrypt the actual data.

The developers of public key cryptography were economical with keys. Both the public and private key are used for more than just encrypting and decrypting data or session keys. The private key also is used to digitally sign the sent message so that the sender’s identity is guaranteed. If the sender wishes to prove to a recipient that they are the source of the information (perhaps they accept legal responsibility for it), the sender uses his or her (or its) private key to digitally sign a message (a digital signature). Unlike a handwritten signature, a digital signature is different every time it is created. To create the digital signature, a hash of the message is signed (encrypted) with the sender’s private key The encrypted value either is attached to the end of the message or is sent as a separate file together with the message. The sender’s public key that corresponds to this private key may also be sent with the message, either on its own or as part of a certificate.

The receiver uses the sender’s public key to verify that the message hash calculated by the receiver (when certificates are used, the type of hashing algorithm will be included in the public key certificate sent with the message) is the same as the original hash. If the values match, the receiver is reasonably assured that the sender (the individual or device that owns the private key that corresponds with the public key) sent the information. The receiver also is reasonably assured that the information has not been altered since it was signed. This exchange forms the basis for two key security principles: nonrepudiation (the identity of the sender is verified) and message integrity (the contents of the message have not been altered in transit). Table 1 summarizes the intended use and owner of both public and private keys in public key cryptography.

Table 1: Key Usage in Public Key Cryptography
Function	Key Type	Key Owner
Encrypt Data	Public Key	Bob (Receiver)
Sign Data	Private Key	Alice (Sender)
Decrypt Data	Private Key	Bob (Receiver)
Verify Data Integrity	Public Key	Alice (Sender)

MS-CHAPv2

2012-01-15T07:24:00.000-08:00

MS-CHAP v2 is a one-way encrypted password, two-way authentication process that provides mutual authentication between peers (see Figure 1). It differs from MS-CHAP-V1 because it piggybacks an additional peer challenge (PCS) on the Response packet and an additional authenticator response on the Success packet. Both the authenticating server and the client challenge and authenticate each other. The message flow is as follows:

Authenticator sends a challenge consisting of a Session ID and random authenticator challenge string (ACS).
Client (peer) sends a response containing an encrypted one-way hash of the session ID, username, a peer challenge string (PCS), the peer response (PR), and the user password (secret).
Authenticator responds with another one-way hash (based on the client response) of a success/failure code, the authenticator response (AR), and the user’s password (secret).
The peer verifies the authenticator response and begins communications if the response is successful. It disconnects on failure.

Figure 1: MS-CHAP-V2

This authentication method depends upon a secret (password) known only to the authenticator and the peer. The secret is not sent over the link. A one-way hash function, also known as a message digest, is a mathematical function that takes a variable-length input string and converts it into a fixed-length binary sequence that is computationally difficult to invert—that is, generate the original string from the hash.

CHAP and MS-CHAP

CHAP was defined in RFC1994: PPP Challenge Handshake Authentication Protocol. CHAP (Challenge-Handshake Authentication Protocol) was initially used to verify client identity on PPP links using a three-way handshake. The handshake begins with the authenticator issuing a challenge to the client. The client responds with a digest calculated using a hashing function. The authenticator then verifies the response and acknowledges the connection if the match is successful, otherwise it terminates the connection. CHAP depends upon a secret known only to the authenticator and the client. The secret is not sent over the link.

MS-CHAP differs from CHAP in that MS-CHAP does not require that the shared secret be stored in cleartext at both ends of the link. The Microsoft client knows the hash method used by the server so it can reproduce it, effectively creating a “matching” password on both ends. The client proves its identity based on the fact that it can reproduce the hashed value of the password.

PAP

PAP (Password Authentication Protocol) is described in RFC1334. PAP provides a simple method for the peer to establish its identity using a two-way handshake. PAP is not a strong authentication method. Passwords are sent over the connection in cleartext and there is no protection from playback or repeated trial and error attacks.

MD5

MD5 (Message-Digest algorithm 5) is a widely used cryptographic hash function that results in a 128-bit hash value. The 128-bit (16-byte) MD5 hashes (also termed message digests) typically are represented as 32-digit hexadecimal numbers (for example, ec55d3e698d289f2afd663725127bace). EAP-MD-5 typically is not recommended for wireless LAN implementations because it may expose the user’s password, and because several collision-based weaknesses have been demonstrated. It provides for only one way authentication—there is no mutual authentication of wireless client and the network. And very importantly it does not provide a means to derive dynamic, per-session wired equivalent privacy (WEP) keys.

GTC

Typically, password (PIN) information is read by a user from a token card device and entered as ASCII text into the client. GTC is similar to PAP in that passwords are sent in the clear.

Notes from the Underground—Dictionary Attacks

Passwords can be broken in real-time (active) and offline (passive) modes. The premise of a dictionary attack is that by trying every possible combination or words (or tokens), an attacker ultimately will succeed in discovering user secret passwords. A dictionary attack relies on the fact that d. password is often a common word, name, or concatenation of words or names with a minor modification such as a trailing digit or two, Longer passwords with a variety of characters (such as ^Y2o4uEA16r3-2e64A12EFing!) offer the greatest protection against dictionary attacks.

During an online dictionary attack, an attacker tries to actively gain network access by trying many possible combinations of passwords for a specific user. Online dic-tionary attacks can be prevented using password lockout mechanisms that lock out the user account after a certain number of invalid login attempts. Online attacks also generally show up in logs, which can indicate that this type of “loud” hacking activity occurred or is occurring. Offline attacks rely on the attacker’s ability to capture and record data from the datastream usually by using a sniffer such as tcpdump or ethereal. These captured data can then be compared at leisure against tables of hashes until a password ‘s discovered or the attacker gives up, The offline attacks can be thwarted by changing passwords regularly and limiting attackers’ access to the datastream.

EAP Authentication Types

2012-01-12T07:22:00.000-08:00

Most of the more recent EAP types are made up of two components: an outer and an inner authentication type, separated by a forward slash—such as PEAPv0/EAP-MSCHAPv2. The outer type defines the method used to establish an encrypted channel between the client (peer) and the Authentication Server.

Note

The primary goal of the Transport Level Security (TLS) Protocol is to provide privacy and data integrity between two communicating applications. TLS is based on the Netscape SSL 3.0 Protocol Specification, although they are not interoperable. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol, and is situated between ISO layers 3 and 4. Symmetric cryptography is used for data encryption (e.g., DES, RC4, AES, etc). The keys for this symmetric encryption are generated uniquely for each connection. Message transport includes a message integrity check using a keyed MAC (SHA, MD5). These two elements ensure data confidentiality and integrity for each connection.

In Figure 1 an outer authentication method, PEAP, is negotiated between a client such as an IP phone or a workstation and a RADIUS authentication server. The intermediate NAS proxies the first several exchanges and then serves to passively mediate traffic in both directions. The NAS does not have knowledge of the keys used to instantiate the TLS tunnel, and thus, cannot be used to snoop on the encrypted traffic passing through it.

Figure 1: EAP Part I Outer Tunnel

This outer tunnel verifies the server to the client using digital certificates.

Once the outer channel is established, the inner authentication type passes the user’s credentials to the Authentication Server over this TLS encrypted tunnel for additional authentication of, typically, user credentials. Passing user credentials through the TLS encrypted tunnel protects them from exposure (see Figure 2).

One of EAP’s potential security vulnerabilities is that data exchanged as part of some of the outer authentication types, such as identity data, and the results of parameter negotiations are sent in the clear. This can result in a Denial-of-Service (DoS) condition since an attacker, for example, can flood the connection with different types of EAP notification messages.

Figure 2: EAP Part II Inner Tunnel

In Table 1some of the characteristics for the different types are summarized. In the last two fields more plus signs (&) equals greater difficulty and more strength, respectively.

Most of the newer EAP types defined by the Wi-Fi Alliance (those with the forward slash and EAP-SIM) are derived from this EAP type. EAP-PEAP and PEAPv0/EAP-MSCHAPv2 are the same thing. PEAPv1/EAP-GTC is a Cisco invention.

EAP-TLS

EAP-TLS (Extensible Authentication Protocol—Transport Layer Security) provides for certificate-based and mutual authentication of the client and the network. EAP-TLS is the most secure of the common EAP types, but requires a PKI (public key infrastructure) to manage and distribute client certificates. The TLS protocol has its roots in the Netscape SSL protocol, which was originally intended to secure HTTP. It provides either one-way or mutual authentication of client and server based on certificates. In its most typical use in HTTP, the client authenticates the server based on the server’s certificate and establishes a tunnel through which HTTP traffic is passed. Username and password management in this scheme is irrelevant as identity is based upon possession of the appropriate private key. The obligatory overhead of a certificate management infrastructure normally precludes use of this EAP type.

Table 1: EAP Types Summary
EAP Type	Server Authentication	Client Authentication	Native Windows 2003 Support	Confidentiality	Integrity	Deployment Difficulty	Security Strength
EAP-TLS	Certificate	Certificate	Yes	TLS	+	+++++	+++++
EAP-PEAP	Certificate	Certificate, Smartcard, MS-CHAP-V2	Yes	TLS	+	++	++++
PEAPv0/ EAP-MS CHAPv2	Certificate	Certificate, Smartcard, MS-CHAP-V2	Yes	TLS	+	++	++++
EAP-TTLS	Certificate	PAP, CHAP, EAP, MS-CHAP-V2, Certificate	No	TLS	+	+++	++++
PEAPv1/ EAP-GTC	Password hash	Password hash (Token)	No	No	+	???	+++
EAP-SIM	128-bit secret	SIM secret	No	+/−	+/−	+++	++
EAP-FAST	Optional (PAC) password	Password (PAC)	No	+	+	+++	+++
LEAP	Password	Password	No	+	+	+++	+
MD5	None	None	Yes	−	−	+	+

EAP-PEAP

EAP-PEAP (Extensible Authentication Protocol-Protected Extensible Authentication Protocol) provides a method to transport secure authentication data, including legacy pass-word-based protocols. PEAP accomplishes this by tunneling user credentials over a TLS tunnel between PEAP clients and an authentication server. EAP-PEAP is the best combination of security and ease of deployment in Windows environments today. EAP-PEAP requires only a server certificate (which is simple enough to create for testing using the native MS Certification Authority) and client side username/password combinations. EAP-PEAP is natively supported on Windows XP and Windows 2000 SP4 and above client platforms and IAS (Internet Authentication server). PEAPvO/EAP-MSCHAPv2 is the same thing as EAP-PEAP.

EAP-TTLS

EAP-TTLS (Extensible Authentication Protocol-Tunneled Transport Layer Security) is supported primarily by the Funk RADIUS people. EAP-TTLS, like PEAP, is also relatively easy to deploy (it requires only a server-side certificate) and quite secure since it tunnels user credentials inside of a TLS tunnel; however, this Funk Software invention has not been supported by Microsoft on clients or IAS server. Thus, EAP-TTLS requires the use of an additional software. TTLS and PEAP are similar in other ways, but there are differences: TTLS supports other EAP authentication methods and also supports inner authentication methods, PAP, CHAP, MS-CHAP, and MS-CHAPv2; whereas PEAP can tunnel only EAP-type protocols such as EAP-TLS, EAP-MS-CHAPv2, and EAP-SIM.

PEAPv1/EAP-GTC

PEAPv1/EAP-GTC (Extensible Authentication Protocol-Generic Token Card) was defined in RFC2284 along with one-time passwords, and MD5 was one of the initial set of EAP Types used in Request/Response exchanges. Cisco supports this type of PEAP (v1 vs. v0) and Microsoft supports only PEAPv0.

EAP-FAST

EAP-FAST (Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling) was developed by Cisco. EAP-FAST authenticates both the client and the authentication server using a preshared secret known as the Protected Access Credential (PAC). EAP-FAST is a certificate-free replacement for LEAP EAP-FAST is easy to implement in Windows/Cisco mixed environments, but this method is vulnerable to MITM (man in the middle) attacks in which an attacker can acquire the MS-CHAPv2 hash of the user’s passwords, which can then be subjected to off-line dictionary attacks.

LEAP

LEAP (Lightweight Extensible Authentication Protocol) is an EAP authentication type used primarily in Cisco Aironet WLANs. LEAP supports strong mutual authentication, based upon a modified MS-CHAPv2 challenge/response, between the client and a RADIUS server using a logon password as the shared secret. It provides dynamic per-user, per-session WEP encryption keys. LEAP has been superseded by EAP-FAST due to the public availability of LEAP hash cracking tools such as ASLEAP. There is some disagreement regarding the value of complex password enforcement when using LEAP. When in doubt, use the longest, most complicated passwords that your userbase will agree to.

EAP-MD-5

EAP-MD-5 (Extensible Authentication Protocol-Message Digest) is an EAP authentication type that provides base-level EAP support. EAP-MD5-Tunneled is an EAP protocol designed for use as an inner authentication protocol within a tunneling protocol such as EAP- TTLS or EAP-PEAP. This has additional security features, but has not been widely deployed.

Notes from the Underground—RainbowCrack

Passwords are the most common form of computer authentication today. Password encryption is done using a one-way hashing algorithm such as MD5 or SHA-1. A one-way hash function, also known as a message digest, is a mathematical function that takes a variable-length input string and converts it into a f ixed-length binary sequence that is computationally difficult to invert—that is, generate the original string from the hash. Conventional password crackers grab a word or string of wordlike tokens and run it though the hash algorithm. It then compares its generated hash with the target password hash. If they match, then the password has been discovered. The computationally expensive part of this process is the hash generation preceding the hash comparison, not the actual comparison process itself.

RainbowCrack is a general-purpose implementation of Philippe Oechslin’s faster time-memory trade-off technique. In short, the RainbowCrack tool is an extremely fast and effective hash cracker The simple but brilliant idea of time-memory trade-off is to do all the hash generation computation in advance and store the result in chains of files called “rainbow tables.” It does take a long time to precompute the tables (it takes 2–3 days to generate the rainbow tables necessary to crack a lowercase-letters-only Windows (LM hash) password that’s between 1 and 7 characters in length), but after this one-time computation is finished, a time-memory trade off crarker can crack passwords hundreds or thousands of times faster than a brute force cracker.

Inner Authentication Types

A number of inner authentication methods exist. The most commonly used is MS-CHAP-V2 because it is relatively secure and it is supported natively on all recent Microsoft clients. Additionally, PAP, CHAP, MD5, GTC, and other inner authentication methods exist but are not nearly as commonly used. Interestingly, even EAP itself can be tunneled within EAP.

802.1x/EAP Authentication

2012-01-08T09:09:00.000-08:00

Now we’ll define the terms associated with 802.1x/EAP authentication.

Supplicant (Peer)

This is the other end of the point-to-point link; the end that is being authenticated by the authenticator. Generally this term refers to the client in an EAP exchange.

Authenticator

Authenticator is a wireless access point (AP) or switch (NAS—Network Access Server). The authenticator maintains the network (WLAN or LAN) in closed state to all unauthenticated traffic. It does not do authentication directly, but instead tunnels the extensible authentication protocol (EAP) to an authentication server.

Authentication Server

The authentication server performs the actual client authentication and instructs the authenticator to allow or reject the supplicants traffic. The authentication server is typically a RADIUS server.

Figure 1 illustrates the basic message flow in an 802.1x/EAP authentication scenario. This is an example of the most common 802.1x/EAP model —a Full/Pass-Through state machine, which allows an NAS (network access server) or edge device to pass EAP Response messages to an Authentication Server where the authentication method resides. The NAS does not have to understand the request type and must be able to simply act as a passthrough agent for a back-end server. The NAS need look only for the success/failure code from the Authentication Server to terminate the authentication phase.

Figure 1: Generic EAP Authentication

RADIUS (Remote Authentication Dial In User Service) is an AAA (authentication, authorizaticm, and accounting) protocol for applications such as network access or IP mobility, AAA is a term for a framework that allows methods to intelligently control access to computer resources, enforce policies, audit usage, and provide information necessary to bill for services. Because AAA services often are used to authenticate remote system administrators, availability is critical, and should always be provided by at least a pair of physically separated, dedicated AAA servers that serve as master and backup.

DIAMETER is a new extended AAA protocol that is designed to replace RADIUS, DIAMETER {a play on words, since diameter is twice the radius of a circle) is designed to enhance RADIUS functions and to fix several security problems (such as unencrypted CHAP response) that have plagued RADIUS in recent years.

In step 1, the supplicant (a workstation, wireless access point, IP phone, etc.) sends one or more requests to the NAS petitioning for access to the network. The NAS (step 2) passes the EAP message to the Authentication Server, which is almost always a RADIUS server. In step 3, the Authentication Server requests the credentials of the supplicant and specifies the type of credentials required to confirm the supplicant’s identity. (Note here that the arrows between the RADIUS server and the client indicate logical, not physical, connectivity. All traffic between the two passes through the NAS.) The Authentication Server makes its decision to grant or deny access based upon Native RADIUS credentials. In step 4, the supplicant sends its credentials to the RADIUS server. Upon validating the supplicant’s credentials, the Authentication Server transmits a success/failure message to the NAS (step 5). In step 6, if access is granted, the NAS opens the port to all traffic (as opposed to just EAPOL traffic) and data exchange between the authenticated LAN device and the LAN is allowed. If access is granted, then (step 7) the supplicant is able to access network resources.

You will notice that after access is approved, the supplicant has unrestricted access to network resources. Only the device identity has been authenticated. No authorization has been performed, nor has the user of the device been authenticated.

Figure 2 illustrates a more typical generic 802.1x transaction. The first several steps in this scenario are similar to the scenario we just described. In step 1, the supplicant (a workstation, wireless access point, IP phone, etc) sends one or more requests to the NAS petitioning for access to the network. The NAS (Step 2) passes the EAP message to the Authentication Server, which is almost always a RADIUS server. In step 3, The Authentication Server requests the credentials of the supplicant and specifies the type of credentials required to confirm the supplicant’s identity. (Note here that the arrows between the RADIUS server and the client indicate logical, not physical, connectivity. All traffic between the two passes through the NAS.)

Figure 2: EAP Authentication with Authorization

In step 5 the Authentication Server (RADIUS) forwards the access request to the AD server. The AD server responds with a success or failure message, and if successful, also forwards the client’s AD domain credentials in step 6. Upon validating the supplicant’s credentials, the Authentication Server transmits a success/failure message to the NAS (step 7). In step 8, if access is granted, the NAS opens the port to all traffic. If access is granted, then (step 9) the supplicant is able to access authorized network resources.

In this scenario, administrators can limit user access to specific VLANs, and via Windows permissions, to most network resources. The specifics of authentication and authorization depend upon the type of EAP policy chosen.

802.1x and 802.11i (WPA2)

2012-01-04T07:17:00.000-08:00

The 802.1x protocol defines port-based, network access control that is used to provide authenticated network access (see Figure 1). Although this standard is designed for wired Ethernet networks, it has been adapted for use on 802.11 WLANs. It is simply a standard for passing EAP over a wired or wireless LAN.

Figure 1: EAPOL

802.1x restricts unauthorized clients from connecting to a LAN. The client must first authenticate with an Authentication server, typically a RADIUS server, before the switch port is made available and the network can be accessed. EAP (Extensible Authentication Protocol) is a general authentication protocol that provides a framework for multiple authentication methods, including traditional passwords, token cards, Kerberos, Digital Certificates, and public-key authentication.

WEP (Wireless Equivalent Privacy) has famously been shown to be insecure (Anton Rager’s wepcrack was the first publicly available tool for this—http://wepcrack.source-forge.net/); however WEP protection of wireless connections is still better than no encryption at all. The Wi-Fi Alliance (a consortium of major vendors—http://wi-fi.org/) is responsible for drafting both the WPA (Wi-Fi Protected Access) and WPA2 standards. The Wi-Fi alliance also formed a VoWLAN (Voice over Wireless LAN) working group tasked with developing WMM (Wi-Fi Multimedia) QoS standards for VoIP and other multimedia over wireless networks.

WPA implements a subset of IEEE802.11i, and differs from WEP mainly in that it utilizes TKIP (Temporal Key Integrity protocol) and the EAP framework for authentication. 802.11i is a draft IEEE standard for 802.11 wireless network security. 802.11i, also known as WPA2, uses 802.1x as the authentication mechanism and the Advanced Encryption Standard (AES) block cipher for encryption. WEP and WPA use the RC4 stream cipher. Table 1 shows some of the key features of these three security standards.

Table 1: Security Standard Features
Protocol	Authentication	Cipher	Key Length	Key Management
WEP	None	RC-4	40/104	None
WPA	802.1x/EAP	RC-4	128	802.1x/EAP
WPA2	802.1x/EAP	AES	128	802.1x/EAP

It is helpful to think of 802.1x not as a single protocol but rather as a security frame-work using existing, and proven security standards that serves two critical security func-tions—authentication (PSK or PKI, for example) and encryption (TLS or AES, for example). Note that 802.1x does not define either authentication or encryption methods (in fact 802.1x can be used without encryption); rather these are defined largely through this choice of an EAP type.

Until the client is authenticated via 802.1x/EAP access control, the only protocol allowed through the port to which the client is connected is Extensible Authentication Protocol traffic. After authentication is successful, traffic can pass through the port.

Confirm User Identity | Authentication

2011-12-27T06:30:00.000-08:00

Authentication is a measure of trust. The point of this chapter is to illustrate trust complexities and to cover authentication of both user identity and device identity. These two identities are not equal. Authentication in the networking world, in general, is based either on using a shared secret (you are authenticated if you know the secret) or on public key-based methods with certificates (you prove your identity by possessing the correct private key). Authentication establishes the identities of devices and users to a degree that is in accord with your security policies. Authorization, on the other hand, establishes the amount and type of network and application resources authorized individuals and devices are able to access.

Device authentication can be automated and made transparent to the user based upon assigning and verifying a unique profile for the device. This profile may include attributes such as model, serial number, MAC address, IP address, physical location, time-of-day, and so on, and may include a shared secret or a certificate. Device authentication literally blocks rogue endpoints from accessing any network resources, In a VoIP environment, this prevents malicious endpoints from placing unauthorized calls or causing other mischief. Some of the 802.1x and 802.11i standards described later in this chapter can be used as part of an automated device authentication process.

Everyone who has logged on to a computer is familiar with user authentication. Users identify themselves to an authenticator by presenting credentials. The most common of these is a username/password combination, although user authentication can also be accomplished using other means including biometric or token-based methods. Common network-based authentication methods include Windows domain authentication, NIS+, and Kerberos. Windows 2000 and later platforms offer two default authentication mechanisms: MS Kerberos and NTLM. Most users believe that logging on to an account in a Windows domain gives them access to the network. That is not true. When the Kerberos protocol (the default) is used for network authentication, the user’s first access is to the domain’s authentication service, which ultimately provides access to network resources.

In order to secure VoIP networks, the identity of both the user and the device must be verified. This can be accomplished in a number of ways. Network-based authentication methods such as those mentioned earlier in this chapter often are used, and in many environments, this user authentication is considered sufficient for virtually unrestricted access to network resources. However, network boundaries are disappearing, network users are increasingly mobile, more types and quantities of devices are registering with the network, and devices no longer even require a physical link to access network resources. The addition of VoIP resources to the existing infrastructure only adds to this complexity. The aforementioned mechanisms are not sufficient to cope with these new sophisticated technologies.

Some simple fixes are available. User identity can be confirmed using a method as simple as HTTP Digest authentication, and devices can simply be filtered by MAC address lists. These point solutions have their drawbacks. Both can be circumvented by attackers with minimal skills, and neither scale well. In order to confirm user and device identity on enterprise VoIP networks, system administrators will ultimately turn to 802.1x/EAP, a certificate infrastructure, or a combination of these. The remainder of this chapter discusses these two technologies.

Figure 1 shows the generic components involved in a model authentication scheme. The static beginning and end states are the device and user identities, and internal network access, respectively. The processes are access control and authorization.Exploring these mechanisms.

Figure 1: General Authentication—Authorization Framework

In H.323 environments the basis for authentication (trust) is defined by the endpoints of the communications channel. For a connection establishment channel, this may be between the caller (such as a gateway or IP telephone endpoint) and a hosting network component (a gateway or gatekeeper). For example, a telephone “trusts” that the gatekeeper will connect it with the telephone whose number has been dialed. The result of trusting an element is the confidence to reveal the privacy mechanism (algorithm and key) to that element. Given the aforementioned information, all participants in the communications path should authenticate any and all trusted elements.

The SIP draft does not explicitly define authentication mechanisms. In contrast, SIP developers chose a modular approach—reusing the same headers, error codes, and encoding rules as HTTP. From RFC 3261:

The fundamental security services required for the SIP protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, integrity, and authentication. Rather than defining new security mechanisms specific to SIP, SIP reuses wherever possible existing security models derived from the HTTP and SMTP space.

SIP defines a set of security mechanisms that can be used by any SIP client or server to share authentication data (see Table 1).

Table 1: SIP Security Mechanisms

Since SIP’s syntax is based on HTTP, it reuses HTTP Digest Authentication to authenticate endpoints. S/MIME, TLS, and IPSec can also be used to protect components of the SIP infrastructure. SIP can use TLS for signaling security between routing elements (hop by hop), as well as S/MIME for security of signaling end to end. TLS security is visible to users and other elements by using the “sips:” URI scheme, similar to “https:”.

The threats in this category rely on the absence of cryptographic assurance of a request’s originator. Attacks in this category seek to compromise the message integrity of a conversation and interfere with nonrepudiation. Oftentimes the goal of these attacks is economic or data theft. These threats demonstrate the need for security services that enable entities to authenticate the originators of requests and to verify that the contents of the message and control streams have not been altered in transit.

VoIP Communications Systems Security

2011-12-23T05:58:00.000-08:00

DoS attacks, whether they are intentional or unintended, are the most difficult VoIP-related threat to defend against. The packet switching nature of data networks allows multiple connections to share the same transport medium. Therefore, unlike telephones in circuitswitched networks, an IP terminal endpoint can receive and potentially participate in multiple calls at once. Thus, an endpoint can be used to amplify attacks. On VoIP networks, resources such as bandwidth must be allocated efficiently and fairly to accommodate the maximum number of callers. This property can be violated by attackers who aggressively and abusively obtain an unnecessarily large amount of resources. Alternatively, the attacker simply can flood the network with large number of packets so that resources are unavailable to all other callers.

In addition, viruses and worms create DoS conditions due to the network traffic generated by these agents as they replicate and seek out other hosts to infect. These agents are proven to wreak havoc with even relatively well-secured data networks. VoIP networks, by their nature, are exquisitely sensitive to these types of attacks. Remedies for DoS include logical network partitioning at layers 2 and 3, stateful firewalls with application inspection capabilities, policy enforcement to limit flooded packets, and out-of-band management. Out-of-band management is required so that in the event of a DoS event, system administrators are still able to monitor the network and respond to additional events.

Theft of services and information is also problematic on VoIP networks. These threats are almost always due to active attack. Many of these attacks can be thwarted by implementing additional security controls at layer 2. This includes layer 2 security features such as DHCP Snooping, Dynamic ARP Inspection, IP Source Guard, Port Security, and VLAN ACLs. The fundamental basis for this class of attacks is that the identity of one or more of the devices that participate is not legitimate.

Endpoints must be authenticated, and end users must be validated in order to ensure legitimacy Hijacking and call interception revolves around the concept of fooling and manipulating weak or nonexistent authentication measures. We are all familiar with different forms of authentication, from the password used to login to your computer to the key that unlocks the front door. The conceptual framework for authentication is made up of three factors: “something you have” (a key or token), “something you know” (a password or secret handshake), or “something you are” (fingerprint or iris pattern). Authentication mechanisms validate users by one or a combination of these. Any type of unauthenticated access, particularly to key infrastructure components such as the IP PBX or DNS server, for example, can result in disagreeable consequences for both users and administrators.

VoIP relies upon a number of ancillary services as part of the configuration process, as a means to locate users, manage servers and phones, and to ensure favorable transport, among others. DNS, DHCP, HTTP, HTTPS, SNMP, SSH, RSVP, and TFTP services all have been the subject of successful exploitation by attackers. Potential VoIP users may defer transi tioning to IP Telephony if they believe it will reduce overall network security by creating new vulnerabilities that could be used to compromise non-VoIP systems and services within the same network. Effective mitigation of these threats to common data networks and services could be considered a security baseline upon which a successful VoIP deployment depends. Firewalls, network and system intrusion detection, authentication systems, anti-virus scanners, and other security controls, which should already be in place, are required to counter attacks that might debilitate any or all IP-based services (including VoIP services).

H.323 and SIP suffer security vulnerabilities based simply upon their encoding schemes, albeit for different reasons. Because SIP is an unstructured text-based protocol, it is impossibly to test all permutations of SIP messages during development for security vulnerabilities. Its fairly straightforward to construct a malformed SIP message or message sequence that results in a DoS for a particular SIP device. This may not be significant for a single UA endpoint, but if this “packet of death” can render all the carrier-class media gateway controllers in a network useless, then this becomes a significant problem. H.323 on the other hand is encoded according to ASN.1 PER encoding rules. The implementation of H.323 message parsers, rather than the encoding rules themselves, results in security vulnerabilities in the H.323 suite.

SIP-Specific Attacks

2011-12-20T13:58:00.000-08:00

Multiple vendors have confirmed vulnerabilities in their respective SIP (Session Initiation Protocol) implementations. The vulnerabilities have been identified in the INVITE message used by two SIP endpoints during the initial call setup. The impact of successful exploitation of the vulnerabilities has not been disclosed but potentially could result in a compromise of a vulnerable device. (CERT: CA-2003–06.) In addition, many recent examples of SIP Denial of Service attacks have been reported.

Recent issues that affect Cisco SIP Proxy Server (SPS) [Bug ID CSCec31901] demonstrate the problems SIP implementers may experience due to the highly modular architecture or this protocol. The SSL implementation in SPS (used to secure SIP sessions) is vulnerable to an ASN.1 BER decoding error similar to the one described for H.323 and other protocols. This example illustrates a general concern with SIP: As the SIP protocol links existing protocols and services together, all the classic vulnerabilities in services such as SSL, HTTP, and SMTP may resurface in the VoIP environment.

H.323-Specific Attacks

2011-12-17T17:57:00.000-08:00

The only existing vulnerabilities that we are aware of at this time take advantage of ASN.1 parsing defects in the first phase of H.225 data exchange. More vulnerabilities can be expected for several reasons: the large number of differing vendor implementations, the complex nature of this collection of protocols, problems with the various implementations of ASN.1/PER encoding/decoding, and the fact that these protocols—alone and in concert—have not endured the same level of scrutiny that other more common protocols have been subjected to. For example, we have unpublished data that shows that flooding a gateway or media server with GRQ request packets (RAS registration request packets) results in a DoS against certain vendor gateway implementations—basically the phones deregister.

Call Hijacking and Interception

2011-12-14T07:53:00.000-08:00

Call interception and eavesdropping are other major concerns on VoIP networks. The VOIPSA threat taxonomy (www.voipsa.org/Activities/taxonomy-wiki.php) defines eavesdropping as “a method by which an attacker is able to monitor the entire signaling and/or data stream between two or more VoIP endpoints, but cannot or does not alter the data itself.” Successful call interception is akin to wiretapping in that conversations of others can be stolen, recorded, and replayed without their knowledge. Obviously, an attacker who can intercept and store these data can make use of the data in other ways as well.

A DNS A (or address) record is used for storing a domain or hostname mapping to an IP address. SIP makes extensive use of SRV records to locate SIP services such as SIP proxies and registrars. SRV (service) records normally begin with an underscore (_sip.tcpserver.udp.domain.com) and consist of information describing service, transport, host, and other information. SRV records allow administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.

An attacker’s goal, when attempting a DNS Poisoning or spoofing attack, is to replace valid cached DNS A, SRV, or NS records with records that point to the attacker’s server(s). This can be accomplished in a number of fairly trivial ways—the easiest being to initiate a zone transfer from the attacker’s DNS server to the victim’s misconfigured DNS server, by asking the victim’s DNS server to resolve a networked device within the attacker’s domain, The victim’s DNS server accepts not only the requested record from the attacker’s server, but it also accepts and caches any other records that the attacker’s server includes.

Thus, in addition to the A record for www.attacker.com, the victim DNS server may receive a bogus record for www.yourbank.com. The innocent victim will then be redirected to the attacker.com Web site anytime be or she attempts to browse to the yourbank.com Web site, as long as the bogus records are cached, Substitute a SIP URL for a Web site address, and the same scenario can be repeated in a VoIP environment.

This family of threats relies on the absence of cryptographic assurance of a request’s originator. Attacks in this category seek to compromise the message integrity of a conversation. This threat demonstrates the need for security services that enable entities to authenticate the originators of requests and to verify that the contents of the message and control streams have not been altered in transit.

In the past several years, as host PCs have improved their processing power and their ability to process networked information, network administrators have instituted a hierarchical access structure that consists of a single, dedicated switched link for each host PC to distribution or backbone devices. Each networked user benefits from a more reliable, secure connection with guaranteed bandwidth. The use of a switched infrastructure limits the effectiveness of packet capture tools or protocol analyzers as a means to collect VoIP traffic streams. Networks that are switched to the desktop allow normal users’ computers to monitor only broadcast and unicast traffic that is destined to their particular MAC address. A user’s NIC (network interface card) literally does not see unicast traffic destined for other computers on the network.

The address resolution protocol (ARP) is a method used on IPv4 Ethernet networks to map the IP address (layer 3) to the hardware or MAC (Media Access Control) layer 2 address. (Note that ARP has been replaced in IPv6 by Neighbor Discovery [ND] protocol. The ND protocol is a hybrid of ARP and ICMP) Two classes of hardware addresses exist: the broadcast address of all ones, and a unique 6 byte identifier that is burned into the PROM of every NIC (Network Interface Card).

Figure 1 illustrates a typical ARP address resolution scheme. A host PC (10.1.1.1) that wishes to contact another host (10.1.1.2) on the same subnet issues an ARP broadcast packet (ARPs for the host) containing its own hardware and IP addresses. NICs contain filters that allow them to drop all packets not destined for their unique hardware address or the broadcast address, so all NICs but the query target silently discard the ARP broadcast. The target NIC responds to the query request by unicasting its IP and hardware address, completing the physical to logical mapping, and allowing communications to proceed at layer 3.

Figure 1: Typical ARP Request/Reply

To minimize broadcast traffic, many devices cache ARP addresses for a varying amount of tirne:The default ARP cache timeout for Linux is one minute; for Windows NT, two minutes, and for Cisco routers, four hours. This value can be trivially modified in most sys-tems. The ARP cache is a table structure that contains IP address, hardware address, and oftentimes, the name of the interface the MAC address is discovered on, the type of media, and the type of ARP response. Depending upon the operating system, the ARP cache may or may not contain an entry for its own addresses.

In Figure 2, Sams ARP cache contains one entry prior to the ARP request/response:

Internet Address	Physical Address
10.1.1.1	AA:BB:CC:DD:EE:FF	int0

After the ARP request/response completes, Sam’s ARP cache now contains two entries:

Internet Address	Physical Address
10.1.1.1	AA:BB:CC:DD:EE:FF	int0
10.1.1.2	AA:BB:CC:DD:EE:00	int0

Note that Sally’s ARP cache, as a result of the request/response communications, is updated with the hardware:IP mappings for both workstations as well.

ARP Spoofing

ARP is a fundamental Ethernet protocol. Perhaps for this reason, manipulation of ARP packets is a potent and frequent attack mechanism on VoIP networks. Most network administrators assume that deploying a fully switched network to the desktop prevents the ability of network users to sniff network traffic and potentially capture sensitive information traversing the network. Unfortunately several techniques and tools exist that allow any user to sniff traffic on a switched network because ARP has no provision for authenticating queries or query replies. Additionally, because ARP is a stateless protocol, most operating systems (Solaris is an exception) update their cache when receiving ARP reply, regardless of whether they have sent out an actual request.

Among these techniques, ARP redirection, ARP spoofing, ARP hijacking, and ARP cache poisoning are related methods for disrupting the normal ARP process. These terms frequently are interchanged and confused. For the purpose of this section, we’ll refer to ARP cache poisoning and ARP spoofing as the same process. Using freely available tools such as ettercap, Cain, and dsniff, an evil IP device can spoof a normal IP device by sending unsolicited ARP replies to a target host. The bogus ARP reply contains the hardware address of the normal device and the IP address of the malicious device. This “poisons” the host’s ARP cache (see Figure 2).

Figure 2: ARP Spoofing (Cache Poisoning)

In Figure 2, Ned is the attacking computer. When SAM broadcasts an ARP query for Sally’s IP address, Ned, the attacker, responds to the query stating that the IP address (10.1.1.2) belongs to Ned’s MAC address, BA:DB:AD:BA:DB:AD. Packets sent from Sam supposedly to Sally will be sent to Ned instead. Sam will mistakenly assume that Ned’s MAC address corresponds to Sally’s IP address and will direct all traffic destined for that IP address to Ned’s MAC. In fact, Ned can poison Sam’s ARP cache without waiting for an ARP query since on Windows systems (9x/NT/2K), static ARP entries are overwritten whenever a query response is received regardless of whether or not a query was issued.

Sam’s ARP cache now looks like this:

Internet Address	Physical Address
10.1.1.1	AA:BB:CC:DD:EE:FF	int0
10.1.1.2	BA:DB:AD:BA:DB:AD	int0

This entry will remain until it ages out or a new entry replaces it.

ARP redirection can work bidirectionally, and a spoofing device can insert itself in the middle of a conversation between two IP devices on a switched network (see Figure 3). This is probably the most insidious ARP-related attack. By routing packets on to the devices that should truly be receiving the packets, this insertion (known as a Man/Monkey/Moron in the Middle attack) can remain undetected for some time. An attacker can route packets to /dev/null (nowhere) as well, resulting in a DoS attack.

Figure 3: An ARP MITM Attack

Sam’s ARP cache:

Internet Address	Physical Address
10.1.1.1	AA:BB:CC:DD:EE:FF	int0
10.1.1.2	BA:DB:AD:BA:DB:AD	int0

Sally’s ARP cache:

Internet Address	Physical Address
10.1.1.1	BA:DB:AD:BA:DB:AD	int0
10.1.1.2	AA:BB:CC:DD:EE:00	int0

As all IP traffic between the true sender and receiver now passes through the attacker’s device, it is trivial for the attacker to sniff that traffic using freely available tools such as Ethereal or tcpdump. Any unencrypted information (including e-mails, usernames and passwords, and web traffic) can be intercepted and viewed.

This interception has potentially drastic implications for VoIP traffic. Freely available tools such as vomit and rtpsniff, as well as private tools such as VoipCrack, allow for the interception and decoding of VoIP traffic. Captured content can include speech, signaling and billing information, multimedia, and PIN numbers. Voice conversations traversing the internal IP network can be intercepted and recorded using this technique.

There are a number of variations of the aforementioned techniques. Instead of imitating a host, the attacker can emulate a gateway. This enables the attacker to intercept numerous packet streams. However, most ARP redirection techniques rely on stealth. The attacker in these scenarios hopes to remain undetected by the users being impersonated. Posing as a gateway may result in alerting users to the attacker’s presence due to unanticipated glitches in the network, because frequently switches behave in unexpected ways when attackers manipulate ARP processes. One unintended (much of the time) consequence of these attacks, particularly when switches are heavily loaded, is that the switch CAM (Content-Addressable Memory) table—a finite-sized IP address to MAC address lookup table—becomes disrupted. This leads to the switch forwarding unicast packets out many ports in unpredictable fashion. Penetration testers may want to keep this in mind when using these techniques on production networks.

In order to limit damage due to ARP manipulation, administrators should implement software tools that monitor MAC to IP address mappings. The freeware tool, Arpwatch, monitors these pairings. At the network level, MAC/IP address mappings can be statically coded on the switch; however, this is often administratively untenable. Dynamic ARP Inspection (DAI) is available on newer Cisco Catalyst 6500 switches. DAI is part of Cisco’s Integrated Security (CIS) functionality and is designed to prevent several layer two and layer three spoofing attacks, including ARP redirection attacks. Note that DAI and CIS are available only on Catalyst switches using native mode (Cisco IOS).

The potential risks of decoding intercepted VoIP traffic can be eliminated by implementing encryption. Avaya’s Media Encryption feature is an example of this. Using Media Encryption, VoIP conversations between two IP endpoints are encrypted using AES encryption. In highly secure environments, organizations should ensure that Media Encryption is enabled on all IP codec sets in use.

DAI enforces authorized MAC-to-IP address mappings. Media Encryption renders traffic, even if intercepted, unintelligible to an attacker.

The following are some additional examples of call or signal interception and hijacking. This class of threats, though typically more difficult to accomplish than DoS, can result in significant loss or alteration of data. DoS attacks, whether caused by active methods or inadvertently, although important in terms of quality of service, are more often than not irritating to users and administrators. Interception and hijacking attacks, on the other hand, are almost always active attacks with theft of service, information, or money as the goal. Note that this list is not exhaustive but illustrates some attack scenarios.

Rogue VoIP Endpoint Attack Rogue IP endpoint contacts VoIP server by leveraging stolen or guessed identities, credentials, and network access. For example, a rogue endpoint can use an unprotected wall jack and auto-registration of VOIP phones to get onto the network. RAS password guessing can be used to masquerade as a legitimate endpoint. Lax account maintenance (expired user accounts left active) increases risk of exploitation.
Registration Hijacking Registration hijacking occurs when an attacker imper-sonates a valid UA to a registrar and replaces the registration with its own address. This attack causes all incoming calls to be sent to the attacker.
Proxy Impersonation Proxy impersonation occurs when an attacker tricks a SIP UA or proxy into communicating with a rogue proxy. If an attacker successfully impersonates a proxy, he or she has access to all SIP messages.
Toll Fraud Rogue or legitimate VoIP endpoint uses a VoIP server to place unauthorized toll calls over the PSTN. For example, inadequate access controls can let rogue devices place toll calls by sending VoIP requests to call processing applications. VoIP servers can be hacked into in order to make free calls to outside destinations. Social engineering can be used to obtain outside line prefixes.
Message Tampering Capture, modify, and relay unauthenticated VoIP packets to/from endpoints. For example, a rogue 802.11 AP can exchange frames sent or received by wireless endpoints if no payload integrity check (e.g., WPA MIC, SRTP) is used. Alternatively, these attacks can occur through registration hijacking, proxy impersonation, or an attack on any component trusted to process SIP or H.323 messages, such as the proxy, registration servers, media gateways, or firewalls. These represent non-ARP-based MITM attacks.
VoIP Protocol Implementation Attacks Send VoIP servers or endpoints invalid packets to exploit VoIP protocol implementation CVEs. Such attacks can lead to escalation of privileges, installation and operation of malicious programs, and system compromise. For example, CAN-2004–0054 exploits Cisco IOS H.323 implementation CVEs to execute arbitrary code. CSCed33037 uses unsecured IBM Director agent ports to gain administrative control over IBM servers running Cisco VoIP products.

Notes from the Underground—ANI/Caller-ID Spoofing

Caller ID is a service provided by most telephone companies (for a monthly cost) that will tell you the name and number of an incoming call. Automatic Number Identification (ANI) is a system used by the telephone company to determine the number of the calling party. To spoof Caller-ID, an attacker sends modem tones over a POTS lines between rings 1 and 2. ANI spoofing is setting the ANI so as to send incorrect ANI information to the PSTN so that the resulting Caller-ID is misleading. Traditionally this has been a complicated process either requiring the assistance of a cooperative phone company operator or an expensive company PBX system.

In ANI/Caller-ID spoofing, an evildoer hijacks phone number and the identity of a trusted party, such as a bank or a government office. The identity appears on the caller ID box of an unsuspecting victim, with the caller hoping to co-opt valuable information, such as account numbers, or otherwise engage in malicious mischief. This is not a VoIP issue, per se. In fact, one of the big drawbacks about VoIP trunks is their inability to send ANI properly because of incomplete standards.

Denial-of-Service or VoIP Service Disruption

2011-12-10T09:49:00.000-08:00

Denial-of-service (DoS) attacks can affect any IP-based network service. The impact of a DoS attack can range from mild service degradation to complete loss of service. There are several classes of DoS attacks. One type of attack in which packets can simply be flooded into or at the target network from multiple external sources is called a distributed denial-ofservice (DDoS) attack (see Figures 1 and 2).

Figure 1: Typical Internet Access

Figure 2: A Distributed Denial-of-Service Attack

In this figure, traffic flows normally between internal and external hosts and servers. In Figure 2, a network of computers (e.g., a botnet) directs IP traffic at the interface of the firewall.

The second large class of Denial of Service (DoS) conditions occurs when devices within the internal network are targeted by a flood of packets so that they fail—taking out related parts of the infrastructure with them. As in the DdoS scenarios described earlier in this chapter, service disruption occurs to resource depletion—primarily bandwidth and CPU resource starvation (see Figure 3). For example, some IP telephones will stop working if they receive a UDP packet larger than 65534 bytes on port 5060.

Figure 3: An Internal Denial-of-Service Attack

Neither integrity checks nor encryption can prevent these attacks. DoS or DDoS attacks are characterized simply by the volume of packets sent toward the victim computer; whether those packets are signed by a server, contain real or spoofed source IP addresses, or are encrypted with a fictitious key—none of these are relevant to the attack.

DoS attacks are difficult to defend against, and because VoIP is just another IP network service, it is just as susceptible to DoS attack as any other IP network services. Additionally, DoS attacks are particularly effective against services such as VoIP and other real-time services, because these services are most sensitive to adverse network status. Viruses and worms are included in this category as they often cause DoS or DDoS due to the increased network traffic that they generate as part of their efforts to replicate and propagate.

How do we defend against these DoS conditions (we won’t use the term attack here because some DoS conditions are simply the unintended result of other unrelated actions)? Let’s begin with internal DoS. Note in Figure 3 that VLAN 10 on the right is not affected by the service disruption on the left in VLAN 2. This illustrates one critical weapon the security administrator has in thwarting DoS conditions—logical segregation of network domains in separate compartments. Each compartment can be configured to be relatively immune to the results of DoS in the others.

Point solutions will also be effective in limiting the consequences of DoS conditions. For example, because strong authentication is seldom used in VoIP environments, the message processing components must trust and process messages from possible attackers. The additional processing of bogus messages exhausts server resources and leads to a DoS. SIP or H.323 Registration Flooding is an example of this, described in the list of DoS threats, later. In that case, message processing servers can mitigate this specific threat by limiting the number of registrations it will accept per minute for a particular address (and/or from a specific IP address). An intrusion prevention system (IPS) may be useful in fending off certain types of DoS attacks. These devices sit on the datapath and monitor passing traffic. When anomalous traffic is detected (either by matching against a database of attack signatures or by matching the results of an anomaly-detection algorithm) the IPS blocks the suspicious traffic. One problem I have seen with these devices—particularly in environments with high availability requirements—is that they sometimes block normal traffic, thus creating their own type of DoS.

Additionally, security administrators can minimize the chances of DoS by ensuring that IP telephones and servers are updated to the latest stable version and release. Typically, when a DoS warning is announced by bugtraq, the vendor quickly responds by fixing the offending software.

Note

VoIP endpoints can be infected with new VoIP device or protocol-specific viruses. WinCE, PalmOS, SymbianOS, and POSIX-based softphones are especially vulnerable because they typically do not run antivirus software and have less robust operating systems. Several Symbian worms already have been detected in the wild. Infected VoIP devices then create a new “weak link” vector for attacking other network resources.

Compromised devices can be used to launch attacks against other systems in the same network, particularly if the compromised device is trusted (i.e., inside the firewall). Malicious programs installed by an attacker on compromised devices can capture user input, capture traffic, and relay user data over a “back channel” to the attacker. This is especially worrisome for softphone users.

VoIP systems must meet stringent service availability requirements. Following are some example DoS threats can cause the VoIP service to be partially or entirely unavailable by preventing successful call placement (including emergency/911), disconnecting existing calls, or preventing use of related services like voicemail. Note that this list is not exhaustive but illustrates some attack scenarios.

TLS Connection Reset It’s not hard to force a connection reset on a TLS connection (often used for signaling security between phones and gateways)—just send the right kind of junk packet and the TLS connection will be reset, interrupting the signaling channel between the phone and call server.
VoIP Packet Replay Attack Capture and resend out-of-sequence VoIP packets (e.g., RTP SSRC—SSRC is an RTP header field that stands for Synchronization Source) to endpoints, adding delay to call in progress and degrading call quality.
Data Tunneling Not exactly an attack; rather tunneling data through voice calls creates, essentially, a new form of unauthorized modem. By transporting modem signals through a packet network by using pulse code modulation (PCM) encoded packets or by residing within header information, VoIP can be used to support a modem call over an IP network. This technique may be used to bypass or undermine a desktop modem policy and hide the existence of unauthorized data connections. This is similar in concept to the so-called “IP over HTTP” threat (i.e., “Firewall Enhancement Protocol” RFC 3093)—a classic problem for any ports opened on a firewall from internal sources.
QoS Modification Attack Modify non-VoIP-specific protocol control information fields in VoIP data packets to and from endpoints to degrade or deny voice service. For example, if an attacker were to change 802.1Q VLAN tag or IP packet ToS bits, either as a man-in-the-middle or by compromising endpoint device configuration, the attacker could disrupt the quality of service “engineered” for a VoIP network. By subordinating voice traffic to data traffic, for example, the attacker might substantially delay delivery of voice packets.
VoIP Packet Injection Send forged VoIP packets to endpoints, injecting speech or noise or gaps into active call. For example, when RTP is used without authentication of RTCP packets (and without SSRC sampling), an attacker can inject RTCP packets into a multicast group, each with a different SSRC, which can grow the group size exponentially.
DoS against Supplementary Services Initiate a DoS attack against other network services upon which the VoIP service depends (e.g., DHCP, DNS, BOOTP). For example, in networks where VoIP endpoints rely on DHCP-assigned addresses, disabling the DHCP server prevents endpoints (soft- and hardphones) from acquiring addressing and routing information they need to make use of the VoIP service.
Control Packet Flood Flood VoIP servers or endpoints with unauthenticated call control packets, (e.g., H.323 GRQ, RRQ, URQ packets sent to UDP/1719). The attacker’s intent is to deplete/exhaust device, system, or network resources to the extent that VoIP service is unusable. Any open administrative and maintenance port on call processing and VoIP-related servers can be a target for this DoS attack.
Wireless DoS Initiate a DoS attack against wireless VoIP endpoints by sending 802.11 or 802.1X frames that cause network disconnection (e.g., 802.11 Deauthenticate flood, 802. 1X EAP-Failure, WPA MIC attack, radio spectrum jam-ming). For example, a Message Integrity Code attack exploits a standard countermeasure whereby a wireless access point disassociates stations when it receives two invalid frames within 60 seconds, causing loss of network connectivity for 60 seconds. In a VoIP environment, a 60-second service interruption is rather extreme.
Bogus Message DoS Send VoIP servers or endpoints valid-but-forged VoIP protocol packets to cause call disconnection or busy condition (e.g., RTP SSRC collision, forged RTCP BYE, forged CCMS, spoofed endpoint button push). Such attacks cause the phone to process a bogus message and incorrectly terminate a call, or mislead a calling party into believing the called party’s line is busy.
Invalid Packet DoS Send VoIP servers or endpoints invalid packets that exploit device OS and TCP/IP implementation denial-of-service CVEs. For example, the exploit described in CAN-2002–0880 crashes Cisco IP phones using jolt,jolt2, and other common fragmentation-based DoS attack methods. CAN-2002–0835 crashes certain VoIP phones by exploiting DHCP DoS CVEs. Avaya IP phones may be vulnerable to port zero attacks.
Immature Software DoS PDA/handheld softphones and first generation VoIP hardphones are especially vulnerable because they are not as mature or intensely scrutinized. VoIP call servers and IP PBXs also run on OS platforms with many known CVEs. Any open administrative/maintenance port (e.g., HTTP, SNMP, Telnet) or vulnerable interface (e.g., XML, Java) can become an attack vector.
VoIP Protocol Implementation DoS Send VoIP servers or endpoints invalid packets to exploit a VoIP protocol implementation vulnerability to a DoS attack. Several such exploits are identified in the MITRE CVE database (http://cve.mitre.org). For example, CVE-2001–00546 uses malformed H.323 packets to exploit Windows ISA memory leak and exhaust resources. CAN-2004–0056 uses malformed H.323 packets to exploit Nortel BCM DoS vulnerabilities. Lax software update practices (failure to install CVE patches) exacerbate risk.
Packet of Death DoS Flood VoIP servers or endpoints with random TCP, UDP, or ICMP packets or fragments to exhaust device CPU, bandwidth, TCP sessions, and so on. For example, an attacker can initiate a TCP Out of Band DoS attack by sending a large volume of TCP packets marked “priority delivery” (the TCP Urgent flag). During any flood, increased processing load interferes with the receiving system’s ability to process real traffic, initially delaying voice traffic processing but ultimately disrupting service entirely.
IP Phone Flood DoS Send a very large volume of call data toward a single VoIP endpoint to exhaust that device’s CPU, bandwidth, TCP sessions, and so on. Interactive voice response systems, telephony gateways, conferencing servers, and voicemail systems are able to generate more call data than a single endpoint can handle and so could be leveraged to flood an endpoint.

Threats to VoIP Communications Systems

2011-12-07T00:00:00.000-08:00

Converging voice and data on the same wire, regardless of the protocols used, ups the ante for network security engineers and managers. One consequence of this convergence is that in the event of a major network attack, the organizations entire telecommunications infrastructure can be at risk. Securing the whole VoIP infrastructure requires planning, analysis, and detailed knowledge about the specifics of the implementation you choose to use.

Table 1 describes the general levels that can be attacked in a VoIP infrastructure.

Table 1: VoIP Vulnerabilities
Vulnerability	Description
IP infrastructure	Vulnerabilities on related non-VoIP systems can lead to compromise of VoIP infrastructure.
Underlying operating system	VoIP devices inherit the same vulnerabilities as the operating system or firmware they run on. Operating systems are Windows and Linux.
Configuration	In their default configuration most VoIP devices ship with a surfeit of open services. The default services running on the open ports may be vulnerable to DoS attacks, buffer overflows, or authentication bypass.
Application level	Immature technologies can be attacked to disrupt or manipulate service. Legacy applications (DNS, for example) have known problems.

Skinny/SCCP

2011-11-27T07:59:00.000-08:00

The Skinny protocol is the casual name for a complex, lightweight VoIP protocol signaling scheme owned by Cisco Systems, Inc., and is in use for all VoIP telephones that Cisco produces. The formal name is SCCP, for Skinny Client Control Protocol, and was originally designed by the Selsius Corporation, which Cisco acquired. Skinny is a proprietary protocol that allows “skinny clients”, such as Cisco IP telephones, to communicate with each other via Cisco CallManager (CCM). The Skinny clients are small, user-friendly devices that work in conjunction with a CCM. The CCM also acts as a proxy to relay communications to H.323 clients and the PSTN.

Skinny Specifications

Skinny (SCCP) is the exclusive protocol used by Cisco brand IP telephones, as well as some phones developed by other manufacturers. Using the Skinny protocol, an IP phone will use normal TCP/IP to communicate with the Cisco CallManager. If the Cisco phone needs to communicate with a non-Skinny client, then the CCM acts as a proxy gateway, allowing the two to communicate, at which time the phones will start using UDP. However, when a Skinny phone wishes to communicate with another Skinny phone, the two will use RTP/UDP packets for communication.

Skinny Operation

The ability for Skinny clients to communicate with each other is governed by the Cisco CallManager (CCM) on the same network. When an IP phone wishes to dial another on the same network, the user takes the phone off-hook and begins dialing the necessary numbers. As the numbers are entered, they are transmitted to the CCM over TCP packets. The CCM performs a “digit analysis” to determine if they match another phone number in the database. If so, the CCM communicates with the receiving phone, causing it to start ringing and to send a ring back to the calling phone. Once the second phone goes off-hook, the CCM sends packets to both phones requesting their IP address and open UDP port on which to accept the RTP media. The CCM also checks the media capabilities of each phone to determine if they can directly communicate with each other, or if a transcoder is required to allow the communication. Once the CCM has received the connection information from each phone, it proceeds to transmit the information to the other phone, so that each phone has the connection information of its peer. At this point, the CCM creates an RTP/UDP channel for the phones to pass data through for communication. Once either of the phones goes on-hook and disconnects the line, the CCM terminates the channel. An example of this connection process is shown in Figure 1.

Figure 1: The Skinny Client Communication Process

Security Implications for Skinny

Similar in implications to the other protocols discussed previously, the largest problem with the Skinny (SCCP) protocol is the fact that all traffic that uses it is sent in the clear, with no encryption taking place unless the device is capable and configured to support Transport Layer Security (TLS). Ultimately, this means that people with malicious intent on the same network segment are able to capture the traffic using a network sniffer. This allows such people to store recorded conversations, or to even capture the numbers that a particular phone dials during a time period.

Note

While the SCCP/Skinny protocol was not designed for the transfer of secure data, some protocols are. Cisco CallManager 4.0 introduced Secure SCCP, or simply “Secure Skinny” to add beefier security to a Cisco VoIP network. Secure SCCP encrypts all data between IP telephones and the Cisco CallManager using TLS.

Certain Cisco CallManager versions also suffer from a known vulnerability. This vulnerability takes advantage of malformed SCCP packets sent to a vulnerable Cisco IOS (internal operating system). If successful, the exploit is able to cause devices, or the entire CCM, to reboot. The issue is documented as Cisco bug ID CSCee08584, and can be fixed by upgrading or migrating the IOS of the affected hardware.

Session Description Protocol

2011-11-23T04:32:00.000-08:00

SDP

SDP, short for Session Description Protocol, is a simple protocol that allows clients to share information about a multimedia stream to clients wishing to connect. Further extensions on the protocol also allow clients to share their multimedia abilities with other devices. As its name denotes, it is used primarily to describe a client’s session abilities. It plays an integral part in VoIP communications to share the fact that a communication session is taking place, and to provide information to other clients so that they have the ability to join and interact with the session, such as with a group teleconference.

SDP was first described in RFC 2327 in April 1998, and the original RFC still defines the protocol’s basic abilities today. There are updates, though, to the RFC, such as RFC 3266, which adds IPv6 support to SDP. Other associated RFCs include the RTCP attribute in SDP (RFC 3605), TCP-Based Media Transport in SDP (RFC 4145) and PSTN/Internet Interworking (PINT), a set of extensions to SIP and SDP for IP Access to Telephone Call Services (RFC 2848). A fairly recent RFC, RFC 3407, allowed the clients the ability to share their multimedia abilities to other devices.

SDP Specifications

SDP is used as a specification protocol, not as an actual transport protocol (or even a session negotiation protocol, although higher-level protocols like SIP may add that capability above it). In other words, SDP does not actually transfer data between clients, it just establishes a structure for communicating the attributes for those data streams. The data must be transferred using another transport protocol, such as SAP, SIP, RTSP, or HTTP. The information contained within an SDP packet is in ASCII text, and although it was not designed for human readability, it is easy to decipher. An SDP packet is broken into multiple lines of text, where each line represents a single field and its corresponding value. Common data fields include

v (Protocol Version)
o (Owner of session, Session ID, Session Version, Network Type, Address type, and Owner’s IP Address)
s (Session name)
i (Session description)
u (URI of subject material)
e (E-mail address of Session Point of Contact)
p (Phone number of Session Point of Contact)
c (Connection information: IP version and CIDR IP address)
e (Encryption key as clear text, base64, uri, or prompt)
m (Media type, connection port, transport method, and format list)
t (Session begin and end times)
a (Attribute)

The following is an example of SDP data for supplying capabilities:

v=0
o=bsmith 2208988800 2208988800 IN IP4 68.33.152.147
s=-
e=bsmith@foo.com
c=IN IP4 20.1.25.50
t=0 0
a=recvonly
m=audio 0 RTP/AVP 0 1 101
a=rtpmap:0 PCMU/8000
a=rtpmap:1 GSM/8000
a=rtpmap:101 telephone-event/8000

SDP Operation

Once a device has been queried, usually by a client sending an SIP request, it forms an SDP packet to send back. This SDP packet supplies all of the critical information about the session capabilities that the device offers. In its simplest form, this data contains the owner information, the audio and video codecs supported, and which ports connections are accepted on. In queries for particular sessions, the reply contains the session name, the session description, connection ports, and the range of time when the session will be active. All time stamps in SDP data are formed using Network Time Protocol (NTP) values. Additionally, the session ID and session version, which must be unique values, are generally created using NTP values to signify the current date and time.

Much of the current SDP usage is documented in RFC 4317, which describes the SDP Offer/Answer model. In this model, when a client wishes to communicate with another, it transmits an SDP offer packet. This packet is arranged in a structure similar to the following example, provided by RFC 4317:

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

Reading through this packet, you can see that the owner line describes that the packet sender is “alice” who is listening for connections on host.atlanta.example.com. his data is sent to the person with whom she wishes to communicate. Once the other person has received the data and wishes to continue the connection, an answer packet is returned. Here is an example of this answer:

v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49170 RTP/AVP 32
a=rtpmap:32 MPV/90000

In this example, Alice is initiating a connection with Bob. Alice’s Offer packet identifies that she supports three types of audio connections (PCMU, PCMIA, and iLBC), as well as two types of video connections (H.261 and MPV). Once Bob’s client has received the invitation and parsed the values, it chooses a compatible audio and video format and responds back.

Security Implications for SDP

Similar to the security issues of RSVP, much of the security implications for SDP arise due to the fact that a person can easily read session IDs and connection information off of a net work segment and then tamper with existing communications. In seeing existing connection offers, and their corresponding SDP replies, an eavesdropper could use the information to determine devices that are allowing VoIP communications, and also spoof his way into an existing communication. An attacker may also be able to collect SDP offers and replay them at a later time, overriding values for ongoing communications, with the potential to disable audio feeds. However, nearly all security issues with SDP can be solved by using protocols to handle user authentication, such as SIP.

RSVP | Support Protocols

2011-11-18T05:55:00.000-08:00

RSVP, short for the Resource ReSerVation Protocol, is a protocol designed to allow clients on networks to negotiate bandwidth to provide and maintain a high Quality of Service (QoS) for a specific connection. Normally, TCP/IP will make a best effort to route packets from one machine to another as quickly as possible. However, due to the dynamic routing of internetworking, where packets take completely different routes each time they are transmitted, this cannot be guaranteed. This creates a special issue for VoIP communication, which requires a high QoS to maintain seamless and non-interruptive communication between two people. VoIP can be an especially demanding protocol that requires long periods of high bandwidth and low latency, and without RSVP, these conditions may fall below acceptable levels which could result in a loss of quality or disconnections. RSVP allows a dedicated path across a network between each client so that packets are routed randomly around, which retains a high level of bandwidth, and less latency RSVP is especially useful for WAN connections within a global organization to maintain these set paths inside a network, as many Internet routers do not support the protocol.

The RSVP protocol was first described in RFC 2205 in late 1997. Further modifications were made to this RFC, and the best current practices for the RSVP protocol are now discussed in RFC 3936, created in late 2004. There are also other RFCs that describe additional extensions and uses for the RSVP protocol. These include RSVP for LSP Tunnels (RFC 3209) and RSVP security properties (RFC 4230).

RSVP Protocol

The RSVP protocol works by transferring UDP packets from the recipient of the data transfer to its sender. This allows the data recipient to control whether to use regular TCP/IP or to use a dedicated path of travel between the two clients. The connection recipient initiates this path by sending a constructed RSVP packet to the connection initiator. This packet will contain a specific Message Type that indicates the action that should be acted upon. The common Message Types for an RSVP protocol are

Path
Resv (Reservation Request)
PathErr (Path Error)
ResvErr (Reservation Error)
PathTear (Path Teardown)
ResvTear (Reservation Teardown)
ResvConf (Reservation Confirmation)

The RSVP packet also carries a data payload containing specific information on how the path should be constructed. The payload contains information such as:

Session (Destination IP, Tunnel ID, Extended Tunnel ID)
Hop (the neighboring router’s IP)
Time Values (the refresh interval)
Explicit Route (a list of routers between the two devices that creates the data path)
Adspec (specifies the minimum path latency, MTU, and bandwidth requirements)

RSVP Operation

To create a dedicated path of travel, the RSVP protocol relies heavily on its Path and Resv messages. The Path message packet is used to define the path of routers to be used for communication between the two clients. This packet is sent from the receiving end of the communication towards the sender. As it passes through each individual router, the router examines the packet to determine its neighboring IP addresses, to which it must route packets to. The Resv message, or Reservation request, is equally important. The Resv message is sent from each router to its neighboring router, one hop at a time. The Resv packet helps create the reservation on each router involved in the path. The transfer of Path and Resv packets is detailed in Figure 1.

Figure 1: Creating an RSVP Path

Once a path has been created, with each router maintaining a reservation for the data, it must be updated routinely to remain open. If a router has not received a Resv and Path packet before the refresh interval on the path has been exhausted, then the router will remove the reservation from itself. As Resv and Path packets arrive to maintain the reservation, they may also make changes to it. If the path between the clients is to change to substitute routers, the recipient just sends a new Path message with the updated path and it will become effective. Each router will continually update its stored information based on the packets it continually receives during the transmission.

Once the communication between the two devices has ended, they initiate a teardown of the path. Although, realistically they could just stop transmitting RSVP packets and eventually the reservations on the routers would expire, it is recommended that they formally tear down the path immediately after finishing the connection. The teardown may be initiated by either side of the communication, or from any of the routers within the communication. A PathTear packet may be sent downstream from the sender, or a ResvTear may be sent upstream from the receiver. As each router in the path receives a teardown packet, they will immediately remove the path reservation and forward the packet onto the next hop in the path.

Security Implications for RSVP

Many of the security issues with the RSVP protocol involve actions that a person with malicious intentions could take to either disrupt traffic or capture it. For one, as the Path and Resc packets are transmitted across the network, they each include a session ID that can be used to uniquely identify a particular RSVP session. This data is also sent as clear text, where anyone who is armed with a network sniffer can capture the data. Knowing the session ID, a person could then use the same session ID and send a Path message to one of the routers in the path. This new Path could alter the path of the network, leading the network transmission to a completely different client than intended. Or, it could be used to disrupt the communication completely, preventing an RSVP connection to take place between the two devices.

There are various solutions that have come about to resolve issues like this. For one, the Session ID could be encoded into a public key that will be included in each packet, as well as a timestamp that acts as a digital signature. If the two devices are within the same localized network, a third-party server could be used to establish the identities of each device. Many such security implications and solutions were drafted by various authors, including Hannes Tschofenig, in an Internet Draft located atwww.tschofenig.com/drafts/draft-ietf-nsis-rsvpsec-properties-06.txt.

DHCP | Support Protocols

2011-11-15T06:13:00.000-08:00

The Dynamic Host Configuration Protocol (DHCP) is a protocol that was designed to allow network configuration of clients and workstations. Every workstation and device that is making use of a network must be assigned a unique IP address, as well as assigned a subnet mask and gateway IP address. In a network environment where there are hundreds, or thousands, of workstations, this could become an administrative nightmare. DHCP is a popular answer to this problem, automatically assigning IP addresses and other relevant configuration information to each individual device as it comes online.

DHCP is a critical support protocol in the VoIP world because it allows VoIP phones and devices to be portable from one network to another. Instead of manually configuring the device after plugging it into each network, the device simply “pings” the network to find an existing DHCP server. The device then automatically receives an IP address and network details from the server and is then immediately useable on the network, without any interaction with the user.

The DHCP protocol was first discussed in RFC 1531 and RFC 1541 in 1993. Currently, RFC 2131 describes DHCP, and has made the previous RFCs obsolete. There are many RFCs that describe additional extensions and uses for DHCP, though—for example, DHCP for IEEE 1394 (RFC 2855) and DHCP for SIP servers (RFC 3361).

DHCP Protocol

The primary function of DHCP is to supply critical network information to clients automatically, to reduce the effort of a network administrator in manually configuring various devices on a network. For DHCP to work, there must be a DHCP server (or relay) running on the network segment where clients will be connecting. The DHCP server listens con stantly for incoming UDP packets on port 67, a port reserved for DHCP usage. When a new, DHCP-enabled device is connected to the network, it sends a broadcast packet to detect any running DHCP servers. The DHCP server then responds with a DHCP offer, which contains an assigned IP address.

Eight types of packets are used within the DHCP protocol:

Discover
Offer
Request
Decline
ACK
NAK
Release
Inform

DHCP Operation

When a client first joins a network, either by being plugged into the network segment or by being powered on, it does not have an IP address assigned to it. In order to request one, it sends a DHCP Discover packet across the network. It does so by sending a packet from IP address 0.0.0.0 to the broadcast IP address 255.255.255.255, which allows the packet to reach every single device on the network segment. This packet may include information about the client itself, such as the network interface’s MAC address and the computer’s designated host name.

Once a server has received a DHCP Discover packet, it immediately checks its preset range (scope) of IP addresses to determine the next available number. Optionally, the DHCP server will also compare the requestor’s MAC address against a local table to determine if the client is allowed to receive an IP address. After an address has been chosen, a DHCP Offer packet is transmitted back to the requesting client, targeted by its MAC address. This packet includes the assigned IP address, the lease time of the IP address, subnet mask, gateway address, and chosen DNS servers, as well as other network information that is to be implemented into the client.

Once the client has received a DHCP Offer packet, it responds with a DHCP Request packet. This packet is similar to the original DHCP Discover packet in that it is sent from 0.0.0.0 to 255.255.255.255. This packet serves to notify the server that the client has accepted the assigned IP address, and also notifies all other clients on the network segment that the assigned IP address has been taken. Finally, the server responds back to the client with a DHCP Acknowledgement (ACK) to confirm the address has Request has been received. This communication between the client and DHCP server is detailed in Figure 1.

Figure 1: The DHCP Process

Security Implications for DHCP

A variety of security concerns come into play whenever DHCP is enabled on a network segment. These security issues don’t deal so much with leaked data such as passwords. Instead, they focus more on access into a network from unauthorized clients. A basic DHCP server runs under the assumption that any DHCP Discover and Request should be honored as an authorized client. In this setup, any device that requests network information will be able to receive it, no questions asked. However, this opens the door for any person with physical access to the network to be able to plug in unauthorized devices and receive network access.

A number of ways exist to reduce this network exposure, from modifying the network switches to modifying the DHCP configuration. Most of these security implementations involve verifying the MAC address of the client device before allowing it to receive an IP address. One of the more extensive fixes is to enable port security on the implemented network switches. With port security in place, the physical connection port can be locked to allow only a single MAC address access through it. This can help prevent employees, or contractors, from installing a small network hub or wireless router, and giving multiple devices access to the network.

However, an easier method is to provide DHCP addresses just to devices that have a particular MAC address assigned to them. All network devices have a MAC address coded into them, and these addresses follow a set structure. The first six bytes of the MAC address specifies the vendor ID, or the company that manufactured the device. If you wish to restrict DHCP to just particular VoIP phones or devices on your network, this is possible by identifying the vendor ID on the devices and configuring the DHCP server to provide addresses only to devices that have the same vendor ID. For example, Grandstream Networks VoIP phones all have a vendor ID of 00:0B:82.

Another security issue that can arise with DHCP is coupled with TFTP, and the security risks associated with it. If a network uses a TFTP server to transmit bootable disk images to computers, much of the configuration material to specify where these particular disk images are located is located within the DHCP responses. When clients receive a DHCP offer, they can choose to take advantage of this information, depending on their boot states. However, a malicious user could monitor these packets to determine the location of any TFTP servers, as well as the particular files used on these servers.

Tip

To ease the installation of IP telephones, create a separate scope of IP addresses with a MAC filter to only allow IP telephones to lease an address. Collect the unique vendor IDs from the authorized telephones to create this filter.

SNMP | Support Protocols

2011-11-11T00:00:00.000-08:00

SNMP, short for Simple Network Management Protocol, is a high-level protocol and architecture that allows for the monitoring and maintenance of network devices to detect problems, and to fine-tune the network for performance. There are two key versions of SNMP in use today, SNMPv1 and SNMPv2. While the two share many commonalities, there are some very beneficial additions made to SNMPv2. However, as many people disagreed with the security profiles implemented into SNMPv2, it has remained less popular and less used than SNMPv1. Since that time, a newer version of SNMP was released: the Community-Based SNMP, or SNMPv2c. However, the current standard, adopted in 2004, is SNMPv3. SNMP plays a useful role in maintaining and administering VoIP networks by allowing a person the ability to easily monitor the bandwidth and performance of all the major components of a network.

The SNMP protocol is defined under RFC 1157 as SNMPv1, and the characteristics of its immediate successor, SNMPv2, are defined in RFC 1902. SNMPv2c is officially detailed in RFC 1901 and in RFC 1908. SNMPv3 is defined in RFC 3411 and RFC 3418.

SNMP Architecture

An SNMP implementation on a network involves three components to be integrated: the devices to be managed, agents, and Network Management Systems (NMSes). The devices to be managed are simply computers or devices on the network that reside on the network. These are the devices that an administrator would like to monitor on the network. Each device must have an agent installed on them, which is a software application that continually monitors the device for predefined events or errors and transmits them to a centralized management server, an NMS. The NMS collects all of the data that is routinely transferred from the various network devices and correlates it into useful information for an administrator to read and evaluate.

However, even with all of these components working together on a network, there still must be a structure to all of the individual data that can be gathered across a network by an NMS. This is implemented by the use of a Management Information Base (MIB). See Figure 1 for a diagram on how these components work together.

Figure 1: SNMP Network Components

SNMP Operation

The SNMP protocol works under a very simplified model of data collection and control of the managed devices. Only a few basic commands are used in the SNMP protocol, such as GETKEQUEST, GETNEXTREQUEST, SETREQUEST, and TRAP. An NMS invokes GETREQUEST to collect data from a device, and GETNEXTREQUEST to retrieve the next value in a set. An NMS can also invoke the SETREQUEST command to save data to a managed device. The TRAP command is the only one not initiated by the NMS; it is sent out by the client to report any unusual activity it has detected.

On the client side, the Management Information Base (MIB) acts as a tree that catalogs all of the various data components of the system or device. Each of these data components are known by their object identifiers (OIDs). The OID is made up of multiple sets of numbers, each separated by a period, in a structured order similar to that of an IP address. As a general rule, all OIDs begin with .1.3.6.1.2.1, except on many Cisco devices which use .1.3.6.1.4.1.9. To request a data value, an established OID must be specified. For example, to request the system up time, OID .1.3.6.1.2.1.1.2 is read.

SNMP Architecture

The SNMP protocol has many areas that require careful attention and configuration simply due to the amount of information that could be leaked out to malicious users. Since all of this data is retrievable by anyone requesting it, there must be some safeguards put in place to prevent unauthorized users from being able to read data, or modify it. This is performed by the use of a community string. A community string acts as a password to group data into either read-only or read-write areas. By default, most software is setup to use a default community string of “public” for their read-only data. Likewise, many implementations use a default community string of “private” for their read-write data. It is particularly dangerous to leave such community strings in place, as they are well known to malicious users, and an unchanged read-write community string allows an attacker the ability to modify critical data on a device.

Due to the open nature of SNMP, allowing any person to easily request data, unique community strings should be defined for network components that you can administer. Proper care must also be taken in evaluating IP telephones to ensure that they do not have unsecured SNMP access available. Otherwise, all of your SNMP-enabled components, such as workstations, servers, routers, and phones, can disclose sensitive information to anyone who asks. Unless you are constantly monitoring network traffic, you may not even know that this information is being gathered by malicious people within your network environment—or, even worse, being modified to cover unauthorized actions.

This issue came to light recently when it was discovered that the Cisco 7920 Wireless IP Phone contained a fixed community string that allowed malicious users to gather and modify data on the devices. The vulnerability and its fix were given a Cisco bug ID of CSCsb75186. They can also be reviewed at http://securitytracker.com/id?1015232.

Likewise, similar SNMP vulnerabilities surfaced with the Hitachi IP5000 phone. These devices did not have a protected community string, which meant that any person could have full SNMP access to all of the data on the device, including the ability to alter and erase it.

On a lesser scale, the UTstarcom F1000 IP phone featured the default public community string, which allowed anyone to view data stored on the phone, some of which could be considered sensitive. Additionally, when using SNMP scanning software, the phone suffered from numerous SNMP issues that required a full reboot to fix.

HTTP | Support Protocols

2011-10-27T01:30:00.000-07:00

The Hyper Text Transfer Protocol (HTTP) is one of the most well known, and well used, protocols on the Internet. It is the protocol by which Web pages are transmitted from Web servers to clients, but it is also used by many other applications to send data between computers. For example, many peer-to-peer clients make use of the solid structure of HTTP to transfer data segments of shared files between peers. HTTP can be used to transmit both ASCII and binary data between computers.

HTTP is commonly used in the VoIP community as a way for administrators to remotely administer and configure devices. Many network management devices offer a Web-based administration panel by which the device can be altered and configured for a particular environment. Many such devices also require user authentication to be able to fully access the configuration data.

HTTP was first described in RFC 1945 at HTTP 1.0 by its founder, Tim Berners-Lee. Currently, RFC 2616 is used to describe the HTTP 1.1 protocol; however, various other RFCs describe additional extensions and uses for the HTTP protocol. These include HTTP Authentication (RFC 2617), Secure HTTP (RFC 2660), and CGI (RFC 3875).

HTTP Protocol

The function of HTTP and its protocol was designed to be very straightforward and usable by many applications. When a client wishes to request a file from an HTTP server, it simply creates a TCP session with the server and transmits a GET command with the name of the requested file and the HTTP protocol version (for example, GET /index.html HTTP/1.1). The HTTP server then responds back with the appropriate data. The response from the server will be either the data requested by the client, or an error message describing why it cannot send the data. All of the commands within the HTTP protocol are sent in regular ASCII text, with each line followed by a carriage return/line feed (CR/LF). In network logs, the CR/LF appear as hexadecimal 0x0D0A.

HTTP Client Request

For a client to retrieve data from an HTTP server, it must know the exact filename and location to construct an appropriate file request. For most purposes, this information is supplied in the form of a uniform resource locator (URL), which specifies a particular HTTP server, directory path, and file name (for example, www.digg.com/faq/index.php). When a client wishes to view this specific page, index.php, it must first make a connection to www.digg.com. This is performed by resolving the domain name to an IP through DNS, which results in the IP address of 64.191.203.30. The client then initiates a TCP connection to 64.191.203.30 and makes a request of GET /faq/index.php HTTP/1.1. This request also includes other information about the client, some of which may be required for HTTP 1.1, such as the host value. An example of a full HTTP GET request is shown next:

GET /download.html HTTP/1.1
Host: www.ethereal.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Accept: \
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; \
q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859–1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.ethereal.com/development.html

HTTP Server Response

Upon receiving a GET request from a client, a server first ensures that the file requested does exist. If it does, the data is then sent back to the requesting client. If not, an error message is sent. Regardless of the action, a specific server response is sent back to the client that includes a status code. This status code informs the client of the response type. The most common is a 200 code, which informs the client that the file was found and will be sent. It is transmitted in the form of HTTP/1.1 200 OK, which specifies the HTTP protocol version, the status code, and a brief description of the code. Other common status codes include “404 Not Found,” which indicates that the requested file could not be located by the server, and “500 Internet Server Error” which indicates that there is a problem with the HTTP server. The following is an example of an HTTP response:

HTTP/1.1 200 OK
Date: Thu, 13 May 2004 10:17:12 GMT
Server: Apache
Last-Modified: Tue, 20 Apr 2004 13:17:00 GMT
Accept-Ranges: bytes
Content-Length: 18070
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: t ext/html; charset ++ ISO-8859–1

Security Implications for HTTP

Due to the simple design of HTTP, and the early state of the Internet when it was unveiled, security wasn’t a high priority in the protocol. All data sent through HTTP was sent as clear text, which allowed any person to be able to sniff the traffic flowing across the wire and parse out sensitive data, such as usernames, passwords, and network configuration data. This is particularly dangerous since many VoIP and network management devices use HTTP as a means to allow administrators to check the status of the device and to configure additional settings. A person with malicious intent on the same network segment as the device could pick out various usernames and passwords that may work on additional computers or devices.

HTTP also supports multiple forms of authentication, which is a means by which the HTTP server can verify a user’s identity. The two authentication forms currently used are basic and digest authentications. When a server supports authentication, it sends a 401 “Authentication Required” response to clients that request sensitive data. This response will also include a “realm” (a name associated with the Web site) that notifies the user what they are accessing. When a client receives such a response, it will provide a log-in window to the user to input a valid user name and password. These values will then be transmitted back to the requesting server for verification. Because of HTTP’s design, though, these credentials will have to be constantly transmitted to the server for every further data transmission. Each of these transactions will transmit the user name and password in the clear.

Another form of authentication supported by modern HTTP clients and servers is digest authentication, which is described in depth in RFC 2617. Digest authentication has an advantage over basic authentication in that it does not send a clear password over the network. Instead, an MD5 (Message Digest) value of the password is transmitted to the requesting server. The server then uses this digest value for password comparisons. However, digest authentication is not fully supported in many older Web browsers. It also does not fully protect a user’s credentials. The user name and other information about the user are still transmitted in the clear. And, even though the password is obfuscated, a skilled, malicious user can still capture the MD5 value and use it for future transactions with that particular server to use another person’s account.

Many devices have recently provided support for HTTPS to overcome the openness of the HTTP protocol. HTTPS is a modification of HTTP wherein all data between a client and server are encrypted using the Secure Sockets Layers (SSL). In order for HTTPS to function, both the server and the client must be able to support it, and it must be specifically chosen as the form of communication in the URL. For example, instead of http://www.foo.com, a secure connection would use https://www.foo.com.

TFTP | Support Protocols

2011-10-23T09:50:00.000-07:00

The Trivial File Transfer Protocol (TFTP) is a simplified protocol used to transfer files from a server to a client. Unlike more evolved file protocols, such as FTP, TFTP was designed to work in pure simplicity, requiring less overhead and interaction. Its primary usage today is in computers and devices that do not have storage devices, commonly known as “thin client PCs.” Without offline storage, especially one that can be updated, it is difficult to maintain how such devices can operate. Instead of booting off of a hard drive or flash ROM, these devices use TFTP to request data from a central server to boot from. Or, such devices can boot from internal ROM memory and use TFTP to request configuration data to use during their operation. Also, devices can use TFTP to request firmware updates which they can then flash to their ROM chips to update the built-in software code. This is especially useful since customized sets of data can be stored for individual user devices within a corporate environment.

The role of TFTP in transferring data is well used throughout the computer industry. Virtually all modern computers support the ability to boot from the network. In this mode, the computer will attempt to locate a TFTP server on its network segment once it boots. In finding one, the client requests a bootable image from the server, usually in the form of a floppy disk image. Once it has received the data, the client will then proceed to boot from the image, as if it was an actual floppy disk or CD-ROM.

In the VoIP community, TFTP has a critical role in allowing VoIP devices and telephones to obtain configuration data from centralized servers. These devices are built with internal Flash ROM memory chips that contain simplified hardware architecture that does not allow for continual write access to memory. Instead, data is only written once to the device’s memory and read continuously by the internal operating system.

The TFTP protocol was first described in 1980 as IEN (Internet Experiment Note) 133. Its first formal RFC was RFC 783, which was later updated in RFC 1350. However, there are various RFCs that also describe individual actions and abilities that TFTP could be used for. These include Bootstrap loading (RFC 906) and TFTP multicasting (RFC 2090). The next few sections of the chapter detail a high-level overview of the TFTP architecture and several related security threats associated with the protocol.

TFTP Security Concerns

In order to better understand and be able to address the security concerns associated with TFTP properly, it is important to have at least a high-level understanding of how TFTP works. Unlike most other file transfer protocols, TFTP operates by transmitting UDP packets. While connection-less UDP packets are generally frowned upon for reliable data transmissions, they allow for a simpler implementation into the protocol, as well as faster transfer speeds. The abilities of the protocol are also very limited, allowing only for the ability to read and write data. The protocol does not have any mechanism displaying information about available files and directories on a server. The client must know the name of the file that they wish to download when connecting.

There are very strict regulations on how data is sent between computers, which allows for client applications to be written easier. Similar to the FTP protocol, TFTP allows for data to be sent as either ASCII or binary. This data is sent in individual UDP packets between the two devices. Of these packets, five types can be transmitted, each one identified by an operation code in the header of the data.

Read Request (RRQ)
Write Request (WRQ)
Data
Acknowledgement (ACK)
Error

TFTP File Transfer Operation

When a client wishes to download a file from a TFTP server, it first sends a Read Request (RRQ) packet to the TFTP server. This packet identifies itself as an RRQ packet, and also specifies both the name of the file the client wishes to download and the data mode (binary or ASCII). Likewise, if the client wishes to upload a file to a TFTP server, it sends an identical Write Request (WRQ) packet, which also contains the file name and data mode. The sending computer then immediately starts sending data packets to the recipient computer. If the data is greater than 512 bytes in size, multiple packets will be sent. A packet that contains a data portion smaller than 512 bytes is seen as the last packet in the transfer. Following the receipt of each data packet, the receiving computer sends an acknowledgement (ACK) packet to the sender, notifying it that the transfer was successful. Figure 1 details this transfer of data between two computers.

Figure 1: TFTP Data Transferral

Security Implications for TFTP

Insomuch that TFTP was designed for simplicity and ease of use, any mechanisms normally used to secure data were not implemented into its protocol It was originally planned by engineers that usernames and passwords should not ever be required for TFTP access, but this has led to many security issues. This concern is also greater because all TFTP packets are sent in the clear across a network, with no data encryption. Given there is no authentication, and no encryption, TFTP is generally not recommended for the transfer of sensitive data. However, its role as a “bootstrap protocol” could allow usernames and passwords to be transferred in the clear across a network when these aren’t protected by higher-level mechanisms. Since TFTP is often used to download boot images from a remote server, and these images often contain sensitive data required to connect into various servers on the network, it is possible to retrieve stored account information from within these boot images. Any person who is capturing network traffic on the same network segment as the TFTP session could easily gather the transferred data and re-create the original file. If the file contains sensitive data, such as usernames and passwords, it would then be readily available to anyone capturing the traffic.

Warning

The TFTP protocol sends all data in clear text across the network. As it is commonly used to transfer configuration data to devices and clients, it is important to verify that there is no sensitive data contained within transferred data. Otherwise, anyone sniffing the wire could have access to various usernames and passwords used by such devices.

DNS | Support Protocols

2011-10-20T00:30:00.000-07:00

The Domain Name System (DNS) is a static hierarchical name resolution architecture that relies on client/server communication for operation. DNS is a protocol that many use every day and may not know it. Whenever someone browses the Internet, DNS is used in the background to translate host names into IP addresses so that the proper network destinations can be found. DNS is equally important in VoIP networks for its ability to resolve destination endpoint addresses or allow gateway registration to call servers and gatekeepers by host name.

DNS was created so that no one would be required to memorize the IP addresses of every host on a private network or the Internet. Most people have a hard enough time remembering one or two passwords, let alone several billion IP addresses. With the development of DNS, the only requirement is knowledge of the target Web page name that you wish to go to. DNS resolves the target Web page name entered into one or more server IP addresses. It has also been designed to allow the reverse or “inverse” resolution of IP addresses to host names.

The DNS architecture was first discussed in detail in RFCs 881 through 883, and later updated in RFCs 1034 and 1035. Several of the newer RFCs include recommendations for how to secure the DNS architecture, including the addition of DNS security extensions (DNSSEC) beginning with RFC 4033. The next few sections detail a high-level overview of the DNS architecture and several security threats associated with DNS systems.

DNS Architecture

In order to better understand and be able to address the security concerns associated with DNS properly, it is important to have at least a high-level understanding of how DNS works. The hierarchy previously mentioned for DNS exists as a pyramid, with the highest level of the DNS architecture at the top. DNS is organized into myriad logical groupings called domains, which are further segmented into an endless number of subdomains. Figure 1 illustrates a sample hierarchy of the DNS system and is by no means exhaustive. The intent is to show the structure of the hierarchy.

Figure 1: Sample DNS Architecture

Located at the top of the DNS hierarchy are the root DNS servers. The root DNS servers are located in the root DNS zone, annotated by a single “.”, and are responsible for maintaining the location of the top-level domain servers (TLD). ATLD DNS server is one that is responsible for the management of one of the commonly associated address suffix identifiers, such as .com, .net, .edu, or .org. The TLD DNS servers are assigned or “dele-gated” the responsibility by the root DNS servers. They are known as the authoritative server for that TLD. Likewise, the TLD DNS servers delegate the management of one of their many subdomains. The subdomain DNS servers for .brad.com would be responsible for any resource records (RR) for that subdomain as well as the location of any related subdomains (.hr.brad.com). The resource records are the entries for the host systems. This process of delegation distributes the load of the DNS system across many different servers.

Fully Qualified Domain Name

Each host has its own pointer for DNS, known as a fully qualified domain name (FQDN). The FQDN is used to identify the path taken through the DNS architecture to find the requested host. Figure 2 illustrates what path is taken through the previously discussed DNS hierarchy from Figure 1 to reach host pc1.

Figure 2: Fully Qualified Domain Names

There are a couple of things to keep in mind about FQDNs. First of all, the explicit FQDN path from the top of the hierarchy (root) is read from right to left. Secondly, even though most FQDN illustrations do not include the final dot to represent the root domain, it is an implied part of the complete FQDN. Most applications, like IE, will not append a trailing “.” to the end of a requested Web resource. Followed from right to left, the host pc1 follows a path out of the root domain, through the TLD .com, to the .com subdomain .brad.com, and then finally into the .brad.com subdomain of .hr.brad.com.

FQDNs are entered into the DNS tables as one of several types of RRs:

A An A record is an address record, denoting a standard host entry in the DNS table. The key here is that it is used to resolve an FQDN to an IP address.
PTR PTR records are used by the inverse lookup zones in DNS. The PTR record resolves an IP address to an FQDN.
SOA The SOA record identifies zone information such as the zone name and serial number.
MX MX records identify mail servers for the zone.
NS NS records are used for name servers for the zone.
CNAME CNAME records act as alias records to allow for the translation of one host name into another.
INFO Provides information about hosts listed in the DNS table.
SRV SRV records identify SIP servers for the zone.

DNS Client Operation

In order to locate the IP address for a host, the client’s application will send a request to a resolver on the same client system. The resolver will then formulate and send out the DNS query. From a high level, the query will typically follow a path of trial and error known as a recursive lookup. Figure 3 illustrates what a recursive lookup from a host, pc2, would look like to find the IP address for host pc1.

Figure 3: Recursive Lookups Using DNS

The client’s resolver sends its DNS query which will be sent to the root domain.
The root domain server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the TLD DNS server for .com since it knows where .com. is.
The resolver, in turn, sends a query to the TLD DNS server for .com.
The TLD DNS server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the .brad.com. DNS server since it knows where .brad.com. is.
The resolver, in turn, sends a query to the DNS server for .brad.com.
The .brad.com. DNS server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the .hr.brad.com. DNS server since it knows where .hr.brad.com. is.
The resolver, in turn, sends a query to the DNS server for .hr.brad.com.
The authoritative DNS server for .hr.brad.com. has the RR for the host pc1 and sends back the information to pc2. pc2 now has the IP address information for pc1, and may use it accordingly.

Note

It is not required to have a separate DNS server for each subdomain. A single DNS server may be the authoritative server for many, or all, of the subdomains in a corporation, although there are usually backup DNS servers configured for each primary DNS server.

DNS Server Operation

The DNS server is responsible for cataloging all of the RRs that belong to any of the zones that it is the authoritative DNS server for. It is also responsible for keeping track of any of the DNS servers that it has delegated subdomain responsibility to. By keeping track of the subdomains, the DNS server is able to redirect client queries to the proper location in the event that the requested host RR does not reside on that server.

DNS servers may also be configured to maintain a cache of domain names, as well as their respective IP addresses, as they are requested by clients. This configuration allows a DNS server to retrieve an IP address only once and then store the value for any subsequent queries by the same client or any other client. These entries are cached for only a short period of time, equal to the Time To Live (ttl) value applied to the record. When a client requests a particular domain name resolution, the DNS server will first attempt to find the records in its local database. If this search fails, the DNS server will attempt to contact a root name server, if it’s been configured to do so, to request the value.

Another important function that the DNS servers provide is the replication of the DNS table, also known as a zone transfer. The zone transfer insures that all entries for a given zone will be available on all DNS servers in that zone. This is necessary so that DNS can provide a resilient operating architecture. Two types of zone transfers can be found between DNS servers: full and incremental. A full zone transfer is exactly as it sounds, a complete transfer of zone information between DNS servers. An incremental zone transfer, on the other hand, is one where only changed zone information is exchanged between DNS servers. Incremental zone transfers make more efficient use of bandwidth and network resources, but not all DNS server vendors support the newer implementation.

Zone transfers are based on several items, including serial numbers and refresh intervals. The secondary DNS server will request a zone transfer from the primary DNS server and there is a serial number embedded in the response. If the secondary server receives the response and the serial number is lower than or equal to the serial number of its current table version, the response will not be used to update the server’s table. However, if the serial number is higher, the DNS table will be updated to what is enclosed in the response.

The refresh interval is used to identify how often the secondary server should request a zone transfer from the primary server. It is used as a polling mechanism to help ensure that the secondary server remains up-to-date with the current DNS information. NOTIFY messages may also be used by the primary DNS server to tell the secondary DNS servers when changes have been made to the DNS table. When the secondary DNS server receives the NOTIFY, they can request a zone transfer to ensure table synchronization.

Security Implications for DNS

DNS is a core component of modern networking, and as such, is a rather attractive target for many attackers. When the DNS architecture was developed, security was not included as part of the design. There was nothing designed into the architecture for peer authentication, origin authentication, or data encryption. Some recent advancements in DNS have helped to alleviate some of the current security concerns, but they have not been able to remove them altogether.

The dangers of DNS are well publicized and well documented, owing to its long life on the Internet. More information on these security threats, how they are performed, and how to protect your DNS servers can be found at www.dnssec.net/dns-threats.php. There is also an RFC on DNS Threats, published as RFC 3833. Several types of attacks should be kept in mind regarding your DNS deployment, and some best practices can be employed to help lessen your exposure:

DNS footprinting (using DNS zone data to learn host names, subdomains, and subnets)
Denial of Service (DoS)
1. SYN flooding of DNS server
2. Transfer of blank DNS table

DNS cache poisoning

Frequently Asked Questions | SIP Architecture

2011-09-29T04:53:00.000-07:00

Q: I am used to seeing users that follow the scheme SIP: username@domain.com, but I’ve also seen them with the scheme SIPS: username@domain.com. What’s the difference?

A: SIP uses Universal Resource Identifiers (URIs) for identifying users. A URI identifies resources on the Internet, and those used by SIP incorporate phone numbers or names in the username. At the beginning of this is SIP:, which indicates the protocol being used. This is similar to Web site addresses, which begin with HTTP: to indicate the protocol to use when accessing the site. When SIP: is at the beginning of the address, the transmission is not encrypted. Those beginning with SIPS: require encryption for the session.

Q: Why do all responses to a request in SIP begin with the numbers 1 through 6?

A: This indicates the category to which the response belongs. There are six categories of responses that may be returned from a request: Informational, Success, Redirection, Client Error, Server Error, and Global Failure.

Q: I received a response that my request was met with a server error. Does this mean I can’t use this feature of my VoIP program?

A: Not necessarily. When a request receives a Server Error response, it means that the server it was sent to met with the error. The request could still be forwarded to other servers. A Global Error meanns that it wouldn’t be forwarded because every other server would also have the same error.I need to use a different computer for VoIP. The software is the same as the one on my computer, but I’m concerned that others won’t be able to see that I’m online because I’m using a different machine.When you start the program and log onto your VoIP account, SIP makes a REGISTER request that provides your SIP address and IP address to a Registrar server. This allows multiple people to use multiple computers. No matter what your location, SIP allows others to find you with this mapping of your SIP-address to the current IP address.

Q: Should I always use encryption to protect the data that I’m transmitting over the Internet?

A: Unless you expect to be discussing information or transferring files that require privacy, it shouldn’t matter whether your transmission is encrypted or not. After all, if someone did eavesdrop on an average conversation, would you really care that they heard your opinion on the last movie you watched? If, however, you were concerned that the content of your conversation or other data that was transmitted might be viewed by a third party, then encryption would be a viable solution to protecting your interests. As of this writing however, there are no interoperable, nonproprietary implementations of SIP that use encrypted signaling and media, so you will need to refer to the documentation of the application(s) being used to determine if this is available.

SIMPLE | SIP Architecture

2011-09-26T09:30:00.000-07:00

SIMPLE is an extension of SIP, which is used for maintaining presence information and managing the messages that are exchanged between the participants using instant messaging. Just as SIP registers users with a SIP server before they can begin a session, SIMPLE registers presence information. When a user registers through SIMPLE, those with this user in their Buddy List can access information that the user is online. When the people who have the user in their lists are alerted that the user is online, they can initiate a chat. If the user needs to do some work and changes their status to busy, or goes away from their desk and changes their status to being away, then this information is updated in the IM applications that have this person as a contact. Generally, the presence of a user is indicated in these programs through icons that change based on the user’s status.

Because SIMPLE is an extension of SIP, it has the same features and methods of routing messages. The users are registered, and then send text-based requests to initiate a session. The messages are sent between user agents as individual requests between User agent clients and User agent servers. Because the messages are small, they can move between the two User agents quickly with minimal time lag even during peak Internet hours.

Although the IETF IM and Presence Protocol Working Group are still developing SIMPLE as a standard, it has been implemented by a number of IM applications. Windows XP was the first operating system to include SIMPLE, and is used by Microsoft Windows Messenger, and numerous other IM applications also are using SIMPLE as a standardized method for instant messaging.

Instant messaging has become a tool that not only is used by the public for pleasure, but also one that is used by companies for business. IM software can be used as an alternative method of communicating with salespeople, customers, suppliers, and others who need to be contacted quickly. Because it is an effective communication tool, businesses have found benefits implementing it as part of their communications systems.

Unfortunately, a drawback of IM applications is that it provides a potential gap in security. Although companies will monitor outgoing e-mail for illegal or inappropriate content, IM applications available to the public don’t provide a centralized method of logging conversations that can be locked down. IM applications routinely offer a method of logging conversations, but these settings can be toggled on and off by the person using the program. This means that someone could inadvertently or maliciously provide sensitive information in Instant messages without anyone at the company every realizing it.

Added to this problem is the fact that IM applications provide the ability to transfer other forms of media between participants. IM applications can be used for file sharing, where one person sends a file to another through the program.

This can result in activities like sharing music files at work, which albeit illegal is relatively harmless, but it could also cause major issues if sensitive corporate files were being sent. Imagine an employee at a hospital or doctor’s office sending patient files, or a disgruntled employee sending out a secret formula to the public or competition, and its impact becomes more apparent.

Because files may contain more than you bargained for, the possibility of spyware or viruses being disseminated through instant messaging must also be considered. Some applications that have supported instant messaging include additional software that is spyware, which can obtain information about your system or track activities on your system. Even if the IM software used on a machine doesn’t include spyware, the files sent between participants of a communication session can contain viruses or other malicious code. By opening these files, the person puts their computer and possibly their local network at risk.

If a company wishes to allow IM software installed on their machines, and doesn’t want to block IM communications to the Internet, they need to educate users and install additional software on the computers. Just as employees should know what information should not be discussed on a telephone or sent by mail, they should know these same facts, and files should be off-limits in other communications. In addition to this, anti-virus software should be installed, and regularly updated and run. To determine if spyware is installed on the machines, they should either invest in anti-virus software that also looks for these programs or install additional software that searches for and removes them from the computer. In performing these steps, the risks associated with IM applications in a business can be decreased, making it safer for both the user and the company.

Instant Messaging | SIP Architecture

2011-09-23T09:29:00.000-07:00

In different variations, instant messaging has been around longer than the Internet has been popular. In the 1970s, the TALK command was implemented on UNIX machines, which invoked a split screen that allowed users of the system to see the messages they typed in individual screens. In the 1980s, Bulletin Board Systems (BBSes) became popular, where people would use a modem to dial into another person’s computer to access various resources, such as message boards, games, and file downloads. On BBSes, the system operator (SYSOP) could invoke a chat feature that allowed the SYSOP to send messages back and forth with the caller on a similar split-screen. If the BBS had multiple phone lines, then the callers could Instant message with each other while they were online. As the Internet gained popularity, the ability to exchange messages with other users became a feature that was desired and expected.

Today there are a large number of IM applications that can be used to exchange text messages over the Internet and other IP networks. Although this is nowhere near a complete list, some of the more popular ones include:

AIM, America Online Instant Messenger
ICQ
Yahoo Messenger
MSN Messenger

In addition to these, there are also applications that allow communication using VoIP or other multimedia that also provide the ability to communicate using text messages. As seen in Figure 1, Skype provides a chat feature that allows two or more users to communicate in a private chat room. Each message between the participants appears on a different line, indicating who submitted which line of text and optionally the time that each message was sent. This allows participants to scroll back in the conversation to identify previously mentioned statements or topics of discussion. Although the figure depicts instant messaging in Skype, it is a common format that is used in modern IM software.

Figure 1: Instant Messaging through Skype

One of the important features of any IM application is the ability to keep a contact list of those with whom you routinely communicate. In many programs the contact list is also known as a Buddy List. However, even with this listing, it would be impossible to contact anyone if you didn’t know when each contact was available. If a person had a high-speed connection and was always connected to the Internet, then they might always appear online. As such, they would need a way of indicating that they were online but not available, or whether the person was available for one form of communication but not another. The ability to display each contact’s availability in a Buddy List when someone opens an IM application is called presence.

Understanding SIP’s Architecture

2011-09-20T05:25:00.000-07:00

Let’s look at how they work together to provide communication between two endpoints on a system. In doing so, we can see how the various elements come together to allow single and multimedia to be exchanged over a local network or the Internet.

The User agents begin by communicating with various servers to find other User agents to exchange data with. Until they can establish a session with one another, they must work in a client/server architecture, and make requests of servers and wait for these requests to be serviced. Once a session is established between the User agents, the architecture changes. Because a User agent can act as either a client or a server in a session with another User agent, these components are part of what is called a peer-to-peer (P2P) architecture. In this architecture, the computers are equal to one another, and both make and service requests made by other machines. To understand how this occurs, let’s look at several actions that a User agent may make to establish such a session with another machine.

SIP Registration

Before a User agent can even make a request to start communication with another client, each participant must register with a Registrar server. As seen in Figure 1, the User agent sends a REGISTER request to the SIP server in the Registrar role. Once the request is accepted, the Registrar adds the SIP-address and IP address that the User agent provides to the location service. The location service can then use this information to provide SIP-address to IP-address mappings for name resolution.

Figure 1: Registering with a SIP Registrar

Requests through Proxy Servers

When a Proxy Server is used, requests and responses from user agents initially are made through the Proxy server. As seen in Figure 2, User Agent A is attempting to invite User Agent B into a session. User Agent A begins by sending an INVITE request to User Agent B through a Proxy server, which checks with the location service to determine the IP address of the client being invited. The Proxy server then passes this request to User Agent B, who answers the request by sending its response back to the Proxy server, who in turn passes this response back to User Agent A. During this time, the two User agents and the Proxy server exchange these requests and responses using SDP. However, once these steps have been completed and the Proxy server sends acknowledgements to both clients, a session can be created between the two User agents. At this point, the two User agents can use RTP to transfer media between them and communicate directly.

Figure 2: Request and Response Made through Proxy Server

Requests through Redirect Servers

When a Redirect server is used, a request is made to the Redirect server, which returns the IP address of the User agent being contacted. As seen in Figure 3, User Agent A sends an INVITE request for User Agent B to the Redirect server, which checks the location service for the IP address of the client being invited. The Redirect server then returns this information to User Agent A. Now that User Agent A has this information, it can now contact User Agent B directly. The INVITE request is now sent to User Agent B, which responds directly to User Agent A. Until this point, SDP is used to exchange information. If the invitation is accepted, then the two User agents would begin communicating and exchanging media using RTP.

Figure 3: Request Made through Redirect Server

Peer to Peer

Once the user agents have completed registering themselves, and making requests and receiving responses on the location of the user agent they wish to contact, the architecture changes from one of client/server to that of peer-to-peer (P2P). In a P2P architecture, user agents act as both clients who request resources, and servers that respond to those requests and provide resources. Because resources aren’t located on a single machine or a small group of machines acting as network servers, this type of network is also referred to as being decentralized.

When a network is decentralized P2P, it doesn’t rely on costly servers to provide resources. Each computer in the network is used to provide resources, meaning that if one becomes unavailable, the ability to access files or send messages to others in the network is unaffected. For example, if one person’s computer at an advertising firm crashed, you could use SIP to communicate with another person at that company, and talk to them and have files transferred to you. If one computer goes down, there are always others that can be accessed and the network remains stable.

In the same way, when user agents have initiated a session with one another, they become User agent clients and User agent servers to one another, and have the ability to invite additional participants into the session. As seen in Figure 6.5, each of these User agents can communicate with one another in an audio or videoconference. If one of these participants ends the session, or is using a device that fails during the communication, the other participants can continue as if nothing happened. This architecture makes communication between User agents stable, without having to worry about the network failing if one computer or device suddenly becomes unavailable.

Figure 4: Once SIP Has Initiated a Session, a Peer-to-Peer Architecture Is Used

Protocols Used with SIP | SIP Architecture

2011-09-16T03:20:00.000-07:00

Although SIP is a protocol in itself, it still needs to work with different protocols at different stages of communication to pass data between servers, devices, and participants. Without the use of these protocols, communication and the transport of certain types of media would either be impossible or insecure. In the sections that follow, we’ll discuss a number of the common protocols that are used with SIP, and the functions they provide during a session.

UDP

The User Datagram Protocol (UDP) is part of the TCP/IP suite of protocols, and is used to transport units of data called datagrams over an IP network. It is similar to the Transmission Control Protocol (TCP), except that it doesn’t divide messages into packets and reassembles them at the end. Because the datagrams don’t support sequencing of the packets as the data arrives at the endpoint, it is up to the application to ensure that the data has arrived in the right order and has arrived completely. This may sound less beneficial than using TCP for transporting data, but it makes UDP faster because there is less processing of data. It often is used when messages with small amounts of data (which requires less reassembling) are being sent across the network, or with data that will be unaffected overall by a few units of missing data.

Although an application may have features that ensure that datagrams haven’t gone missing or arrived out of order, many simply accept the potential of data loss, duplication, or errors. In the case of Voice over IP, streaming video, or interactive games, a minor loss of data or error will be a minor glitch that generally won’t affect the overall quality or performance. In these cases, it is more important that the data is passed quickly from one endpoint to another. If reliability were a major issue, then the use of TCP as a transport protocol would be a better choice over hindering the application with features that check for the reliability of the data it receives.

Although denial-of-service (DoS) attacks are less common using UDP, data sent over this protocol can be used to bog down or even shut down a system that’s victim to it. Because UDP is a connectionless protocol, it doesn’t need to have a connection with another system before it transfers data. In a UDP Flood Attack, the attacker will send UDP packets to random ports on another system. When the remote host receives the UDP packets, it will do the following:

Determine which application is listening to the port.
Find that no application is waiting on that port.
Reply to the sender of the data (which may be a forged source address) with an ICMP packet of DESTINATION UNREACHABLE.

Although this may be a minor issue if the remote host has to send only a few of these ICMP packets, it will cause major problems if enough UDP packets are sent to the host’s ports. A large number of UDP packets sent to the victim will cause the remote host to repeat these steps over and over. The victim’s ports are monopolized by receiving data that isn’t used by any application on the system, and ICMP packets are sent out to relay this fact to the attacker. Although other clients will find the remote host unreachable, eventually the system could even go down if enough UDP packets are sent.

To reduce the chances of falling victim to this type of attack, a number of measures can be taken. Proxy servers and firewalls can be implemented on a network to prevent UDP from being used maliciously and filter unwanted traffic. For example, if an attack appeared to come from one source previously, you could set up a rule on the firewall that blocks UDP traffic from that IP address. In addition to this, chargen and echo services, as well as other unused UDP services, could be either disabled or filtered. Once these measures are taken, however, you should determine which applications on your network are using UDP, and monitor for signs of a UDP Flood Attack or other signs of misuse.

Transport Layer Security

Transport Layer Security (TLS) is a protocol that can be used with other protocols like UDP to provide security between applications communicating over an IP network. TLS uses encryption to ensure privacy, so that other parties can’t eavesdrop or tamper with the messages being sent. Using TLS, a secure connection is established by authenticating the client and server, or User Agent Client and User Agent Server, and then encrypting the connection between them.

Transport Layer Security is a successor to Secure Sockets Layer (SSL), which was developed by Netscape. Even though it is based on SSL 3.0, TLS is a standard that has been defined in RFC 2246, and is designed to be its replacement. In this standard, TLS is designed as a multilayer protocol that consists of:

TLS Handshake Protocol
TLS Record Protocol

The TLS Handshake Protocol is used to authenticate the participants of the communication and negotiate an encryption algorithm. This allows the client and server to agree upon an encryption method and prove who they are using cryptographic keys before any data is sent between them. Once this has been done successfully, a secure channel is established between them.

After the TLS Handshake Protocol is used, the TLS Record Protocol ensures that the data exchanged between the parties isn’t altered en route. This protocol can be used with or without encryption, but TLS Record Protocol provides enhanced security using encryption methods like the Data Encryption Standard (DES). In doing so, it provides the security of ensuring data isn’t modified, and others can’t access the data while in transit.

Tip

The Transport Layer Security Protocol isn’t a requirement for using SIP, and generally isn’t needed for standard communications. For example, if you’re using VoIP or other communication software to trade recipes or talk about movies with a friend, then using encryption might be overkill. However, in the case of companies that use VoIP for business calls or to exchange information that requires privacy, then using TLS is a viable solution for ensuring that information and data files exchanged over the Internet are secure.

When sessions are initiated using SIP, the data passed between the servers and other users is sent using UDP. As it is sent across the Internet, it can go through a number of servers and routers, and may be passed through a local network on your end or the other participant’s end. During any point in this trip, it is possible that the data may be intercepted by a third party, meaning that any confidential information you transmit may be less private than you expected.

One method that third parties might use to access this data is with a packet sniffer. A packet sniffer is a tool that intercepts the traffic passed across a network. They are also known as network analyzers and Ethernet sniffers, and can be either software or hardware that captures the packets of data so they can be analyzed. It is a tool that can be used to identify network problems, but it is also used to eavesdrop on network users, and view the data sent to and from a specific source. This allows someone to grab the data you’re sending, decode it, and view what you’ve sent and received.

To avoid this problem, sensitive communications should always be encrypted. When data is encrypted, the data becomes unreadable to anyone who isn’t intended to receive it. If a person accessed encrypted packets of data with a packet sniffer, it would be seen as gibberish and completely unusable to them. It makes the transmission secure, preventing the wrong people from viewing what you’ve sent.

Other Protocols Used by SIP

As mentioned, SIP does not provide the functionality required for sending single-media or multimedia across a network, or many of the services that are found in communications programs. Instead, it is a component that works with other protocols to transport data, control streaming media, and access various services like caller-ID or connecting to the Public Switched Telephone Network (PSTN). These protocols include:

Session Description Protocol, which sends information to effectively transmit data
Real-Time Transport Protocol, which is used to transport data
Media Gateway Control Protocol, which is used to connect to the PSTN
Real-time Streaming Protocol, which controls the delivery of streaming media

The Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) are protocols that commonly are used by SIP during a session. SDP is required to send information needed during a session where multimedia is exchanged between user agents, and RTP is to transport this data. The Media Gateway Control Protocol (MGCP) and Real-time Streaming Protocol (RTSP) commonly are used by systems that support SIP, and are discussed later for that reason.

Session Description Protocol

The Session Description Protocol (SDP) is used to send description information that is necessary when sending multimedia data across the network. During the initiation of a session, SDP provides information on what multimedia a user agent is requesting to be used, and other information that is necessary in setting up the transfer of this data.

SDP is a text-based protocol that provides information in messages that are sent in UDP packets. The text information sent in these packets is the session description, and contains such information as:

The name and purpose of the session
The time that the session is active
A description of the media exchanged during the session
Connection information (such as addresses, phone number, etc.) required to receive media
Note
SDP is a standard that was designed by the IETF under RFC 2327.

Real-Time Transport Protocol

The Real-Time Transport Protocol (RTP) is used to transport real-time data across a network. It manages the transmission of multimedia over an IP network, such as when it is used for audio communication or videoconferencing with SIP. Information in the header of the packets sent over RTP tells the receiving user agent how the data should be reconstructed and also provides information on the codec bit streams.

Although RTP runs on top of UDP, which doesn’t ensure reliability of data, RTP does provide some reliability in the data sent between user agents. The protocol uses the Real-time Control Protocol to monitor the delivery of data that’s sent between participants. This allows the user agent receiving the data to detect if there is packet loss, and allows it to compensate for any delays that might occur as data is transported across the network.

Note

RTP was designed by the IETF Audio-Video Transport Working Group, and originally was specified as a standard under RFC 1889. Since then, this RFC has become obsolete, but RTP remains a standard and is defined under RFC 3550. In RFC 2509, Compressed Real-time Transport Protocol (CRTP) was specified as a standard, allowing the data sent between participants to be compressed, so that the size was smaller and data could be transferred quicker. However, since CRTP doesn’t function well in situations without reliable, fast connections, RTP is still commonly used for communications like VoIP applications.

Media Gateway Control Protocol

The Media Gateway Control Protocol (MGCP) is used to control gateways that provide access to the Public Switched Telephone Network (PSTN), and vice versa. In doing so, this protocol provides a method for communication on a network to go out onto a normal telephone system, and for communications from the PSTN to reach computers and other devices on IP networks. A media gateway is used to convert the data from a format that’s used on PSTN to one that’s used by IP networks that use packets to transport data; MGCP is used to set up, manage, and tear down the calls between these endpoints.

Note

MGCP was defined in RFC 2705 as an Internet standard by the IETF. However, the Media Gateway Control Protocol is also known as H.248 and Megaco. The IETF defined Megaco as a standard in RFC 3015, and the Telecommunication Standardization Sector of the International Telecommunications Union endorsed the standard as Recommendation H.248.

Real-Time Streaming Protocol

The Real-Time Streaming Protocol (RTSP) is used to control the delivery of streaming media across the network. RTSP provides the ability to control streaming media much as you would control video running on a VCR or DVD player. Through this protocol, an application can issue commands to play, pause, or perform other actions that effect the playing of media being transferred to the application.

Note

IETF defined RTSP as a standard in RFC 2326, allowing clients to control streaming media sent to them over protocols like RTP.

SIP Requests and Responses | SIP Architecture

2011-09-12T04:48:00.000-07:00

Because SIP is a text-based protocol like HTTP, it is used to send information between clients and servers, and User Agent clients and User Agent servers, as a series of requests and responses. When requests are made, there are a number of possible signaling commands that might be used:

REGISTER Used when a user agent first goes online and registers their SIP address and IP address with a Registrar server.
INVITE Used to invite another User agent to communicate, and then establish a SIP session between them.
ACK Used to accept a session and confirm reliable message exchanges.
OPTIONS Used to obtain information on the capabilities of another user agent, so that a session can be established between them. When this information is provided a session isn’t automatically created as a result.
SUBSCRIBE Used to request updated presence information on another user agent’s status. This is used to acquire updated information on whether a User agent is online, busy, offline, and so on.
NOTIFY Used to send updated information on a User agent’s current status. This sends presence information on whether a User agent is online, busy, offline, and so on.
CANCEL Used to cancel a pending request without terminating the session.
BYE Used to terminate the session. Either the user agent who initiated the session, or the one being called can use the BYE command at any time to terminate the session.

When a request is made to a SIP server or another user agent, one of a number of possible responses may be sent back. These responses are grouped into six different categories, with a three-digit numerical response code that begins with a number relating to one of these categories. The various categories and their response code prefixes are as follows:

Informational (1xx) The request has been received and is being processed.
Success (2xx) The request was acknowledged and accepted.
Redirection (3xx) The request can’t be completed and additional steps are required (such as redirecting the user agent to another IP address).
Client error (4xx) The request contained errors, so the server can’t process the request
Server error (5xx) The request was received, but the server can’t process it. Errors of this type refer to the server itself, and they don’t indicate that another server won’t be able to process the request.
Global failure (6xx) The request was received and the server is unable to process it. Errors of this type refer to errors that would occur on any server, so the request wouldn’t be forwarded to another server for processing.

There are a wide variety of responses that apply to each of the categories. The different responses, their categories, and codes are shown in Table 1.

Table 1: Listing of Responses, Response Codes, and Their Meanings
Response Code	Response Category	Response Description
100	Informational	Trying
180	Informational	Ringing
181	Informational	Call is being forwarded
182	Informational	Queued
200	Success	OK
300	Redirection	Multiple choices
301	Redirection	Moved permanently
302	Redirection	Moved temporarily
303	Redirection	See other
305	Redirection	Use proxy
380	Redirection	Alternative service
400	Client Error	Bad request
401	Client Error	Unauthorized
402	Client Error	Payment required
403	Client Error	Forbidden
404	Client Error	Not found
405	Client Error	Method not allowed
406	Client Error	Not acceptable
407	Client Error	Proxy authentication required
408	Client Error	Request timeout
409	Client Error	Conflict
410	Client Error	Gone
411	Client Error	Length required
413	Client Error	Request entity too large
414	Client Error	Request-URI too large
415	Client Error	Unsupported media type
420	Client Error	Bad extension
480	Client Error	Temporarily not available
481	Client Error	Call leg/transaction does not exist
482	Client Error	Loop detected
483	Client Error	Too many hops
484	Client Error	Address incomplete
485	Client Error	Ambiguous
486	Client Error	Busy here
500	Server Error	Internal server error
501	Server Error	Not implemented
502	Server Error	Bad gateway
503	Server Error	Service unavailable
504	Server Error	Gateway time-out
505	Server Error	SIP version not supported
600	Global Failures	Busy everywhere
603	Global Failures	Decline
604	Global Failures	Does not exist anywhere
606	Global Failures	Not acceptable

Client/Server versus Peer-to-Peer Architecture

2011-09-08T00:12:00.000-07:00

In looking at the components of SIP, you can see that requests are processed in different ways. When user agents communicate with one another, they send requests and responses to one another. In doing so, one acts as a User Agent Client, and the other fulfills the request acts as a User Agent Server. When dealing with SIP servers however, they simply send requests that are processed by a specific server. This reflects two different types of architectures used in network communications:

Client/Server
Peer-to-peer

Client/Server

In a client/server architecture, the relationship of the computers are separated into two roles:

The client, which requests specific services or resources
The server, which is dedicated to fulfilling requests by responding (or attempting to respond) with requested services or resources

An easy-to-understand example of a client/server relationship is seen when using the Internet. When using an Internet browser to access a Web site, the client would be the computer running the browser software, which would request a Web page from a Web server. The Web server receives this request and then responds to it by sending the Web page to the client computer. In VoIP, this same relationship can be seen when a client sends a request to register with a Registrar server, or makes a request to a Proxy Server or Redirect Server that allows it to connect with another user agent. In all these cases, the client’s role is to request services and resources, and the server’s role is to listen to the network and await requests that it can process or pass onto other servers.

The servers that are used on a network acquire their abilities to service requests by the programs installed on it. Because a server may run a number of services or have multiple server applications installed on it, a computer dedicated to the role of being a server may provide several functions on a network. For example, a Web server might also act as an e-mail server. In the same way, SIP servers also may provide different services. A Registrar can register clients and also run the location service that allows clients and other servers to locate other users who have registered on the network. In this way, a single server may provide diverse functionality to a network that would otherwise be unavailable.

Another important function of the server is that, unlike clients that may be disconnected from the Internet or shutdown on a network when the person using it is done, a server is generally active and awaiting client requests. Problems and maintenance aside, a dedicated server is up and running, so that it is accessible. The IP address of the server generally doesn’t change, meaning that clients can always find it on a network, making it important for such functions as finding other computers on the network.

Peer to Peer

A peer-to-peer (P2P) architecture is different from the client/server model, as the computers involved have similar capabilities, and can initiate sessions with one another to make and service requests from one another. Each computer provides services and resources, so if one becomes unavailable, another can be contacted to exchange messages or access resources. In this way, the user agents act as both client and server, and are considered peers.

Once a user agent is able to establish a communication session with another user agent, a P2P architecture is established where each machine makes requests and responds to the other. One machine acting as the User Agent client will make a request, while the other acting as the User Agent server will respond to it. Each machine can then swap roles, allowing them to interact as equals on the network. For example, if the applications being used allowed file sharing, a UAC could request a specific file from the UAS and download it. During this time, the peers could also be exchanging messages or talking using VoIP, and once these activities are completed, one could send a request to terminate the session to end the communications between them. As seen by this, the computers act in the roles of both client and server, but are always peers by having the same functionality of making and responding to requests.