The T38 to G711 Fallback Procedure

If the SIP External Gateway configuration parameter is “T38 to G711 Fallback” and if the IP Couplers in front of FAX are INTIP3/MG3 couplers and if the initial call is established with G711, OXE will try to establish the FAX in T38 mode.

If the remote SIP Party is not able to support FAX in T38 mode, it will send Error message. This will result in OXE to switch the FAX to G711 Mode.

Outgoing call
If OXE receives a RE-INVITE with T38 parameters, the call will proceed in T38. If OXE receives FAX call in G711, it will directly detect and handle it.

Incoming call 
Step1: When OXE detects a T38 FAX call, it sends Re-INVITE with T38 parameters as usual.
Step2: If the SIP Carrier accepts it and 200 OK is received with T38 parameters, then call proceeds in T38 mode.

Else if the SIP Carrier does not accept it and sends an Error response, the following cases are envisaged: -

• Case 1: If the negotiated codec is G711 and the IP couplers are INTIP3/MG3 couplers, then OXE will switch to G711 mode. 

• Case 2: If the coupler in front of FAX is other than INTIP3/MG3 coupler, or if the negotiated codec is G729/G723, the call is disconnected. 

Remark: If OXE is in transit position, the Error response will be relayed transparently

Overview of G711 Transparent Fax and T38 fallback G711

In a FAX over IP communication, when a SIP External Gatway is involved, the transmission is done through T38 Procedure. From OXE R11, the G711 procedure for fax communication is implemented, as well as a “Fallback” procedure from T38 to G711.

With this feature, OXE will support two more procedures. For SIP calls, FAS support will be done in 3 modes:

• The T38 only procedure

• The G711 transparent procedure

• The T38 to G711 Fallback procedure (In a first step, fax will try to establish with T38, if remote side doesn’t support it, it will fallback to G711 mode) The configuration of the above options is made in the corresponding External Gateway parameter (Fax procedure type).

Remark: this feature is applicable for the INTIP3/MG3 couplers only

OXE Remote Extension

Enhancement with OXE R11: Overflow to associate set if REX user is unavailable


Behavior before R11:
when the mobile set of a Remote Extension user receives a call from OXE and the mobile is in one of the following states (swithed off, busy, Out of Coverage area, Out of Service, the REX user may reject the call), OXE will receive a DISCONNECT message from the REX is unavailable due to the above mentioned reasons. When an Associate Set is managed in OXE for the Remote Extension, on receiving a DISCONNECT message, the behavior in OXE depends on the value of a system parameter

System ->  Descend Hierarchy -> Other System Parameters -> Descend Hierarchy -> External Signaling Parameter ->  Review/Modify -> “Listen to guide on DISCONNECT”

According to the existing implementation of Remote Extension, when the parameter “Listen to guide on DISCONNECT” is set to:

• TRUE the incoming call to Remote Extension overflows to its Associate Set only after no answer timer expires.
• FALSE the incoming call to Remote Extension overflows to its Associate Set immediately

Enhancement from R11: 

When REX user is configured as Non-Tandem set, then the call will overflow to the associate set of the REX immediately irrespective of the value of parameter “Listen to guide on Disconnect”. 

Whenever REX user is configured as Tandem’s secondary set, the overflow will depend upon the state when the DISCONNECT message is received. If OXE receives a DISCONNECT message before ALERT, the call will not overflow to the associate Set immediately but will overflow only after the call no answer timer. If OXE receives the DISCONNECT message after ALERT, the call will overflow to the associate set of the REX immediately

OXE Gateway

Entity between SIP world and legacy world, the gateway is used to establish a call from a SIP equipment to an ISDN link, to a legacy set, etc… and vice versa

• Do not confuse the SIP gateway with the OmniPCX Enterprise media gateway boards:
• The SIP gateway is a logical entity that resides within the call server (CS) and is responsible for the SIP signaling for the conversation setup,
• The media gateway boards (GD, GA, INTIP) are the physical devices where the media session will be established when calling to a classic PBX set.

• There is one and only one internal SIP gateway. But there can be many different external SIP gateways (we will come back to this in a later section).

• The SIP gateway is associated to a SIP trunk group. Although there can be many SIP Trunk Groups, there is only one SIP trunk group which is associated to the local SIP gateway. We call this special trunk group the local SIP trunk group.

OXE Dictionnary

Contains the SIP users created on the OXE, it is the database that holds the mapping between SIP URLs and PBX directory numbers (MCDUs). Each registered SIP terminal is automatically added to the dictionnary. Classic PBX terminals are added only if a SIP URL is defined for them in the user management.

