<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3550 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3551 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC4566 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4568 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY RFC4585 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY RFC7435 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7435.xml">
<!ENTITY RFC3711 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC5124 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY RFC2397 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2397.xml">
<!ENTITY OSRTP PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-sipbrandy-osrtp.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc updates="4568,4585" category="std" docName="draft-ietf-mmusic-opportunistic-negotiation-01" ipr="trust200902">
    
    <!-- ***** FRONT MATTER ***** -->
    
    <front>
        <title abbrev="Negotiating RTP Profiles">Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile</title>
        
        <!-- add 'role="editor"' below for the editors if appropriate -->
        
        <!-- Another author who claims to be an editor -->
        
        <author fullname="Andrew Hutton" initials="A."
            surname="Hutton">
            <organization>Unify / Atos</organization>            
            <address>
                <postal>
                    <street>4 Triton Square</street>
                    <city>London</city>
                    <code>NW1 3HG</code>
                    <country>UK</country>
                </postal>
                
                <phone></phone>
                
                <email>andrew.hutton@atos.net</email>
                
                <!-- uri and facsimile elements may also be added -->
            </address>
        </author>
	<author initials="R" surname="Jesske" fullname="Roland Jesske">
      <organization>Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Heinrich-Hertz-Strasse 3-7</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>R.Jesske@telekom.de</email>
      </address>
    </author>
  <author fullname="Alan Johnston" initials="A." surname="Johnston">
      <organization>Rowan University</organization>
      <address>
        <postal>
          <street></street>
          <city>Glassboro</city>
          <region>NJ</region>
          <code></code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>alan.b.johnston@gmail.com</email>
      </address>
    </author>
    <author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>
          <city>RTP</city>
          <region>NC</region>
          <code>27709</code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>gsalguei@cisco.com</email>
      </address>
    </author>
<author fullname="Bernard Aboba" initials="B." surname="Aboba">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>USA</country>
        </postal>
        <phone></phone>
        <email>bernard.aboba@gmail.com</email>
      </address>
    </author>


        
        <date />
        
        <!-- Meta-data Declarations -->
        
        <area>ART</area>
     <!--   <workgroup>MMUSIC</workgroup> -->
        
        <keyword>SIP</keyword>
        <keyword>SDP</keyword>
        <keyword>SRTP</keyword>        
        <keyword>OSRTP</keyword>
        
        <abstract>
            <t>
            This document describes how the use of the Secure Real-time transport protocol (SRTP) <xref target="RFC3711"></xref>. can be negotiated using the RTP/AVP (Audio Video Profile) defined in <xref target="RFC3551"></xref>. Such a mechanism is used to provide a means for encrypted media to be used in environments where support for encryption is not known in advance, and not required. The same mechanism is also applied to negotiation of the Extended RTP Profile for Real-time Transport Control Protocol Based Feedback (RTP/AVPF) <xref target="RFC4585"></xref>. 
            </t>  

        </abstract>
    </front>
    <!-- *********************************************************************** -->
    <middle>
        <section title="Introduction">

<t>Opportunistic Security <xref target="RFC7435"></xref> is an approach to security that defines a third mode for security between "cleartext" and "comprehensive protection" that allows encryption and authentication to be used if supported but will not result in failures if it is not supported.  In terms of secure media, cleartext is RTP <xref target="RFC3550"></xref> media which is negotiated with the RTP/AVP (Audio Video Profile) profile defined <xref target="RFC3551"></xref>.  Comprehensive protection is Secure RTP <xref target="RFC3711"></xref>,   negotiated with a secure profile, such as RTP/SAVP or RTP/SAVPF <xref target="RFC5124"></xref>.</t>

<t><xref target="I-D.ietf-sipbrandy-osrtp"/> describes how Secure Real-time transport protocol (SRTP) can be negotiated opportunistically.</t>

<t><xref target="RFC4568"></xref> however requires that SRTP is only negotiated using the RTP/SAVP profile <xref target="RFC3711"></xref> or the RTP/SAVPF profile <xref target="RFC5124"></xref>. This document relaxes this rule by allowing SRTP to be used with the RTP/AVP profile when negotiated opportunistically.
</t>

<t>Similarly <xref target="RFC4585"></xref> requires that the RTCP extended reports are only used in media sessions for which the RTP/AVPF profile is specified. This document therefore also relaxes this rule allowing RTCP based feedback to be used with the RTP/AVP profile.
</t>

