INTERNET-DRAFT                                              Joerg Ott
                                    Helsinki University of Technology
draft-ietf-avt-profile-savpf-10.txt                Elisabetta Carrara
                                                        February 2007
                                                  Expires August 2007

     Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)

   Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   An RTP profile (SAVP) is defined for secure real-time
   communications, and another profile (AVPF) is specified to provide
   timely feedback from the receivers to a sender.  This memo defines
   the combination of both profiles to enable secure RTP
   communications with feedback.

Ott, Carrara             Expires August 2007                  [Page 1]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   Table of Contents

   1  Introduction..................................................2
      1.1  Definitions..............................................3
      1.2  Terminology..............................................4
   2  SAVPF Rules...................................................4
      2.1  Packet Formats...........................................5
      2.2  Extensions...............................................5
      2.3  Implications from combining AVPF and SAVP................5
   3  SDP Definitions...............................................6
      3.1  Profile Definition.......................................6
      3.2  Attribute Definitions....................................6
      3.3  Profile Negotiation......................................6
       3.3.1 Offer/Answer-based Negotiation of Session Descriptions.6
       3.3.2 RTSP-based Negotiation of Session Descriptions.........7
       3.3.3 Announcing Session Descriptions........................8
       3.3.4 Describing Alternative Session Profiles................9
      3.4  Examples.................................................9
   4  Interworking of AVP, SAVP, AVPF, and SAVPF Entities..........13
   5  Security Considerations......................................13
   6  IANA Considerations......................................... 14
   7  Acknowledgements ........................................... 15
   8  Authors' Addresses.......................................... 15
   9  Bibliography................................................ 15
      9.1  Normative references................................... 15
      9.2  Informative References................................. 16
   10 IPR Notice.................................................. 17
   11 Disclaimer of Validity...................................... 17
   12 Full Copyright Statement ................................... 17
   13 Acknowledgment.............................................. 17

1  Introduction

   The Real-time Transport Protocol (RTP/RTCP) [1] and the associated
   profile for audiovisual communications with minimal control [2]
   define mechanisms for transmitting time-based media across an IP
   network.  RTP provides means to preserve timing and detect packet
   losses, among other things, and RTP payload formats provide for
   proper framing of (continuous) media in a packet-based environment.
   RTCP enables receivers to provide feedback on reception quality and
   allows all members of an RTP session to learn about each other.

Ott, Carrara             Expires August 2007                  [Page 2]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   The RTP specification provides only rudimentary support for
   encrypting RTP and RTCP packets.  SRTP [4] defines an RTP profile
   ("SAVP") for secure RTP media sessions, defining methods for proper
   RTP and RTCP packet encryption, integrity and replay protection.
   The initial negotiation of SRTP and its security parameters needs
   to be done out of band, using e.g. the Session Description Protocol
   (SDP) [6] together with extensions for conveying keying material

   The RTP specification also provides limited support for timely
   feedback from receivers to senders, typically by means of reception
   statistics reporting in somewhat regular intervals depending on the
   group size, the average RTCP packet size, and the available RTCP
   bandwidth.  The extended RTP profile for RTCP-based feedback
   ("AVPF") [3] allows session participants statistically to provide
   immediate feedback while maintaining the average RTCP data rate for
   all senders.  As for SAVP, the use of AVPF and its parameters needs
   to be negotiated out-of-band by means of SDP [6] and the extensions
   defined in [3].

   Both SRTP and AVPF are RTP profiles and need to be negotiated.
   This implies that either one or the other may be used, but both
   profiles cannot be negotiated for the same RTP session (using one
   SDP session level description).  However, using secure
   communications and timely feedback together is desirable.
   Therefore, this document specifies a new RTP profile ("SAVPF") that
   combines the features of SAVP and AVPF.

   As SAVP and AVPF are largely orthogonal, the combination of both is
   mostly straightforward.  No sophisticated algorithms need to be
   specified in this document.  Instead, reference is made to both
   existing profiles and only the implications of their combination
   and possible deviations from rules of the existing profiles are
   described as is the negotiation process.

   1.1  Definitions

   The definitions of [1], [2], [3], and [4] apply.

   The following definitions are specifically used in this document:

   RTP session:
        An association among a set of participants communicating with
        RTP as defined in [1].

   (SDP) media description:
        This term refers to the specification given in a single m=
        line in an SDP message.  An SDP media description may define
        only one RTP session.  Grouping of m= lines in SDP may cause