• Most of the time you shouldn’t do anything with the Dictionnary. Everything will be handled automatically. You need to access the SIP Dictionnary configuration only for configuration of aliases

OXE Duplication

In case of OXE duplication, the SIPMOTOR is completely started on the Stand-By CPU, but acting as Stand-By(cannot handle the SIP requests). The Main CPU puts the Stand-By CPU up to date about the SIP contexts (Calls,registrations, subscriptions, etc...). In case of CPU switchover, the SIP calls are maintained and the registration andsubscriptions are kept.

In Case of spatial redundancy with dual subnetworks (2 main IP addresses), the SIP uses the FQDN of the OXE(nodename + DNS local domain name) for the SIP messages and also for the responses of the SIP messages. In thatcase, the remote SIP equipment must use it. The use of external DNS server is recommended to resolve this FQDN

The OXE contains the following compoments:

Registrar

Registers the SIP terminals addresses (“Location Service”)

·       The REGISTRAR is contained in the “localize.sip” file under /tmpd. If for any reasons you need to clear allentries in the registrar database, remove this file and then restart the SIPMOTOR:

(1)OXE> rm /tmpd/localize.sip

(1)OXE> dhs3_init -R SIPMOTOR

Proxy

Entity between the Client and the Server, the proxy is used to route the SIP requests.

·       The call can be routed between 2 SIP terminals. For instance, if Alice calls Bob (both are SIP), Alice sends a SIP request to the proxy, and the proxy sends this request to Bob.

·       The proxy can be used only for the authentication of the SIP equipment for Registration or SIP request.

o   The proxy can modify the request by adding information like a Via, Record-route, etc...

The INVITE is the same on each proxy sides, to get this behavior, and the UAC manages the IP address of the OXE SIP  proxy as the “Outbound proxy”

Here is an example:

·              UAC IP address: 172.27.143.184

·              proxy IP address: 172.27.143.186

·             UAS FQDN: oxe-ov.alcatel.fr (IP address: 172.27.141.151)

SIPMOTOR Processes

In the OmniPCX Enterprise, the logical functions of registrar, location service, proxy server and gateway are co-locatedin the process called sipmotor, running on the CPU7/CS2/AS board.

You may use the linux ps command to verify that the SIP processes are running :Example:All processes can be forced to reset with the command:

Example:

All processes can be forced to reset with the command:

•        dhs3_init -R SIPMOTOR 

This command stops properly the SIPMOTOR processes and restarts them. They will be automatically relaunched after a few seconds.The following commands can be used as well:

(1)OXE> dhs3_init –R SIPMOTOR

They will be automatically relaunched after a few seconds.

The following commands can be used as well

• killall sipmotor, this command kills the SIPMOTOR processes and restarts them.
• kill -9 “father pid”, this command kills the SIPMOTOR processes and restarts them.

Remarks:

If no licenses about SIP are present, the SIPMOTOR processes are not running.

Starting FreeSWITCH

Once you have compiled and installed FreeSWITCH, it is time to launch the application:

•    Linux/Unix/OS X: run /usr/local/freeswitch/bin/freeswitch •    Windows: run freeswitchconsole.exe from the Release directory

The system will start loading, and numerous messages will display on the screen. Console messages are color-coded for readability. Do not worry about all of the messages right now, just make sure that your system starts up and you get to the FreeSWITCH console, which we call the command-line interface (CLI). The CLI prompt looks like the following:

freeswitch@localhost>

Let's issue a few commands to verify that the system is operational. First, issue the version command to verify the version of FreeSWITCH that we have installed. You'll see something similar to this:

FreeSWITCH Version 1.2.1

Next, issue the status command, which displays a few statistics about your system. You'll see output similar to this:

freeswitch@localhost> status

UP 0 years, 0 days, 0 hours, 0 minutes, 16 seconds, 808 milliseconds, 260 microseconds

FreeSWITCH is ready

0 session(s) since startup 0 session(s) 0/30

1000 session(s) max

min idle cpu 0.00/100.00

Current Stack Size/Max 240K/8192K

These are just a few of the many commands you will learn about in FreeSWITCH. For a complete list of commands, simply type help and press Enter. Lastly, shut down FreeSWITCH with this command: fsctl shutdown. The system will display numerous messages as it shuts down, and will return you to the system command prompt. (If you launched freeswitchconsole.exe from the Windows Explorer then the FreeSWITCH window will simply close.)

NAT as a Topology Shield

