SRTP not working between CUBE virtual c8000 routers

[Mark Cantrell]

Hi. 

I could use some help getting SRTP working on the WAN call legs of SIP trunks between two two CUBE virtual routers (c8000v with Network Advantage licenses, and IOS-XE v17.10.01a).  Note that I would rather not use SRTP on the internal call legs between each CUBE and its local CME (also a c8000 VM).  I would also prefer not to bother with TLS, since my goal is simply to ensure privacy for the voice media across the WAN.

I have attempted to configure the CUBEs per this Cisco document regarding SRTP-RTP interworking:
   https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/srtp-rtp-interworking.html

My inter-site calls are completing, but the output of the "show call active voice brief" command indicates that SRTP remains off for both internal and external call legs.

Examples of my internal and external call legs, as well as relevant global settings, are pasted below.

------------[ CONFIG EXTRACTS ]-------------------
!
dial-peer voice 1400 voip
description INBOUND CALL LEG FROM WAN PEER TO CUBE
preference 1
session protocol sipv2
incoming called-number 400....
voice-class sip pass-thru content sdp
voice-class sip bind control source-interface GigabitEthernet1
voice-class sip bind media source-interface GigabitEthernet1
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 1410 voip
description OUTBOUND INTERNAL CALL LEG FROM CME TO CUBE
preference 1
session protocol sipv2
incoming called-number 410....
voice-class sip pass-thru content sdp
voice-class sip bind control source-interface GigabitEthernet2
voice-class sip bind media source-interface GigabitEthernet2
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 2400 voip
description INBOUND INTERNAL CALL LEG FROM CUBE TO CME
translation-profile outgoing STRIP_PREFIX
preference 1
destination-pattern 400....
session protocol sipv2
session target ipv4:172.18.70.10:5060
voice-class sip pass-thru content sdp
voice-class sip bind control source-interface GigabitEthernet2
voice-class sip bind media source-interface GigabitEthernet2
codec g711ulaw
!
dial-peer voice 2410 voip
description OUTBOUND CALL LEG FROM CUBE TO WAN PEER
preference 1
destination-pattern 410....
session protocol sipv2
session target ipv4:192.168.126.5:5060
voice-class sip pass-thru content sdp
voice-class sip bind control source-interface GigabitEthernet1
voice-class sip bind media source-interface GigabitEthernet1
dtmf-relay rtp-nte
codec g711ulaw
!
voice service voip
ip address trusted list
ipv4 172.18.70.10 255.255.255.255
ipv4 0.0.0.0 255.255.255.255
ipv4 192.168.126.5 255.255.255.255
rtp-port range 16384 32766
mode border-element
srtp pass-thru
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
no supplementary-service sip handle-replaces
h323
call service stop
trace
sip
header-passing
error-passthru
referto-passing
asserted-id pai
srtp negotiate cisco
early-offer forced
no silent-discard untrusted
midcall-signaling passthru
g729 annexb-all
pass-thru headers unsupp
pass-thru content unsupp
pass-thru content sdp mode non-rtp
!
==============================================================

Some show command and debug log outputs are attached.

Any ideas?

Thanks,
  Mark

[Jonathan Schulenberg]

The “pass-thru content sdp” commands disable CUBE’s media negotiation- including SRTP. Remove them. You might be able to get away with codec transparent on the dial-peer instead but that command has proven problematic for me in the past so test thoroughly.

Also, SRTP is completely pointless without TLS for the SIP dialog; the symmetric key will be sent in the clear!

PS- Matching incoming dial-peers by SIP URI, typically the via header, and then using dial-peer groups to force the appropriate outbound dial-peer is a much better approach these days.

[Roger Kallberg]

Apart from what @Jonathan Schulenberg wrote you are missing the srtp command on the dial peers that are WAN facing. Try adding it to dial peer 1400 and 2410. Also have you configured certificate stores on the routers?

[cantrellme]

Yeah, sorry.  The SRTP command was in those dial peers during an earlier attempt.  I temporarily removed that setting during one of my many test runs, and forgot to put it back in for my initial post here.  An updated copy of the dial peer settings, with SRTP but no SDP pass-thru, was in the attachment to my update earlier today.  Again, SRTP is still not being applied to those media streams.
BTW, both CUBEs also have RSA keys, self-signed certs, and trustpoints defined.

[Roger Kallberg]

Not related to your question, but you have the description incorrect on two of your dial peers. It should be this.

dial-peer voice 1410 voip
 description INBOUND INTERNAL CALL LEG FROM CME TO CUBE
