RFC 7879

DTLS-SRTP Handling in SIP Back-to-Back User Agents

📅 published May 2016, from ietf

RFC 7879: DTLS-SRTP Handling in SIP Back-to-Back User Agents 🎀

Okay bestie, here's the tea ☕ on this doc. It's RFC 7879, an IETF Standards Track document, dated May 2016. The authors are R. Ravindranath, T. Reddy, and G. Salgueiro from Cisco, V. Pascual from Oracle, and P. Ravindran from Nokia Networks. It's ISSN 2070-1721, and it doesn't obsolete or update anything, since there's no Obsoletes or Updates line in the header 💅

Abstract ✨

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) hang out on the signaling and media paths between the endpoints 🦋 This doc describes how B2BUAs behave when a Secure Real-time Transport (SRTP) security context gets set up with the Datagram Transport Layer Security (DTLS) protocol.

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7879.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🧚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Goals and Scope of this Document  . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  B2BUAs Procedures to Allow End-to-End DTLS-SRTP . . . . . . .   5
   4.  Signaling-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . .   5
     4.1.  Proxy-B2BUAs  . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Signaling-Only and SDP-Modifying Signaling-Only B2BUAs  .   6
   5.  Media-Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . .   6
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.1.  Media Relay . . . . . . . . . . . . . . . . . . . . .   6
       5.1.2.  RTP- and RTCP-Aware Media-Aware B2BUA . . . . . . . .   8
   6.  Forking Considerations  . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1. Introduction 💖

1.1. Overview

[RFC5763] describes how the Session Initiation Protocol (SIP) [RFC3261] can be used to establish a Secure Real-time Transport Protocol (SRTP) [RFC3711] security context with the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. It describes a mechanism for transporting a certificate fingerprint using the Session Description Protocol (SDP) [RFC4566]. The fingerprint identifies the certificate that will be presented during the DTLS handshake. DTLS-SRTP is currently defined for point-to-point media sessions, in which there are exactly two participants. Each DTLS-SRTP session (described in Section 3 of [RFC5764]) contains a single DTLS connection (if RTP and RTP Control Protocol (RTCP) are multiplexed) or two DTLS connections (if RTP and RTCP are not multiplexed), and either two SRTP contexts (if media traffic is flowing in both directions on the same 5-tuple) or one SRTP context (if media traffic is only flowing in one direction).