NAT provides a security function by segregating private hosts from the publicly routed Internet. Depending upon your addressing requirements, NAT can isolate, to some extent, your VoIP network IP space from the balance of your internal network IP space. The large number of private RFC1918 IP addresses allows system architects to intelligently address hosts and other network elements based upon location, function, or other criteria during the design phase of the VoIP network.

External hosts cannot directly access a particular internal host if a NAT intervenes since the external host has no way of targeting its payload to a chosen IP address. Of course, when addresses are assigned dynamically, it becomes even more problematic for an attacker to point to a specific host within the NAT domain. This may help protect internal hosts from external malicious content. At worst, NAT is an additional layer of security controls that you implement as part of your overall security architecture.

The IPsec model is instructive in that it illustrates a complex interaction between encryption and NAT. However, IPsec is not the only functional or proposed security mechanism for VoIP environments. SSL/TLS, S/MIME, HTTP 1.1 digest, and ZRTP have also been proposed as security instruments. Nor are all environments as simple as the symmetric examples we have seen where one or more devices reside on opposite sides of a NAT device. Asymmetric or hairpin call routing (a call from one phone behind a NAT to another phone behind the same NAT), in an environment where basic NAT and encryption issues have been resolved, can cause communications to fail. The point here is to introduce some of the concepts that you will come across as you design and troubleshoot in this area. We’ll see in the next section how encryption, NAT, and VoIP protocols work (or don’t work) together.

NAT and Encryption

As IPsec VPNs became popular, NAT became an impediment to their initial widespread implementation. I’ll use the IPsec model to develop a description of the interactions between NAT and encryption since it is one of the more popular Internet encryption systems and has potential value in VoIP networks. The IP security (IPsec) protocol was defined by the Internet Engineering Task Force (IETF) to provide security for IP networks. IPsec is a large protocol suite designed to provide the following security services for IP networks: Data Integrity, Authentication, Confidentiality, and Application-transparent Security. IPSec secures packet flows and key transmission. Since we are interested in NAT and encryption, we’ll ignore most of the protocol suite including key exchange (IKE), and the various hash and encryption algorithms, and focus instead on the protocols that are used to secure packet flows.

The AH and ESP protocols can operate in two modes: Transport Mode can be visualized simply as a secure connection between two concurring hosts. In Tunnel Mode—more of a “VPN-like” mode—IPsec completely encapsulates the original IP datagram, including the original IP header, within a second IP datagram. ESP and AH normally are implemented independently, though it’s possible (but uncommon) to use them both together.

The Authentication Header (AH) and the Encapsulating Security Payload (ESP) are the two main network protocols used by IPsec. The AH provides data origin authentication, message integrity, and protection against replay attacks, but has no provision for privacy—data is not encrypted. The key to the AH authentication process is the inclusion in the AH header of an Integrity Check Value (ICV) —a hash based upon a secret key that is calculated over a subset of the original IP header fields, including the source and destination IP addresses. AH guarantees (if implemented correctly) that the data received is identical to the data sent, and asserts the identity of the true sender. AH provides authentication for as much of the IP header as possible, as well as for upper level protocol data. However, some IP header fields (SIP, DIP, TTL, CHKSUM, and optionally, TOS, FLAGS, and OPTIONS) change in transit. The values of such fields usually are not protected by AH. In transport mode, AH is inserted after the IP header and before the upper layer protocol (TCP, UDP, ICMP, etc.) header. In tunnel mode, the AH header precedes the encapsulated IP header. Figure 1 shows the AH transport and tunnel modes.

 
Figure 1: Authentication Header: Transport and Tunnel Modes

In Figure 1, sections A and B show the location of the AH header in transport mode. Sections C) and D show the location of the AH header in tunnel mode. The data field in all packets is not to scale (indicated by the double slanted lines). You can see from this figure that tunnel mode AH adds an additional 20 bytes to the length of each packet. None of the fields in this figure are encrypted.

Note

The key to the incompatibility of NAT and IPsec AH is the presence of the ICV, whose value depends partially on the values of the source and destination IP addresses, the IP header checksum, and either the TCP or UDP header checksum. The AH ICV calculation takes into account the mutable and predictable header fields that change as the packet moves from hop to hop through the network, but because intermediate devices do not share the secret key, they cannot recalculate the correct ICV after NAT has altered the aforementioned original header fields.

ESP, on the other hand, was used initially only for encryption; authentication functionality was subsequently added. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode).

Figure 2 shows the location of the ESP header in both transport mode (sections A and B) and tunnel mode (sections C) and D) for TCP (sections A and C) and UDP (sections B and D). In transport mode, the original IP header is followed by the ESP header. The rightmost field contains the ESP trailer and optionally, the ESP authorization field. Only the upper-layer protocol header, data, and the ESP trailer (also, optionally, the ESP authorization field) is encrypted. The IP header is not encrypted.

 
Figure 2: ESP Header: Transport Mode and Tunnel Mode

