draft-ietf-straw-b2bua-dtls-srtp-04.txt   draft-ietf-straw-b2bua-dtls-srtp-05.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: January 23, 2016 Cisco Expires: February 18, 2016 Cisco
V. Pascual V. Pascual
Quobis Quobis
Parthasarathi. Ravindran Parthasarathi. Ravindran
Nokia Networks Nokia Networks
July 22, 2015 August 17, 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-04 draft-ietf-straw-b2bua-dtls-srtp-05
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 January 23, 2016. This Internet-Draft will expire on February 18, 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 21 skipping to change at page 2, line 21
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 Aware Relay . . . . . . . . . . . . . . . . . . 6 3.1.2. Media plane and 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 2, line 46 skipping to change at page 2, line 46
[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 Datagram Transport Layer Security
(DTLS) [RFC6347] protocol. It describes a mechanism of transporting (DTLS) [RFC6347] protocol. It describes a mechanism of transporting
a certificate fingerprint in the Session Description Protocol (SDP) a certificate fingerprint in the Session Description Protocol (SDP)
[RFC4566], which identifies the certificate that will be presented [RFC4566], which identifies the certificate that will be presented
during the DTLS handshake. DTLS-SRTP is defined for point-to-point during the DTLS handshake. DTLS-SRTP is defined for point-to-point
media sessions, in which there are exactly two participants. Each media sessions, in which there are exactly two participants. Each
DTLS-SRTP session (described in section 3 of [RFC5764]) contains a DTLS-SRTP session (described in section 3 of [RFC5764]) contains a
single DTLS association, and either two SRTP contexts (if media 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 entities exist in the SIP signaling path
between the originating and final terminating endpoints. These SIP between the originating and final terminating endpoints. These SIP
entities, as described in [RFC7092], modify SIP and SDP bodies and entities, as described in [RFC7092], modify SIP and SDP bodies and
also are likely to be on the media path. Such entities, when present also are likely to be on the media path. Such entities, when present
in the signaling/media path, are likely to do several things. For in the signaling/media path, are likely to do several things. For
example, some B2BUAs modify parts of the SDP body (like IP address, example, some B2BUAs modify parts of the SDP body (like IP address,
port) and subsequently modify the RTP headers as well. port) and subsequently modify the RTP headers as well.
1.2. Goals 1.2. Goals
[RFC7092] describes two different categories of such B2BUAs, [RFC7092] describes two different categories of such 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 act 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 modifies the UDP/IP header anything that is transported and only terminates the media plane
of the packets. 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 on end-to-end DTLS-SRTP streams.
2. Terminology 2. Terminology
skipping to change at page 4, line 16 skipping to change at page 4, line 16
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 UDP connection, without inspecting or modifying them. a negotiated connection, without inspecting or modifying them. A
It forwards the UDP payload as-is changing only the UDP/IP header. media relay only modifies the transport layer (UDP/TCP) and IP
headers.
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
DTLS-SRTP and a media relay B2BUA that changes only the IP address/ DTLS-SRTP and a media relay B2BUA that changes only the IP address/
port. 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) | (B2BUA's IP, port) | | (alice's IP/port) | (B2BUAs IP/port) |
|------------------------>|-------------------------->| |------------------------>|-------------------------->|
| | | | | |
| (2) 100 trying | | | (2) 100 trying | |
|<------------------------| | |<------------------------| |
| | (4) 100 trying | | | (4) 100 trying |
| |<--------------------------| | |<--------------------------|
| | | | | |
| | (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 address,port | | | B2BUAs IP/port | |
| (7, 8)ClientHello + use_srtp | | (7, 8)ClientHello + use_srtp |
|<------------------------|<--------------------------| |<------------------------|<--------------------------|
| | | | | |
| | | | | |
| (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 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. NOTE: For brevity the entire fingerprint attribute is not shown. The
example here shows only one DTLS connection for the sake of
simplicity. In reality depending on whether the RTP and RTCP flows
are multiplexed or un-multiplexed there will be one or two DTLS
connections.
For each RTP or RTCP flow, the peers do a DTLS handshake on the same If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a
source and destination port pair to establish a DTLS association. In single port then only a single DTLS connection would be required
this case, Bob, after he receives an INVITE, triggers a DTLS between the peers. If RTP and RTCP are not multiplexed, then the
connection. Note the DTLS handshake and the response to the INVITE peers would have to establish two DTLS connections. In this case,
may happen in parallel; thus, the B2BUA SHOULD be prepared to receive Bob, after he receives an INVITE, triggers the establishment of a
media on the ports it advertised to Bob in the OFFER. Since a media DTLS connection. Note the DTLS handshake and the response to the
relay B2BUA does not differentiate between a DTLS, RTP or any packet INVITE may happen in parallel; thus, the B2BUA SHOULD be prepared to
sent it receives, it just changes the UDP/IP addresses and forwards receive DTLS, STUN and media on the ports it advertised to Bob in the
the packet on either leg. OFFER. Since a media relay B2BUA does not differentiate between a
DTLS, RTP or any packet sent it receives, it just changes the
transport layer (UDP/TCP) and IP headers and forwards the packet on
either leg.
[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 headers used to construct
the signature. 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 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.1.2. Media Aware Relay 3.1.2. Media plane and Media Aware B2BUA
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.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 B2BUAs explained in Section 3.2.2 of [RFC7092] do not modify the RTP
skipping to change at page 7, line 25 skipping to change at page 7, line 29
4. Forking 4. Forking
In SIP, it is possible that a request can get forked and multiple In SIP, it is possible that a request can get forked and multiple
answers might be received for that request. So a single endpoint may answers might be received for that request. So a single endpoint may
end up negotiating multiple DTLS-SRTP sessions due to forking. B2BUA end up negotiating multiple DTLS-SRTP sessions due to forking. B2BUA
in both media relay and media aware relay modes MUST forward the in both media relay and media aware relay modes MUST forward the
certificate fingerprints and setup attributes it receives from each certificate fingerprints and setup attributes it receives from each
answerer as-is to the offerer. Since DTLS operates on the 5-tuple, answerer as-is to the offerer. Since DTLS operates on the 5-tuple,
B2BUA MUST replace the answerers transport addresses in each answer B2BUA MUST replace the answerers transport addresses in each answer
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 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
skipping to change at page 7, line 48 skipping to change at page 8, line 4
\ \
\ 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 connections, 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.2.3:7777) and Charlie's transport 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 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 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
skipping to change at page 8, line 31 skipping to change at page 8, line 36
discussed in [I-D.ietf-stir-rfc4474bis]. 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, Simon Perreault, Albrecht Schwarz and Jens Guballa for
suggestions, and early reviews that were critical to the formulation their constructive comments, suggestions, and early reviews that were
and refinement of this document. 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 9 skipping to change at page 10, line 15
[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>.
[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>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<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>.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Cisco
Cessna Business Park Cessna Business Park
skipping to change at page 10, line 46 skipping to change at page 11, line 16
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 Quobis
Spain Spain
Email: victor.pascual@quobis.com Email: victor.pascual.avila@gmail.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. 20 change blocks. 
32 lines changed or deleted 46 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/