One document matched: draft-ietf-straw-b2bua-dtls-srtp-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!--rfc category="info" ipr="full3978"-->
<rfc category="std" docName="draft-ietf-straw-b2bua-dtls-srtp-12"
ipr="trust200902">
<front>
<title abbrev="DTLS-SRTP Handling in SIP B2BUA">DTLS-SRTP Handling in
Session Initiation Protocol (SIP) Back-to-Back User Agents
(B2BUAs)</title>
<author fullname="Ram Mohan Ravindranath" initials="R."
surname="Ravindranath">
<organization>Cisco</organization>
<address>
<postal>
<street>Cessna Business Park</street>
<street>Sarjapur-Marathahalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rmohanr@cisco.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Cisco</organization>
<address>
<postal>
<street>Cessna Business Park</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>
<email>gsalguei@cisco.com</email>
</address>
</author>
<author fullname="Victor Pascual" initials="V.P."
surname="Pascual">
<organization>Oracle</organization>
<address>
<postal>
<street></street>
<city>Barcelona, Spain</city>
</postal>
<email>victor.pascual.avila@oracle.com</email>
</address>
</author>
<author fullname="Parthasarathi Ravindran" initials="Parthasarathi"
surname="Ravindran">
<organization>Nokia Networks</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<region>Karnataka</region>
<country>India</country>
</postal>
<email>partha@parthasarathi.co.in</email>
</address>
</author>
<date year="2016" />
<area>Real-time Applications and Infrastructure (RAI)</area>
<workgroup>STRAW</workgroup>
<abstract>
<t>Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA) exist on
the signaling and media paths between the endpoints. This document describes
the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context
is set up with the Datagram Transport Layer Security (DTLS) protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Overview">
<t><xref target="RFC5763"></xref> describes how Session Initiation
Protocol (SIP) <xref target="RFC3261"></xref> can be used to establish
a Secure Real-time Transport Protocol (SRTP) <xref
target="RFC3711"></xref> security context with the Datagram Transport
Layer Security (DTLS) <xref target="RFC6347"></xref> protocol. It
describes a mechanism for transporting a certificate fingerprint using
Session Description Protocol (SDP) <xref target="RFC4566"></xref>. 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 <xref target="RFC5764"></xref>)
contains a single DTLS connection (if RTP and 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).</t>
<t>In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) entities
exist on the SIP signaling path between the endpoints. As described in
<xref target="RFC7092"></xref>, these B2BUAs can modify
SIP and SDP information. For example, as described in Section 3.1.3 of
<xref target="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.
<xref target="RFC7092"></xref> describes two different categories
of media plane B2BUAs, according to the level of activities performed on the
media plane.</t>
<t>
When B2BUAs are present in a call between two SIP User Agents (UAs) they often make
end-to-end DTLS-SRTP sessions impossible. End-to-end DTLS-SRTP
session means that man-in-middle devices cannot break the DTLS-SRTP session
between the endpoints. In other words, the man-in-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 <xref target="RFC7362"/>, although TURN (and ICE) is 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.
</t>
</section>
<section title="Goals and Scope of this Document">
<t>A B2BUA could be deployed for address hiding or media latching, as described in <xref target="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.
</t>
<t>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 session are out of scope of this document.</t>
<t>The following sections describe the behavior B2BUAs can follow to avoid
breaking end-to-end DTLS-SRTP sessions.</t>
</section>
</section>
<section anchor="sec-term" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>Transport Address: The combination of an IP address and port number. </t>
<t>The following generalized terms are defined in <xref
target="RFC3261"></xref>, Section 6.</t>
<t><list style="hanging">
<t>B2BUA: a SIP Back-to-Back User Agent, which is the logical
combination of a User Agent Server (UAS) and User Agent Client
(UAC).</t>
<t>UAS: a SIP User Agent Server.</t>
<t>UAC: a SIP User Agent Client.</t>
</list></t>
<t>All of the pertinent B2BUA terminology and taxonomy used in this
document is based on <xref target="RFC7092"></xref>.</t>
<t>It is assumed the reader is already familiar with the fundamental
concepts of the RTP protocol <xref target="RFC3550"></xref> and its
taxonomy <xref target="RFC7656"></xref>,
as well as those of SRTP <xref target="RFC3711"></xref>, and DTLS <xref
target="RFC6347"></xref>.</t>
</section>
<section anchor="b2bua-norm" title="B2BUAs Procedures to Allow End-to-End DTLS-SRTP">
<t>A B2BUA MUST follow the rules mentioned below to allow end-to-end
DTLS-SRTP session.</t>
<t><list style="numbers">
<t>B2BUAs MUST forward the certificate fingerprint and SDP setup attribute
it receives from one endpoint unmodified towards the other endpoint and
vice-versa.</t>
<t><xref target="RFC4474"></xref> provides 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 <xref target="RFC5763"/>. B2BUAs can identify that <xref target="RFC4474"/>
is used for identity assurance if the SIP request contains both Identity and Identity-Info
headers. In cases where endpoints use <xref target="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 SIP header as described in <xref target="RFC4474"></xref>.
In this case, a B2BUA cannot act as a media relay B2BUA.</t>
<t><xref target="I-D.ietf-stir-rfc4474bis"/> is introduced to overcome the limitations
of <xref target="RFC4474"/> (discussed in Section 1 of <xref target="I-D.ietf-stir-rfc4474bis"/>).
Unlike <xref target="RFC4474"/>, <xref target="I-D.ietf-stir-rfc4474bis"/> does not generate 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 <xref target="I-D.ietf-stir-rfc4474bis"/>
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 <xref target="I-D.ietf-stir-rfc4474bis"/>.
A B2BUA MUST ensure that it does not modify any of the headers used to construct the identity signature.</t>
<t>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. </t>
</list></t>
</section>
<section title="Signaling Plane B2BUA Handling of DTLS-SRTP">
<t>Section 3.1 of <xref target="RFC7092"/> describes different categories of signaling plane B2BUAs.
This section explains how these B2BUAs are expected to comply with the recommendations in <xref target="b2bua-norm"/>.</t>
<section title="Proxy-B2BUAs">
<t>Proxy-B2BUAs, as defined in Section 3.1.1 of <xref target="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 it does not modify any of the headers used to construct the identity signature.
</t>
</section>
<section title="Signaling-only and SDP-modifying Signaling-only B2BUAs">
<t>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 <xref target="b2bua-norm"/>. Depending upon the application requirements, such a B2BUA may
be able to limit modification of header fields to those allowed to be modified by <xref target="RFC4474"/> or
<xref target="I-D.ietf-stir-rfc4474bis"/>. </t>
</section>
</section>
<section title="Media Plane B2BUA Handling of DTLS-SRTP">
<section title="General">
<t>This section describes how the different types of media plane B2BUAs defined in <xref target="RFC7092"/>
are expected to comply with the recommendations in <xref target="b2bua-norm"/>.
</t>
<section anchor="sec-med-relay" title="Media Relay">
<t>A media relay, as defined in Section 3.2.1 of <xref
target="RFC7092"></xref>, from an application layer point-of-view,
forwards all packets it receives on a negotiated connection,
without inspecting or modifying the packet contents. A media relay
only modifies the transport layer (UDP/TCP) and IP headers.</t>
<t>A media relay B2BUA follows the rule 1 mentioned in <xref target="b2bua-norm"/>
and forwards the certificate fingerprint and SDP setup attribute it receives
from one endpoint unmodified towards the other endpoint and vice-versa. The
example below shows a SIP call establishment flow, with both SIP endpoints
(user agents) using DTLS-SRTP, and a media relay B2BUA.</t>
<t><figure anchor="Figure1"
title="INVITE with SDP call-flow for Media Relay B2BUA">
<artwork align="center"><![CDATA[
+-------+ +------------------+ +-----+
| Alice | | MediaRelay 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] |
]]></artwork>
</figure></t>
<t>NOTE: For brevity the entire value of the SDP fingerprint attribute is not
shown. The example here shows only one DTLS connection for the sake of simplicity.
In reality depending on whether the RTP and RTCP flows are multiplexed or
demultiplexed there will be one or two DTLS connections.</t>
<t>If RTP and RTCP traffic is multiplexed as described in <xref target="RFC5761"/>
on a single port then only a single DTLS connection is required between the peers.
If RTP and RTCP are not multiplexed, then the peers would have to establish two
DTLS connections. In this case, Bob, after he receives an INVITE request, triggers
the establishment of a DTLS connection. Note that the DTLS handshake and the
sending of INVITE response can happen in parallel; thus, the B2BUA has to be
prepared to receive DTLS, STUN and media on the ports it advertised to Bob in the
SDP offer before it receives a SDP answer from Bob. Since a media relay B2BUA
does not differentiate between a DTLS message, RTP or any packet it receives,
it only changes the transport layer (UDP/TCP) and IP headers and forwards the
packet towards the other endpoint. The B2BUA cannot decrypt the RTP payload as
the payload is encrypted using the SRTP keys derived from the DTLS connection
setup between Alice and Bob.</t>
<t>If the endpoints use <xref target="RFC4474"/>, a B2BUA cannot function as a media-relay
without violating rule 2 in <xref target="b2bua-norm"/>. If [4474bis] is used, a B2BUA
can modify the IP address in the c= line and the port in the m= line, as shown in
Figure 1, as long as it does not otherwise violate rule 3 in <xref target="b2bua-norm"/>.</t>
</section>
<section title="RTP/RTCP-Aware Media-Aware B2BUA">
<t>Unlike the media relay discussed in <xref target="sec-med-relay"/>, a media-aware relay as
defined in Section 3.2.2 of <xref target="RFC7092"/>, is aware of the type of
media traffic it is receiving. There are two types of media-aware relays, those
that merely inspect the RTP headers and unencrypted portions of RTCP packets, and
those that inspect and modify the RTP headers and unencrypted portions of RTCP
packets.</t>
<section title="RTP Header and RTCP Packets Inspection">
<t>A RTP/RTCP aware media relay does not modify the RTP headers and RTCP
packets but only inspects the packets. Such B2BUAs follow rule 4 in <xref target="b2bua-norm"/>
and can continue to do their function while allowing end-to-end DTLS-SRTP.
Inspection by the B2BUA will not reveal the clear-text for encrypted parts of the SRTP/SRTCP
packets.</t>
</section>
<section title="RTP Header and RTCP Packet Modification">
<t>
A B2BUA cannot modify RTP headers or RTCP packets, as to do so it
would need to act as a DTLS endpoint, terminate the DTLS-SRTP session and
decrypt/re-encrypt RTP packets. If a B2BUA modifies unencrypted or encrypted
portions of the RTP or RTCP packets then the integrity check will fail and the
packet will be dropped by the endpoint. The unencrypted and encrypted portions
of the RTP or RTCP packets are integrity protected using the HMAC algorithm negotiated
during DTLS handshake (discussed in Section 4.1.2 of <xref target="RFC5764"/>). B2BUAs have to
follow the rules in <xref target="b2bua-norm"/> to avoid breaking integrity of SRTP/SRTCP streams.
</t>
</section>
</section>
</section>
</section>
<section title="Forking Considerations">
<t>Due to forking <xref target="RFC3261"/>, a SIP request carrying an SDP offer
sent by an endpoint (offerer) can reach multiple remote endpoints. As a result,
multiple DTLS-SRTP sessions can be established, one between the endpoint that sent
the SIP request and each of the remote endpoints that received the request. B2BUAs have to follow
rule 1 in <xref target="b2bua-norm"/> while handling offer/answer and forward the certificate
fingerprints and SDP setup attributes it received in the SDP answer from each endpoint (answerer)
unmodified towards the offerer. Since each DTLS connection is setup on a unique 5-tuple, B2BUA
replaces the answerer's transport addresses in each answer with its unique transport addresses
so that the offerer can establish a DTLS connection with each answerer. The
B2BUA acting as a media relay here follows rule 4 mentioned in <xref target="b2bua-norm"/>. </t>
<figure anchor="Figure2"
title="B2BUA handling multiple answers">
<artwork><![CDATA[
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)
]]></artwork>
</figure>
<t>For instance, as shown in Figure 2 Alice sends a request with an offer, and the request is forked.
Alice receives answers from both Bob and Charlie. The B2BUA advertises different
B2BUA transport address in each answer, as shown in Figure2,
where XXX and YYY represent different DTLS-SRTP sessions. The B2BUA replaces Bob's
transport address (192.0.2.1:6666) in the answer with
its transport address (192.0.2.3:7777) and Charlie's transport address
(192.0.2.2:6666) in the answer with its transport address
(192.0.2.3:8888). The B2BUA tracks the remote sources (Bob and Charlie) and
associates them to the local sources that are used to send packets to
Alice.</t>
</section>
<section anchor="sec-consid" title="Security Considerations">
<t>This document describes the behavior B2BUAs must follow to avoid breaking end-to-end
DTLS-SRTP. Media relays that modify RTP or RTCP, or modify SIP header fields or SDP
fields that are protected by the identity signature, are incompatible with end-to-end
DTLS-SRTP. Such relays are out of scope for this document. Security considerations
discussed in <xref target="RFC5763"></xref> are also applicable to this document.
In addition, the B2BUA behaviors outlined in this document 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 <xref target="RFC4474"/> or <xref target="I-D.ietf-stir-rfc4474bis"/>.
Either the endpoints or authentication service
proxies involved in the call can use the identity validation mechanisms discussed in
<xref target="RFC4474"/> or <xref target="I-D.ietf-stir-rfc4474bis"/> to validate the
identity of peers and detect malicious B2BUA's that can attempt to terminate the DTLS
connection to decrypt the RTP payload.
</t>
</section>
<section anchor="sec.iana-considerations" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section title="Acknowledgments">
<t>Special thanks 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 for their constructive comments, suggestions, and
early reviews that were critical to the formulation and refinement of this
document. The authors would also like to thank Dan Romascanu, Vijay K. Gurbani,
Francis Dupont, Paul Wouters and Stephen Farrell for their review and feedback of this document.</t>
</section>
<section title="Contributors">
<t>Rajeev Seth provided substantial contributions to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.5763"?>
<?rfc include="reference.RFC.5764"?>
<?rfc include="reference.RFC.6347"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.4474"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5761"?>
<?rfc include="reference.RFC.7092"?>
<?rfc include="reference.RFC.7362"?>
<?rfc include="reference.RFC.7656"?>
<?rfc include="reference.I-D.ietf-stir-rfc4474bis"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:43 |