In transport mode, ESP encrypts the entire packet. This means that the entire original IP datagram, including the original IP and protocol header, is encrypted. In this mode, when IP traffic moves between gateways, the outer, unencrypted IP header contains the IP addresses of the penultimate source and destination gateways, and the inner, encrypted IP header contains the IP source and destination addresses of the true endpoints. However, even though ESP encrypts most of the IP datagram in either transport or tunnel mode, ESP is relatively compatible with NAT, since ESP does not incorporate the IP source and destination addresses in its keyed message integrity check. Still, ESP has a dependency on TCP and UDP checksum integrity through inclusion of the pseudo-header in the calculation. As a result, when checksums are calculated, they will be invalidated by passage through a NAT device (except in some cases where the UDP checksum is set to zero).

NAT traversal using ESP leads to a catch-22. NAT must recalculate the TCP header checksums used to verify packet integrity, because as was showed earlier, NAT modifies those headers. If NAT updates the header checksum, ESP authentication will fail. If NAT does not update the checksum, TCP verification will fail. One way around this, if the transport endpoint is under your control, is to turn off checksum verification, but I’m not aware of anyone who has done this in production environments. A second, more common means to do this is to NAT before IPSec; don’t perform IPSec before NAT. This can be accomplished by locating the NAT device logically behind the IPsec device. The most common form of NAT traversal used today relies on encapsulating IPsec packets in UDP in order to bypass NAT devices. The IPsec packet is encapsulated in a meta-UDP packet and the metaUDP packet is stripped off after it passes through the NAT device. This enables NAT and IPsec to function together but none of these are hardly elegant solutions.

NAT Has Three Common Modes of Operation

Depending upon networking requirement and topology requirements, NAT is manifested in one of three related modes. Static NAT refers to a one-to-one mapping or correspondence between internal and external IP addresses. In this case, the number of internal IP addresses equals the number of external addresses (see Figure 1).

 
Figure 1: Static NAT

The NAT device maintains a lookup table of internal and external addresses in order to manage translations in a stateless manner. Static NAT has utility in mapping the private internal IP addresses of critical infrastructure servers and network appliances to a unique globally available IP address.

Dynamic NAT in its original form consisted of an outside pool or collection of public IP addresses that were used on a first-come, first-served strategy (see Figure 2). Each unique single internal address could be used by any member of the outside pool to communicate with external Internet hosts. Consequently, the size of the outside pool member set limited the number of inside users that could connect externally. A built-in timeout mechanism allowed external pool members to be reused.

 
Figure 2: Dynamic NAT

The third and probably most common style of NAT is derived functionally from Dynamic NAT since it reuses a smaller pool or a single external IP address to proxy for all the internal IP addresses. This NAT is known by a number of names, including Network Address Port Translation (NAPT), Port Address Translation (PAT), Full Cone NAT (From the STUN RFC3489), hiding NAT, and masquerading NAT. This type of NAT (we’ll call it NAPT to keep things organized) works to preserve state by maintaining a lookup table of source IP, destination IP, source port, and destination port. This 4-tuple is almost always guaranteed to be unique within a given conversation stream. You’ll find NAPT operating in almost all home broadband and in most large enterprise networking scenarios. Figure 3 shows an example of NAPT.

 
Figure 3: Network Address Port Translation

So a normal scenario that occurs when moving TCP traffic between two domains running NAT at each edge is shown in Figure 4.

 
Figure 4: Normal NAT Process with TCP

In addition to these three NAT modes, STUN (we’ll see this later) has defined a three types of NAT that map more or less to these three modes. These are cone NAT, restricted NAT, and symmetric NAT. We’ll talk more about these in the section on STUN and TURN.

Section A of Figure 4 shows the TCP/IP packet header prior to NAT. After passing through the first NAT edge device (section B), the four header fields are modified: the three IP header fields—source address, destination address, and checksum—and the TCP header checksum. After passing through the second NAT edge device, the original header fields are regenerated (section C). The same is true for UDP in this situation, except that if the UDP checksum is zero, it will not be altered.

You may naturally ask by now, why is NAT such an issue for VoIP? Well, when we begin to combine NAT and protocols such as H.323 and SIP that partition the signaling and media channels; and, to make things even more interesting, embed IP addresses in the signaling channel, it will be important to understand how, when, and where NAT manipulates these fields. When we add encryption into the mix, NAT adds further complexity to these systems. Additionally, note that NAT stores its address mapping information in binding tables, and that these bindings are only initiated by outbound traffic. NAT breaks the choreography of SIP session flow. Encryption adds further complexity to these systems.