Ott, Carrara             Expires August 2007                  [Page 3]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

        several SDP session level descriptions to define (alternatives
        of) the same RTP session for the same media type.

   Media session:
        A media session refers to a collection of SDP media
        descriptions that are semantically grouped to represent
        alternatives of the same communications means.  Out of such a
        group, one will be negotiated or chosen for a communication
        relationship and the corresponding RTP session will be
        instantiated.  Or the media session will be rejected.
        In the simplest case, a media session is equivalent to an SDP
        media description and equivalent to an RTP session.

   1.2  Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    in this document are to be interpreted as described in RFC 2119

2  SAVPF Rules

   SAVP is defined as an intermediate layer between RTP (following the
   regular RTP profile AVP) and the transport layer (usually UDP).
   This yields a two layer hierarchy within the Real-time Transport
   Protocol.  In SAVPF, the upper (AVP) layer is replaced by the
   extended RTP profile for feedback (AVPF).

   AVPF modifies timing rules for transmitting RTCP packets and adds
   extra RTCP packet formats specific to feedback.  These functions
   are independent of whether or not RTCP packets are subsequently
   encrypted and/or integrity protected.  The functioning of the AVPF
   layer remains unchanged in SAVPF.

   The AVPF profile derives from [1] the (optional) use of the
   encryption prefix for RTCP. The encryption prefix MUST NOT be used
   within the SAVPF profile (it is not used in SAVP, as it is only
   applicable to the encryption method specified in [1]).

   The SAVP part uses extra fields added to the end of RTP and RTCP
   packets and executes cryptographic transforms on (some of) the
   RTP/RTCP packet contents.  This behavior remains unchanged in
   SAVPF.  The average RTCP packet size calculation done by the AVPF
   layer for timing purposes MUST take into account the fields added
   by the SAVP layer.

Ott, Carrara             Expires August 2007                  [Page 4]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   The SRTP part becomes only active whenever the RTP or RTCP was
   scheduled by the "higher" AVPF layer or received from the transport
   protocol, irrespective of its timing and contents.

   2.1  Packet Formats

   AVPF defines extra packet formats to provide feedback information.
   Those extra packet formats defined in [3] (and further ones defined
   elsewhere for use with AVPF) MAY be used with SAVPF.

   SAVP defines a modified packet format for SRTP and SRTCP packets
   that essentially consists of the RTP/RTCP packet formats plus some
   trailing protocol fields for security purposes.  For SAVPF, all
   RTCP packets MUST be encapsulated as defined in section 3.4 of [4].

   2.2  Extensions

   Extensions to AVPF RTCP feedback packets defined elsewhere MAY be
   used with the SAVPF profile provided that those extensions are in
   conformance with the extension rules of [3].

   Additional extensions (e.g., transforms) defined for SAVP following
   the rules of section 6 of [4] MAY also be used with the SAVPF
   profile.  The overhead per RTCP packet depends on the extensions
   and transforms chosen. New extensions and transforms added in the
   future MAY introduce yet unknown further per-packet overhead.

   Finally, further extensions specifically to SAVPF MAY be defined

   2.3  Implications from combining AVPF and SAVP

   The AVPF profile aims at -- statistically -- allowing receivers to
   provide timely feedback to senders.  The frequency at which
   receivers are, on average, allowed to send feedback information
   depends on the RTCP bandwidth, the group size, and the average size
   of an RTCP packet.  SRTCP (see Section 3.4 of [4]) adds extra
   fields (some of which are of configurable length) at the end of
   each RTCP packet that are probably at least some 10 to 20 bytes in
   size (14 bytes as default).  Note that extensions and transforms
   defined in the future, as well as the configuration of each field
   length, MAY add greater overhead.  By using SRTP, the average size
   of an RTCP packet will increase and thus reduce the frequency at
   which (timely) feedback can be provided.  Application designers
   need to be aware of this, and take precautions so that the RTCP
   bandwidth shares are maintained.  This MUST be done by adjusting