!
dial-peer voice 2400 voip
 description OUTBOUND INTERNAL CALL LEG FROM CUBE TO CME

[cantrellme]

Thanks Jonathon and Roger.

I removed the "pass-thru content sdp" commands from all of the dial-peers.  (Those lines were inserted while troubleshooting, based on comments in other community posts.)  The SRTP command has also been added back to the relevant dial-peers.

Still no joy.  Updated dial-peer settings. show command outputs, and debug logs attached.

My apologies for the confusing dial-peer descriptions.  I used "inbound" and "outbound" to refer to the direction of the media flows from the perspective of the overall enclave, not the CUBE.  The term "internal" is used to label trunks between the CUBE and its local CME, while "external" means a local CUBE to distant CUBE trunk. I will take a stab at making all that more intuitive once it all works.

Regarding protection of the key exchange, I figured I would tack that on once SRTP is working.  My hope is that I can use self-signed certs and DTLS-SRTP (RFC-5764, if IOS-XE supports it) or TLS (for encyption only, not server authentication).

For context, I am developing a template for some transportable systems that would be used for emergency operations in the field.  So things like cert chain verification, server authentication, global DNS, URIs, and revocation checks are not compatible with my use cases.

Thanks again,
  Mark

[Roger Kallberg]

With your version of IOS this document is more suitable. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-srtp-rtp-int.html

[cantrellme]

SRTP-RTP interworking is now working properly in my lab setup.  I had to make these changes to my "voice service voip" section in both CUBEs:

!
voice service voip
no srtp fall
sip
no pass-thru headers unsupp
no pass-thru content sdp mode non-rtp
no pass-thru content unsupp
!

For anyone with similar requirements, here are the final voice service and dial-peer settings:

!-------------------------------------------
voice service voip
ip address trusted list
ipv4 172.18.70.10 255.255.255.255
ipv4 192.168.126.5 255.255.255.255
rtp-port range 16384 32766
mode border-element
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
no supplementary-service sip handle-replaces
h323
call service stop
no trace
sip
header-passing
error-passthru
referto-passing
asserted-id pai
srtp negotiate cisco
early-offer forced
no silent-discard untrusted
midcall-signaling passthru
g729 annexb-all
!
dial-peer voice 1400 voip
description INBOUND CALL LEG FROM WAN PEER TO CUBE
preference 1
session protocol sipv2
incoming called-number 400....
voice-class sip bind control source-interface GigabitEthernet1
voice-class sip bind media source-interface GigabitEthernet1
dtmf-relay rtp-nte
srtp
codec g711ulaw
dial-peer voice 2410 voip
description OUTBOUND CALL LEG FROM CUBE TO WAN PEER
preference 1
destination-pattern 410....
session protocol sipv2
session target ipv4:192.168.126.5:5060
voice-class sip bind control source-interface GigabitEthernet1
voice-class sip bind media source-interface GigabitEthernet1
dtmf-relay rtp-nte
srtp
codec g711ulaw
dial-peer voice 1410 voip
description OUTBOUND INTERNAL CALL LEG FROM CME TO CUBE
preference 1
session protocol sipv2
incoming called-number 410....
voice-class sip bind control source-interface GigabitEthernet2
voice-class sip bind media source-interface GigabitEthernet2
dtmf-relay rtp-nte
codec g711ulaw
dial-peer voice 2400 voip
description INBOUND INTERNAL CALL LEG FROM CUBE TO CME
translation-profile outgoing STRIP_PREFIX
preference 1
destination-pattern 400....
session protocol sipv2
session target ipv4:172.18.70.10:5060
voice-class sip bind control source-interface GigabitEthernet2
voice-class sip bind media source-interface GigabitEthernet2
codec g711ulaw
!-----------------------------

Thanks again to Jonathon and Roger for the assist.

Mark

[Roger Kallberg]

Glad to hear that you made it work. One thing, why have you turned off the trace collection? It’s a really good function that helps with troubleshooting as it collects call information without needing to have debugging enabled.

[cantrellme]

I turned trace off once SRTP started working.  But then turned right back on, after my last post, so I could work on enabling TLS with self signed certs for key negotiation.

BTW, I had hoped to use DTLS (RFC 5764) for encrypting the key negotiation.  But haven't found any hints on how to enable DTLS-SRTP on a Cisco CUBE.  Again, I am developing a template for field systems that don't have access to the Internet.  So CA trust chains, revocation checks, and other conventional PKI approaches only serve to complicate the pre-deployment setup tasks. 

Thanks again,
  Mark