How Does NAT Work?

To a system on the Internet, a NAT device appears to be the source/destination for all traffic originating from behind the NAT device. Hosts behind a NAT device do not have true end-to-end Internet connectivity and cannot directly participate in Internet protocols that require initiation of TCP connections from outside the NAT device, or protocols that split signaling and media into separate channels.

A NAT device examines and records certain IP header information from each packet within an active IP connection. It uses these connection data to multiplex or demultiplex traffic depending upon the direction of the traffic flows. Multiplexing, in this case, means that two or more traffic streams are combined into a single outbound channel; demultiplexing refers to the process of separating a complex inbound traffic stream into single traffic streams (see Figure 1).

 
Figure 1: Multiplexing and Demultiplexing

NAT devices manipulate a subset of the IP header information. In order to comprehend the sometimes complex interaction of NAT, encryption, and VoIP protocols, you will have to understand the IP header fields and how they are altered during the NAT and encryption processes. It is not necessary for you to understand these concepts if you are concerned only with a NAT device’s ability to hide internal network topology from the Internet, but as part of the process of securing VoIP communications, this information is critical. Get to know the header diagrams shown in Figure 2. You’ll be seeing them frequently.

 
Figure 2: IP, TCP, and UDP Headers

Note that the rest of this section applies only to IPv4 packets. IPv6 resolves most of the following issues, but it just hasn’t caught on yet. The IP header normally consists of 20 bytes of data. The TCP header also normally consists of 20 bytes of data. An options field exists within each header that allows further bytes to be added, but normally this is not used. The UDP header is 8 bytes in length. Both the TCP and UDP headers reside in the data field of an IP packet. In Figure 2, the data field is to the right of the options field for IP and TCP headers and to the right of the CHKSUM field in the case of the UDP header.

NAT devices monitor, record, and alter the source IP address (SIP), destination IP address (DIP), and checksum (CHKSUM) fields within IP headers. NAT also modifies the checksum fields of bothTCP and UDP packets since these checksums are computed over a pseudo-header that conceptually consists of the source and destination IP addresses, and the protocol and length fields for TCP. The UDP checksum is calculated over a pseudo-header that consists of the source and destination IP addresses, the UDP header and data. As for ICMP Query packets, no further changes in the ICMP header are required as the checksum in the ICMP header does not include the IP addresses. These checksum fields will prove particularly troubling as we modify VoIP packets by encryption over NAT.

In response to the pseudo-header complexities, RFC1631 suggests that:

NAT must also look out for ICMP and FTP and modify the places where the IP address appears. There are undoubtedly other places, where modifications must be done. Hopefully, most such applications will be discovered during experimentation with NAT.

Though these were bright individuals it seems to me unlikely that they would have imagined that their complex solution would prove to be a major complication to end-to-end application availability on today’s contemporary internetworks. Figure 3 shows how NAT alters four header fields.

 
Figure 3: NAT Alters Four Header Fields

NAT and IP Addressing

Network Address Translation (NAT) is a method for rewriting the source and/or destination addresses of IP packets as they pass through a NAT device, which is often a router or firewall that separates two realms or domains on the Internet. NAT was first officially proposed (RFC1631) in 1994 as a temporary solution to the problems of IP address space depletion and the rapidly increasing size of route tables. Addresses, at that time, were divided into two classes: local and global addresses. Today we normally refer to these addresses as either private or public, and the private IP space often is referred to as RFC1918 addresses. Per RFC1918, the Internet Assigned Numbers Authority (IANA) reserved three blocks of the IP address space for private internets:

• 10.0.0.0–10.255.255.255 (10/8 prefix)
• 172.16.0.0–172.31.255.255 (172.16/12 prefix)
• 192.168.0.0–192.168.255.255 (192.168/16 prefix)

NAT commonly is used to enable multiple hosts on private networks to access the Internet using a single public (Internet routable) IP address. Note that although NAT most commonly is used to map IP addresses from internal private IP space to the public IP space, NAT can be used to map between any two IP address domains. Additionally, NAT provides a security function by segregating (hiding) private hosts from the publicly routed Internet. This short-term kludge has had an enormous impact on the day-to-day functioning of the Internet, and has special relevance to system administrators who are charged with securely transporting VoIP packet data across network boundaries.

QoS and Traffic Shaping