Ott, Carrara             Expires August 2007                  [Page 5]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   the RTCP variable "avg_rtcp_size" to reflect the size of the SRTCP

3  SDP Definitions

   3.1  Profile Definition

   The AV profiles defined in [2], [3], and [4] are referred to as
   "AVP", "AVPF", and "SAVP", respectively, in the context of e.g. the
   Session Description Protocol (SDP) [3].  The combined profile
   specified in this document is referred to as "SAVPF".

   3.2  Attribute Definitions

   SDP attributes for negotiating SAVP sessions are defined in [7] and
   [8].  Those attributes MAY also be used with SAVPF.  The rules
   defined in [7] and [8] apply.

   SDP attributes for negotiating AVPF sessions are defined in [3].
   Those attributes MAY also be used with SAVPF.  The rules defined in
   [3] apply.

   3.3  Profile Negotiation

   Session descriptions for RTP sessions may be conveyed using
   protocols dedicated for multimedia communications such as the SDP
   offer/answer model [9] used with SIP, RTSP [10], or SAP [11] but
   may also be distributed using email, NetNews, web pages, etc.

   The offer/answer model allows the resulting session parameters to
   be negotiated using the SDP attributes defined in [7] and [8].  In
   the following subsection, the negotiation process is described in
   terms of the offer/answer model.

   Afterwards, the cases that do not use the offer/answer model are
   addressed: RTSP-specific negotiation support is provided by [7] as
   discussed in subsection 3.3.2 and support for SAP announcements
   (with no negotiation at all) is addressed in subsection 3.3.3.

   3.3.1 Offer/Answer-based Negotiation of Session Descriptions

   Negotiations (e.g. of RTP profiles, codecs, transport addresses,
   etc.) are carried out on a per-media session basis (i.e. per m=
   line in SDP).  If negotiating one media session fails, others MAY
   still succeed.

Ott, Carrara             Expires August 2007                  [Page 6]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   Different RTP profiles MAY be used in different media sessions.
   For negotiation of a media description, the four profiles AVP,
   AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
   SAVP and SAVPF entities MAY be mixed in a single RTP session (see
   section 4).  Also, the offer/answer mechanism MAY be used to offer
   alternatives for the same media session (e.g. using the same
   transport parameters) and allow the answered to choose one of the

   An offerer that is capable of supporting multiple of these profiles
   for a certain media session SHOULD always offer all alternatives
   acceptable in a certain situation.  The alternatives SHOULD be
   listed in order of preference and the offerer SHOULD prefer secure
   profiles over non-secure ones.  The offer SHOULD NOT include both a
   secure alternative (SAVP and SAVPF) and an insecure alternative
   (e.g. AVP and AVPF) in the same offer as this may enable bidding
   down and other attacks.  Therefore, if both secure and non-secure
   RTP profiles shall be offered (e.g., for best-effort SRTP [14]),
   care SHOULD be taken to appropriately protect the negotiation

   If an offer contains multiple alternative profiles the answerer
   MUST select exactly only one and reject the other(s), e.g., by
   setting the port number in the respect m= line to 0.  If supported,
   the answerer SHOULD prefer a secure profile over non-secure ones.
   Among the secure or insecure profiles, the answerer SHOULD select
   the first acceptable alternative to respect the preference of the

   If a media description in an offer uses SAVPF and the answerer does
   not support SAVPF, the media session MUST be rejected.

   If a media description in an offer does not use SAVPF but the
   answerer wants to use SAVPF, the answerer MUST reject the media
   session.  The answerer MAY provide a counter-offer with a media
   description indicating SAVPF in a subsequently initiated
   offer/answer exchange.

   3.3.2 RTSP-based Negotiation of Session Descriptions

   RTSP [10] does not support the offer/answer model.  However, RTSP
   supports exchanging media session parameters (including profile and
   address information) by means of the "Transport:" header.  SDP-
   based key management as defined in [7] adds an RTSP header
   (KeyMgmt:) to support conveying a key management protocol
   (including keying material).