</section>
        
<section anchor="normative" title="Normative Language">
            
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 <xref target="RFC2119"/>.</t>
</section>

<section title="Motivation" >

<t>In theory SDP <xref target="RFC4566"></xref> allows different RTP profiles such as RTP/SAVP, RTP/AVPF, and RTP/AVP to be offered as separate m-lines, and allows the answerer to reject profiles it does not support or does not wish to use. However the use of multiple m-lines for such a negotiation is not well defined and implementations receiving such an offer are likely to reject the SDP Offer rather than use the profile they support. This negotiation failure has been observed when negotiating the secure profile (RTP/SAVP) and also when negotiating RTCP based feedback messages <xref target="RFC4585"></xref> (RTP/AVPF) or both (RTP/SAVPF).
</t>

<t>To avoid using multiple m-lines to negotiate RTP profiles this draft recognized that existing implementation of SRTP, and RTCP feedback, make use of the relevant SDP attributes to indicate such capabilities. The approach therefore taken in this draft uses the "a=" lines in SDP to negotiate these capabilities in a single offer/answer exchange, by offering the RTP/AVP profile but indicating the supported functionality in a=lines.
</t>

</section>


<section title="Use of RTP/AVP profile with SRTP">

<t>To negotiate SRTP in an opportunistic way such as that described in <xref target="I-D.ietf-sipbrandy-osrtp"/> requires a fallback to unencrypted media to occur if the remote endpoint does not support SRTP.</t>

<t>Therefore when negotiating SRTP opportunistically the SDP offerer MUST use the RTP/AVP profile <xref target="RFC3551"></xref>. This is independent of the key exchange mechanism used.</t>

<t>The SDP answerer MUST use the RTP/AVP profile if it does not encrypt the media and MAY use the RTP/AVP if it encrypts the media. The exact negotiation mechanism is however outside the scope of this document, an example mechanism can be found in <xref target="I-D.ietf-sipbrandy-osrtp"/>.</t>


</section>

<section title="Use of RTP/AVP profile with RTCP Feedback">

<t>Negotiating the use of the Extended RTP Profile for
RTCP Based Feedback (RTP/AVPF) <xref target="RFC4585"></xref> opportunistically also requires the offerer to use the RTP/AVP profile otherwise the offer is likely to be rejected by an answerer who does not support RTP/AVPF. 
</t>

<t>Therefore when negotiating RTCP Based Feedback opportunistically the SDP offerer MUST use the RTP/AVP profile <xref target="RFC3551"></xref> and include the "a=rtcp-fb" SDP attribute as described in <xref target="RFC4585"></xref>. 
</t>

<t>The SDP answerer indicates support for RTCP Based Feedback by including the "a=rtcp-fb" SDP attribute in the SDP Answer. The RTP profile in the SDP answer MAY be set to RTP/AVP (SAVP) or RTP/AVPF (SAVPF).
</t>

<t>This is an update to <xref target="RFC4585"></xref> which requires that the "a=rtcp-fb" attribute is only used with the RTP/AVPF profile. All other <xref target="RFC4585"></xref> procedures remain unchanged.
</t>
	

</section>


    <section anchor="IANA" title="IANA Considerations">

    <t>None</t>        


    </section>
    
    <section anchor="security" title="Security Considerations">
        
<t>The security considerations of <xref target="RFC7435"></xref> apply to any opportunistic approach to SRTP.</t>

<t>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 offer contains a secure profile of RTP, such as RTP/SAVP or RTP/SAVPF.  As discussed in <xref target="RFC7435"></xref> this is the "comprehensive protection" for media mode.</t>

</section>


    <section title="Acknowledgements">
        <t>This document is dedicated to our friend and colleague Francois Audet who is greatly missed in our community.  His work on improving security in SIP and RTP provided the foundation for this work.</t>
    </section>
    
</middle>

<!-- ********************************************************************************* -->

<back>
    <references title="Normative References">
        &RFC2119;
     </references>
    <references title="Informative References">
        &RFC3550;
        &RFC3551;
        &RFC4566;
        &RFC4568;
        &RFC4585;
        &RFC5124;
        &RFC7435;
        &RFC3711;
        &OSRTP;
    </references>
</back>
</rfc>