VoIP has strict performance requirements. The factors that affect the quality of data transmission are different from those affecting the quality of voice transmission. For example, data generally is not affected by small delays. The quality of voice transmissions, on the other hand, is lowered by relatively small amounts of delay. VoIP call quality depends on three network factors, as mentioned earlier:

• Latency The time it takes for a voice transmission (or any transmission) to travel from source to destination is increased as packets traverse each security node. Primary latency-producing processes are firewall/NAT traversal, negotiation of long ACLs, and traffic encryption/decryption.
• Jitter (erratic packet delays) Jitter may be increased, because in many circumstances, jitter is a function of hop count.
• Packet loss The number of non-QoS-aware routers and firewalls that ignore or fail to properly process Type of Service (ToS) fields in the IP header can influence packet loss.

In the absence of QoS or Traffic shaping, data networks operate on a best-effort delivery basis, which means that all data traffic has equal priority and an equal chance of being delivered in a prompt manner. However, when network congestion occurs, all data traffic has an equal chance of being dropped and/or delayed. When voice data is introduced into a network, it becomes critical that priority is given to the voice packets to insure the expected quality of voice calls. The mechanisms used to accomplish this are generically referred to as traffic shaping.

Traffic shaping is an attempt to organize network traffic in order to optimize or guarantee performance and/or bandwidth. Traffic shaping relies upon concepts such as classification, queue disciplines, scheduling, congestion management, quality of service (QoS), class of service (CoS), and fairness.

Common CoS models include the Differentiated Services Code Point (DiffServ or DSCP, defined in RFC 2474 and others) and IEEE 802.1Q/p. DSCP specifies that each packet is classified upon entry into the network. The classification is carried in the IP packet header, using 6 bits from the deprecated IP type-of-service (ToS) field to carry the classification (code point) information, which ranges from 0 through 63. Generally, the higher number equates to higher priority.

802.1Q defines the open standards for VLAN tagging. Twelve of the 16 bits within the two Tag Control Information bytes are used to tag each frame with a VLAN identification number. 802.1p uses three of the remaining bits (the User Priority bits) in the 802.1Q header to assign one of eight different classes of service (0 = low priority; 8 = high priority).

Quality of Service involves giving preferential treatment of particular classes or flows of traffic primarily by manipulating queues and scheduling. A service quality is then negotiated.

Examples of QoS are CBWFQ (Class Based Weighted Fair Queuing), RSVP (RESERVATION Protocol-RFC 2205), MPLS, (Multi Protocol Label Switching-RFC 1117 and others). CoS, or tagging, is ineffective in the absence of QoS because it can only mark data. QoS relies on those tags or filters to give priority to data streams.

Networks with periods of congestion can still provide excellent voice quality when using an appropriate QoS/CoS policy. The recommendation for switched networks is to use IEEE 802.1p/Q. The recommendation for routed networks is to use DiffServ Code Points (DSCP). The recommendation for mixed networks is to use both.

The main purpose of these technologies is to ensure that application performance remains satisfactory regardless of network conditions. In general, they all work by categorizing traffic into discrete subsets that are processed with different priorities. For this reason, QoS techniques may be useful in protecting VoIP networks from a significant security threat—Denial of Service. A number of authors have shown that some VoIP architecture components including IP telephones, SIP proxies, and H.323 gateways may freeze and crash when attempting to process a high rate of packet traffic. QoS can provide some security for these devices during DoS attack either by prioritizing unauthorized data low and/or by prioritizing VoIP high. This measure (security layer) will mitigate the consequences of a DoS attack on applications that share the same physical bandwidth.

The downside of all this is that traffic shaping is, at times, a stew of poorly interoperable technologies and techniques. This ad hoc nature makes a true end-to-end QoS strategy sometimes difficult to implement. If possible, provide enough bandwidth resources to meet the expected peak demands with a substantial safety margin. Note also that the implementation of some security measures can degrade quality of service.

These security-related complications are bulleted at the beginning of this section, and range from interruption or prevention of call setup by misconfigured firewall rules to encryp-tion-produced latency and delay variation (jitter). There is no single best method at present to optimize traffic shaping on VoIP networks without taking into account the relationship of these technologies with the security measures implemented within your environment.

VLANs and Softphones

Softphones present a security challenge in a VoIP environment, particularly if VLANs are employed as a major security control. Several popular softphones (such as X-Lite) store credentials unencrypted in the Window’s registry even after uninstallation of the program. Many softphones contain advertising software that attempts to “phone home” with private user information. Host-based IDS or firewall applications have limited use in this situation because softphones require that PC-based firewalls open a number of high UDP ports as part of the media stream transaction. Additionally, any special permissions that the VoIP application has within the host-based firewall rule set will apply to all applications on that desktop (e.g., peer-to-peer software may use SIP for bypassing security policy prohibitions).

