cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2417
Views
0
Helpful
7
Replies

media and signaling encryption

asif.rehman
Level 1
Level 1

Hi,

I have two question regarding media and signaling encryption.

1 - Can I just use media encryption only ? or I have to encrypt both signaling and media ?

2-  Our client has a Centralized CUCM Cluster 8.5 and some remote offices. CUCM cluster is behind Cisco firewall in HQ and remote sites are also behind Cisco firewalls (WAN connectivity is over IPSec Tunnel) .Now if I implement media/sig encryption in the cluster will it work for remote sites ?

I came acorss few cisco documentation and it seems that firewalls may not be able to inspect the signaling traffic and calls might not work. Can any one please confirm this and what is the workaround ?

Regards,

Asif

1 Accepted Solution

Accepted Solutions

The FWSM do not support the Trusted Firewall Control feature. You're correct that they also cannot inspect SRTP or TLS-encoded SCCP/SIP traffic.

It's still not clear if you actually have a problem though. For example, if a SIP packet is sent from the router/phone at a remote site to the servers at HQ, do the FWSM inspect that traffic flow? If they're not doing WAN-side firewalling you don't have to worry about them. It's possible they are only terminating the IPsec tunnels and/or only inspecting internet traffic. It's time to talk with your security folks.

View solution in original post

7 Replies 7

Jonathan Schulenberg
Hall of Fame
Hall of Fame
1 - Can I just use media encryption only ? or I have to encrypt both signaling and media ?

The shared secret for the SRTP media is sent through the signaling path. If you do not encrypt the signaling then encrypting the media is pointless.

2-  Our client has a Centralized CUCM Cluster 8.5 and some remote offices. CUCM cluster is behind Cisco firewall in HQ and remote sites are also behind Cisco firewalls (WAN connectivity is over IPSec Tunnel) .Now if I implement media/sig encryption in the cluster will it work for remote sites ?

Is this an ASA or IOS-based ZBFW?

Is the firewall inspecting inter-site traffic inside the IPsec tunnels?

  • If yes: You will need to open port range exemptions for the ports used. The design guide and security guide both say that signaling and media encryption make Application Layer Inspection impossible (one exception being a TRP with ISO ZBFW).
  • If no (i.e. uninhibited routing between sites inside the tunnel): Yes it will work. Just remember that NAT is also not supported between the endpoint and the servers/gateways.

As I mentioned above the one exception is IOS Zone-Based Firewalls if used with a Trusted Relay Point. Marketing calls this the Trusted Firewall Client. The TRP can locally instruct specific ports to be opened for individual media flows since it is participating in the encrypted call.

Q. What is Cisco Unified Communications Trusted Firewall Control?

A. Cisco Unified Communications Trusted Firewall Control is a feature in Cisco IOS Firewall and Cisco IOS Software call control to tackle the following three commonly seen scenarios when voice protocols traverse Cisco IOS Firewall:

• Cisco IOS Firewall uses an Application Layer Gateway (ALG) to inspect voice protocols to open "pinholes" to allow media flows. When a newer version of the voice protocols is released, Cisco IOS Firewall needs to update the ALG to conform to the protocol changes. Frequent voice protocol changes mean frequent updates to ALG.

• When the call signaling and media take different paths and do not traverse the same Cisco IOS Firewall, hence the media flows for that call cannot traverse Cisco IOS Firewall.

• When the call signaling is encrypted and Cisco IOS Firewall cannot determine the "pinholes" need to be opened to allow the call.

Starting with Release 12.4(22)T, Cisco IOS Firewall incorporates Unified Communications Trusted Firewall, a feature that allows Cisco IOS Firewall to inspect, authenticate and authorize voice calls regardless which voice protocol version is in use; this essentially makes Cisco IOS Firewall voice protocol inspection version independent, while maintaining secure encrypted signaling paths as well as asymmetric signaling and media paths.

Additional details are listed here: http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/feature/guide/TrustedFirewallControll.html

Hi Jonathan,

Thanks for the reply. I have FWSM's in all locations and as for WAN connectivity to remote sites we have MPLS links (provided by loca ISP) and for security reasons our network guys are encrypting and decrypting all WAN traffic on our core routers.

I am not a security guy so not sure if FWSM's support Trusted Firewall Control feature for encrypted voice packets. Any ideas ?

I was going thru some cisco documentation and it seems that FWSM's can not inspect encrypted voice packets and hence it will not be able to open dynamic ports. Also is it necessary to have TLS proxy for voice/signaling encryption ?

Thanks,

Asif

The FWSM do not support the Trusted Firewall Control feature. You're correct that they also cannot inspect SRTP or TLS-encoded SCCP/SIP traffic.

It's still not clear if you actually have a problem though. For example, if a SIP packet is sent from the router/phone at a remote site to the servers at HQ, do the FWSM inspect that traffic flow? If they're not doing WAN-side firewalling you don't have to worry about them. It's possible they are only terminating the IPsec tunnels and/or only inspecting internet traffic. It's time to talk with your security folks.

Thanks but you are right I am not facing any issues because I have not implemeted SRTP/TLS as of yet but I need to make sure it will work before i implement it.

I have sip, sccp, h323 inspections enabled on my fwsm's and I assume that phones in remote sites will communicate with CUCM via skinny same for sip phones and my understanding is that firewalls will open the required ports after inspecting the packet. Similarly I have voice gateways in remote locations and they will communicate over h323 to CUCM.

UC Servers and Phones are behind firewall and my remote phones are also behind firewall..so any traffic going from HQ to remote must go through both firewalls one at HQ other at remote side.

Servers > Switch > Core Switch/FWSM > Core Router ---------------------- Core Router >Core Sw/FWSM > Access switches > Phones

I am afraid that FWSM's will not be able to inspect the encrypted voice SRTP/TLS packets and our production sytem may go down.. OR we might have to open the ACL's with every port range that h233 sip skinny and rtp might use

Once the signaling encrypted the firewall will no longer have the information to Be unified communication-aware firewall !

Cisco has developed a solution for this to get the firewall involved in the encrypted signaling between the CUCM and endpoints for inspection  Where the firewall added to the phone CTL list this feature is only available in ASA called TLS Proxy

Hope this help

You're correct, this will not work without opening ACLs to allow the traffic through FWSMs (and not perform inspection). If mixed mode is really a requirement AND you cannot bypass the FWSMs it is time for a WAN equipment refresh. This would be doable with ISR G2 hardware using IOS Zone-Based Firewalls and the Trusted Firewall Control feature. GETVPN should replace the IPsec tunnels across the MPLS VPN.

Cisco has developed a solution for this to get the firewall involved in the encrypted signaling between the CUCM and endpoints for inspection  Where the firewall added to the phone CTL list this feature is only available in ASA called TLS Proxy

My advise is to avoid this "solution" like a plague. It is a horribly cobbled together bandaid which was only introduced because customers were demanding VPN functionality for remote phones before the embedded AnyConnect SSL client was baked into the phone firmware. Using this to overcome the FWSMs limitations would be a mistake in my opinion.

Thanks Jonathan and Marwan for your input and suggestions. I will discuss these limitations with the sec folks and I hope they will understand