In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) entities exist on the SIP-signaling path between the endpoints. As described in [RFC7092], these B2BUAs can modify SIP and SDP information. For example, as described in Section 3.1.3 of [RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify the SDP. B2BUAs can also be present on the media path, in which case they modify parts of the SDP information (like IP address, port) and subsequently modify the RTP headers as well. Such B2BUAs are referred to as "media-plane B2BUAs". [RFC7092] describes two different categories of media-plane B2BUAs, according to the level of activities performed on the media plane.

When B2BUAs are present in a call between two SIP User Agents (UAs), they often make end-to-end DTLS-SRTP sessions impossible. An "end-to-end DTLS-SRTP session" means that man-in-the-middle devices cannot break the DTLS-SRTP session between the endpoints. In other words, the man-in-the-middle device cannot create a separate DTLS-SRTP session between the client and the middle device on one side, and the middle device and the remote peer on the other side. B2BUAs may be deployed for address hiding or media latching [RFC7362], although Traversal Using Relays around NAT (TURN) and Interactive Connectivity Establishment (ICE) are expected to be used more often for this purpose as it provides better security properties. Such B2BUAs are able to perform their functions without requiring termination of DTLS-SRTP sessions, i.e., these B2BUAs need not act as DTLS proxy and decrypt the RTP payload. 🙈

1.2. Goals and Scope of this Document

A B2BUA could be deployed for address hiding or media latching as described in [RFC7362]. Such B2BUAs only terminate the media plane at the IP and transport (UDP/TCP) layers and may inspect the RTP headers or RTP Control Protocol (RTCP) packets. The goal of this specification is to provide guidance on how such B2BUAs function without breaking the end-to-end DTLS-SRTP session. A B2BUA could also terminate the media, or modify the RTP headers or RTP Control Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-SRTP. The recommendations made in this document are not expected to be applied by B2BUAs terminating DTLS-SRTP sessions given deployment reality.

This specification assumes that a B2BUA is not providing identity assurance and is not authorized to terminate the DTLS-SRTP session. A B2BUA that provides identity assurance on behalf of endpoints behind it can modify any portion of SIP and SDP before it generates the identity signature. As the B2BUA is generating the identity signature, it is not possible to detect if a B2BUA has terminated the DTLS-SRTP session. B2BUAs providing identity assurance and terminating DTLS-SRTP sessions are out of scope of this document.

The following sections describe the behavior B2BUAs can follow to avoid breaking end-to-end DTLS-SRTP sessions. 🦋

2. Terminology 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Transport Address: The combination of an IP address and port number.

The following generalized terms are defined in [RFC3261], Section 6.

  • B2BUA: A SIP Back-to-Back User Agent, which is the logical combination of a User Agent Server (UAS) and a User Agent Client (UAC).
  • UAS: A SIP User Agent Server.
  • UAC: A SIP User Agent Client.

All of the pertinent B2BUA terminology and taxonomy used in this document are based on [RFC7092].

It is assumed the reader is already familiar with the fundamental concepts of the RTP protocol [RFC3550] and its taxonomy [RFC7656], as well as those of SRTP [RFC3711] and DTLS [RFC6347].

3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP 🔥

A B2BUA MUST follow the rules mentioned below to allow end-to-end DTLS-SRTP sessions.

  1. B2BUAs MUST forward the certificate fingerprint and SDP setup attribute it receives from one endpoint unmodified towards the other endpoint and vice versa.
  2. The enhancements described in [RFC4474] provide a means for signing portions of SIP requests in order to provide identity assurance and certificate pinning by providing an identity signature over the SDP that carries the fingerprint of keying for DTLS-SRTP [RFC5763]. B2BUAs can identify that the enhancements in [RFC4474] are used for identity assurance if the SIP request contains both Identity and Identity-Info headers. In cases where endpoints use [RFC4474], B2BUAs MUST ensure that it does not modify any of the information used to construct the identity signature. This includes the entire SDP body and portions of the SIP header as described in [RFC4474]. In this case, a B2BUA cannot act as a media-relay B2BUA.
  3. [SIP-ID] is introduced to overcome the limitations of [RFC4474] (discussed in Section 1 of [SIP-ID]). Unlike [RFC4474], [SIP-ID] does not generate an identity signature over material that intermediaries in the field commonly alter. In this case, a B2BUA can act as a media-relay B2BUA. B2BUAs can identify that [SIP-ID] is used for identity assurance if the SIP request contains an Identity header but does not include an Identity-Info header. The Identity-Info header is deprecated in [SIP-ID]. A B2BUA MUST ensure that it does not modify any of the headers used to construct the identity signature.
  4. Both media relays and media-aware relays MUST NOT modify the authenticated portion of RTP and RTCP packets, and MUST NOT modify the authentication tag in the RTP and RTCP packets.

4. Signaling-Plane B2BUA Handling of DTLS-SRTP 📞

Section 3.1 of [RFC7092] describes different categories of signaling-plane B2BUAs. This section explains how these B2BUAs are expected to comply with the recommendations in Section 3.

4.1. Proxy-B2BUAs 🌈

Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only the Via and Record-Route SIP headers. These B2BUAs can continue to perform their function and still allow end-to-end DTLS-SRTP sessions since none of the headers used to construct the identity signature are modified. Honestly, this is the easy-mode category 🫶

4.2. Signaling-Only and SDP-Modifying Signaling-Only B2BUAs 👀

These categories of B2BUAs are likely to modify headers that are used to construct the identity signature. For example, a signaling-only B2BUA can modify the Contact URI. Such B2BUAs are likely to violate rule 2 or rule 3 in Section 3. Depending upon the application requirements, such a B2BUA may be able to limit modification of header fields to those allowed to be modified by [RFC4474] or [SIP-ID]. This is where things get messy, bestie 😭

5. Media-Plane B2BUA Handling of DTLS-SRTP ✨

5.1. General ✨

okay so this section is where we look at how each kind of media-plane B2BUA from [RFC7092] is supposed to behave so it keeps following the recommendations in Section 3 🎀 no cap, it's a whole vibe check for middleboxes 💅

5.1.1. Media Relay 🦋

okay bestie, from the application layer's point of view, a media relay (the one defined in Section 3.2.1 of [RFC7092]) just forwards every packet it gets on a negotiated connection 📦 it does NOT peek inside or touch the packet contents at all. the only things it changes are the transport layer (UDP/TCP) and IP headers, so it's giving minimal and iconic 🫶

a media-relay B2BUA follows rule 1 from Section 3 🌸 it forwards the certificate fingerprint and SDP setup attribute it gets from one endpoint unmodified to the other endpoint, and vice versa. no edits, no drama 💖

here's a SIP call setup flow with both user agents using DTLS-SRTP and a media-relay B2BUA in the middle ✨

    +-------+            +-------------------+             +-----+
    | Alice |            | Media-Relay B2BUA |             | Bob |
    +-------+            +-------------------+             +-----+
        |(1) INVITE               |  (3) INVITE               |
        |   a=setup:actpass       |   a=setup:actpass         |
        |   a=fingerprint1        |   a=fingerprint1          |
        |   (Alice's IP/port)     |   (B2BUAs IP/port)        |
        |------------------------>|-------------------------->|
        |                         |                           |
        |    (2)  100 trying      |                           |
        |<------------------------|                           |
        |                         | (4) 100 trying            |
        |                         |<--------------------------|
        |                         |                           |
        |                         |  (5) 200 OK               |
        |                         |   a=setup:active          |
        |                         |    a=fingerprint2         |
        |                         |  (Bob's IP/port)          |
        |<------------------------|<--------------------------|
        |    (6) 200 OK           |                           |
        |    a=setup:active       |                           |
        |    a=fingerprint2       |                           |
        |    B2BUAs IP/port       |                           |
        |               (7, 8) ClientHello + use_srtp         |
        |<----------------------------------------------------|
        |(B2BUA changes transport(UDP/TCP) and IP header)     |
        |                         |                           |
        |                         |                           |
        |           (9,10) ServerHello + use_srtp             |
        |---------------------------------------------------->|
        |(B2BUA changes transport(UDP/TCP) and IP header)     |
        |                         |                           |
        |                         |                           |
        |                 (11)    |                           |
        |  [Certificate exchange between Alice and Bob over   |
        |   DTLS ]                |                           |
        |                         |                           |
        |         (12)            |                           |
        |<---------SRTP/SRTCP-----------SRTP/SRTCP----------->|
        | [B2BUA changes transport(UDP/TCP) and IP headers]   |

Figure 1: INVITE with SDP Call Flow for Media-Relay B2BUA

Note: for brevity, the entire value of the SDP fingerprint attribute isn't shown 🙈 and the example only shows one DTLS connection to keep things simple. in real life, depending on whether RTP and RTCP are multiplexed or demultiplexed, there will be one or two DTLS connections 🧚

if RTP and RTCP traffic is multiplexed on a single port as described in [RFC5761], then only a single DTLS connection is required between the peers. if RTP and RTCP are NOT multiplexed, the peers have to establish two DTLS connections. in that case, after receiving an INVITE request, Bob triggers the establishment of a DTLS connection. the DTLS handshake and the sending of the INVITE response can happen in parallel, so the B2BUA has to be prepared to receive DTLS, Session Traversal Utilities for NAT (STUN), and media on the ports it advertised to Bob in the SDP offer before it gets an SDP answer from Bob 😭 since a media-relay B2BUA doesn't tell a DTLS message, RTP, or any other packet apart, it only changes the transport layer (UDP/TCP) and IP headers and forwards the packet to the other endpoint. the B2BUA cannot decrypt the RTP payload, because the payload is encrypted with the SRTP keys derived from the DTLS connection setup between Alice and Bob 🔐

if the endpoints use [RFC4474], a B2BUA cannot function as a media-relay without violating rule 2 in Section 3. if [SIP-ID] is used, a B2BUA can modify the IP address in the c= line and the port in the m= line in the SDP, as long as it doesn't otherwise violate rule 3 in Section 3. 💜

5.1.2. RTP- and RTCP-Aware Media-Aware B2BUA 🌈

unlike the media relay from Section 5.1.1, a media-aware relay (defined in Section 3.2.2 of [RFC7092]) is aware of the type of media traffic it's receiving 👀 there are two flavors: ones that just inspect the RTP headers and unencrypted portions of RTCP packets, and ones that inspect AND modify the RTP headers and unencrypted portions of RTCP packets. ✨

5.1.2.1. RTP Header and RTCP Packets Inspection 🔍

an RTP-/RTCP-aware media relay does NOT modify the RTP headers or RTCP packets, it only inspects them 🫧 these B2BUAs follow rule 4 in Section 3 and can keep doing their job while still allowing end-to-end DTLS-SRTP 💖 inspection by the B2BUA won't reveal the clear-text of the encrypted parts of the SRTP/SRTCP packets 🙌

5.1.2.2. RTP Header and RTCP Packet Modification 🚫

okay this one is the big no-no era 💀 a B2BUA cannot modify RTP headers or RTCP packets, because to do that it would need to act as a DTLS endpoint, terminate the DTLS-SRTP session, and decrypt/re-encrypt the RTP packets. if a B2BUA modifies unencrypted OR encrypted portions of the RTP or RTCP packets, the integrity check fails and the endpoint drops the packet 🗑️ the unencrypted and encrypted portions of RTP or RTCP packets are integrity protected using the HMAC algorithm negotiated during the DTLS handshake (discussed in Section 4.1.2 of [RFC5764]) 🔒 B2BUAs MUST follow the rules in Section 3 to avoid breaking the integrity of SRTP/SRTCP streams 🫶

6. Forking Considerations 🍴

okay so forking is a whole thing 🌀 due to forking [RFC3261], a SIP request carrying an SDP offer from an endpoint (the offerer) can reach multiple remote endpoints. that means multiple DTLS-SRTP sessions can get set up, one between the endpoint that sent the request and each remote endpoint that received it 👯‍♀️ B2BUAs MUST follow rule 1 in Section 3 while handling offer/answer, and forward the certificate fingerprints and SDP setup attributes it received in the SDP answer from each endpoint (the answerer) unmodified towards the offerer. since each DTLS connection is set up on a unique 5-tuple, the B2BUA replaces the answerer's transport addresses in each answer with its own unique transport addresses, so the offerer can establish a DTLS connection with each answerer. the B2BUA, acting as a media relay here, follows rule 4 from Section 3 💅

                                             Bob (192.0.2.1:6666)
                                            /
                                           /
                                          / DTLS-SRTP=XXX
                                         /
                                        /
                         DTLS-SRTP=XXX v
                         <----------->  (192.0.2.3:7777)
   Alice (192.0.2.0:5555)             B2BUA
                         <----------->  (192.0.2.3:8888)
                         DTLS-SRTP=YYY ^
                                        \
                                         \  DTLS-SRTP=YYY
                                          \
                                           \
                                            \
                                             Charlie (192.0.2.2:6666)

Figure 2: B2BUA Handling Multiple Answers

so like, in Figure 2, Alice sends a request with an offer and it gets forked. Alice gets answers from both Bob and Charlie 🦋 the B2BUA advertises different B2BUA transport addresses in each answer, where XXX and YYY are different DTLS-SRTP sessions. the B2BUA swaps Bob's transport address (192.0.2.1:6666) in the answer for its own (192.0.2.3:7777), and Charlie's transport address (192.0.2.2:6666) for its own (192.0.2.3:8888). the B2BUA tracks the remote sources (Bob and Charlie) and links them to the local sources it uses to send packets to Alice 🧚

7. Security Considerations 🚨

⚠️ bestie, this part is SERIOUS, read it carefully 💖

this document describes the behavior B2BUAs MUST follow to avoid breaking end-to-end DTLS-SRTP. media relays that modify RTP or RTCP, or that modify SIP header fields or SDP fields protected by the identity signature, are incompatible with end-to-end DTLS-SRTP, and they're out of scope for this document 🙅‍♀️ the security considerations discussed in [RFC5763] also apply to this document. on top of that, the B2BUA behaviors outlined here do NOT impact the security and integrity of a DTLS-SRTP session or the data exchanged over it. a malicious B2BUA can try to break into the DTLS connection, but such an attack can be prevented using the identity validation mechanism discussed in [RFC4474] or [SIP-ID] 🛡️ either the endpoints or the authentication service proxies involved in the call can use the identity validation mechanisms from [RFC4474] or [SIP-ID] to validate the identity of peers and detect malicious B2BUAs that might try to terminate the DTLS connection to decrypt the RTP payload 🕵️‍♀️

8. References 📚

8. References ✨

8.1. Normative References

These are the big-deal docs you MUST have read to get the spec, so let's go 🤓

8.2. Informative References

These ones are the background reading. Super helpful, not strictly required 🧚

  • [RFC3261]: Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. 📞 SIP, the signaling protocol that sets up the calls
  • [RFC4474]: Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>. 🪪 Identity stuff for SIP, very main character
  • [RFC4566]: Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>. 📝 SDP, where the session details get written down
  • [RFC5761]: Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>. 🚪 RTP and RTCP sharing one port, which is honestly genius
  • [RFC7092]: Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>. 🗂️ The B2BUA taxonomy, which is basically the map for this whole doc
  • [RFC7362]: Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", RFC 7362, DOI 10.17487/RFC7362, September 2014, <http://www.rfc-editor.org/info/rfc7362>. 🧭 Latching, for getting media through NATs
  • [RFC7656]: Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>. 🎙️ The RTP sources taxonomy, very organized, I love it
  • [SIP-ID]: Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-09, May 2016. 🚧 Still a draft, so it's giving work in progress 💅

Acknowledgments

Huge shoutout to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, Christer Holmberg, Colin Perkins, Ben Campbell, and Alissa Cooper 🫶 They gave constructive comments, suggestions, and early reviews that were critical to getting this doc into shape ✨

The authors also want to thank Dan Romascanu, Vijay K. Gurbani, Francis Dupont, Paul Wouters, and Stephen Farrell for reviewing it and giving feedback 🌸

Contributors

Rajeev Seth provided substantial contributions to this document. The absolute MVP 👑

Authors' Addresses

Here's where to find the authors 💌

Ram Mohan Ravindranath
Cisco
Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka  560103
India

Email: rmohanr@cisco.com
Tirumaleswar Reddy
Cisco
Cessna Business Park
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

Email: tireddy@cisco.com
Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC  27709
United States

Email: gsalguei@cisco.com
Victor Pascual
Oracle
Barcelona, Spain

Email: victor.pascual.avila@oracle.com
Parthasarathi Ravindran
Nokia Networks
Bangalore, Karnataka
India

Email: partha@parthasarathi.co.in

That's the whole spec, bestie 🌈🦋💖

📦 where this page comes from