Connecting MPLS Voice VPNs Enabling the Secure Interconnection of Inter-Enterprise VoIP

Transcription

1 Connecting MPLS Voice VPNs Enabling the Secure Interconnection of Inter-Enterprise VoIP

2 Connecting MPLS Voice VPNs Enabling the secure interconnection of Inter-Enterprise VoIP Executive Summary: MPLS Virtual Private Networks (VPNs) are among the hottest technologies offered today by service providers for the secure transport of data, voice and multi-media services within a geographically dispersed enterprise network. This technology, in combination with IP telephony, is the basis of a service offering called the Voice VPN. Enterprise customers are using Voice VPNs as a means to drive down cost and increase integration between the handset, computer and mobile devices of the corporate user. For example, utilizing premised based IP PBXs and IP phones at all sites within the VPN allows the enterprise customer to bypass long distance toll charges when calling another enterprise location with the VPN. This is commonly referred to as On-Net to On-Net calling. However, voice traffic that leaves the enterprise, referred to as On-Net to Off-Net calling, must transit the PSTN. This requires a device called a media gateway, which connects the IP network to the PSTN at each location. Even if the On-Net to Off-Net call is destined for an enterprise that is also a Voice VPN customer the call still must transit the PSTN for security and billing purposes. This ties up expensive gateway ports and TDM transport facilities. It also degrades the voice quality, due to the fact that calls are converted from IP to TDM and back to IP (possibly a number of times). The goal of this paper is to explain, in detail, what technologies are required to enable costeffective On-Net to Off-Net calling between Voice VPNs without transiting the PSTN in a highly secure and scalable fashion. Page 1 of 11

3 Today s Enterprise VoIP VPN Today s enterprise VoIP VPN s are islands and only able to interconnect to other enterprise VoIP VPNs via the PSTN (See Figure 1). Figure 1: Today s MPLS Infrastructure for Enterprise Voice VPNs In examining this architecture the obvious question is Why is the PSTN needed when the call origination and destination is a VoIP endpoint between two enterprise Voice VPNs? Well, there are several valid reasons why this is necessary today in the carrier network. 1. Network Address Port Translation (NAPT) A VPN typically utilizes a private IP addressing scheme, which is not routable outside that VPN. To connect to another IP network such as the Internet, a router, illustrated as the NAPT Provider Edge (PE) device, translates and maps a private IP address to a public IP address which is then routable to any other reachable IP network. This scheme, described by RFC 1631, has been in place for years and works well for data applications. However, VoIP protocol suites such as H.323, MGCP and SIP that include IP address and port information in their message payloads are adversely affected by the use of NAPT. Most NAPT devices do not edit the contents of the IP payload (Layer 7 content), therefore the indicated IP address and port for media in a signaling packet will be ignored and the media (voice) will not pass through the router/firewall. Page 2 of 11

4 Figure 2: SIP Example - destination address and port of the media is embedded in the SIP payload, which current NAPT devices cannot translate. Compounding the NAT problem is the fact that it is common for Voice VPN customers utilizing private IP addressing schemes to have overlapping IP addresses. For example, VPN-1 and VPN-2 could in fact have IP Phones with the same IP address making it impossible to route calls between them. Even if the NAPT PE device illustrated below had the capability to solve these problems it would still be routing the voice to a public IP network, allowing enterprise voice traffic to be vulnerable to hackers that can easily eavesdrop and place unauthorized calls over the enterprise network s resources. Figure 3: Current deployment architecture for Firewall and NAT devices 2. Security Voice VPNs are implemented in a manner that prohibits any Inter-Enterprise communication for security purposes. This allows all traffic within the Voice VPN to be Page 3 of 11

5 considered trusted, therefore once a user is authenticated and authorized onto the network no further security policing, such as a firewall, is required for that user to communicate with all locations within the Voice VPN. To enable interconnection of Voice VPNs, service providers will need to interconnect trusted networks together and must ensure that there is a secure boundary (firewall) between the Voice VPNs - protecting the enterprise networks from security threats. The most recognized threats to a Voice VPN are: Denial-of-service (DoS) attacks: Prevention of access to a network service by bombarding IP PBXs, IP Phones or media gateway devices on the Voice VPN with unauthorized packets. Eavesdropping: Unauthorized interception of Real-Time Transport Protocol (RTP) media streams and decoding of signaling messages for the purposes of listening to the calls or learning the IP network topology of the Voice VPN or service provider networks. Unauthorized access: Impersonation of a legitimate user allowing the hacker to gain access to enterprise network resources to place unauthorized phone calls. Another security requirement the service provider must address is how to ensure privacy when voice traffic must transit a public non-trusted network. As mentioned earlier, private IP addresses must use a NAPT function to be mapped to a public IP address before the packets can be routed to another enterprise Voice VPN. Most enterprise customers see this as a major security concern and mandate that all voice traffic transiting a public IP network must be encrypted. The use of RTP encryption and IPSec is an option but very complex and costly for the service provider to administer and maintain. Also, these technologies typically do not interoperate in the multi-vendor environments deployed within the enterprise networks. Of course the carrier VoIP network elements such as proxy servers, gatekeepers, and media gateways must be protected from these types of attacks originating from a Voice VPN customers network as well. Traditional routers and firewalls do not meet these VoIP security requirements. 3. Billing Without traffic traversing the PSTN how can the service provider generate call detail records (CDR) needed to capture revenue for the origination/termination of the On-Net to Off-Net calls placed between the Voice VPNs? 4. Call Admission Control (CAC) How can the service provider create and enforce a Service Level Agreement (SLA) for each Voice VPN customer, which limits the number of calls or amount of bandwidth the Voice VPN is allowed to use on the IP network in a manner similar to the way they can today with a TDM trunk connection to the PSTN? MPLS routers are not session aware and cannot offer this capability on a call-by -call basis, which is required for Call Admission Control (CAC). Since voice is real-time traffic it is imperative that it is policed at the point of ingress onto the service provider s network to ensure that the authorized calls have adequate network resources to guarantee toll quality. Without this capability honoring a Voice VPN SLA is not possible. Page 4 of 11