---

Tools & Traps…—Watch What You Plug into That Phone

We recently observed a situation where plugging in a single phone brought down a substantial piece of the network, The IP phone had two RJ45 plugs in the back and a technician mistakenly plugged both of these into a nearby access switch running STP. No one realized (until later) that the IP phone failed to bridge spanning tree BPDUs. The resulting broadcast storm took out several core switches. This problem was solved temporarily with a bit of glue and some RJ45 plugs.

---

The most important rule for securing softphones is to harden the underlying operating system. Malware that affects any other application software on the PC can also interfere with voice communications. The flip-side is also true—malware that affects the VoIP software will affect all other applications on the PC and the data services available to that PC (a separate VoIP phone would not require access to file services, databases, etc.). Softphones that contain any type of advertising software must be banned in a secure environment Softphone installation targets should be tested before deployment and those that do not encrypt user credentials should be prohibited.

Because PC workstations are necessarily on the data network, using a softphone system conflicts with the requirement to separate voice and data networks since the principle of logically separating voice and data networks is defeated because the PC must reside in both domains. One solution to this is dual home workstations—dedicate one NIC to the data domain and one NIC to the voice domain. This arrangement still allows for possible routing of information between domains via a workstation. Cisco recently has introduced a Certificate Trust List (CTL) that contains among other information, the IP addresses of trusted VoIP peers. However, this feature is available only in selected IP phones and requires, for the most part, setup and maintenance of a complex certificate infrastructure. Additionally, unless complex host firewall rules are implemented, non-VoIP related data can enter the voice domain from workstations. Frankly, there is no single good security solution to the issue of softphones on workstations in split voice/data environments. In a highly secure environment, your best choice is to ban them via policy and monitor for illicit usage via IDS or IPS.

VLAN Security

VLAN and layer 2 security is a complex topic, partially because of the uneven support by switch vendors for appropriate datalink safeguards and because many of the exploitable vulnerabilities arise due to misconfiguration of available safeguards. The single most important rule with regard to this topic is to absolutely ensure that unauthorized individuals do not have access to the switch console. Additionally, terminal access to the console should either require strong authentication (RADIUS or AAA) and be restricted to a small set of management PCs, or should be eliminated altogether.

VLAN function depends upon the presence or absence of tag information. If the integrity of the tag information is assured, then the logical security afforded by VLANs is as legitimate as physical security. The key is to certify that tag information originates from the appropriate hosts and is unchanged in transit. A number of controls exist to verify this information such as ARP inspection, DHCP spoofing, VACLs (VLAN ACLs), private and dynamic VLANs, port security, and 802. 1X admission controls, but implementation of these is vendor specific and beyond the scope of this section. Additionally, the IEEE 802.1 Working Group has established drafts, particularly, 802.1aj, that decompose security when two related MACs are in a relay configuration.

VLANs | Logically Segregate Network Traffic

Logical separation of voice and data traffic via VLANs is recommended in order to prevent data network problems from affecting voice traffic and vice versa. In a switched network environment, VLANs create a logical segmentation of broadcast or collision domains that can span multiple physical network segments. VLANs remove the need to organize and manage PCs or softphones based upon physical location, and can be used to arrange endpoints based upon function, class of service, class of user, connection speed, or other criteria. The separation of broadcast domains reduces traffic to the balance of the network. Effective bandwidth is increased due to the elimination of latency from router links. Additional security is realized if access to VLAN hosts is limited to only hosts on specific VLANs and not those that originate from other subnets beyond the router.

VLANs, or virtual LANs, can be thought of as logically segmented networks mapped onto physical hardware. One or more VLANs can coexist on a single physical switch. The predominant VLAN flavor is IEEE 802.1Q, as defined by the IEEE. Prior to the introduction of 802.1q, Cisco’s ISL (Inter-Switch Link) was one of several proprietary VLAN protocols. ISL is now deprecated in favor of 802.1 q. VLANs operate at layer 2 of the OSI model. However, a VLAN often is configured to map directly to an IP network or subnet, which gives the appearance that it is involved at layer 3.

VLANs can be configured in various ways—by protocol (IP or IPX, for example) or based on MAC address, subnet, or physical port. They can be static, dynamic, or port-centric. Mechanistically, VLANs are formed by either frame-tagging or frame-filtering. Frame-tag-ging, the more common mechanism, requires adding and removing a unique, 2-byte L2 frame identifier so that switches may appropriately send and receive their cognate VLAN traffic. Frame-filtering relies upon the participating switches building and communicating a filtering database in order to forward traffic to its correct VLAN.

