DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

 

In this section:

 

Recommended Deployment Topologies

The SBC and the Firewall: Serial vs. Parallel Deployment

The discussion of deploying Session Border Controllers and firewalls is a complex topic that many find interesting. The development of the SBC primarily occurred due to the specific media and messaging related deficiencies of general purpose firewalls.

SBCs and firewalls differ in several aspects. General purpose data firewalls have historically experienced poor SIP support and are known to cause problems with SIP call flows. Another weak spot for firewalls is Real Time Protocol (RTP) support. If a firewall cannot automatically open and close UDP ports for RTP (signaled within SIP, which could be a SIP limitation of the firewall), then the firewall requires forcing open a large range of UDP ports.

Another firewall consideration is performance and throughput for RTP flows. Regardless of RTP UDP port support (dynamic or static), sizing of the firewall is paramount to account for all of the simultaneous RTP flows the network must sustain. A firewall properly sized for RTP traffic may be significantly more expensive than a firewall that does not need to accommodate Voice over IP (VoIP) and Unified Communications (UC).

Most networks supporting VoIP/UC will likely deploy both firewalls and SBCs, but considering an SBC is essentially a purpose-built firewall and general purpose firewalls can perform poorly for VoIP/UC, the SBC is typically deployed in parallel, rather than in series, with a traditional data firewall.

Parallel Deployment Model

 

Deployments using a serial configuration generally apply when the limitations of the firewall are less of a concern due to smaller performance and capacity requirements of those environments.

Serial Deployment Model

 

 

While they still need to be sized appropriately and cannot take the place of an SBC, newer "next-generation" firewalls can provide some synergies with an SBC . In addition to support for security orchestration or coordination with the SBC (e.g. dynamic information sharing), some next-generation firewalls can also support identity and signature-based detection of SIP and Media payloads. These new capabilities can change the deployment equation towards an SBC deployed in series.

Whether an SBC is deployed in series or in parallel with a firewall, additional security measures (defense in depth) may be available via static IP address-level filtering at the router connecting the DMZ to the external networks. This filtering is dependent upon the exact capabilities and performance of the router.

Securing the Network Interfaces

List of open/required ports

Refer to SBC Core Network Listener Ports for a listing of open and required ports.

Management Interfaces

Most Ribbon SBC Core products have three distinct types of user-configurable Ethernet interfaces:

  • Media Ports – Signaling and media
  • Management Ports – Normal management of the SBC (monitoring, troubleshooting, etc..)
  • Field Service Port – Access to the Baseboard Management Controller (BMC), an IP out-of-band interface

While the security configuration of each type is covered separately within this document, this section focuses on the non-Media ports.

For a general overview of all the SBC Core products interfaces and network-level deployment information, refer to the Ribbon Networks Deployment Guide for the SBC Core product in question.

Management Port Configuration

Management functionality, such as ssh, https, RADIUS, etc., on SBC Core products is only available via the dedicated Management Ethernet ports; no user configuration is necessary to prevent management functions from being accessible via the Media Ethernet ports (and no user configuration can allow management functions via the Media ports).

For production deployments, Ribbon recommends connecting Management ports to an IP subnet which is separate from the Media ports, and ensuring the Management subnet is a nonpublic, company-internal network, accessible only to authorized users. As most customers deploy SBC Core products with the Management ports connected to a non-public, company-internal, managed network dedicated to OAM uses (e.g. not connecting these ports directly to the Internet), 

Internal firewalling of the Management subnet is not required. Ribbon is aware of customers using firewalls separating various parts of their OAM network and managing their SBC Core products through those firewalls without any issues.

The management ports on the SBC 5000 series and 7000 series platforms are protected by the same wire-rate-capable, NP-based ACL and policing mechanism that is used on the Media ports. All Ribbon SBC Core products provide users the option to augment the default, dynamic, system-level ACLs (created for available services, e.g. ssh) on the Management ports with their own additional ACLs (e.g. to only allow ssh access from specific endpoints or subnets within their private, corporate network).

