Risks Associated with using Symmetric RTP
Voice Over IP communications equipment will ideally use public IP addressing when negotiating RTP (Real-time Transport Protocol) media. However, many networks employ Network Address Translation (NAT) using private IP address spaces. A NAT that is not SIP-aware can cause one-way audio issues. One way to resolve these issues is by using Symmetric RTP latching.
Symmetric RTP latching is a Hosted NAT Traversal (HNT) feature available in many SIP infrastructures where, after receiving a defined number of RTP packets, the SIP device locks onto the source IP address and port of that packet, and sends any subsequent return-media RTP packets to that same source.
When a Twilio SIP session is negotiated, the endpoints exchange their RTP IP address and port information in the session signaling as part of their Session Description Protocol (SDP) information. Your Twilio Elastic SIP Trunks include a configuration switch to enable/disable Symmetric RTP latching. When Symmetric RTP is disabled, Twilio will send RTP to the destination negotiated in the SDP. When Symmetric RTP is enabled Twilio will detect where the remote RTP stream is coming from and latch on to that IP Address and port, sending RTP to that destination instead of the one negotiated in the SDP.
By default, Symmetric RTP latching is disabled on Twilio elastic SIP Trunks, and we only recommend enabling the feature if a proper RTP stream with your SIP infrastructure cannot be established by other means.
There is no authentication of RTP packets in unencrypted RTP sessions. This leaves such sessions vulnerable to man-in-the-middle sniffing of the unencrypted RTP packets, commonly known as eavesdropping. However, such attacks require that the attacker be strategically positioned within the target network.
In the case of Symmetric RTP scenarios, attackers may inject arbitrary RTP packets to an RTP proxy without needing to be positioned as a man-in-the-middle in the target network. As a result, they could also receive the proxied RTP traffic meant to be for the caller or callee of an established RTP stream. This can therefore lead to leakage of confidential media, insertion of invalid media, and possible denial of service. Upon successful exploitation, the attacker could impersonate someone else, sending illegitimate media, and/or convert the RTP stream into its media equivalent, allowing them to listen in on an ongoing phone call or record the audio.
These vulnerabilities are commonly known as RTP Inject, or RTP Bleed, because they allow attackers to inject and receive RTP media streams meant for legitimate users. These vulnerabilities are not specific to Twilio, or any other SIP provider or device. They exist in many telephony products, devices, and RTP proxies, as media latching is a simple solution for NAT limitations. While useful for NAT traversal, the IETF advises that media latching mechanisms have security implications and suggests using more robust solutions to protect your media.
While we do offer the feature/ability to enable Symmetric RTP latching on your Elastic SIP Trunks, Twilio strongly recommends that you leave the Symmetric RTP feature disabled, as that is a more secure method of deploying your trunks. This may require configuration of further NAT handling on your SIP infrastructure and network, but it will effectively address the RTP Inject/Bleed vulnerability.
Additionally, Twilio recommends implementing Secure Trunking using Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP) for encryption wherever possible to ensure that your call media and associated signalling remains private.
RTPbleed Security Alert: Asterisk Calls Can be Intercepted
Rtpengine RTP Injection and Media Bleed Vulnerabilities
Kamailio World 2017: Listening By Speaking - Security Attacks On Media Servers And RTP Relays