draft-ietf-straw-b2bua-dtls-srtp-11.txt   draft-ietf-straw-b2bua-dtls-srtp-12.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: September 8, 2016 Cisco Expires: October 6, 2016 Cisco
V. Pascual V. Pascual
Quobis Oracle
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
March 7, 2016 April 4, 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-11 draft-ietf-straw-b2bua-dtls-srtp-12
Abstract Abstract
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA) Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA)
exist on the signaling and media paths between the endpoints. This exist on the signaling and media paths between the endpoints. This
document describes the behavior of B2BUAs when Secure Real-time document describes the behavior of B2BUAs when Secure Real-time
Transport (SRTP) security context is set up with the Datagram Transport (SRTP) security context is set up with the Datagram
Transport Layer Security (DTLS) protocol. Transport Layer Security (DTLS) protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 8, 2016. This Internet-Draft will expire on October 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
referred to as media plane B2BUAs. [RFC7092] describes two different referred to as media plane B2BUAs. [RFC7092] describes two different
categories of media plane B2BUAs, according to the level of categories of media plane B2BUAs, according to the level of
activities performed on the media plane. activities performed on the media plane.
When B2BUAs are present in a call between two SIP User Agents (UAs) 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 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 means that man-in-middle devices cannot break the
DTLS-SRTP session between the endpoints. In other words, the man-in- DTLS-SRTP session between the endpoints. In other words, the man-in-
middle device cannot create a separate DTLS-SRTP session between the middle device cannot create a separate DTLS-SRTP session between the
client and the middle device, on one side, and the middle device and 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 the remote peer on the other side. B2BUAs may be deployed for
that are typically deployed for address hiding or media latching, as address hiding or media latching [RFC7362], although TURN (and ICE)
described in [RFC7362], and such B2BUAs are able to perform their is expected to be used more often for this purpose as it provides
better security properties. Such B2BUAs are able to perform their
functions without requiring termination of DTLS-SRTP sessions i.e. functions without requiring termination of DTLS-SRTP sessions i.e.
these B2BUAs need not act as DTLS proxy and decrypt the RTP payload. these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.
1.2. Goals and Scope of this Document 1.2. Goals and Scope of this Document
A B2BUA could be deployed for address hiding or media latching, as A B2BUA could be deployed for address hiding or media latching, as
described in [RFC7362]. Such B2BUAs only terminate the media plane described in [RFC7362]. Such B2BUAs only terminate the media plane
at the IP and transport (UDP/TCP) layers and may inspect the RTP at the IP and transport (UDP/TCP) layers and may inspect the RTP
headers or RTP Control Protocol (RTCP) packets. The goal of this headers or RTP Control Protocol (RTCP) packets. The goal of this
specification is to provide guidance on how such B2BUAs function specification is to provide guidance on how such B2BUAs function
without breaking the end-to-end DTLS-SRTP session. A B2BUA could without breaking the end-to-end DTLS-SRTP session. A B2BUA could
also terminate the media or modify the RTP headers or RTP Control also terminate the media or modify the RTP headers or RTP Control
Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS- Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-
SRTP. Those B2BUAs terminating DTLS-SRTP sessions are outside the SRTP. The recommendations made in this document are not expected to
scope of this document. be applied by B2BUAs terminating DTLS-SRTP sessions given deployment
reality.
This specification assumes that a B2BUA is not providing identity This specification assumes that a B2BUA is not providing identity
assurance and is not authorized to terminate the DTLS-SRTP session. assurance and is not authorized to terminate the DTLS-SRTP session.
A B2BUA that provides identity assurance on behalf of endpoints A B2BUA that provides identity assurance on behalf of endpoints
behind it can modify any portion of SIP and SDP before it generates behind it can modify any portion of SIP and SDP before it generates
the identity signature. As the B2BUA is generating the identity the identity signature. As the B2BUA is generating the identity
signature it is not possible to detect if a B2BUA has terminated the signature it is not possible to detect if a B2BUA has terminated the
DTLS-SRTP session. B2BUAs providing identity assurance and DTLS-SRTP session. B2BUAs providing identity assurance and
terminating DTLS-SRTP session are out of scope of this document. terminating DTLS-SRTP session are out of scope of this document.
skipping to change at page 4, line 30 skipping to change at page 4, line 32
(UAC). (UAC).
UAS: a SIP User Agent Server. UAS: a SIP User Agent Server.
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 [RFC7656], as
[I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP well as those of SRTP [RFC3711], and DTLS [RFC6347].
[RFC3711], and DTLS [RFC6347].
3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP 3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP
A B2BUA MUST follow the rules mentioned below to allow end-to-end A B2BUA MUST follow the rules mentioned below to allow end-to-end
DTLS-SRTP session. DTLS-SRTP session.
1. B2BUAs MUST forward the certificate fingerprint and SDP setup 1. B2BUAs MUST forward the certificate fingerprint and SDP setup
attribute it receives from one endpoint unmodified towards the attribute it receives from one endpoint unmodified towards the
other endpoint and vice-versa. other endpoint and vice-versa.
skipping to change at page 5, line 27 skipping to change at page 5, line 28
that it does not modify any of the headers used to construct the that it does not modify any of the headers used to construct the
identity signature. identity signature.
4. Both media relays and media-aware relays MUST NOT modify the 4. Both media relays and media-aware relays MUST NOT modify the
authenticated portion of RTP and RTCP packets, and MUST NOT authenticated portion of RTP and RTCP packets, and MUST NOT
modify the authentication tag in the RTP and RTCP packets. modify the authentication tag in the RTP and RTCP packets.
4. Signaling Plane B2BUA Handling of DTLS-SRTP 4. Signaling Plane B2BUA Handling of DTLS-SRTP
Section 3.1 of [RFC7092] describes different categories of signaling Section 3.1 of [RFC7092] describes different categories of signaling
plane B2BUAs. This section explains the impact these B2BUAs can have plane B2BUAs. This section explains how these B2BUAs are expected to
on end-to-end DTLS-SRTP sessions. comply with the recommendations in Section 3.
4.1. Proxy-B2BUAs 4.1. Proxy-B2BUAs
Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only 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 the Via and Record-Route SIP headers. These B2BUAs can continue to
perform their function and still allow end-to-end DTLS-SRTP sessions 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 since it does not modify any of the headers used to construct the
identity signature. identity signature.
4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs 4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs
skipping to change at page 6, line 9 skipping to change at page 6, line 9
B2BUA can modify the Contact URI. Such B2BUAs are likely to violate B2BUA can modify the Contact URI. Such B2BUAs are likely to violate
rule 2 or rule 3 in Section 3. Depending upon the application rule 2 or rule 3 in Section 3. Depending upon the application
requirements, such a B2BUA may be able to limit modification of requirements, such a B2BUA may be able to limit modification of
header fields to those allowed to be modified by [RFC4474] or header fields to those allowed to be modified by [RFC4474] or
[I-D.ietf-stir-rfc4474bis]. [I-D.ietf-stir-rfc4474bis].
5. Media Plane B2BUA Handling of DTLS-SRTP 5. Media Plane B2BUA Handling of DTLS-SRTP
5.1. General 5.1. General
This section describes the DTLS-SRTP handling by the different types This section describes how the different types of media plane B2BUAs
of media plane B2BUAs defined in [RFC7092]. defined in [RFC7092] are expected to comply with the recommendations
in Section 3.
5.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, as described in Section 3, forwards the A media relay B2BUA follows the rule 1 mentioned in Section 3 and
certificate fingerprint and SDP setup attribute it receives from one forwards the certificate fingerprint and SDP setup attribute it
endpoint unmodified towards the other endpoint and vice-versa. The receives from one endpoint unmodified towards the other endpoint and
example below shows a SIP call establishment flow, with both SIP vice-versa. The example below shows a SIP call establishment flow,
endpoints (user agents) using DTLS-SRTP, and a media relay B2BUA. with both SIP 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 11, line 39 skipping to change at page 11, line 39
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>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-07 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-08
(work in progress), February 2016. (work in progress), March 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>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
skipping to change at page 12, line 36 skipping to change at page 12, line 30
[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 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
Traversal (HNT) for Media in Real-Time Communication", Traversal (HNT) for Media in Real-Time Communication",
RFC 7362, DOI 10.17487/RFC7362, September 2014, RFC 7362, DOI 10.17487/RFC7362, September 2014,
<http://www.rfc-editor.org/info/rfc7362>. <http://www.rfc-editor.org/info/rfc7362>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
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
skipping to change at page 13, line 22 skipping to change at page 13, line 22
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
Victor Pascual Victor Pascual
Quobis Oracle
Barcelona, Spain
Email: victor.pascual.avila@gmail.com Email: victor.pascual.avila@oracle.com
Parthasarathi Ravindran Parthasarathi Ravindran
Nokia Networks Nokia Networks
Bangalore, Karnataka Bangalore, Karnataka
India India
Email: partha@parthasarathi.co.in Email: partha@parthasarathi.co.in
 End of changes. 16 change blocks. 
33 lines changed or deleted 36 lines changed or added

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