Some small, remote sites may not warrant a private carrier connection (e.g. MPLS) back to the company's core network. In such an environment, and even larger ones, Ribbon has seen customers utilize IPsec VPN appliances to provide a secure IP connection for the management traffic of all the devices at the remote location, when the only available or economical network connection to the site is public.

If Management ports are deployed on a publicly accessible network, then Ribbon strongly suggests creating Management port user-level ACLs to limit the management functions to only specific IP endpoints that the user will manage the SBC from. Ideally in that situation, the IP endpoints would be from very separate IP blocks, to help maintain management availability during Internet routing instability.

Protection of the management interfaces via network isolation and the use of ACLs provides part of a defense-in-depth protection scheme. Protecting the management interfaces is important because many of the threats in the SBC threat model (summarized earlier) involve access through the system management interfaces.

The default Ribbon SBC Management functions do not require Internet connectivity; however, two optional SBC management functions do require internet connectivity: SecureLink and machine-to-machine (M2M) communications. Even though these necessitate Internet connectivity, no pinholes or other inbound firewall rules are required as these are outbound-only functions controllable by the user. More information about these functions are covered later in this document.

Field Service Port Configuration

The Field Service Ethernet port, unavailable on the SBC SWe1, provides network access to the Baseboard Management Controller (BMC) of the SBC. The BMC is a specialized micro-controller embedded in the hardware-based SBC Core products. The BMC network interface (Field Service port) is not seen by the SBC application software as it provides a lights-out, IP out-of-band style interface (i.e. iLO, ILOM, NET MGT, etc...) to the platform. The serial port provides a serial CLI connection to the BMC, but as its a functional subset of Field Service, the serial console is usually considered a backup mechanism (especially as it can be out-of-band for all IP networking, but securing such a terminal service is outside the scope of this document).

As the use of the Field Service port as the primary mechanism for out-of-band connectivity and hardware maintenance (e.g. power cycling, etc.), Ribbon strongly recommends users to provide the same network isolation and protections (or better) to the Field Service port that they provide to the Management ports. Many customers collocate the Field Service and Management ports in the same IP subnet for simplicity, but others put the Field Service port in a dedicated "Out of Band" subnet (which typically also hosts the iLO, iLOM, etc. ports from servers). If the Field Service port is located in an IP subnet separate than the Management ports, Ribbon recommends allowing some IP connectivity between the subnets, (e.g. when authorized by the customer, a Ribbon TAC or PS engineer can use SecureLink on the active SBC node to reach the BMC of the standby node for troubleshooting or upgrade activities).

Protecting the field service ports is important because access to the field service port will also provide access to the primary management interfaces.

If Management ports are deployed on a publicly accessible network, then Ribbon strongly recommends that the Field Service port be located in a separate network with no IP connectivity to the Management ports, or that the Field Service port not be network connected at all. 

1 – Securing console access for virtualized deployments should follow standard practices for any virtualized appliance.

Management Certificates

By default, the Ribbon SBC is shipped with a self-signed X.509 certificate to enable initial HTTPS management of the system. This may get flagged by some security scanning tools. Ribbon recommends replacing these certificates with CA-signed certificates. The SBC allows the user to upload their own certificates.

For additional information, refer to:

 

High Availability Ports

The Ribbon SBC features dedicated High Availability (HA) Ethernet ports to enable nodes to operate in a 1:1 highly redundant system. There is no user configuration of the HA ports themselves. These ports are normally cabled directed between both nodes in an HA pair. If the SBC is deployed in a Geographically Redundant (GR) manner that cannot support direct fiber connections for the HA ports, care must be taken to ensure that secure, completely transparent Layer 2 connectivity is used for the the HA ports. Refer to the SBC Geographic Redundancy Deployment Guide for more details on GR scenarios.

SBC Software Edition (SWe)