Ott, Carrara             Expires August 2007                  [Page 7]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   The RTSP "Transport:" header MAY be used to determine the profile
   for the media session.  Conceptually, the rules defined in section
   3.3.1 apply accordingly.  Detailed operation is as follows:
   An SDP description (e.g., retrieved from the RTSP server by means
   of DESCRIBE) contains the description of the media streams of the
   particular RTSP resource.  To offer two or more alternative RTP
   profiles for a particular media stream, the SDP description MUST
   contain exactly one m= line for this media stream for each profile
   and all the same transport address (IP address and port number).
   The profiles SHOULD be listed in the order of preference.  This is
   similar to formulating an offer per section 3.3.1.

   The RTSP client MUST select exactly one of the profiles per media
   stream it wants to receive.  It MUST do so in the SETUP request.
   The RTSP client MUST indicate the chosen RTP profile by indicating
   the profile and the full server transport address (IP address and
   port) in the Transport: header included in the SETUP request.  The
   RTSP server's response to the client's SETUP message MUST confirm
   this profile selection or refuse the SETUP request (the latter of
   which it should not do after offering the profiles in the first

        Note: To change any of the profiles in use, the client needs
        tear down the RTSP session (using the TEARDOWN method) and re-
        establish it using SETUP.  This may change as soon as media
        updating (similar to a SIP UPDATE or re-INVITE) becomes

   When using the SDP key management [7], the keymgmt: header MUST be
   included in the appropriate RTSP messages if a secure profile is
   chosen.  If different secure profiles are offered in the SDP
   description (e.g., SAVP and SAVPF) and different keying material is
   provided for these, after choosing one profile in the SETUP
   message, only the keymgmt: header for the chosen one MUST be
   provided.  The rules for matching keymgmt: headers to media streams
   according to [7] apply.

   3.3.3 Announcing Session Descriptions

   Protocols that do not allow negotiate session descriptions
   interactively (e.g. SAP [11], descriptions posted on a web page or
   sent by mail) pose the responsibility for adequate access to the
   media sessions on the initiator of a session.

   The initiator SHOULD provide alternative session descriptions for
   multiple RTP profiles as far as acceptable to the application and
   the purpose of the session.  If security is desired, SAVP may be
   offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD

Ott, Carrara             Expires August 2007                  [Page 8]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   NOT be announced unless other security means not relying on SRTP
   are employed.

   The SDP attributes defined in [7] and [8] may also be used for the
   security parameter distribution of announced session descriptions.

   The security scheme description defined in [8] requires a secure
   communications channel to prevent third parties from eavesdropping
   on the keying parameters and manipulation.  Therefore, SAP security
   (as defined in [11]), S/MIME [12], HTTPS [13], or other suitable
   mechanisms SHOULD be used for distributing or accessing these
   session descriptions.

   3.3.4 Describing Alternative Session Profiles

   SAVP and SAVPF entities MAY be mixed in the same RTP session (see
   also section 4) and so MAY AVP and AVPF entities.  Other
   combinations -- i.e. between secure and insecure profiles -- in the
   same RTP session are incompatible and MUST NOT be used together.

   If negotiation between the involved peers is possible (as with the
   offer/answer model per section 3.3.1 or RTSP per section 3.3.2),
   alternative (secure and non-secure) profiles MAY be specified by
   one entity (e.g., the offerer) and a choice of one profile MUST be
   made by the other.  If no such negotiation is possible (e.g., with
   SAP as per section 3.3.3) incompatible profiles MUST NOT be
   specified as alternatives.

   The negotiation of alternative profiles is for further study.

   RTP profiles MAY be mixed arbitrarily across different RTP

   3.4  Examples

   Example 1: The following session description indicates a secure
   session made up from audio and DTMF for point-to-point
   communication in which the DTMF stream uses Generic NACKs.  The key
   management protocol indicated is MIKEY.  This session description
   (the offer) could be contained in a SIP INVITE or 200 OK message to
   indicate that its sender is capable of and willing to receive
   feedback for the DTMF stream it transmits.  The corresponding
   answer may be carried in a 200 OK or an ACK.  The parameters for
   the security protocol are negotiated as described by the SDP
   extensions defined in [7].

Ott, Carrara             Expires August 2007                  [Page 9]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

      o=alice 3203093520 3203093520 IN IP4
      s=Media with feedback
      t=0 0
      c=IN IP4
      m=audio 49170 RTP/SAVPF 0 96
      a=rtpmap:0 PCMU/8000
      a=rtpmap:96 telephone-event/8000
      a=fmtp:96 0-16
      a=rtcp-fb:96 nack
      a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

   Example 2: This example shows the same feedback parameters as
   example 1 but uses the secure descriptions syntax [8].  Note that
   the key part of the a=crypto attribute is not protected against
   eavesdropping and thus the session description needs to be
   exchanged over a secure communication channel.

      o=alice 3203093520 3203093520 IN IP4
      s=Media with feedback
      t=0 0
      c=IN IP4
      m=audio 49170 RTP/SAVPF 0 96
      a=rtpmap:0 PCMU/8000
      a=rtpmap:96 telephone-event/8000
      a=fmtp:96 0-16
      a=rtcp-fb:96 nack

   Example 3: This example is replicated from example 1 above but
   shows the interaction between the offerer and the answered in an
   offer/answer exchange, again using MIKEY to negotiate the keying

Ott, Carrara             Expires August 2007                 [Page 10]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007


      o=alice 3203093520 3203093520 IN IP4
      s=Media with feedback
      t=0 0
      c=IN IP4
      a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
      m=audio 49170 RTP/SAVPF 0 96
      a=rtpmap:0 PCMU/8000
      a=rtpmap:96 telephone-event/8000
      a=fmtp:96 0-16
      a=rtcp-fb:96 nack


      o=alice 3203093521 3203093521 IN IP4
      s=Media with feedback
      t=0 0
      c=IN IP4
      a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
      m=audio 53012 RTP/SAVPF 0 96
      a=rtpmap:0 PCMU/8000
      a=rtpmap:96 telephone-event/8000
      a=fmtp:96 0-16
      a=rtcp-fb:96 nack

   Example 4: This example shows the exchange for video streaming
   controlled via RTSP.  A client inquires a media description from a
   server using DESCRIBE and obtains a static SDP description without
   any keying parameters but the media description shows that both
   secure and non-secure media sessions using (S)AVPF are available.
   Note that a future grouping mechanism will allow to explicitly
   identify these as alternatives in the session description.  The
   client then issues a SETUP request and indicates its choice by
   including the respective profile in the Transport parameter.
   Furthermore, the client includes a KeyMgmt: header to convey its
   security parameters which is matched by a corresponding KeyMgmt
   header from the server in the response.  Only a single media
   session is chosen so that the aggregate RTSP URI is sufficient for
   identification; if several media sessions shall use different
   keying material, the a=control: attribute needs to be included in
   the SDP description.

Ott, Carrara             Expires August 2007                 [Page 11]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

      RTSP DESCRIBE request-response pair (optional):

      DESCRIBE rtsp:// RTSP/2.0
      CSeq: 314
      Accept: application/sdp

      200 OK
      CSeq: 314
      Date: 25 Nov 2005 22:09:35 GMT
      Content-Type: application/sdp
      Content-Length: 316

      o=alice 3203093520 3203093520 IN IP4
      s=Media with feedback
      t=0 0
      c=IN IP4
      m=video 49170 RTP/SAVPF 96
      a=rtpmap:96 H263-2000/90000
      a=rtcp-fb:96 nack
      m=video 49172 RTP/AVPF 96
      a=rtpmap:96 H263-2000/90000
      a=rtcp-fb:96 nack

      RTSP SETUP request-response pair

      SETUP rtsp:// RTSP/2.0
      CSeq: 315
      Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
      KeyMgmt: prot=mikey;url="rtsp://";

      200 OK
      CSeq: 315
      Date: 25 Nov 2005 22:09:36 GMT
      Session: 4711
      Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
      KeyMgmt: prot=mikey;url="rtsp://";
      Accept-Ranges: NPT, SMPTE

   Example 5: The following session description indicates a multicast
   audio/video session (using PCMU for audio and either H.261 or
   H.263+) with the video source accepting Generic NACKs for both
   codecs and Reference Picture Selection for H.263.  The parameters
   for the security protocol are negotiated as described by the SDP
   extensions defined in [7], used at the session level. Such a

Ott, Carrara             Expires August 2007                 [Page 12]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   description may have been conveyed using the Session Announcement
   Protocol (SAP).

      o=alice 3203093520 3203093520 IN IP4
      s=Multicast video with feedback
      t=3203130148 3203137348
      a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
      m=audio 49170 RTP/SAVP 0
      c=IN IP4
      a=rtpmap:0 PCMU/8000
      m=video 51372 RTP/SAVPF 98 99
      c=IN IP4
      a=rtpmap:98 H263-1998/90000
      a=rtpmap:99 H261/90000
      a=rtcp-fb:* nack
      a=rtcp-fb:98 nack rpsi

4  Interworking of AVP, SAVP, AVPF, and SAVPF Entities

   The SAVPF profile defined in this document is a combination of the
   SAVP profile [4] and the AVPF profile [3](which in turn is an
   extension of the RTP profile as defined in [2]).

   SAVP and SAVPF use SRTP [4] to achieve security.  AVP and AVPF use
   plain RTP [1] and hence do not provide security (unless external
   security mechanisms are applied as discussed in section 9.1 of
   [1]).  SRTP and RTP are not meant to interoperate, the respective
   protocol entities are not supposed to be part of the same RTP
   session.  Hence, AVP and AVPF on one side and SAVP and SAVPF on the
   other MUST NOT be mixed.

   RTP entities using the SAVP and the SAVPF profiles MAY be mixed in
   a single RTP session.  The interworking considerations defined in
   section 5 of [3] apply.

5  Security Considerations

   The SAVPF profile inherits its security properties from the SAVP
   profile; therefore it is subject to the security considerations
   discussed in [4].  The SAVP profile does not add, nor take away,
   any security services compared to SAVP.

   There is a desire to support security for media streams and, at the
   same time, for backward compatibility with non-SAVP(F) nodes.
   Application designers should be aware that security SHOULD NOT be
   traded for interoperability.  If information is to be distributed
   to closed groups (i.e. confidentially protected), it is RECOMMENDED

Ott, Carrara             Expires August 2007                 [Page 13]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   not to offer alternatives for a media session other than SAVP and
   SAVPF as described in sections 3.3 and 3.4, unless other security
   mechanisms will be used, e.g. the ones described in Section 9.1 of
   [1]. Similarly, if integrity protection is considered important, it
   is RECOMMENDED not to offer the alternatives other than SAVP and
   SAVPF, unless other mechanisms are known to be in place that can
   guarantee it, e.g. lower-layer mechanisms as described in Section 9
   of [1].

   Offering secure and insecure profiles simultaneously may open to
   bidding down attacks. Therefore, such a mix of profile offer SHOULD
   NOT be made.

   Note that the rules for sharing master keys apply as described in
   [4] (e.g., Section 9.1). In particular, the same rules for avoiding
   the two-time pad (keystream reuse) apply: a master key MUST NOT be
   shared among different RTP sessions if the SSRCs used are unique
   across all the RTP streams of the RTP sessions that share the same
   master key.

   The key management MUST be called to provide new master key(s)
   (previously stored and used keys MUST NOT be used again), or the
   session MUST be terminated, when 2^48 SRTP packets or 2^31 SRTCP
   packets have been secured with the same key (whichever occurs

   Different media sessions may use a mix of different profiles,
   particularly including a secure profile and an insecure profile.
   However, mixing secure and insecure media sessions may reveal
   information to third parties and thus the decision to do so MUST be
   in line with a local security policy.  For example, the local
   policy MUST specify whether it is acceptable to have e.g. the audio
   stream not secured and the related video secured.

   The security considerations in [3] are valid too. Note in
   particular, applying the SAVPF profile implies mandatory integrity
   protection on RTCP.  While this solves the problem of false packets
   from members not belonging to the group, it does not solve the
   issues related to a malicious member acting improperly.

6  IANA Considerations

   The following contact information shall be used for all
   registrations included here:

     Contact:      Joerg Ott

Ott, Carrara             Expires August 2007                 [Page 14]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   The secure RTP feedback profile as a combination of Secure RTP and
   the feedback profile needs to be registered for the Session
   Description Protocol (specifically the type "proto"): "RTP/SAVPF".

   SDP Protocol ("proto"):

     Name:               RTP/SAVPF
     Long form:          Secure RTP Profile with RTCP-based Feedback
     Type of name:       proto
     Type of attribute:  Media level only
     Purpose:            RFC XXXX
     Reference:          RFC XXXX

   All the SDP attribute defined for RTP/SAVP and RTP/AVPF are valid
   for RTP/SAVPF, too.

NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document.

7  Acknowledgements

   This document is a product of the Audio-Visual Transport (AVT)
   Working Group of the IETF.  The authors would like to thank Magnus
   Westerlund and Colin Perkins for their comments.

8  Authors' Addresses

   Joerg Ott                  
   Helsinki University of Technology    tel:+358-9-451-2460
   Otakaari 5A
   FI-02150 Espoo

   Elisabetta Carrara                   mailto:
   Royal Institute of Technology

9  Bibliography

   9.1  Normative references

   [1]  H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP
        - A Transport Protocol for Real-time Applications," RFC 3550
        (STD0064), July 2003.

Ott, Carrara             Expires August 2007                 [Page 15]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

   [2]  H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video
        Conferences with Minimal Control," RFC 3551 (STD0065), March

   [3]  J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended
        RTP Profile for RTCP-based Feedback (RTP/AVPF), RFC 4585,
        July 2006.

   [4]  M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman,
        "The Secure Real-time Transport Protocol", RFC 3711, March

   [5]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels," RFC 2119, March 1997.

   [6]  M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

   [7]  J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
        "Key Management Extensions for Session Description Protocol
        (SDP) and Real Time Streaming Protocol (RTSP)," RFC 4567, July

   [8]  F. Andreassen, M. Baugher, and D. Wing, "Session Description
        Protocol Security Descriptions for Media Streams," RFC 4568,
        July 2006.

   [9]  J. Rosenberg and H. Schulzrinne, "An offer/answer model with
        SDP," RFC 3264, June 2002.

   [10] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)," RFC 2326, April 1998.

   9.2  Informative References

   [11] M. Handley, C. Perkins, and E. Whelan, "Session Announcement
        Protocol," RFC 2974, October 2000.

   [12] B. Ramsdell (ed.), "Secure/Multipurpose Internet Mail
        Extensions (S/MIME) Version 3.1 Message Specification," RFC
        3851, July 2004.

   [13] E. Rescorla, "HTTP Over TLS," RFC 2818, May 2000.

   [14] H. Kaplan and F. Audet, "Session Description Protocol (SDP)
        Offer/Answer Negotiation For Best-Effort Secure Real-Time
        Transport Protocol," draft-kaplan-mmusic-best-effort-srtp-01,
        Work in Progress, October 2006.

Ott, Carrara             Expires August 2007                 [Page 16]

Internet Draft   draft-ietf-avt-profile-savpf-10.txt     January 2007

10 IPR Notice

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

11 Disclaimer of Validity

   This document and the information contained herein are provided on

12 Full Copyright Statement

   Copyright (C) The IETF Trust (2007).  This document is subject to
   the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

13 Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Ott, Carrara             Expires August 2007                 [Page 17]