draft-ietf-mmusic-opportunistic-negotiation-00.txt   draft-ietf-mmusic-opportunistic-negotiation-01.txt 
Network Working Group A. Hutton Network Working Group A. Hutton
Internet-Draft Unify Internet-Draft Unify / Atos
Updates: 4568,4585 (if approved) R. Jesske Updates: 4568,4585 (if approved) R. Jesske
Intended status: Standards Track Deutsche Telekom Intended status: Standards Track Deutsche Telekom
Expires: December 7, 2017 A. Johnston Expires: March 18, 2018 A. Johnston
Unaffiliated Rowan University
G. Salgueiro G. Salgueiro
Cisco Cisco
B. Aboba B. Aboba
Microsoft Microsoft
June 5, 2017 September 14, 2017
Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile
draft-ietf-mmusic-opportunistic-negotiation-00 draft-ietf-mmusic-opportunistic-negotiation-01
Abstract Abstract
This document describes how the use of the Secure Real-time transport This document describes how the use of the Secure Real-time transport
protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Audio protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio
Video Profile) defined in [RFC3551]. Such a mechanism is used to Video Profile) defined in [RFC3551]. Such a mechanism is used to
provide a means for encrypted media to be used in environments where provide a means for encrypted media to be used in environments where
support for encryption is not known in advance, and not required. support for encryption is not known in advance, and not required.
The same mechanism is also applied to negotiation of the Extended RTP The same mechanism is also applied to negotiation of the Extended RTP
Profile for Real-time Transport Control Protocol Based Feedback (RTP/ Profile for Real-time Transport Control Protocol Based Feedback (RTP/
AVPF) [RFC4585]. AVPF) [RFC4585].
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 https://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 December 7, 2017. This Internet-Draft will expire on March 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use of RTP/AVP profile with SRTP . . . . . . . . . . . . . . 3 4. Use of RTP/AVP profile with SRTP . . . . . . . . . . . . . . 3
5. Use of RTP/AVP profile with RTCP Feedback . . . . . . . . . . 4 5. Use of RTP/AVP profile with RTCP Feedback . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Opportunistic Security [RFC7435] is an approach to security that Opportunistic Security [RFC7435] is an approach to security that
defines a third mode for security between "cleartext" and defines a third mode for security between "cleartext" and
"comprehensive protection" that allows encryption and authentication "comprehensive protection" that allows encryption and authentication
to be used if supported but will not result in failures if it is not to be used if supported but will not result in failures if it is not
supported. In terms of secure media, cleartext is RTP [RFC3550] supported. In terms of secure media, cleartext is RTP [RFC3550]
media which is negotiated with the AVP (Audio Video Profile) profile media which is negotiated with the RTP/AVP (Audio Video Profile)
defined [RFC3551]. Comprehensive protection is Secure RTP [RFC3711], profile defined [RFC3551]. Comprehensive protection is Secure RTP
negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. [RFC3711], negotiated with a secure profile, such as RTP/SAVP or RTP/
SAVPF [RFC5124].
[I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transport [I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transport
protocol (SRTP) can be negotiated opportunistically. protocol (SRTP) can be negotiated opportunistically.
[RFC4568] however requires that SRTP is only negotiated using the [RFC4568] however requires that SRTP is only negotiated using the
RTP/SAVP profile [RFC3711] or the RTP/SAVPF profile [RFC5124]. This RTP/SAVP profile [RFC3711] or the RTP/SAVPF profile [RFC5124]. This
document relaxes this rule by allowing SRTP to be used with the RTP/ document relaxes this rule by allowing SRTP to be used with the RTP/
AVP profile when negotiated opportunistically. AVP profile when negotiated opportunistically.
Similarly [RFC4585] requires that the RTCP extended reports are only Similarly [RFC4585] requires that the RTCP extended reports are only
used in media sessions for which the "AVPF" profile is specified. used in media sessions for which the RTP/AVPF profile is specified.
This document therefore also relaxes this rule allowing RTCP based This document therefore also relaxes this rule allowing RTCP based
feedback to be used with the RTP/AVP profile. feedback to be used with the RTP/AVP profile.
2. Normative Language 2. Normative Language
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Motivation 3. Motivation
In theory SDP [RFC4566] allows different RTP profiles such as SAVP, In theory SDP [RFC4566] allows different RTP profiles such as RTP/
AVPF, and AVP to be offered as separate m-lines, and allows the SAVP, RTP/AVPF, and RTP/AVP to be offered as separate m-lines, and
answerer to reject profiles it does not support or does not wish to allows the answerer to reject profiles it does not support or does
use. However the use of multiple m-lines for such a negotiation is not wish to use. However the use of multiple m-lines for such a
not well defined and implementations receiving such an offer are negotiation is not well defined and implementations receiving such an
likely to reject the SDP Offer rather than use the profile they offer are likely to reject the SDP Offer rather than use the profile
support. This negotiation failure has been observed when negotiating they support. This negotiation failure has been observed when
the secure profile (SAVP) and also when negotiating RTCP based negotiating the secure profile (RTP/SAVP) and also when negotiating
feedback messages [RFC4585] (RTP/AVPF) or both (RTP/SAVPF). RTCP based feedback messages [RFC4585] (RTP/AVPF) or both (RTP/
SAVPF).
To avoid using multiple m-lines to negotiate RTP profiles this draft To avoid using multiple m-lines to negotiate RTP profiles this draft
recognized that existing implementation of SRTP, and RTCP feedback, recognized that existing implementation of SRTP, and RTCP feedback,
make use of the relevant SDP attributes to indicate such make use of the relevant SDP attributes to indicate such
capabilities. The approach therefore taken in this draft uses the capabilities. The approach therefore taken in this draft uses the
"a=" lines in SDP to negotiate these capabilities in a single offer/ "a=" lines in SDP to negotiate these capabilities in a single offer/
answer exchange, by offering the AVP profile but indicating the answer exchange, by offering the RTP/AVP profile but indicating the
supported functionality in a=lines. supported functionality in a=lines.
4. Use of RTP/AVP profile with SRTP 4. Use of RTP/AVP profile with SRTP
To negotiate SRTP in an opportunistic way such as that described in To negotiate SRTP in an opportunistic way such as that described in
[I-D.ietf-sipbrandy-osrtp] requires a fallback to unencrypted media [I-D.ietf-sipbrandy-osrtp] requires a fallback to unencrypted media
to occur if the remote endpoint does not support SRTP. to occur if the remote endpoint does not support SRTP.
Therefore when negotiating SRTP opportunistically the SDP offerer Therefore when negotiating SRTP opportunistically the SDP offerer
MUST use the AVP profile [RFC3551]. This is independent of the key MUST use the RTP/AVP profile [RFC3551]. This is independent of the
exchange mechanism used. key exchange mechanism used.
The SDP answerer MUST use the AVP profile if it does not encrypt the The SDP answerer MUST use the RTP/AVP profile if it does not encrypt
media and MAY use the AVP if it encrypts the media. The exact the media and MAY use the RTP/AVP if it encrypts the media. The
negotiation mechanism is however outside the scope of this document, exact negotiation mechanism is however outside the scope of this
an example mechanism can be found in [I-D.ietf-sipbrandy-osrtp]. document, an example mechanism can be found in
[I-D.ietf-sipbrandy-osrtp].
5. Use of RTP/AVP profile with RTCP Feedback 5. Use of RTP/AVP profile with RTCP Feedback
Negotiating the use of the Extended RTP Profile for RTCP Based Negotiating the use of the Extended RTP Profile for RTCP Based
Feedback (RTP/AVPF) [RFC4585] opportunistically also requires the Feedback (RTP/AVPF) [RFC4585] opportunistically also requires the
offerer to use the AVP profile otherwise the offer is likely to be offerer to use the RTP/AVP profile otherwise the offer is likely to
rejected by an answerer who does not support AVPF. be rejected by an answerer who does not support RTP/AVPF.
Therefore when negotiating RTCP Based Feedback opportunistically the Therefore when negotiating RTCP Based Feedback opportunistically the
SDP offerer MUST use the AVP profile [RFC3551] and include the SDP offerer MUST use the RTP/AVP profile [RFC3551] and include the
"a=rtcp-fb" SDP attribute as described in [RFC4585]. "a=rtcp-fb" SDP attribute as described in [RFC4585].
The SDP answerer indicates support for RTCP Based Feedback by The SDP answerer indicates support for RTCP Based Feedback by
including the "a=rtcp-fb" SDP attribute in the SDP Answer. The RTP including the "a=rtcp-fb" SDP attribute in the SDP Answer. The RTP
profile in the SDP answer MAY be set to AVP (SAVP) or AVPF (SAVPF). profile in the SDP answer MAY be set to RTP/AVP (SAVP) or RTP/AVPF
(SAVPF).
This is an update to [RFC4585] which requires that the "a=rtcp-fb" This is an update to [RFC4585] which requires that the "a=rtcp-fb"
attribute is only used with the AVPF profile. All other [RFC4585] attribute is only used with the RTP/AVPF profile. All other
procedures remain unchanged. [RFC4585] procedures remain unchanged.
6. IANA Considerations 6. IANA Considerations
None None
7. Security Considerations 7. Security Considerations
The security considerations of [RFC7435] apply to any opportunistic The security considerations of [RFC7435] apply to any opportunistic
approach to SRTP. approach to SRTP.
It is important to note that negotiating SRTP in an opportunistic way It is important to note that negotiating SRTP in an opportunistic way
makes no changes, and has no effect on media sessions in which the makes no changes, and has no effect on media sessions in which the
offer contains a secure profile of RTP, such as SAVP or SAVPF. As offer contains a secure profile of RTP, such as RTP/SAVP or RTP/
discussed in [RFC7435] this is the "comprehensive protection" for SAVPF. As discussed in [RFC7435] this is the "comprehensive
media mode. protection" for media mode.
8. Acknowledgements 8. Acknowledgements
This document is dedicated to our friend and colleague Francois Audet This document is dedicated to our friend and colleague Francois Audet
who is greatly missed in our community. His work on improving who is greatly missed in our community. His work on improving
security in SIP and RTP provided the foundation for this work. security in SIP and RTP provided the foundation for this work.
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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-sipbrandy-osrtp] [I-D.ietf-sipbrandy-osrtp]
Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T.
Stach, "An Opportunistic Approach for Secure Real-time Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-02 Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-02
(work in progress), May 2017. (work in progress), May 2017.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[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, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<http://www.rfc-editor.org/info/rfc4568>. <https://www.rfc-editor.org/info/rfc4568>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
Authors' Addresses Authors' Addresses
Andrew Hutton Andrew Hutton
Unify Unify / Atos
Brickhill Street 4 Triton Square
Milton Keynes MK15 0DJ London NW1 3HG
UK UK
Email: andrew.hutton@unify.com Email: andrew.hutton@atos.net
Roland Jesske Roland Jesske
Deutsche Telekom Deutsche Telekom
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: R.Jesske@telekom.de Email: R.Jesske@telekom.de
Alan Johnston Alan Johnston
Unaffiliated Rowan University
Bellevue, WA Glassboro, NJ
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Cisco
7200-12 Kit Creek Road 7200-12 Kit Creek Road
RTP, NC 27709 RTP, NC 27709
USA USA
 End of changes. 32 change blocks. 
55 lines changed or deleted 59 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/