6 It is clear that with existing router and firewall technology, service providers cannot overcome the critical obstacles of: NAT traversal, NAPT, overlapping IP addresses, security, billing and admission control. Connecting even two enterprises introduces new requirements. Because existing products cannot meet these requirements, a new product category has risen to the challenge Session Controllers. Session Controllers reside at the edge of the service provider s network and are a highperformance, high-capacity critical network element that handle both signaling and media. Session Controllers meet the requirements for interconnection by delivering security, QoS mediation, and management (session detail records for billing and reconciliation) for the peering of VoIP networks. They support service provider SIP and H.323 networks and complement existing network infrastructure such as MPLS routers and Layer 3 and 4-aware firewalls. Page 5 of 11

7 Netrake ncite Session Controller Enabling the secure interconnection of Voice VPNs A Session Controller is a new network element that provides carrier grade, secure, protocol aware session based network address/port translation, hosted Voice VPN firewall, session admission control and session detail records for real time, multi-media communications such as IP telephony. With a session controller, interconnecting Voice VPNs is now possible as illustrated in Figure 4. Figure 4: The deployment of session controllers within existing MPLS VPN networks is seamless How the Hosted Voice VPN Firewall works The ncite Session Controller connects to the provider edge (PE) MPLS router via gigabit ethernet interfaces. The PE router sets an 802.1q VLAN tag, which correlates to a Voice VPN within the MPLS network on all packets routed to the ncite. Through the use of the 802.1q VLAN tags the ncite is able to support overlapping private IP addresses used in the Voice VPNs via a virtual interface. Each Voice VPN uses a unique virtual interface configured on the ncite which acts as an outbound proxy, in the case of SIP, for the Voice VPN and performs SIP proxy 1, media anchoring* and registration binding* for the sessions. This places the ncite in the signaling and media path for all voice traffic routed between the Voice VPNs where it serves as a firewall protecting the Voice VPNs from the VoIP security threats such as Denial of Service attacks, flood protection, Rogue RTP, etc. The ncite also performs the following critical tasks to enable the secure interconnection of the Voice VPNs. 1 *For a more detailed explanation of the ncite s SIP features please read Page 6 of 11

8 1. Network Address Port Translation (NAPT) Figure 5: Hosted Firewall - The ncite is seamlessly deployed into existing architectures and dynamically opens/closes pinholes and performs NAT bindings to allow authorized traffic through The ncite performs NAPT of the layer 3 IP addresses as well as the IP address and port information in the message payloads of SIP and H.323 protocols. The ncite has a virtual network that contains a pool of registered public IP addresses to interconnect all virtual interfaces in the system.. When a voice packet arrives on a virtual interface, the ncite requests an address/port pair from the pool and translates the Voice VPNs private IP address to a public IP address allowing it to be routed to the destination Voice VPN. The ncite then creates a pinhole through the Voice VPN firewall for the duration of the call. Once the call is complete the pinhole is closed in the firewall and the ncite releases the IP address/port pair for future use. 2. Security The ncite acts as a hosted Voice VPN firewall within the carrier network providing protection from the most important threats to a Voice VPN: Denial-of-service (DoS) Attack Prevention The ncite also detects a sophisticated form of DoS attack called Rogue RTP. Rogue RTP is defined as receiving RTP traffic from multiple sources matching the open pinholes of an active call. What makes it difficult to detect is that in most cases this may be a legitimate function of the voice network, such as a media server injecting RTP packets into an active call mid stream to provide music while the call is on hold or a gateway fails over to another device. Or, in some cases, this could be a hacker that guessed the IP address/port of an active call and is injecting inauthentic RTP packets for the purposes of disrupting the call. Due to the varying scenarios, this situation makes it impossible to guarantee the sending and receiving of IP addresses and port numbers of all RTP packets will be the same for Page 7 of 11

