draft-ietf-straw-b2bua-dtls-srtp-02.txt   draft-ietf-straw-b2bua-dtls-srtp-03.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: November 22, 2015 Cisco Expires: December 20, 2015 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
May 21, 2015 June 18, 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-02 draft-ietf-straw-b2bua-dtls-srtp-03
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 function on the media plane, rather than just on the signaling
path. This document describes the behavior B2BUAs should follow when path. This document describes the behavior B2BUAs should follow when
acting on the media plane that use Secure Real-time Transport (SRTP) acting on the media plane that use Secure Real-time Transport (SRTP)
security context setup with Datagram Transport Layer Security (DTLS) security context setup with Datagram Transport Layer Security (DTLS)
protocol. protocol.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 22, 2015. This Internet-Draft will expire on December 20, 2015.
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 B2BUAs . . . . . . . . . . . . . . . . . . . . . 4 3. Media Plane B2BUA handling of DTLS-SRTP . . . . . . . . . . . 4
3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Media Aware Relay . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. RTP and RTCP Header Inspection . . . . . . . . . . . 6 3.1.2. Media Aware Relay . . . . . . . . . . . . . . . . . . 6
3.2.2. RTP and RTCP Header Modification . . . . . . . . . . 6 3.2. Media Plane B2BUA with NAT handling . . . . . . . . . . . 7
3.3. Media Plane B2BUA with NAT handling . . . . . . . . . . . 7
4. Forking . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Forking . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 26 skipping to change at page 3, line 23
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 act as a simple media relay effectively unaware of A B2BUA that act as a simple media relay effectively unaware of
anything that is transported and only modifies the UDP/IP header anything that is transported and only modifies the UDP/IP header
of the packets. of the packets.
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 behaviour 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 on 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.
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 B2BUAs 3. Media Plane B2BUA handling of DTLS-SRTP
3.1. Media Relay 3.1. General
This section describes the DTLS-SRTP handling by the different types
of media plane B2BUAs defined in [RFC7092].
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 UDP connection, without inspecting or modifying them. a negotiated UDP connection, without inspecting or modifying them.
It forwards the UDP payload as-is changing only the UDP/IP header. It forwards the UDP payload as-is changing only the UDP/IP header.
A media relay B2BUA MUST forward the certificate fingerprint and A media relay B2BUA MUST forward the certificate fingerprint and
setup attribute it receives in the SDP from the originating endpoint setup attribute it receives in the SDP from the originating endpoint
as-is to the remote side and vice-versa. The example below shows an as-is to the remote side and vice-versa. The example below shows an
"INVITE with SDP" SIP call flow, with both SIP user agents doing "INVITE with SDP" SIP call flow, with both SIP user agents doing
skipping to change at page 5, line 42 skipping to change at page 5, line 42
| (9,10)ServerHello + use_srtp | | (9,10)ServerHello + use_srtp |
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| (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 just changes UDP/IP header] | | [B2BUA just changes UDP/IP header] |
Figure 1: INVITE with SDP callflow 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. NOTE: For brevity the entire fingerprint attribute is not shown.
For each RTP or RTCP flow, the peers do a DTLS handshake on the same For each RTP or RTCP flow, the peers do a DTLS handshake on the same
source and destination port pair to establish a DTLS association. In source and destination port pair to establish a DTLS association. In
this case, Bob, after he receives an INVITE, triggers a DTLS this case, Bob, after he receives an INVITE, triggers a DTLS
connection. Note the DTLS handshake and the response to the INVITE connection. Note the DTLS handshake and the response to the INVITE
may happen in parallel; thus, the B2BUA SHOULD be prepared to receive may happen in parallel; thus, the B2BUA SHOULD be prepared to receive
media on the ports it advertised to Bob in the OFFER. Since a media media on the ports it advertised to Bob in the OFFER. Since a media
relay B2BUA does not differentiate between a DTLS, RTP or any packet relay B2BUA does not differentiate between a DTLS, RTP or any packet
skipping to change at page 6, line 23 skipping to change at page 6, line 23
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 B2BUA changes some of
the SIP headers or SDP content that was used by Alice's authorization the SIP headers or SDP content that was used by Alice's authorization
server to generate the identity, it would break the identity server to generate the identity, it would break the identity
verification procedure explained in section 4.2 of 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.2. Media Aware Relay 3.1.2. Media Aware Relay
A media-aware relay, unlike the media relay discussed in the previous A media-aware relay, unlike the media relay discussed in the previous
section, is actually aware of the media traffic it is handling. A section, is actually aware of the media traffic it is handling. A
media-aware relay inspects SRTP and SRTCP packets flowing through it, media-aware relay inspects SRTP and SRTCP packets flowing through it,
and may or may not modify the headers of the packets before and may or may not modify the headers of the packets before
forwarding them. forwarding them.
3.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 B2BUAs explained in Section 3.2.2 of [RFC7092] do not modify the RTP
and RTCP headers but only inspect the headers. Such B2BUA MUST NOT and RTCP headers but only inspect the headers. Such B2BUA MUST NOT
terminate the DTLS-SRTP session. terminate the DTLS-SRTP session.
3.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, the B2BUAs
explained in section 3.2.2 [RFC7092], can also potentially modify explained in section 3.2.2 [RFC7092], can also potentially modify
them. To modify media headers a B2BUA needs to act as a DTLS them. To modify media headers a B2BUA needs to act as a DTLS
intermediary and terminate the DTLS connection so it can decrypt/re- intermediary and terminate the DTLS connection so it can decrypt/re-
encrypt RTP packets. This breaks end-to-end security. This security encrypt RTP packets. This breaks end-to-end security. This security
and privacy problem can be addressed by having separate keys for and privacy problem can be addressed by having separate keys 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-avtcore-private-media-reqts], in which case the B2BUA is going work in [I-D.jones-avtcore-private-media-reqts], in which case
not aware of the keys used to decrypt the media payload. the B2BUA is not aware of the keys used to decrypt the media payload.
3.3. 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 offer/answer can happen in parallel. If a
UA is behind a NAT and acting as a DTLS server, the ClientHello UA is behind a NAT and acting as a DTLS server, the ClientHello
message from a B2BUA(DTLS client) is likely to be lost, as described message from a B2BUA(DTLS client) is likely to be lost, as described
in section 7.3 of [RFC5763]. In order to overcome this problem, a UA in section 7.3 of [RFC5763]. In order to overcome this problem, a UA
and B2BUA must support ICE as discussed in section 7.3 of [RFC5763]. and B2BUA must support ICE as discussed in section 7.3 of [RFC5763].
If ICE check is successful then UA will receive ClientHello packet If ICE check is successful then UA will receive ClientHello packet
from B2BUA. from B2BUA.
4. Forking 4. Forking
skipping to change at page 7, line 34 skipping to change at page 7, line 34
with its unique transport addresses so that the offerer can establish with its unique transport addresses so that the offerer can establish
a DTLS association with each answerer. a DTLS association 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.3.1:7777) <-----------> (192.0.2.3:7777)
Alice (192.0.2.0:5555) B2BUA Alice (192.0.2.0:5555) B2BUA
<-----------> (192.0.3.1: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 For instance, if Alice makes a call that is forked and receives
multiple answers from Bob and Charlie, B2BUA must advertise different multiple answers from Bob and Charlie, B2BUA must advertise different
B2BUA transport address in each answer, as shown in the above Figure, B2BUA transport address in each answer, as shown in the above Figure,
where XXX and YYY represent different DTLS-SRTP associations, B2BUA where XXX and YYY represent different DTLS-SRTP associations, B2BUA
replaces the Bob's transport address (192.0.2.1:6666) in the answer replaces the Bob's transport address (192.0.2.1:6666) in the answer
with its transport address (192.0.3.1:7777) and Charlie's transport with its transport address (192.0.2.3:7777) and Charlie's transport
address (92.0.2.2:6666) in the answer with its transport address address (192.0.2.2:6666) in the answer with its transport address
(192.0.3.1:8888). B2BUA tracks the remote sources (Bob and Alice) (192.0.2.3:8888). B2BUA tracks the remote sources (Bob and Alice)
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. It does not uses SRTP security context setup with the DTLS protocol. Attempting
introduce any specific security considerations beyond those detailed to cover Media-aware Relay and Media Termination scenarios involving
in [RFC5763]. The B2BUA behaviors outlined here also do not impact secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA
the security and integrity of the DTLS-SRTP session nor the data acting as a man-in-the-middle, and as such its behavior is
exchanged over it. A malicious B2BUA can try to break into the DTLS unspecified and Discouraged. It does not introduce any specific
session, but such an attack can be prevented using the identity security considerations beyond those detailed in [RFC5763]. The
validation mechanism discussed in [I-D.ietf-stir-rfc4474bis]. B2BUA behaviors outlined here also do not impact the security and
integrity of the DTLS-SRTP session nor the data exchanged over it. A
malicious B2BUA can try to break into the DTLS session, but such an
attack can be prevented using the 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 and Simon Perreault for their constructive comments, Charles Eckel and Simon Perreault for their constructive comments,
 End of changes. 18 change blocks. 
33 lines changed or deleted 41 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/