Designing a Zero-Trust Network Architecture for Cloud-Hosted SIP Infrastructure

How-To-Articles
1

Designing a Zero-Trust Network Architecture for Cloud-Hosted SIP Infrastructure

What This Guide Covers

You are migrating your enterprise telephony infrastructure from an on-premise PBX connected via physical MPLS lines to a BYOC (Bring Your Own Carrier) Cloud model, integrating your corporate Session Border Controllers (SBCs) directly with Genesys Cloud over the public internet. When complete, your architecture will adhere to Zero-Trust principles: utilizing strict mutual TLS (mTLS) for SIP signaling authentication, dynamic port restriction for RTP media, and SRTP for media encryption, ensuring that even though your voice traffic traverses the public internet, it is completely secure from eavesdropping, SIP flooding, and toll fraud.

Prerequisites, Roles & Licensing

  • Genesys Cloud: Any CX tier with BYOC Cloud enabled.
  • Permissions required:
    • Telephony > Trunk > Add, Edit
    • Telephony > Location > Edit
    • Telephony > Edges > View
  • Infrastructure:
    • An enterprise SBC (e.g., AudioCodes, Ribbon/Sonus, Cisco CUBE) deployed in your DMZ or public cloud VPC.
    • A publicly trusted SSL/TLS certificate for your SBC.
  • Understanding: SIP signaling, RTP/SRTP media, and public key infrastructure (PKI).

The Implementation Deep-Dive

1. The Death of the “Trusted Network”

In a legacy on-premise architecture, security was achieved by drawing a perimeter: “The PBX is on VLAN 10, the SBC is on VLAN 20, and a firewall sits between them and the carrier. Everything inside is trusted.”

When moving to BYOC Cloud, that perimeter dissolves. Your SBC must accept inbound connections from Genesys Cloud over the public internet. If you simply open UDP port 5060 to the internet and “trust” the IP addresses of Genesys Cloud, you are vulnerable to IP spoofing and DoS attacks.

Zero-Trust dictates: Never trust the network. Always authenticate the endpoint.

2. Securing SIP Signaling with Mutual TLS (mTLS)

To establish a Zero-Trust SIP connection, we replace unencrypted UDP/TCP SIP with TLS. Crucially, we must use mutual TLS (mTLS).

  • Standard TLS: The SBC verifies the Genesys Cloud certificate to ensure it’s talking to the real Genesys Cloud. (Protects against Man-in-the-Middle).
  • Mutual TLS (mTLS): Genesys Cloud also requests the SBC’s certificate and verifies it against a list of trusted Certificate Authorities (CAs). If an attacker connects to your SBC claiming to be Genesys Cloud, their connection drops during the TLS handshake because they don’t possess the private key of a trusted certificate.

Genesys Cloud Configuration:

  1. Navigate to Admin > Telephony > Trunks.
  2. Create a new BYOC Cloud Trunk.
  3. Protocol: Select TLS. Do not select TCP or UDP.
  4. Port: Standard TLS port is 5061.
  5. Inbound Configuration (Genesys → SBC): Enter the Fully Qualified Domain Name (FQDN) of your SBC (e.g., sbc-east.yourcompany.com). Do not use an IP address; TLS validation requires an FQDN to match the certificate Subject Alternative Name (SAN).
  6. Outbound Configuration (SBC → Genesys): Genesys Cloud provides a unique FQDN (e.g., yourorg.byoc.use1.pure.cloud).

SBC Configuration (AudioCodes Example):

  1. Generate a CSR and obtain a certificate from a public CA (e.g., DigiCert, Let’s Encrypt). Genesys Cloud BYOC Cloud requires a publicly trusted CA; self-signed certificates are rejected.
  2. Load the certificate and private key into the SBC’s TLS Context.
  3. Configure the SIP Interface to listen on TLS 5061.
  4. Load the Genesys Cloud Root Certificate (DigiCert Global Root CA) into the SBC’s Trusted Root store so the SBC can validate the inbound connection from Genesys Cloud.
  5. Set the TLS Mutual Authentication requirement to Required.

3. Securing Voice Media with SRTP

