draft-ietf-straw-b2bua-dtls-srtp-05.txt   draft-ietf-straw-b2bua-dtls-srtp-06.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: February 18, 2016 Cisco Expires: February 22, 2016 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
August 17, 2015 August 21, 2015
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-05 draft-ietf-straw-b2bua-dtls-srtp-06
Abstract Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
often function on the media plane, rather than just on the signaling often act on the media plane, rather than just on the signaling path.
path. This document describes the behavior B2BUAs should follow when This document describes the behavior such B2BUAs should adhere to
acting on the media plane that use Secure Real-time Transport (SRTP) when acting on the media plane that uses an Secure Real-time
security context setup with Datagram Transport Layer Security (DTLS) Transport (SRTP) security context set up with the Datagram Transport
protocol. Layer Security (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 February 18, 2016. This Internet-Draft will expire on February 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Media Plane B2BUA handling of DTLS-SRTP . . . . . . . . . . . 4 3. Media Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 4
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Media plane and Media Aware B2BUA . . . . . . . . . . 6 3.1.2. Media Aware B2BUA . . . . . . . . . . . . . . . . . . 6
3.2. Media Plane B2BUA with NAT handling . . . . . . . . . . . 7 3.2. Media Plane B2BUA with NAT Handling . . . . . . . . . . . 7
4. Forking . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Forking Considerations . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 Datagram Transport Layer Security [RFC3711] security context with the Datagram Transport Layer Security
(DTLS) [RFC6347] protocol. It describes a mechanism of transporting (DTLS) [RFC6347] protocol. It describes a mechanism for transporting
a certificate fingerprint in the Session Description Protocol (SDP) a certificate fingerprint using Session Description Protocol (SDP)
[RFC4566], which identifies the certificate that will be presented [RFC4566]. The fingerprint, identifies the certificate that will be
during the DTLS handshake. DTLS-SRTP is defined for point-to-point presented during the DTLS handshake. DTLS-SRTP is defined for point-
media sessions, in which there are exactly two participants. Each to-point media sessions, in which there are exactly two participants.
DTLS-SRTP session (described in section 3 of [RFC5764]) contains a Each DTLS-SRTP session (described in Section 3 of [RFC5764]) contains
single DTLS connection, and either two SRTP contexts (if media a single DTLS connection, and either two SRTP contexts (if media
traffic is flowing in both directions on the same 5-tuple) or one traffic is flowing in both directions on the same 5-tuple) or one
SRTP context (if media traffic is only flowing in one direction). SRTP context (if media traffic is only flowing in one direction).
In many SIP deployments, SIP entities exist in the SIP signaling path In many SIP deployments, SIP Back-to-Back User Agents (B2BUA)
between the originating and final terminating endpoints. These SIP entities exist on the SIP signaling path between the endpoints. As
entities, as described in [RFC7092], modify SIP and SDP bodies and described in [RFC7092], these B2BUAs may modify SIP and SDP
also are likely to be on the media path. Such entities, when present information. They may also be present on the media path, in which
in the signaling/media path, are likely to do several things. For case they may modify parts of the SDP information (like IP address,
example, some B2BUAs modify parts of the SDP body (like IP address, port) and subsequently modify the RTP headers as well. Such B2BUAs
port) and subsequently modify the RTP headers as well. are referred to as media plane B2BUAs
1.2. Goals 1.2. Goals
[RFC7092] describes two different categories of such B2BUAs, [RFC7092] describes two different categories of media plane B2BUAs,
according to the level of activities performed on the media plane: 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 that acts as a simple media relay effectively unaware of
anything that is transported and only terminates the media plane anything that is transported and only terminates the media plane
at the IP and transport (UDP/TCP) layers. at the IP and transport (UDP/TCP) layers.
A B2BUA that performs a media-aware role. It inspects and A B2BUA that performs a media-aware role. It inspects and
potentially modifies RTP or RTP Control Protocol (RTCP) headers; potentially modifies RTP or RTP Control Protocol (RTCP) headers;
but it does not modify the payload of RTP/RTCP. but it does not modify the payload of RTP/RTCP.
The following sections describe the behavior B2BUAs should follow in The following sections describe the behavior B2BUAs should follow in
order to avoid any impact on end-to-end DTLS-SRTP streams. order to avoid any impact to end-to-end DTLS-SRTP streams.
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].
The following generalized terms are defined in [RFC3261], Section 6. The following generalized terms are defined in [RFC3261], Section 6.
B2BUA: a SIP Back-to-Back User Agent, which is the logical B2BUA: a SIP Back-to-Back User Agent, which is the logical
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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. Media Plane B2BUA Handling of DTLS-SRTP
3.1. General 3.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 3.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 them. A a negotiated connection, without inspecting or modifying the packet
media relay only modifies the transport layer (UDP/TCP) and IP contents. A media relay only modifies the transport layer (UDP/TCP)
headers. and IP headers.
A media relay B2BUA MUST forward the certificate fingerprint and A media relay B2BUA MUST forward the certificate fingerprint and SDP
setup attribute it receives in the SDP from the originating endpoint setup attribute it receives from one endpoint unmodified towards the
as-is to the remote side and vice-versa. The example below shows an other endpoint and vice-versa. The example below shows a SIP call
"INVITE with SDP" SIP call flow, with both SIP user agents doing establishment flow, with both SIP endpoints (user agents) using DTLS-
DTLS-SRTP and a media relay B2BUA that changes only the IP address/ SRTP, and a media relay B2BUA.
port.
+-------+ +------------------+ +-----+ +-------+ +------------------+ +-----+
| 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 44 skipping to change at page 5, line 44
| (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 fingerprint attribute is not shown. The NOTE: For brevity the entire value of the SDP fingerprint attribute
example here shows only one DTLS connection for the sake of is not shown. The example here shows only one DTLS connection for
simplicity. In reality depending on whether the RTP and RTCP flows the sake of simplicity. In reality depending on whether the RTP and
are multiplexed or un-multiplexed there will be one or two DTLS RTCP flows are multiplexed or demultiplexed there will be one or two
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 would be required single port then only a single DTLS connection would be required
between the peers. If RTP and RTCP are not multiplexed, then the between the peers. If RTP and RTCP are not multiplexed, then the
peers would have to establish two DTLS connections. In this case, peers would have to establish two DTLS connections. In this case,
Bob, after he receives an INVITE, triggers the establishment of a Bob, after he receives an INVITE request, triggers the establishment
DTLS connection. Note the DTLS handshake and the response to the of a DTLS connection. Note that the DTLS handshake and the sending
INVITE may happen in parallel; thus, the B2BUA SHOULD be prepared to of INVITE response may happen in parallel; thus, the B2BUA SHOULD be
receive DTLS, STUN and media on the ports it advertised to Bob in the prepared to receive DTLS, STUN and media on the ports it advertised
OFFER. Since a media relay B2BUA does not differentiate between a to Bob in the INVITE request. Since a media relay B2BUA does not
DTLS, RTP or any packet sent it receives, it just changes the differentiate between a DTLS message, RTP or any packet it receives,
transport layer (UDP/TCP) and IP headers and forwards the packet on it only changes the transport layer (UDP/TCP) and IP headers and
either leg. forwards the packet towards the other endpoint.
[I-D.ietf-stir-rfc4474bis] provides a means for signing portions of [I-D.ietf-stir-rfc4474bis] provides a means for signing portions of
SIP requests in order to provide identity assurance and certificate SIP requests in order to provide identity assurance and certificate
pinning by providing a signature over the fingerprint of keying pinning by providing a signature over the fingerprint of keying
material in SDP for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST material in SDP for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST
ensure that it does not modify any of the headers used to construct ensure that it does not modify any of the information used to
the signature. construct the signature.
In the above example Alice may be authorized by the authorization In the above example, Alice may be authorized by the authorization
server (SIP proxy) in its domain using the procedures in section 5 of server (SIP proxy) in its domain using the procedures in Section 5 of
[I-D.ietf-stir-rfc4474bis]. In such a case, if B2BUA changes some of [I-D.ietf-stir-rfc4474bis]. In such a case, if the B2BUA modifies
the SIP headers or SDP content that was used by Alice's authorization some of the SIP headers or SDP content that was used by Alice's
server to generate the identity, it would break the identity authorization server to generate the identity, it would break the
verification procedure explained in section 4.2 of identity verification procedure explained in Section 4.2 of
[I-D.ietf-stir-rfc4474bis] resulting in a 438 error response being [I-D.ietf-stir-rfc4474bis] resulting in a 438 error response being
returned. returned.
3.1.2. Media plane and Media Aware B2BUA 3.1.2. Media Aware B2BUA
A media-aware relay, unlike the media relay discussed in the previous Unlike the media relay discussed in Section 3.1.1, a media-aware
section, is actually aware of the media traffic it is handling. A relay as defined in Section 3.2.2 of [RFC7092], is aware of the type
media-aware relay inspects SRTP and SRTCP packets flowing through it, of media traffic it is receiving. A media-aware relay inspects
and may or may not modify the headers of the packets before received SRTP and SRTCP packets and may modify the headers before
forwarding them. forwarding the packets.
3.1.2.1. RTP and RTCP Header Inspection 3.1.2.1. RTP and RTCP Header Inspection
B2BUAs explained in Section 3.2.2 of [RFC7092] do not modify the RTP A media-aware relay does not modify the RTP and RTCP headers but only
and RTCP headers but only inspect the headers. Such B2BUA MUST NOT inspects the header values. It MUST NOT terminate the DTLS-SRTP
terminate the DTLS-SRTP session. connection on which the packets are received.
3.1.2.2. RTP and RTCP Header Modification 3.1.2.2. RTP and RTCP Header Modification
In addition to inspecting the RTP and RTCP headers, the B2BUAs In addition to inspecting the RTP and RTCP headers, a media-aware
explained in section 3.2.2 [RFC7092], can also potentially modify relay may also modify them. In order to modify headers a B2BUA needs
them. To modify media headers a B2BUA needs to act as a DTLS to act as a DTLS endpoint and terminate the DTLS connection and
endpoint and terminate the DTLS connection so it can decrypt/re- decrypt/re-encrypt RTP packets. This would break end-to-end security
encrypt RTP packets. This breaks end-to-end security and hence a and hence a B2BUA MUST NOT terminate DTLS-SRTP sessions. This
B2BUA MUST NOT terminates DTLS-SRTP sessions. This security and security and privacy problem can be mitigated by having separate keys
privacy problem can be addressed by having separate keys for for encrypting the RTP header and media payload as discussed in
encrypting the RTP header and media payload as discussed in the on [I-D.jones-perc-private-media-reqts]. With such an approach, the
going work in [I-D.jones-perc-private-media-reqts], in which case the
B2BUA is not aware of the keys used to decrypt the media payload. B2BUA is not aware of the keys used to decrypt the media payload.
3.2. Media Plane B2BUA with NAT handling 3.2. Media Plane B2BUA with NAT Handling
DTLS-SRTP handshakes and offer/answer can happen in parallel. If a DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may
UA is behind a NAT and acting as a DTLS server, the ClientHello happen in parallel. If an endpoint is behind a NAT, and the endpoint
message from a B2BUA(DTLS client) is likely to be lost, as described is acting as a DTLS server, the ClientHello message from a B2BUA
in section 7.3 of [RFC5763]. In order to overcome this problem, a UA (acting as DTLS client) is likely to be lost, as described in
and B2BUA must support ICE as discussed in section 7.3 of [RFC5763]. Section 7.3 of [RFC5763]. In order to overcome this problem, the
If ICE check is successful then UA will receive ClientHello packet endpoint and B2BUA can support the Interactive Connectivity
from B2BUA. 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 4. Forking Considerations
In SIP, it is possible that a request can get forked and multiple Due to forking [RFC3261], a SIP request carrying an SDP offer sent by
answers might be received for that request. So a single endpoint may an endpoint (offerer) may reach multiple remote endpoints. As a
end up negotiating multiple DTLS-SRTP sessions due to forking. B2BUA result, multiple DTLS-SRTP connections may be established, one
in both media relay and media aware relay modes MUST forward the between the endpoint that sent the SIP request and each of the remote
certificate fingerprints and setup attributes it receives from each endpoints that received the request. Both media relays and media-
answerer as-is to the offerer. Since DTLS operates on the 5-tuple, aware relays MUST forward the certificate fingerprints and SDP setup
B2BUA MUST replace the answerers transport addresses in each answer attributes it received in the SDP answer from each endpoint
with its unique transport addresses so that the offerer can establish (answerer) unmodified towards the offerer. Since DTLS operates on
a DTLS connection with each answerer. the 5-tuple, B2BUA MUST replace 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.
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
<-----------> (192.0.2.3:8888) <-----------> (192.0.2.3:8888)
DTLS-SRTP=YYY ^ DTLS-SRTP=YYY ^
\ \
\ DTLS-SRTP=YYY \ DTLS-SRTP=YYY
\ \
\ \
\ \
Charlie (192.0.2.2:6666) Charlie (192.0.2.2:6666)
For instance, if Alice makes a call that is forked and receives Figure 2: B2BUA handling multiple answers
multiple answers from Bob and Charlie, B2BUA must advertise different
B2BUA transport address in each answer, as shown in the above Figure, For instance, as shown in Figure 2 Alice sends a request with an
where XXX and YYY represent different DTLS-SRTP connections, B2BUA offer, and the request is forked. Alice receives answers from both
replaces the Bob's transport address (192.0.2.1:6666) in the answer Bob and Charlie. B2BUA MUST advertise different B2BUA transport
with its transport address (192.0.2.3:7777) and Charlie's transport address in each answer, as shown in Figure2, where XXX and YYY
address (192.0.2.2:6666) in the answer with its transport address represent different DTLS-SRTP connections. B2BUA replaces the Bob's
(192.0.2.3:8888). B2BUA tracks the remote sources (Bob and Alice) 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). B2BUA tracks the remote sources (Bob and Charlie)
and associates them to the local sources that are used to send and associates them to the local sources that are used to send
packets to Alice. packets to Alice.
5. Security Considerations 5. Security Considerations
This document describes the behavior media plane B2BUAs (media-aware This document describes the behavior media plane B2BUAs (media-aware
and media-unaware) should follow when acting on the media plane that and media-unaware) should follow when acting on the media plane that
uses SRTP security context setup with the DTLS protocol. Attempting uses SRTP security context setup with the DTLS protocol. Attempting
to cover Media-aware Relay and Media Termination scenarios involving to cover media-aware relay and media termination scenarios involving
secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA
acting as a man-in-the-middle, and as such its behavior is acting as a man-in-the-middle, and as such its behavior is
unspecified and Discouraged. It does not introduce any specific unspecified and discouraged. This document does not introduce any
security considerations beyond those detailed in [RFC5763]. The specific security considerations beyond those detailed in [RFC5763].
B2BUA behaviors outlined here also do not impact the security and In addition, the B2BUA behaviors outlined in this document do not
integrity of the DTLS-SRTP session nor the data exchanged over it. A impact the security and integrity of a DTLS-SRTP connection or the
malicious B2BUA can try to break into the DTLS session, but such an data exchanged over it. A malicious B2BUA may try to break into the
attack can be prevented using the identity validation mechanism DTLS connection, but such an attack can be prevented using the
discussed in [I-D.ietf-stir-rfc4474bis]. identity validation mechanism discussed in
[I-D.ietf-stir-rfc4474bis].
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
7. Acknowledgments 7. 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 and Jens Guballa for Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa and
their constructive comments, suggestions, and early reviews that were Christer Holmberg for their constructive comments,suggestions, and
critical to the formulation and refinement of this document. early reviews that were critical to the formulation and refinement of
this document.
8. Contributors 8. Contributors
Rajeev Seth provided substantial contributions to this document. Rajeev Seth provided substantial contributions to this document.
9. References 9. References
9.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
skipping to change at page 10, line 11 skipping to change at page 10, line 36
J., and R. Barnes, "Private Media Requirements in Privacy J., and R. Barnes, "Private Media Requirements in Privacy
Enhanced RTP Conferencing", draft-jones-perc-private- Enhanced RTP Conferencing", draft-jones-perc-private-
media-reqts-00 (work in progress), July 2015. media-reqts-00 (work in progress), July 2015.
[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
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[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>.
 End of changes. 33 change blocks. 
123 lines changed or deleted 141 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/