Topology Enforcement

Topology Enforcement protects the managed network and provides seamless interworking functions. The SBC Core implements topology enforcement by hiding network addresses and names for both the access and backbone (network core) sides, and by implementing traffic filtering to prevent malicious attacks.

Address and Topology Hiding

The SBC hides network internals (private addresses, network topology, etc.) by acting as a B2B UA. Trunk Groups are employed at the network edge to manage call admission, traffic controls, etc. between the carrier network and the peering partner; consequently, all call signaling traffic is routed through the SBC. Similarly, RTP Relay allows media flows to be proxied through the SBC. Thus, the SBC translates IP addresses and ports for signaling and media streams that traverse the system to hide the core network addressing schemes and translations.

Traffic Filtering

The two main objectives for traffic filters in any SBC configuration are:

• Anti-spoofing—prevent externally-originated traffic masquerading as a trusted network source. The SBC achieves this by implementing disjointed networks (see "Disjointed Networks" below).
• Access control—allow only packets to legitimate destination addresses/ports that are from predefined source addresses/ports. The SBC filters incoming packets at wire-rate using IP Access Control Lists (ACL). See IP ACL Policing - Packet Filtering  for more information on IP ACL.

Disjointed Networks

Where networks of different levels of trust must be interconnected, the prevailing security model is to create a "gate" through which all inter-network communication must pass: a single point (or very limited number of points) at which security policy is enforced. From the perspective of a given network, communications initiated from an external untrusted network into the trusted network are of greatest concern. Thus, accepted practice is to deploy a "demilitarized zone" (DMZ) network containing the only hosts the untrusted network can directly access. A filtering device (firewall appliance or filtering router) with three interfaces is then employed to enforce different rules for the permissible communication flows:

• Directly between the trusted and untrusted network.
• Between the untrusted network and the DMZ network hosts.
• Between the DMZ network hosts and the trusted network.

Where more than one DMZ Host is required (DMZ Hosts are typically application-specific) an Ethernet switching fabric is often used to provide separation between DMZ Hosts while maintaining the "three-legged" filtering topology.
As a general rule, DMZ networks should be addressed outside of the public (IANA registered) IP address space, regardless of whether the trusted and untrusted networks employ private (RFC 1918) or public addresses internally.  

Figure 1 illustrates a generic DMZ network configuration and the filter rules for externally initiated communication flows.

Figure 1: Generic DMZ Network Configuration

The most common example of a DMZ network configuration is where the trusted network is the intranet of a private enterprise and the untrusted network is the public Internet. In such a configuration, externally-initiated communication flows (e.g., incoming e-mail messages) are typically required to traverse the DMZ Hosts (e.g., SMTP servers); internal users within the trusted network are, however, often allowed to initiate communication directly with hosts in the untrusted network (e.g., an Internet web server).

The desire to maintain security that is unobtrusive while internal users are permitted to access a wide variety of applications greatly complicates the task of the filtering device. This complexity is further compounded by a host of application protocols that separate signaling from media flows requiring the filtering device to be sufficiently application-aware that it be able to detect which protocols, addresses and ports are negotiated in the signaling flow in order to correctly admit the corresponding data flow(s) yet deny any "rogue" flows. Consequently, for a private enterprise's connection to the public Internet, a general-purpose firewall appliance is typically employed as the filtering device.

The SBC differs from this private intranet/public Internet case in several important ways:

• If an SBC is positioned between two private networks as well as between a private network and the Internet, the level of trust (or distrust) between two private networks may be significantly different from that relative to the public Internet. For example, a common Border Switching application is a dedicated peering connection between two carrier networks that have established a bilateral agreement specifically to exchange VoIP traffic.
• The characteristics and performance requirements of VoIP traffic differ significantly from general Internet traffic, which is largely comprised of non-realtime-critical services such as web browsing and email. General-purpose firewall appliances are typically based on commercial server platforms that may not exhibit the same low latency and jitter of hardware designed specifically to support VoIP traffic.
• When two VoIP peers interconnect, the administrative authority for each network generally considers the respective peer as the untrusted party. As a result, back-to-back DMZ network configurations are often deployed such that each administrative authority is responsible for its own filters, DMZ hosts, etc.

In summary, criteria and tradeoffs specific to SBC must be considered in the design of a packet peering connection's DMZ.

SBC in a DMZ Host Configuration

In an SBC network, interconnections are largely used for packetized voice. As a result, the Access Control List features of prevalent IP routers are sufficiently capable to perform the requisite filtering functions as a dedicated DMZ Router, while the SBC fulfills the role of DMZ Host. This combination of DMZ Router and DMZ Host provides the layered security model typical of firewall configurations. Use of a high-performance IP router rather than a firewall appliance also has the advantage of eliminating the risk of increased latency and/or jitter associated with general-purpose firewall products.

This configuration also permits other services to share the physical packet peering connection by deploying additional, application specific DMZ Hosts in parallel with the SBC, as well as appropriate DMZ Router filters. The SBC in a DMZ Host configuration is illustrated in Figure 2 .

Figure 2: SBC in a DMZ Host Configuration

In this configuration, one or more SBC interfaces support both internal (to/from the trusted network) and external (to/from the untrusted network) data flows concurrently. As a result, there must be no overloading (duplication) of IP addresses across:

• the carrier private network,
• the DMZ,
• and the devices reachable in the peering partner.

If, however, back-to-back DMZ network configurations are deployed (i.e., each administrative authority considers its respective peer to be untrusted), and those DMZ networks each adopt the accepted practice to employ public IP addresses, then there are no addressing conflicts even if both peer networks are numbered using the same address space internally.

Other infrastructure systems, such as the Insight Element Management System (EMS), PSX Policy Servers, and NFS Servers are required for the SBC to function normally in this scenario. While Insight is typically deployed at a remote location within the trusted network, other systems may be physically co-located with the SBC for operational and/or performance reasons depending on the overall network design, PSX Policy Servers may also be co-located or deployed at a remote location within the trusted network. However, in all cases communication with infrastructure systems should employ dedicated interfaces on the SBC.

Furthermore, traffic should be separated from the DMZ network either physically (using separate Ethernet switches and routers) or logically (using separate VLANs on shared Ethernet switches) such that the infrastructure systems are not directly accessible from the untrusted network.

Media Pinholes

To preserve this privacy and security model for media flows, the SBC implements an RTP Relay using pinholes. In RTP Relay, the call endpoints send media packets to an address/port on the SBC. As the media packets flow through the SBC, the source and destination addresses are changed to make the SBC always one of the endpoints in each call leg. Thus, the internal topology of the managed network is not exposed, and inbound media flows are directed only to a limited set of well-defined SBC addresses.