Securing the SIP signaling prevents toll fraud and call hijacking, but it does not protect the actual audio of the call. If RTP is sent unencrypted over the internet, an attacker performing packet capture can reconstruct the voice audio.

You must encrypt the media payload using Secure RTP (SRTP).

Configuration:

  1. In the Genesys Cloud Trunk settings, navigate to the Media section.
  2. Set Media Encryption to Required. (Do not use ‘Optional’, as fallback to unencrypted RTP violates Zero-Trust).
  3. The cryptographic keys for SRTP are exchanged within the SIP SDP (Session Description Protocol) payload. Because we secured the SIP signaling with TLS in Step 2, the SRTP key exchange is inherently secure.

4. Firewall Configuration (Dynamic vs. Static Ports)

The SBC sits behind an edge firewall (or an AWS Security Group). You must restrict inbound traffic.

Signaling (TLS 5061):
You must allowlist the specific Genesys Cloud BYOC signaling IP addresses for your AWS Region.
Example (us-east-1): Allow TCP 5061 from 18.232.238.16/28.

Media (UDP SRTP):
Media is more complex. Genesys Cloud allocates media ports dynamically from a massive range (e.g., UDP 16384 - 32768).

The Legacy Approach (Bad): Open UDP 16384-32768 to the entire internet (0.0.0.0/0).
The Zero-Trust Approach (Good): Only open UDP 16384-32768 to the specific AWS IP subnets utilized by the Genesys Cloud Media Edges in your region.

Even with strict IP filtering, keeping 16,000 UDP ports open is risky. Modern SBCs support Dynamic Pinholing. The SBC reads the SIP SDP message, identifies the exact UDP port negotiated for that specific call, and opens a temporary “pinhole” in its internal firewall just for that call, closing it immediately when the call ends. Ensure your SBC is configured for dynamic media port allocation.

5. Protection Against SIP Flooding and DoS

Even with mTLS and firewall rules, your SBC is exposed to the internet and will be scanned by automated bots looking for SIP vulnerabilities (e.g., SIP Vicious).

  1. Drop Invalid Traffic Silently: Configure your firewall/SBC to silently drop (not reject) any TCP connection to 5061 that does not originate from the allowlisted Genesys Cloud IP addresses. Do not respond with a TCP RST; simply drop the packet.
  2. Rate Limiting: Implement strict Call Admission Control (CAC) on the SBC. If an endpoint attempts to initiate 500 INVITEs per second, the SBC should block the IP.
  3. Invalid URI Rejection: Configure the SBC to immediately drop any SIP INVITE where the Request-URI does not match your specific Genesys Cloud tenant domain.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Certificate Expiration Outages

Because mTLS relies on certificates, allowing a certificate to expire causes an immediate, catastrophic telephony outage. If your SBC certificate expires, Genesys Cloud drops the connection.
Solution: Do not rely on calendar reminders. Integrate your SBC with an automated certificate management protocol like ACME (Let’s Encrypt), or use your SIEM to actively monitor the SBC’s SSL certificate validity and generate critical PagerDuty alerts 30 days before expiration.

Edge Case 2: One-Way Audio on SRTP

You complete the configuration, but inbound calls have one-way audio (the agent hears the customer, but the customer hears nothing).
Root Cause: This is almost always an issue with the Edge Firewall blocking inbound UDP media, or the SBC failing to perform Network Address Translation (NAT) correctly on the SIP SDP. If the SBC sends its internal IP address in the SDP payload instead of its public IP, Genesys Cloud sends the SRTP packets to an unrouteable private IP.
Solution: Ensure the SBC’s “SIP Interface” or “NAT Traversal” settings are configured to rewrite the SDP c= line with the public IP address of the firewall.

Edge Case 3: Codec Mismatches with SRTP

When forcing SRTP, some older carrier networks (via your SBC) attempt to transcode the media using an unsupported codec, causing the SRTP cryptographic hash to fail, resulting in dropped calls or robotic audio.
Solution: Enforce strict codec negotiation on the Genesys Cloud trunk. Limit the allowed codecs to Opus and G.711 PCMU/PCMA. Disable G.729 unless strictly required by your carrier, as its compression often interferes with complex cloud transcoding.

Official References