summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5124.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5124.txt')
-rw-r--r--doc/rfc/rfc5124.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc5124.txt b/doc/rfc/rfc5124.txt
new file mode 100644
index 0000000..4b04d0d
--- /dev/null
+++ b/doc/rfc/rfc5124.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group J. Ott
+Request for Comments: 5124 Helsinki University of Technology
+Category: Standards Track E. Carrara
+ KTH
+ February 2008
+
+
+ Extended Secure RTP Profile for
+ Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ An RTP profile (SAVP) for secure real-time communications and another
+ profile (AVPF) to provide timely feedback from the receivers to a
+ sender are defined in RFC 3711 and RFC 4585, respectively. This memo
+ specifies the combination of both profiles to enable secure RTP
+ communications with feedback.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 1]
+
+RFC 5124 February 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Definitions ................................................4
+ 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 ..................6
+ 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 ........................................7
+ 3.3.2. RTSP-Based Negotiation of Session Descriptions ......8
+ 3.3.3. Announcing Session Descriptions .....................9
+ 3.3.4. Describing Alternative Session Profiles .............9
+ 3.4. Examples ..................................................10
+ 4. Interworking of AVP, SAVP, AVPF, and SAVPF Entities ............13
+ 5. Security Considerations ........................................14
+ 6. IANA Considerations ............................................15
+ 7. Acknowledgements ...............................................15
+ 8. References .....................................................15
+ 8.1. Normative References ......................................15
+ 8.2. Informative References ....................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 2]
+
+RFC 5124 February 2008
+
+
+1. Introduction
+
+ The Real-time Transport Protocol, the associated RTP Control Protocol
+ (RTP/RTCP, RFC 3550) [1], and the profile for audiovisual
+ communications with minimal control (RFC 3551) [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.
+
+ The RTP specification provides only rudimentary support for
+ encrypting RTP and RTCP packets. Secure RTP (RFC 3711) [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, e.g., using the Session
+ Description Protocol (SDP, RFC 4566) [6] together with extensions for
+ conveying keying material (RFC 4567 [7], RFC 4568 [8]).
+
+ 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")
+ (RFC 4585, [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 (RFC 4566, [6]) and the
+ extensions defined in RFC 4585 [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.
+
+
+
+
+
+Ott & Carrara Standards Track [Page 3]
+
+RFC 5124 February 2008
+
+
+1.1. Definitions
+
+ The definitions of RFC 3550 [1], RFC 3551 [2], RFC 4585 [3], and RFC
+ 3711 [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 RFC 3550 [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.
+
+ 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. If no common
+ session parameters suitable for the involved endpoints can be
+ found, 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 NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [5].
+
+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.
+
+
+
+
+
+Ott & Carrara Standards Track [Page 4]
+
+RFC 5124 February 2008
+
+
+ The AVPF profile derives from RFC 3550 [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.
+
+ The SRTP part becomes active only when 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 RFC 4585 [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 RFC 3711
+ [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 RFC 4585 [3].
+
+ Additional extensions (e.g., transforms) defined for SAVP following
+ the rules of Section 6 of RFC 3711 [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
+ elsewhere.
+
+
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 5]
+
+RFC 5124 February 2008
+
+
+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 RFC 3711 [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 the RTCP variable
+ "avg_rtcp_size" to reflect the size of the SRTCP packets.
+
+3. SDP Definitions
+
+3.1. Profile Definition
+
+ The AV profiles defined in RFC 3551 [2], RFC 4585 [3], and RFC 3711
+ [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 RFC 4567
+ [7] and RFC 4568 [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 RFC 4585
+ [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 (RFC 3264, [9]) used with the Session Initiation Protocol (SIP)
+ [15], the Real Time Streaming Protocol (RTSP) [10], or the Session
+ Announcement Protocol (SAP) [11], but may also be distributed using
+ email, NetNews, web pages, etc.
+
+
+
+
+
+Ott & Carrara Standards Track [Page 6]
+
+RFC 5124 February 2008
+
+
+ The offer/answer model allows the resulting session parameters to be
+ negotiated using the SDP attributes defined in RFC 4567 [7] and RFC
+ 4568 [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 RFC 4567
+ [7] as discussed in Section 3.3.2, and support for SAP announcements
+ (with no negotiation at all) is addressed in Section 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 (e.g., per m= line
+ in SDP). If negotiating one media session fails, others MAY still
+ succeed.
+
+ 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 and allow the answerer to choose one of
+ the profiles.
+
+ Provided that a mechanism for offering alternative security profiles
+ becomes available (as is presently under development [14]), an
+ offerer that is capable of supporting more than one 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 are
+ offered (e.g., for best-effort SRTP [14]), the negotiation signaling
+ MUST be protected appropriately to avoid such attacks.
+
+ If an offer contains multiple alternative profiles, the answerer
+ SHOULD prefer a secure profile (if supported) over non-secure ones.
+ Among the secure or insecure profiles, the answerer SHOULD select the
+ first acceptable alternative to respect the preference of the
+ offerer.
+
+ If a media description in an offer uses SAVPF and the answerer does
+ not support SAVPF, the media session MUST be rejected.
+
+
+
+
+
+Ott & Carrara Standards Track [Page 7]
+
+RFC 5124 February 2008
+
+
+ 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 RFC 4567 [7] adds an RTSP header (KeyMgmt)
+ to support conveying a key management protocol (including keying
+ material).
+
+ 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.
+
+ 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
+ number) 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
+ place).
+
+ Note: To change any of the profiles in use, the client needs to
+ tear down this media stream (and possibly the whole 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 specified.
+
+ 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 RFC
+ 4567 [7] apply.
+
+
+
+
+
+Ott & Carrara Standards Track [Page 8]
+
+RFC 5124 February 2008
+
+
+3.3.3. Announcing Session Descriptions
+
+ Protocols that do not allow negotiating 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 NOT be
+ announced unless other security means not relying on SRTP are
+ employed.
+
+ The SDP attributes defined in RFC 4567 [7] and RFC 4568 [8] may also
+ be used for the security parameter distribution of announced session
+ descriptions.
+
+ The security scheme description defined in RFC 4568 [8] requires a
+ secure communications channel to prevent third parties from
+ eavesdropping on the keying parameters and manipulation. Therefore,
+ SAP security (as defined in RFC 2974 [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 sessions.
+
+
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 9]
+
+RFC 5124 February 2008
+
+
+3.4. Examples
+
+ This section includes examples for the use of SDP to negotiate the
+ use of secure and non-secure profiles. Depending on what keying
+ mechanism is being used and how it parameterized, the SDP messages
+ typically require integrity protection and, for some mechanisms, will
+ also need confidentiality protection. For example, one could say
+ integrity protection is required for the a=fingerprint of Datagram
+ Transport Layer Security - Secure Real-time Transport Protocol
+ (DTLS-SRTP) [16], and confidentiality is required for RFC 4568 [8]
+ (Security Descriptions) a=crypto.
+
+ Example 1: The following session description indicates a secure
+ session made up from audio and dual tone multi-frequency (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 RFC 4567 [7].
+
+ v=0
+ o=alice 3203093520 3203093520 IN IP4 host.example.com
+ s=Media with feedback
+ t=0 0
+ c=IN IP4 host.example.com
+ 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.
+
+ v=0
+ o=alice 3203093520 3203093520 IN IP4 host.example.com
+ s=Media with feedback
+ t=0 0
+ c=IN IP4 host.example.com
+ m=audio 49170 RTP/SAVPF 0 96
+ a=rtpmap:0 PCMU/8000
+
+
+
+Ott & Carrara Standards Track [Page 10]
+
+RFC 5124 February 2008
+
+
+ a=rtpmap:96 telephone-event/8000
+ a=fmtp:96 0-16
+ a=rtcp-fb:96 nack
+ a=crypto:AES_CM_128_HMAC_SHA1_32
+ inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
+ :32
+
+ Example 3: This example is replicated from example 1 above, but shows
+ the interaction between the offerer and the answerer in an
+ offer/answer exchange, again using MIKEY to negotiate the keying
+ material:
+
+ Offer:
+
+ v=0
+ o=alice 3203093520 3203093520 IN IP4 host.example.com
+ s=Media with feedback
+ t=0 0
+ c=IN IP4 host.example.com
+ 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
+
+ Answer:
+
+ v=0
+ o=alice 3203093521 3203093521 IN IP4 host.another.example.com
+ s=Media with feedback
+ t=0 0
+ c=IN IP4 host.another.example.com
+ 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 acquires 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. A
+ mechanism that allows explicit identification of these alternatives
+ (i.e., secure and non-secure sessions) in the session description is
+ presently being defined [14]. The client then issues a SETUP request
+
+
+
+Ott & Carrara Standards Track [Page 11]
+
+RFC 5124 February 2008
+
+
+ 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.
+
+ RTSP DESCRIBE request-response pair (optional):
+
+ DESCRIBE rtsp://movies.example.org/example 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
+
+ v=0
+ o=alice 3203093520 3203093520 IN IP4 movies.example.com
+ s=Media with feedback
+ t=0 0
+ c=IN IP4 0.0.0.0
+ +-Alternative one-----------------+
+ |m=video 49170 RTP/SAVPF 96 |
+ |a=rtpmap:96 H263-2000/90000 |
+ |a=rtcp-fb:96 nack |
+ +---------------------------------+
+ +-Alternative two-----------------+
+ |m=video 49172 RTP/AVPF 96 |
+ |a=rtpmap:96 H263-2000/90000 |
+ |a=rtcp-fb:96 nack |
+ +---------------------------------+
+
+ RTSP SETUP request-response pair
+
+ SETUP rtsp://movies.example.org/example RTSP/2.0
+ CSeq: 315
+ Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
+ KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
+ data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."
+
+ 200 OK
+ CSeq: 315
+ Date: 25 Nov 2005 22:09:36 GMT
+ Session: 4711
+
+
+
+
+Ott & Carrara Standards Track [Page 12]
+
+RFC 5124 February 2008
+
+
+ Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
+ src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
+ KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
+ data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
+ 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 RFC 4567 [7], used at the session level. Such a
+ description may have been conveyed using the Session Announcement
+ Protocol (SAP).
+
+ v=0
+ o=alice 3203093520 3203093520 IN IP4 host.example.com
+ s=Multicast video with feedback
+ t=3203130148 3203137348
+ a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
+ m=audio 49170 RTP/SAVP 0
+ c=IN IP4 224.2.1.183
+ a=rtpmap:0 PCMU/8000
+ m=video 51372 RTP/SAVPF 98 99
+ c=IN IP4 224.2.1.184
+ 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 RFC 3551 [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 RFC
+ 3550 [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 RFC 4585 [3] apply.
+
+
+
+
+Ott & Carrara Standards Track [Page 13]
+
+RFC 5124 February 2008
+
+
+5. Security Considerations
+
+ The SAVPF profile inherits its security properties from the SAVP
+ profile; therefore, it is subject to the security considerations
+ discussed in RFC 3711 [4]. When compared to SAVP, the SAVPF profile
+ does not add or take away any security services.
+
+ 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 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
+ RFC 3550 [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 RFC 3550 [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 RFC
+ 3711 [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 unless the SSRCs used are
+ unique across all the RTP streams of the RTP sessions that share the
+ same master key.
+
+ When 2^48 SRTP packets or 2^31 SRTCP packets have been secured with
+ the same key (whichever occurs before), 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.
+
+ 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.
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 14]
+
+RFC 5124 February 2008
+
+
+ The security considerations in RFC 4585 [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
+ mail: jo@acm.org
+ tel: +358-9-451-2460
+
+ The secure RTP feedback profile, as a combination of Secure RTP and
+ the feedback profile, has been 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 5124
+ Reference: RFC 5124
+
+ All the SDP attributes defined for RTP/SAVP and RTP/AVPF are valid
+ for RTP/SAVPF, too.
+
+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, Colin Perkins, and Cullen Jennings for their comments.
+
+8. References
+
+8.1. Normative References
+
+ [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+ RFC 3550, July 2003.
+
+ [2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
+
+
+
+
+Ott & Carrara Standards Track [Page 15]
+
+RFC 5124 February 2008
+
+
+ [3] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
+ "Extended RTP Profile for Real-time Transport Control Protocol
+ (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
+
+ [4] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+ 3711, March 2004.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [7] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
+ Carrara, "Key Management Extensions for Session Description
+ Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC
+ 4567, July 2006.
+
+ [8] Andreasen, F., Baugher, M., and D. Wing, "Session Description
+ Protocol (SDP) Security Descriptions for Media Streams", RFC
+ 4568, July 2006.
+
+ [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [10] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
+ Protocol (RTSP)", RFC 2326, April 1998.
+
+8.2. Informative References
+
+ [11] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
+ Protocol", RFC 2974, October 2000.
+
+ [12] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions
+ (S/MIME) Version 3.1 Message Specification", RFC 3851, July
+ 2004.
+
+ [13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [14] Andreasen, F., "SDP Capability Negotiation", Work in Progress,
+ December 2007.
+
+ [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+
+
+
+
+Ott & Carrara Standards Track [Page 16]
+
+RFC 5124 February 2008
+
+
+ [16] McGrew, D. and Rescorla, E., "Datagram Transport Layer Security
+ (DTLS) Extension to Establish Keys for Secure Real-time
+ Transport Protocol (SRTP)", Work in Progress, November 2007.
+
+Authors' Addresses
+
+ Joerg Ott
+ Helsinki University of Technology
+ Otakaari 5A
+ FI-02150 Espoo
+ Finland
+
+ EMail: jo@comnet.tkk.fi
+ Phone: +358-9-451-2460
+
+
+ Elisabetta Carrara
+ Royal Institute of Technology
+ Stockholm
+ Sweden
+
+ EMail: carrara@kth.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 17]
+
+RFC 5124 February 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ 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 at
+ http://www.ietf.org/ipr.
+
+ 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-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Ott & Carrara Standards Track [Page 18]
+