draft-ietf-straw-b2bua-dtls-srtp-09.txt   draft-ietf-straw-b2bua-dtls-srtp-10.txt 
STRAW R. Ravindranath STRAW R. Ravindranath
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track G. Salgueiro Intended status: Standards Track G. Salgueiro
Expires: May 25, 2016 Cisco Expires: August 31, 2016 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
November 22, 2015 February 28, 2016
DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
User Agents (B2BUAs) User Agents (B2BUAs)
draft-ietf-straw-b2bua-dtls-srtp-09 draft-ietf-straw-b2bua-dtls-srtp-10
Abstract Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA)
often act on the media plane rather than just on the signaling path. exist on the signaling and media paths between the endpoints. This
This document describes the behaviour of such B2BUAs when acting on document describes the behavior of B2BUAs when Secure Real-time
the media plane that uses an Secure Real-time Transport (SRTP) Transport (SRTP) security context is set up with the Datagram
security context set up with the Datagram Transport Layer Security Transport Layer Security (DTLS) protocol.
(DTLS) protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 25, 2016. This Internet-Draft will expire on August 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Goals and Scope of this Document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Media Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 4 3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP . . . . . . . 4
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Signaling Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . 5
3.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 4 4.1. Proxy-B2BUAs . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. RTP/RTCP-aware Media Aware B2BUA . . . . . . . . . . 6 4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs . 5
3.2. Media Plane B2BUA with NAT Handling . . . . . . . . . . . 7 5. Media Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 6
4. Forking Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. RTP/RTCP-Aware Media-Aware B2BUA . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Forking Considerations . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
[RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261] [RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261]
can be used to establish a Secure Real-time Transport Protocol (SRTP) can be used to establish a Secure Real-time Transport Protocol (SRTP)
[RFC3711] security context with the Datagram Transport Layer Security [RFC3711] security context with the Datagram Transport Layer Security
(DTLS) [RFC6347] protocol. It describes a mechanism for transporting (DTLS) [RFC6347] protocol. It describes a mechanism for transporting
a certificate fingerprint using Session Description Protocol (SDP) a certificate fingerprint using Session Description Protocol (SDP)
skipping to change at page 3, line 8 skipping to change at page 3, line 10
participants. Each DTLS-SRTP session (described in Section 3 of participants. Each DTLS-SRTP session (described in Section 3 of
[RFC5764]) contains a single DTLS connection (if RTP and RTCP are [RFC5764]) contains a single DTLS connection (if RTP and RTCP are
multiplexed) or two DTLS connections (if RTP and RTCP are not multiplexed) or two DTLS connections (if RTP and RTCP are not
multiplexed), and either two SRTP contexts (if media traffic is multiplexed), and either two SRTP contexts (if media traffic is
flowing in both directions on the same 5-tuple) or one SRTP context flowing in both directions on the same 5-tuple) or one SRTP context
(if media traffic is only flowing in one direction). (if media traffic is only flowing in one direction).
In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) In many SIP deployments, SIP Back-to-Back User Agents (B2BUA)
entities exist on the SIP signaling path between the endpoints. As entities exist on the SIP signaling path between the endpoints. As
described in [RFC7092], these B2BUAs can modify SIP and SDP described in [RFC7092], these B2BUAs can modify SIP and SDP
information. They can also be present on the media path, in which information. For example, as described in Section 3.1.3 of
case they modify parts of the SDP information (like IP address, port) [RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify
and subsequently modify the RTP headers as well. Such B2BUAs are the SDP. B2BUAs can also be present on the media path, in which case
referred to as media plane B2BUAs. 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.
1.2. Goals 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. However, there are certain B2BUAs
that are typically deployed for address hiding or media latching, as
described in [RFC7362], and 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.
[RFC7092] describes two different categories of media plane B2BUAs, 1.2. Goals and Scope of this Document
according to the level of activities performed on the media plane:
A B2BUA that acts as a simple media relay effectively unaware of A B2BUA could be deployed for address hiding or media latching, as
anything that is transported and only terminates the media plane described in [RFC7362]. Such B2BUAs only terminate the media plane
at the IP and transport (UDP/TCP) layers. 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. Those B2BUAs terminating DTLS-SRTP sessions are outside the
scope of this document.
A B2BUA that performs a media-aware role. It inspects and This specification assumes that a B2BUA is not providing identity
potentially modifies RTP headers or RTP Control Protocol (RTCP) assurance and is not authorized to terminate the DTLS-SRTP session.
packets. 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.
The following sections describe the behavior B2BUAs can follow to The following sections describe the behavior B2BUAs can follow to
avoid breaking end-to-end DTLS-SRTP sessions. B2BUAs terminating avoid breaking end-to-end DTLS-SRTP sessions.
DTLS-SRTP session are outside the scope of this document. When
[RFC4474] is used for DTLS-SRTP sessions, the fingerprint attributes
are integrity protected. Thus, under circumstances when [RFC4474] is
used, B2BUAs cannot terminate the DTLS-SRTP session without
invalidating the signature and causing the session to fail.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Transport Address: The combination of an IP address and port number. Transport Address: The combination of an IP address and port number.
The following generalized terms are defined in [RFC3261], Section 6. The following generalized terms are defined in [RFC3261], Section 6.
skipping to change at page 4, line 13 skipping to change at page 4, line 34
UAC: a SIP User Agent Client. UAC: a SIP User Agent Client.
All of the pertinent B2BUA terminology and taxonomy used in this All of the pertinent B2BUA terminology and taxonomy used in this
document is based on [RFC7092]. document is based on [RFC7092].
It is assumed the reader is already familiar with the fundamental It is assumed the reader is already familiar with the fundamental
concepts of the RTP protocol [RFC3550] and its taxonomy concepts of the RTP protocol [RFC3550] and its taxonomy
[I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP [I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP
[RFC3711], and DTLS [RFC6347]. [RFC3711], and DTLS [RFC6347].
3. Media Plane B2BUA Handling of DTLS-SRTP 3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP
3.1. General A B2BUA MUST follow the rules mentioned below to allow end-to-end
DTLS-SRTP session.
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. [RFC4474] 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 [RFC5763]. B2BUAs can
identify that [RFC4474] is 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 SIP header as described in [RFC4474]. In this case,
a B2BUA cannot act as a media relay B2BUA.
3. [I-D.ietf-stir-rfc4474bis] is introduced to overcome the
limitations of [RFC4474] (discussed in Section 1 of
[I-D.ietf-stir-rfc4474bis]). Unlike [RFC4474],
[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 [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 [I-D.ietf-stir-rfc4474bis]. 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 the impact these B2BUAs can have
on end-to-end DTLS-SRTP sessions.
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 it does not modify any of the headers used to construct the
identity signature.
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
[I-D.ietf-stir-rfc4474bis].
5. Media Plane B2BUA Handling of DTLS-SRTP
5.1. General
This section describes the DTLS-SRTP handling by the different types This section describes the DTLS-SRTP handling by the different types
of media plane B2BUAs defined in [RFC7092]. of media plane B2BUAs defined in [RFC7092].
3.1.1. Media Relay 5.1.1. Media Relay
A media relay, as defined in section 3.2.1 of [RFC7092], from an A media relay, as defined in Section 3.2.1 of [RFC7092], from an
application layer point-of-view, forwards all packets it receives on application layer point-of-view, forwards all packets it receives on
a negotiated connection, without inspecting or modifying the packet a negotiated connection, without inspecting or modifying the packet
contents. A media relay only modifies the transport layer (UDP/TCP) contents. A media relay only modifies the transport layer (UDP/TCP)
and IP headers. and IP headers.
A media relay B2BUA MUST forward the certificate fingerprint and SDP A media relay B2BUA, as described in Section 3, forwards the
setup attribute it receives from one endpoint unmodified towards the certificate fingerprint and SDP setup attribute it receives from one
other endpoint and vice-versa. The example below shows a SIP call endpoint unmodified towards the other endpoint and vice-versa. The
establishment flow, with both SIP endpoints (user agents) using DTLS- example below shows a SIP call establishment flow, with both SIP
SRTP, and a media relay B2BUA. endpoints (user agents) using DTLS-SRTP, and a media relay B2BUA.
+-------+ +------------------+ +-----+ +-------+ +------------------+ +-----+
| Alice | | MediaRelay B2BUA | | Bob | | Alice | | MediaRelay B2BUA | | Bob |
+-------+ +------------------+ +-----+ +-------+ +------------------+ +-----+
|(1) INVITE | (3)INVITE | |(1) INVITE | (3)INVITE |
| a=setup:actpass | a=setup:actpass | | a=setup:actpass | a=setup:actpass |
| a=fingerprint1 | a=fingerprint1 | | a=fingerprint1 | a=fingerprint1 |
| (alice's IP/port) | (B2BUAs IP/port) | | (alice's IP/port) | (B2BUAs IP/port) |
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| | | | | |
skipping to change at page 5, line 29 skipping to change at page 7, line 29
| | (5)200 OK | | | (5)200 OK |
| | a=setup:active | | | a=setup:active |
| | a=fingerprint2 | | | a=fingerprint2 |
| | (Bob's IP/port) | | | (Bob's IP/port) |
|<------------------------|<--------------------------| |<------------------------|<--------------------------|
| (6) 200 OK | | | (6) 200 OK | |
| a=setup:active | | | a=setup:active | |
| a=fingerprint2 | | | a=fingerprint2 | |
| B2BUAs IP/port | | | B2BUAs IP/port | |
| (7, 8)ClientHello + use_srtp | | (7, 8)ClientHello + use_srtp |
|<------------------------|<--------------------------| |<----------------------------------------------------|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | | | | |
| | | | | |
| (9,10)ServerHello + use_srtp | | (9,10)ServerHello + use_srtp |
|------------------------>|-------------------------->| |---------------------------------------------------->|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (11) | | | (11) | |
| [Certificate exchange between Alice and Bob over | | [Certificate exchange between Alice and Bob over |
| DTLS ] | | | DTLS ] | |
| | | | | |
| (12) | | | (12) | |
|<---------SRTP/SRTCP---->|<----SRTP/SRTCP----------->| |<---------SRTP/SRTCP-----------SRTP/SRTCP----------->|
| [B2BUA changes transport(UDP/TCP) and IP headers] | | [B2BUA changes transport(UDP/TCP) and IP headers] |
Figure 1: INVITE with SDP call-flow for Media Relay B2BUA Figure 1: INVITE with SDP call-flow for Media Relay B2BUA
NOTE: For brevity the entire value of the SDP fingerprint attribute NOTE: For brevity the entire value of the SDP fingerprint attribute
is not shown. The example here shows only one DTLS connection for is not shown. The example here shows only one DTLS connection for
the sake of simplicity. In reality depending on whether the RTP and the sake of simplicity. In reality depending on whether the RTP and
RTCP flows are multiplexed or demultiplexed there will be one or two RTCP flows are multiplexed or demultiplexed there will be one or two
DTLS connections. DTLS connections.
If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a
single port then only a single DTLS connection is required between single port then only a single DTLS connection is required between
the peers. If RTP and RTCP are not multiplexed, then the peers would 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 have to establish two DTLS connections. In this case, Bob, after he
receives an INVITE request, triggers the establishment of a DTLS receives an INVITE request, triggers the establishment of a DTLS
connection. Note that the DTLS handshake and the sending of INVITE connection. Note that the DTLS handshake and the sending of INVITE
response can happen in parallel; thus, the B2BUA MUST be prepared to response can happen in parallel; thus, the B2BUA has to be prepared
receive DTLS, STUN and media on the ports it advertised to Bob in the to receive DTLS, STUN and media on the ports it advertised to Bob in
SDP offer before it receives a SDP answer from Bob. Since a media 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 relay B2BUA does not differentiate between a DTLS message, RTP or any
packet it receives, it only changes the transport layer (UDP/TCP) and packet it receives, it only changes the transport layer (UDP/TCP) and
IP headers and forwards the packet towards the other endpoint. The IP headers and forwards the packet towards the other endpoint. The
B2BUA cannot decrypt the RTP payload as the payload is encrypted B2BUA cannot decrypt the RTP payload as the payload is encrypted
using the SRTP keys derived from the DTLS connection setup between using the SRTP keys derived from the DTLS connection setup between
Alice and Bob. Alice and Bob.
[RFC4474] provides a means for signing portions of SIP requests in If the endpoints use [RFC4474], a B2BUA cannot function as a media-
order to provide identity assurance and certificate pinning by relay without violating rule 2 in Section 3. If [4474bis] is used, a
providing a signature over the SDP that carries the fingerprint of B2BUA can modify the IP address in the c= line and the port in the m=
keying for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST ensure that line, as shown in Figure 1, as long as it does not otherwise violate
it does not modify any of the information used to construct the rule 3 in Section 3.
signature.
In the above example, Alice can be authorized by the authorization
server (SIP proxy) in its domain using the procedures in Section 5 of
[RFC4474]. In such a case, if the B2BUA modifies some of the SIP
headers or SDP content that was used by Alice's authorization server
to generate the identity signature and place it in the Identity
header field, it would break the identity verification procedure
explained in Section 6 of [RFC4474] resulting in a 438 error response
being returned.
3.1.2. RTP/RTCP-aware Media Aware B2BUA 5.1.2. RTP/RTCP-Aware Media-Aware B2BUA
Unlike the media relay discussed in Section 3.1.1, a media-aware Unlike the media relay discussed in Section 3.1.1, a media-aware
relay as defined in Section 3.2.2 of [RFC7092], is aware of the type relay as defined in Section 3.2.2 of [RFC7092], is aware of the type
of media traffic it is receiving. There are two types of media-aware of media traffic it is receiving. There are two types of media-aware
relays, those that merely inspect the RTP headers and unencrypted relays, those that merely inspect the RTP headers and unencrypted
portions of RTCP packets, and those that inspect and modify the RTP portions of RTCP packets, and those that inspect and modify the RTP
headers and unencrypted portions of RTCP packets. The identity headers and unencrypted portions of RTCP packets.
integrity protection procedures described in Section 5 can be used by
the endpoint or the proxy server in the endpoints network to detect
malicious B2BUAs that attempt to terminate the DTLS-SRTP session.
3.1.2.1. RTP header and RTCP packets Inspection 5.1.2.1. RTP Header and RTCP Packets Inspection
A RTP/RTCP aware media relay does not modify the RTP headers and RTCP A RTP/RTCP aware media relay does not modify the RTP headers and RTCP
packets but only inspects the packets. It is RECOMMENDED that these packets but only inspects the packets. Such B2BUAs follow rule 4 in
B2BUAs do not terminate DTLS-SRTP session on which the packets are Section 3 and can continue to do their function while allowing end-
received. to-end DTLS-SRTP. Inspection by the B2BUA will not reveal the clear-
text for encrypted parts of the SRTP/SRTCP packets.
3.1.2.2. RTP header and RTCP packet Modification 5.1.2.2. RTP Header and RTCP Packet Modification
A B2BUA cannot modify RTP headers or RTCP packets, as to do so it 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 would need to act as a DTLS endpoint, terminate the DTLS-SRTP session
and decrypt/re-encrypt RTP packet. This would cause the identity and and decrypt/re-encrypt RTP packets. If a B2BUA modifies unencrypted
integrity protection procedures discussed in [RFC4474] to fail. This or encrypted portions of the RTP or RTCP packets then the integrity
security and privacy problem can be mitigated by having different check will fail and the packet will be dropped by the endpoint. The
keys for protecting RTP header integrity and encrypting the RTP unencrypted and encrypted portions of the RTP or RTCP packets are
payload. For example, the approach discussed in integrity protected using the HMAC algorithm negotiated during DTLS
[I-D.jones-perc-private-media-reqts] can be used. With such an handshake (discussed in Section 4.1.2 of [RFC5764]). B2BUAs have to
approach, the B2BUA is not aware of the keys used to decrypt the follow the rules in Section 3 to avoid breaking integrity of SRTP/
media payload. SRTCP streams.
3.2. Media Plane B2BUA with NAT Handling
DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may
happen in parallel. If an endpoint is behind a NAT, and the endpoint
is acting as a DTLS server, the ClientHello message from a B2BUA
(acting as DTLS client) is likely to be lost, as described in
Section 7.3 of [RFC5763]. In order to overcome this problem, the
endpoint and B2BUA can support the Interactive Connectivity
Establishment (ICE) mechanism [RFC5245], as discussed in Section 7.3
of [RFC5763]. If the ICE check is successful then the endpoint will
receive the ClientHello message from the B2BUA.
4. Forking Considerations 6. Forking Considerations
Due to forking [RFC3261], a SIP request carrying an SDP offer sent by Due to forking [RFC3261], a SIP request carrying an SDP offer sent by
an endpoint (offerer) can reach multiple remote endpoints. As a an endpoint (offerer) can reach multiple remote endpoints. As a
result, multiple DTLS-SRTP sessions can be established, one between result, multiple DTLS-SRTP sessions can be established, one between
the endpoint that sent the SIP request and each of the remote the endpoint that sent the SIP request and each of the remote
endpoints that received the request. Both media relays and media- endpoints that received the request. B2BUAs have to follow rule 1 in
aware relays MUST forward the certificate fingerprints and SDP setup Section 3 while handling offer/answer and forward the certificate
attributes it received in the SDP answer from each endpoint fingerprints and SDP setup attributes it received in the SDP answer
(answerer) unmodified towards the offerer. Since each DTLS from each endpoint (answerer) unmodified towards the offerer. Since
connection is setup on a unique 5-tuple, B2BUA MUST replace the each DTLS connection is setup on a unique 5-tuple, B2BUA replaces the
answerer's transport addresses in each answer with its unique answerer's transport addresses in each answer with its unique
transport addresses so that the offerer can establish a DTLS transport addresses so that the offerer can establish a DTLS
connection with each answerer. connection with each answerer. The B2BUA acting as a media relay
here follows rule 4 mentioned in Section 3.
Bob (192.0.2.1:6666) Bob (192.0.2.1:6666)
/ /
/ /
/ DTLS-SRTP=XXX / DTLS-SRTP=XXX
/ /
/ /
DTLS-SRTP=XXX v DTLS-SRTP=XXX v
<-----------> (192.0.2.3:7777) <-----------> (192.0.2.3:7777)
Alice (192.0.2.0:5555) B2BUA Alice (192.0.2.0:5555) B2BUA
skipping to change at page 8, line 27 skipping to change at page 9, line 46
\ DTLS-SRTP=YYY \ DTLS-SRTP=YYY
\ \
\ \
\ \
Charlie (192.0.2.2:6666) Charlie (192.0.2.2:6666)
Figure 2: B2BUA handling multiple answers Figure 2: B2BUA handling multiple answers
For instance, as shown in Figure 2 Alice sends a request with an For instance, as shown in Figure 2 Alice sends a request with an
offer, and the request is forked. Alice receives answers from both offer, and the request is forked. Alice receives answers from both
Bob and Charlie. B2BUA MUST advertise different B2BUA transport Bob and Charlie. The B2BUA advertises different B2BUA transport
address in each answer, as shown in Figure2, where XXX and YYY address in each answer, as shown in Figure2, where XXX and YYY
represent different DTLS-SRTP sessions. B2BUA replaces Bob's represent different DTLS-SRTP sessions. The B2BUA replaces Bob's
transport address (192.0.2.1:6666) in the answer with its transport transport address (192.0.2.1:6666) in the answer with its transport
address (192.0.2.3:7777) and Charlie's transport address 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.2:6666) in the answer with its transport address
(192.0.2.3:8888). B2BUA tracks the remote sources (Bob and Charlie) (192.0.2.3:8888). The B2BUA tracks the remote sources (Bob and
and associates them to the local sources that are used to send Charlie) and associates them to the local sources that are used to
packets to Alice. send packets to Alice.
5. Security Considerations 7. Security Considerations
This document describes the behavior media plane B2BUAs (media-aware This document describes the behavior B2BUAs must follow to avoid
and media-unaware) MUST follow when acting on the media plane that breaking end-to-end DTLS-SRTP. Media relays that modify RTP or RTCP,
uses SRTP security context setup with the DTLS protocol. Attempting or modify SIP header fields or SDP fields that are protected by the
to cover media-aware relay modifying RTP headers and media identity signature, are incompatible with end-to-end DTLS-SRTP. Such
termination scenarios involving secure sessions (like DTLS-SRTP) will relays are out of scope for this document. Security considerations
inevitably lead to the B2BUA acting as a man-in-the-middle, and hence discussed in [RFC5763] are also applicable to this document. In
it is RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session. addition, the B2BUA behaviors outlined in this document do not impact
Security considerations discussed in [RFC5763] are also applicable to the security and integrity of a DTLS-SRTP session or the data
this document. In addition, the B2BUA behaviors outlined in this exchanged over it. A malicious B2BUA can try to break into the DTLS
document do not impact the security and integrity of a DTLS-SRTP connection, but such an attack can be prevented using the identity
session or the data exchanged over it. A malicious B2BUA can try to validation mechanism discussed in [RFC4474] or
break into the DTLS connection, but such an attack can be prevented [I-D.ietf-stir-rfc4474bis]. Either the endpoints or authentication
using the identity validation mechanism discussed in [RFC4474]. service proxies involved in the call can use the identity validation
Either the endpoints or authentication service proxies involved in mechanisms discussed in [RFC4474] or [I-D.ietf-stir-rfc4474bis] to
the call MUST use the identity validation mechanisms discussed in validate the identity of peers and detect malicious B2BUA's that can
[RFC4474] to validate the identity of peers and detect malicious attempt to terminate the DTLS connection to decrypt the RTP payload.
B2BUA's that can attempt to terminate the DTLS connection to decrypt
the RTP payload.
6. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
7. Acknowledgments 9. Acknowledgments
Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan,
Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing,
Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa,
Christer Holmberg, Colin Perkins and Ben Campbell for their Christer Holmberg, Colin Perkins, Ben Campbell and Alissa Cooper for
constructive comments, suggestions, and early reviews that were their constructive comments, suggestions, and early reviews that were
critical to the formulation and refinement of this document. The critical to the formulation and refinement of this document. The
authors would also like to thank Dan Romascanu, Vijay K. Gurbani, authors would also like to thank Dan Romascanu, Vijay K. Gurbani,
Francis Dupont and Paul Wouters for their review and feedback of this Francis Dupont and Paul Wouters for their review and feedback of this
document. document.
8. Contributors 10. Contributors
Rajeev Seth provided substantial contributions to this document. Rajeev Seth provided substantial contributions to this document.
9. References 11. References
11.1. Normative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <http://www.rfc-editor.org/info/rfc3711>.
[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>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <http://www.rfc-editor.org/info/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
9.2. Informative References 11.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.jones-perc-private-media-reqts] [I-D.ietf-stir-rfc4474bis]
Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
J., and R. Barnes, "Private Media Requirements in Privacy "Authenticated Identity Management in the Session
Enhanced RTP Conferencing", draft-jones-perc-private- Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-07
media-reqts-00 (work in progress), July 2015. (work in progress), February 2016.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
with Session Description Protocol (SDP)", RFC 3264, Authenticated Identity Management in the Session
DOI 10.17487/RFC3264, June 2002, Initiation Protocol (SIP)", RFC 4474,
<http://www.rfc-editor.org/info/rfc3264>. DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<http://www.rfc-editor.org/info/rfc7092>. <http://www.rfc-editor.org/info/rfc7092>.
[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>.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Cisco
Cessna Business Park Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: rmohanr@cisco.com Email: rmohanr@cisco.com
 End of changes. 48 change blocks. 
167 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/