In Figure 1, dotted lines represent VLAN 2 and solid lines represent VLAN 10. The presence of the two lines that form a trunk between the top level switches should not be taken to indicate that there are two physical connections. Servers and workstations are logically isolated based upon their physical location. If a New York workstation requires the services of a Los Angeles server, then those data are routed between the top level switches.

 
Figure 1: Location-Based VLANs

In Figure 2, dotted lines represent VLAN 2, solid lines represent VLAN 10, and dashdot lines represent VLAN 100. The presence of the three lines that form a trunk between the top level switches should not be taken to indicate that there are three physical connections. In the network shown in Figure 2, broadcast traffic in the telephone subnet will not be seen by hosts in the workstation subnet.

 
Figure 2: Function-Based VLANs

VLANs provide some security and create smaller broadcast domains by creating logically separated subnets. Broadcasts are a common, sometimes noisy phenomenon in data networks. Creating a separate VLAN for voice reduces the amount of broadcast traffic (and unicast traffic on a shared LAN) the telephone will receive. Separate VLANs can result in more effective bandwidth utilization, and reduce the processor burden on IP telephones and PCs by freeing them from having to analyze irrelevant broadcast packets. Management traffic can be segregated on a management VLAN so that SNMP and syslog traffic do not interfere with data traffic. This also has the benefit of adding a layer of security to the management network. Additionally, VLANs can be used in conjunction with various quality of service mechanisms (see next section) to further isolate and prioritize voice traffic.

The consequences of DoS attacks can be mitigated by logically separating voice and data segments into discrete VLANs. Segregation of network traffic requires that IP traffic pass through a Layer 3 device, thereby enabling the traffic to be inspected at the ACL level. VLAN segregation forces any DoS packets through the ACLs on the layer 3 device. The use of packet filtering or stateful firewall inspection at these junctions also is recommended. As a side note, user authentication prior to the user’s accessing the telephony device also will reduce the possibility of internal DoS attacks.

Logically Segregate Network Traffic

One of the principal advantages of converging voice and data is to save money and to simplify administration and management by running both types of traffic over the same physical infrastructure. With this in mind, it is ironic that most of the engineering effort expended during the VoIP architecture design phase focuses on logically separating this same voice and data traffic.

Packetized voice is indistinguishable from any other packet data at Layers 2 and 3, and thus is subject to the same networking and security risks that plague data-only networks. The gen-eral idea that motivates the logical separation of data from voice is the expectation that network events such as broadcast storms and congestion, and security-related phenomena such as worms and DoS attacks, that affect one network will not impact the other. This is the principal consequence of compartmentalization.

In practice, system and security administrators have a number of options to realize this logical division. Packet headers can be manipulated in order to separate datagrams and datastreams at Layer 2, to provide certain classes of packets with preferential treatment or more bandwidth; and to alter source and destination IP addresses. Firewalls (particularly VoIP-aware firewalls), application layer gateways (ALGs), routers, and switches are inserted in the datapath to monitor and control traffic streams. Many devices now support robust access control lists (ACLs) that are used to fine-tune network and application access. Encryption is used often to ensure data and signal channel authentication, integrity, and privacy, but the encryption process results in subtle and not-so-subtle interactions with the methods that manipulate packet headers.

Maintaining and securing contemporary data and voice networks is complex stuff—something not recommended for naïve system administrators. Gone are the days when networks could be pieced together in an ad hoc fashion in order to support gopher, e-mail, and ftp. Modern VoIP/data networks must be designed to support a sometimes bewildering array of applications—all with their own unique service requirements and SLAs—in an open, yet secure environment.

To this end, in this chapter we look at the methods used to segregate voice and data into logically isolated networks that run over the same physical infrastructure. Figure 1 shows the components of this architecture. The primary elements of the security architecture are VLANs, QoS scheduling, firewalls, NAT and intelligent IP address space management, and ACLs. Encryption also plays a role in this. We will look at each of these technologies in more detail in the following sections.

 
Figure 1: Converged Reference Network

Figure 1 is a diagram of a VoIP/data reference network that illustrates the major security components involved in logical segregation of network traffic types. At the border between the Internet and the internal network, firewalls, ALGs, and router-based ACLs provide the first line of defense or security layer against illicit traffic and attackers. Within the internal domains, VLANs, QoS, private IP addresses, and NAT segregate VoIP traffic from other data network traffic, and VoIP-aware firewalls and router-based ACLs manage traffic between the two domains. Softphones may or may not span both domains depending upon an organization’s sensitivity to risk.