The SBC SWe also features a single dedicated HA interface (vNIC) which should connect to a dedicated vSwitch. Ribbon recommends that separate vSwitches are used for each SBC vNIC type and that each vSwitch be associated with a unique physical NIC port (or ports if the hypervisor support NIC teaming for physical interface redundancy). This recommended configuration should ensure that a direct HA connection is used for both SWe nodes operating in an HA pair. If direct HA connections are not used, then the user is advised to use secure, completely transparent Layer 2 connections. In such a virtual environment, refer to Enabling Geographical Redundancy HA Mode for additional insight even though the SBC SWe nodes are not technically geographically separated.

SecureLink/Remote Access coverage (TAC vs. M2M)

SecureLink is an optional, fully-supported, third-party tool that allows a user to provide Ribbon remote access to the SBC for specific Ribbon TAC or Professional Service work, or for periodic M2M communication (that may prove useful for Monitoring or other service offerings).

The user can install the SecureLink Gatekeeper client application on the SBC 5000/7000 series platforms or alternatively install it on a server or a server-based Virtual Machine. Each SecureLink installation requires a unique registration code from Ribbon. The SecureLink Gatekeeper periodically pings the Ribbon server to determine if a secure remote access connection is requested. Under normal circumstances this attempt to establish a connection is declined by the Ribbon server. This outbound communication is done using the SBC Management ports, using the IP addresses assigned to those interfaces. As all communication is outbound, no firewall pinholes or other inbound rules are required.

When an authorized Ribbon service engineer wishes to access the managed device, the engineer registers that intent with the Ribbon SecureLink server. The next time the client polls the server, a secure connection is established between the client and server. The Ribbon SecureLink server brokers an encrypted ssh tunnel over TCP port 22 (if unavailable, alternatively TCP port 80) to the client from the user.

The SecureLink Gatekeeper is configurable by the user with the following options.

  • real-time notifications of any Ribbon connections
  • audit trail reporting
  • configurable privileges to the vendor
  • enabling/disabling by the user (for ad-hoc authorized access)

Resiliency

The resiliency of a service is impacted by the availability of the nodes helping to provide that service. Ribbon strongly recommends deploying the SBC as a High Availability (HA) system to help maximize uptime of services. For guidelines on the deployment of an HA SBC system, refer to the Ribbon Networks Deployment Guide for the SBC Core product in question.

Link Detection and Gateway Polling

The Link Detection functionality on the SBC enables users about physical and logical link failures (Management or Media) to trigger a SBC switchover for link redundancy. Ribbon recommends configuring only one Link Detection Link Monitor (LM) per physical Ethernet interface. In addition to participating in node-level HA, Link Detection is also the same mechanism that facilitates the use of local standby Media ports on the SBC 7000.

Refer to Link Verification Configuration for an example of Link Detection configuration using Ribbon best practices.

 

In addition to physical port integrity, the user can also configure the SBC to probe a subnet-local IP address to determine logical connectivity. On all SBC Core products, active interfaces use ICMP Echo Requests to test the destination IP configured. The SBC 7000 augments this functionality with the ability to test the destination IP via an ARP Probe (RFC 5227) on all standby Media ports; ICMP Echo Requests are still used for probing on active interfaces on the SBC 7000.

Physical Link Redundancy

All Ribbon SBC Core products provide redundant physical links via the Standby SBC node in an HA system. This allows for switchovers with no impact to capacity. Media ports operate in an active/standby mode, while all Management ports are active and uniquely addressed, both on the active and standby SBC nodes.

The SBC 7000 also has optional, dedicated Media standby ports on both the active and standby nodes in an HA system. When a Media port or link fails, the SBC fails over to the local standby interface. The use of these dedicated Media standby ports have no impact to system capacity, ACLs, or QoS, so Ribbon recommends that they be used whenever possible to provide additional resiliency and redundancy.

For more information on Physical Links and Link Redundancy, refer to the Ribbon Networks Deployment Guide for the SBC Core product in question.

 

 

  • No labels