9 the duration of the call. Therefore, configuring an ACL that includes source IP address and source port during the authentication process to prevent Rogue RTP is not possible. The ncite algorithm that detects the occurrence of Rogue RTP is called Late Rouge Detection (LRD). LRD is based on RTP arriving from multiple sources for longer than a configurable time and by performing RTP header validation for each packet. Each RTP packet is compared against expected value of the Source IP Address, Source Port, RTP version number and RTP sequence number. Since it is possible for the RTP packets to arrive out of sequence the RTP sequence number is checked to make sure it is within the range of expected sequence numbers. Any changes to these parameters indicate signs of rogue RTP activity. Once the RTP session is declared rogue, the source IP address and source port of the senders along with the reason for declaring the stream rogue is recorded and an alarm is generated. The ncite informs the operator with appropriate parameters to identify the call and allows the operator to monitor the call while in progress or terminate the call if necessary. The IP address/port used for the pinhole can then placed on a quarantine list, so no future calls will use the pinhole that has been compromised until the operator can make the necessary policy changes to block the hackers access to the network. Eavesdropping The ncite Session Controller is a completely secure network element with a pool of IP address/port pairs that change dynamically on a call-by-call basis as the calls are routed between Voice VPNs. This virtual network in not accessible or known to anyone other than the service provider provisioning the network and the two VoIP endpoints participating in the call. Hence, the RTP (voice) never traverses a public network and requires no RTP encryption for the media or IP Sec tunnels between VPNs to ensure security. This meets the Voice VPN customer requirements for security and greatly simplifies the provisioning and maintenance for the service provider. Unauthorized Access Prior to dynamically opening a pinhole through the existing firewall, ncite performs the session admission control (SAC) function to authenticate the call. ncite opens pinholes by matching 3 tuples (Destination IP Address, Destination Port, and Protocol) against an access control list (ACL) for the Voice VPNs. Once the call is authenticated, ncite performs SIP, H.323 and RTP message validation on each packet in the session and disallows any unauthorized or suspicious packets from passing through the firewall. 3. Billing. The ncite generates session detail records (SDRs), which may be imported by the carrier billing system to capture the origination/termination revenue for all calls routed between Voice VPNs. Since the ncite anchors the media for calls routed between Voice VPNs, the SDR contains detailed information pertaining to the quality of the call. Network conditions such as delay, jitter and packet loss are reported enabling the operator to troubleshoot call quality issues in real-time. Below is a partial SDR. Page 8 of 11

10 Netrake ncite Session Detail Record (SDR) callinghost calleduser calledhost callendstate callstarttime callendtime callduration callingsrcip callingdestip callingflowpacket callingminlatency callingmaxlatency callingavglatency callingavgjitter calledsrcip calleddestip terminatingip calledflowpacket calledminlatency calledmaxlatency c.net c.net c.net c.net c.net c.net Session Admission Control. When a Voice VPN customer is provisioned on the ncite, the operator specifies a virtual line count for that customer. The virtual line count equates to the number of concurrent calls that specific Voice VPN customer is allowed to route through the ncite. When the virtual line count limit is exceeded the ncite can be configured to enforce SLA s by doing the following: Generate a busy message and send to the call initiator. Allow the call and flag the SDR indicating a violation of SLA. This flag can then be used to trigger a premium charge for all calls exceeding the SLA in the carrier billing system. Downgrade the QoS and allow the call through a best effort route. The ncite enables this utilizing diffserv packet marking on all packets routed to the MPLS network where they can be placed on the appropriate LSP per the service providers MPLS trafficengineering scheme. Calls are admitted based on source address, destination port, destination address, and protocol using 3- or 4-tuple admission control. Page 9 of 11

11 Summary The ncite Session Controller is a new class of network infrastructure product that enables service providers offering MPLS VPNs the ability to overlay real-time, peer-to-peer multimedia applications such as IP telephony onto their existing network architecture. By combining the critical functions discussed in this paper into a single scalable, manageable and highly available system the ncite greatly reduces the CAPEX and OPEX associated with other multi-box solutions on the market. ncite can also be utilized by the service provider to enable several other applications such as; Wholesale VoIP origination/termination with other carriers Secure instant messaging with push to talk capabilities Secure video conferencing Hosted Media Gateway Hosted Communications Services such as IP Centrex, Presence, Conferencing and Call Centers Firewall traversal solutions for enterprise and consumer product offerings that utilize a public IP network Finally, the ncite Session Controller is easy to deploy, simply requiring its components to be positioned in the communication path in the servi ce provider and each corresponding enterprise network. The solution provides complete transparency and anonymity for existing network communication devices - none of the devices have to change their behavior. The Netrake solution ensures secure traversal of real-time communications and enables communication service providers to deliver valuable, secure products and services to their enterprise customers.. Page 10 of 11