idnits 2.17.1 draft-ietf-avt-profile-savpf-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 759. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 674 has weird spacing: '...hnology tel...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2007) is 6220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 4566 (ref. '6') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 3388 (ref. '9') (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 2326 (ref. '11') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '13') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. '14') (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Joerg Ott 3 Helsinki University of Technology 4 draft-ietf-avt-profile-savpf-09.txt Elisabetta Carrara 5 KTH 6 October 2006 7 Expires April 2007 9 Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 An RTP profile (SAVP) is defined for secure real-time 38 communications, and another profile (AVPF) is specified to provide 39 timely feedback from the receivers to a sender. This memo defines 40 the combination of both profiles to enable secure RTP 41 communications with feedback. 43 Table of Contents 45 1 Introduction..................................................2 46 1.1 Definitions..............................................3 47 1.2 Terminology..............................................4 48 2 SAVPF Rules...................................................4 49 2.1 Packet Formats...........................................5 50 2.2 Extensions...............................................5 51 2.3 Implications from combining AVPF and SAVP................5 52 3 SDP Definitions...............................................6 53 3.1 Profile Definition.......................................6 54 3.2 Attribute Definitions....................................6 55 3.3 Profile Negotiation......................................6 56 3.3.1 Offer/Answer-based Negotiation of Session Descriptions..6 57 3.3.2 RTSP-based Negotiation of Session Descriptions..........7 58 3.3.3 Announcing Session Descriptions.........................8 59 3.3.4 Describing Alternative Session Profiles.................9 60 3.4 Examples.................................................9 61 4 Interworking of AVP, SAVP, AVPF, and SAVPF Entities..........13 62 5 Security Considerations......................................13 63 6 IANA Considerations..........................................14 64 7 Acknowledgements.............................................15 65 8 Authors' Addresses...........................................15 66 9 Bibliography.................................................15 67 9.1 Normative references....................................15 68 9.2 Informative References..................................16 69 10 IPR Notice...................................................17 70 11 Disclaimer of Validity.......................................17 71 12 Full Copyright Statement.....................................17 72 13 Acknowledgment...............................................17 74 1 Introduction 76 The Real-time Transport Protocol (RTP/RTCP) [1] and the associated 77 profile for audiovisual communications with minimal control [2] 78 define mechanisms for transmitting time-based media across an IP 79 network. RTP provides means to preserve timing and detect packet 80 losses, among other things, and RTP payload formats provide for 81 proper framing of (continuous) media in a packet-based environment. 82 RTCP enables receivers to provide feedback on reception quality and 83 allows all members of an RTP session to learn about each other. 85 The RTP specification provides only rudimentary support for 86 encrypting RTP and RTCP packets. SRTP [4] defines an RTP profile 87 ("SAVP") for secure RTP media sessions, defining methods for proper 88 RTP and RTCP packet encryption, integrity and replay protection. 89 The initial negotiation of SRTP and its security parameters needs 90 to be done out of band, using e.g. the Session Description Protocol 91 (SDP) [6] together with extensions for conveying keying material 92 [7][8]. 94 The RTP specification also provides limited support for timely 95 feedback from receivers to senders, typically by means of reception 96 statistics reporting in somewhat regular intervals depending on the 97 group size, the average RTCP packet size, and the available RTCP 98 bandwidth. The extended RTP profile for RTCP-based feedback 99 ("AVPF") [3] allows session participants statistically to provide 100 immediate feedback while maintaining the average RTCP data rate for 101 all senders. As for SAVP, the use of AVPF and its parameters needs 102 to be negotiated out-of-band by means of SDP [6] and the extensions 103 defined in [3]. 105 Both SRTP and AVPF are RTP profiles and need to be negotiated. 106 This implies that either one or the other may be used, but both 107 profiles cannot be negotiated for the same RTP session (using one 108 SDP session level description). However, using secure 109 communications and timely feedback together is desirable. 110 Therefore, this document specifies a new RTP profile ("SAVPF") that 111 combines the features of SAVP and AVPF. 113 As SAVP and AVPF are largely orthogonal, the combination of both is 114 mostly straightforward. No sophisticated algorithms need to be 115 specified in this document. Instead, reference is made to both 116 existing profiles and only the implications of their combination 117 and possible deviations from rules of the existing profiles are 118 described as is the negotiation process. 120 1.1 Definitions 122 The definitions of [1], [2], [3], and [4] apply. 124 The following definitions are specifically used in this document: 126 RTP session: 127 An association among a set of participants communicating with 128 RTP as defined in [1]. 130 (SDP) media description: 131 This term refers to the specification given in a single m= 132 line in an SDP message. An SDP media description may define 133 only one RTP session. Grouping of m= lines in SDP may cause 134 several SDP session level descriptions to define (alternatives 135 of) the same RTP session for the same media type. 137 Media session: 138 A media session refers to a collection of SDP media 139 descriptions that are semantically grouped to represent 140 alternatives of the same communications means. Out of such a 141 group, one will be negotiated or chosen for a communication 142 relationship and the corresponding RTP session will be 143 instantiated. Or the media session will be rejected. 144 In the simplest case, a media session is equivalent to an SDP 145 media description and equivalent to an RTP session. 147 1.2 Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 150 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 151 in this document are to be interpreted as described in RFC 2119 152 [5]. 154 2 SAVPF Rules 156 SAVP is defined as an intermediate layer between RTP (following the 157 regular RTP profile AVP) and the transport layer (usually UDP). 158 This yields a two layer hierarchy within the Real-time Transport 159 Protocol. In SAVPF, the upper (AVP) layer is replaced by the 160 extended RTP profile for feedback (AVPF). 162 AVPF modifies timing rules for transmitting RTCP packets and adds 163 extra RTCP packet formats specific to feedback. These functions 164 are independent of whether or not RTCP packets are subsequently 165 encrypted and/or integrity protected. The functioning of the AVPF 166 layer remains unchanged in SAVPF. 168 The AVPF profile derives from [1] the (optional) use of the 169 encryption prefix for RTCP. The encryption prefix MUST NOT be used 170 within the SAVPF profile (it is not used in SAVP, as it is only 171 applicable to the encryption method specified in [1]). 173 The SAVP part uses extra fields added to the end of RTP and RTCP 174 packets and executes cryptographic transforms on (some of) the 175 RTP/RTCP packet contents. This behavior remains unchanged in 176 SAVPF. The average RTCP packet size calculation done by the AVPF 177 layer for timing purposes MUST take into account the fields added 178 by the SAVP layer. 180 The SRTP part becomes only active whenever the RTP or RTCP was 181 scheduled by the "higher" AVPF layer or received from the transport 182 protocol, irrespective of its timing and contents. 184 2.1 Packet Formats 186 AVPF defines extra packet formats to provide feedback information. 187 Those extra packet formats defined in [3] (and further ones defined 188 elsewhere for use with AVPF) MAY be used with SAVPF. 190 SAVP defines a modified packet format for SRTP and SRTCP packets 191 that essentially consists of the RTP/RTCP packet formats plus some 192 trailing protocol fields for security purposes. For SAVPF, all 193 RTCP packets MUST be encapsulated as defined in section 3.4 of [4]. 195 2.2 Extensions 197 Extensions to AVPF RTCP feedback packets defined elsewhere MAY be 198 used with the SAVPF profile provided that those extensions are in 199 conformance with the extension rules of [3]. 201 Additional extensions (e.g., transforms) defined for SAVP following 202 the rules of section 6 of [4] MAY also be used with the SAVPF 203 profile. The overhead per RTCP packet depends on the extensions 204 and transforms chosen. New extensions and transforms added in the 205 future MAY introduce yet unknown further per-packet overhead. 207 Finally, further extensions specifically to SAVPF MAY be defined 208 elsewhere. 210 2.3 Implications from combining AVPF and SAVP 212 The AVPF profile aims at -- statistically -- allowing receivers to 213 provide timely feedback to senders. The frequency at which 214 receivers are, on average, allowed to send feedback information 215 depends on the RTCP bandwidth, the group size, and the average size 216 of an RTCP packet. SRTCP (see Section 3.4 of [4]) adds extra 217 fields (some of which are of configurable length) at the end of 218 each RTCP packet that are probably at least some 10 to 20 bytes in 219 size (14 bytes as default). Note that extensions and transforms 220 defined in the future, as well as the configuration of each field 221 length, MAY add greater overhead. By using SRTP, the average size 222 of an RTCP packet will increase and thus reduce the frequency at 223 which (timely) feedback can be provided. Application designers 224 need to be aware of this, and take precautions so that the RTCP 225 bandwidth shares are maintained. This MUST be done by adjusting 226 the RTCP variable "avg_rtcp_size" to reflect the size of the SRTCP 227 packets. 229 3 SDP Definitions 231 3.1 Profile Definition 233 The AV profiles defined in [2], [3], and [4] are referred to as 234 "AVP", "AVPF", and "SAVP", respectively, in the context of e.g. the 235 Session Description Protocol (SDP) [3]. The combined profile 236 specified in this document is referred to as "SAVPF". 238 3.2 Attribute Definitions 240 SDP attributes for negotiating SAVP sessions are defined in [7] and 241 [8]. Those attributes MAY also be used with SAVPF. The rules 242 defined in [7] and [8] apply. 244 SDP attributes for negotiating AVPF sessions are defined in [3]. 245 Those attributes MAY also be used with SAVPF. The rules defined in 246 [3] apply. 248 3.3 Profile Negotiation 250 Session descriptions for RTP sessions may be conveyed using 251 protocols dedicated for multimedia communications such as the SDP 252 offer/answer model [10] used with SIP, RTSP [11], or SAP [12] but 253 may also be distributed using email, NetNews, web pages, etc. 255 The offer/answer model allows the resulting session parameters to 256 be negotiated using the SDP attributes defined in [7] and [8]. In 257 the following subsection, the negotiation process is described in 258 terms of the offer/answer model. 260 Afterwards, the cases that do not use the offer/answer model are 261 addressed: RTSP-specific negotiation support is provided by [7] as 262 discussed in subsection 3.3.2 and support for SAP announcements 263 (with no negotiation at all) is addressed in subsection 3.3.3. 265 3.3.1 Offer/Answer-based Negotiation of Session Descriptions 267 Negotiations (e.g. of RTP profiles, codecs, transport addresses, 268 etc.) are carried out on a per-media session basis (i.e. per m= 269 line in SDP). If negotiating one media session fails, others MAY 270 still succeed. 272 Different RTP profiles MAY be used in different media sessions. 273 For negotiation of a media description, the four profiles AVP, 274 AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that 275 SAVP and SAVPF entities MAY be mixed in a single RTP session (see 276 section 4). Also, the offer/answer mechanism MAY be used to offer 277 alternatives for the same media session (e.g. using the same 278 transport parameters) and allow the answered to choose one of the 279 profiles. 281 An offerer that is capable of supporting multiple of these profiles 282 for a certain media session SHOULD always offer all alternatives 283 acceptable in a certain situation. The alternatives SHOULD be 284 listed in order of preference and the offerer SHOULD prefer secure 285 profiles over non-secure ones. The offer SHOULD NOT include both a 286 secure alternative (SAVP and SAVPF) and an insecure alternative 287 (e.g. AVP and AVPF) in the same offer (as this may open up for 288 bidding down attacks) unless the signaling channel is protected 289 against modification of SDP messages. 291 If an offer contains multiple alternative profiles the answerer 292 MUST select exactly only one and reject the other(s), e.g., by 293 setting the port number in the respect m= line to 0. If supported, 294 the answerer SHOULD prefer a secure profile over non-secure ones. 295 Among the secure or insecure profiles, the answerer SHOULD select 296 the first acceptable alternative to respect the preference of the 297 offerer. 299 If a media description in an offer uses SAVPF and the answerer does 300 not support SAVPF, the media session MUST be rejected. 302 If a media description in an offer does not use SAVPF but the 303 answerer wants to use SAVPF, the answerer MUST reject the media 304 session. The answerer MAY provide a counter-offer with a media 305 description indicating SAVPF in a subsequently initiated 306 offer/answer exchange. 308 3.3.2 RTSP-based Negotiation of Session Descriptions 310 RTSP [11] does not support the offer/answer model. However, RTSP 311 supports exchanging media session parameters (including profile and 312 address information) by means of the "Transport:" header. SDP- 313 based key management as defined in [7] adds an RTSP header 314 (KeyMgmt:) to support conveying a key management protocol 315 (including keying material). 317 The RTSP "Transport:" header MAY be used to determine the profile 318 for the media session. Conceptually, the rules defined in section 319 3.3.1 apply accordingly. Detailed operation is as follows: 321 An SDP description (e.g., retrieved from the RTSP server by means 322 of DESCRIBE) contains the description of the media streams of the 323 particular RTSP resource. To offer two or more alternative RTP 324 profiles for a particular media stream, the SDP description MUST 325 contain exactly one m= line for this media stream for each profile 326 and all the same transport address (IP address and port number). 327 The profiles SHOULD be listed in the order of preference. This is 328 similar to formulating an offer per section 3.3.1. 330 The RTSP client MUST select exactly one of the profiles per media 331 stream it wants to receive. It MUST do so in the SETUP request. 332 The RTSP client MUST indicate the chosen RTP profile by indicating 333 the profile and the full server transport address (IP address and 334 port) in the Transport: header included in the SETUP request. The 335 RTSP server's response to the client's SETUP message MUST confirm 336 this profile selection or refuse the SETUP request (the latter of 337 which it should not do after offering the profiles in the first 338 place). 340 Note: To change any of the profiles in use, the client needs 341 tear down the RTSP session (using the TEARDOWN method) and re- 342 establish it using SETUP. This may change as soon as media 343 updating (similar to a SIP UPDATE or re-INVITE) becomes 344 specified. 346 When using the SDP key management [7], the keymgmt: header MUST be 347 included in the appropriate RTSP messages if a secure profile is 348 chosen. If different secure profiles are offered in the SDP 349 description (e.g., SAVP and SAVPF) and different keying material is 350 provided for these, after choosing one profile in the SETUP 351 message, only the keymgmt: header for the chosen one MUST be 352 provided. The rules for matching keymgmt: headers to media streams 353 according to [7] apply. 355 3.3.3 Announcing Session Descriptions 357 Protocols that do not allow negotiate session descriptions 358 interactively (e.g. SAP [12], descriptions posted on a web page or 359 sent by mail) pose the responsibility for adequate access to the 360 media sessions on the initiator of a session. 362 The initiator SHOULD provide alternative session descriptions for 363 multiple RTP profiles as far as acceptable to the application and 364 the purpose of the session. If security is desired, SAVP may be 365 offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD 366 NOT be announced unless other security means not relying on SRTP 367 are employed. 369 The SDP attributes defined in [7] and [8] may also be used for the 370 security parameter distribution of announced session descriptions. 372 The security scheme description defined in [8] requires a secure 373 communications channel to prevent third parties from eavesdropping 374 on the keying parameters and manipulation. Therefore, SAP security 375 (as defined in [12]), S/MIME [13], HTTPS [14], or other suitable 376 mechanisms SHOULD be used for distributing or accessing these 377 session descriptions. 379 3.3.4 Describing Alternative Session Profiles 381 SAVP and SAVPF entities MAY be mixed in the same RTP session (see 382 also section 4) and so MAY AVP and AVPF entities. Other 383 combinations -- i.e. between secure and insecure profiles -- in the 384 same RTP session are incompatible and MUST NOT be used together. 386 If negotiation between the involved peers is possible (as with the 387 offer/answer model per section 3.3.1 or RTSP per section 3.3.2), 388 alternative (secure and non-secure) profiles MAY be specified by 389 one entity (e.g., the offerer) and a choice of one profile MUST be 390 made by the other. If no such negotiation is possible (e.g., with 391 SAP as per section 3.3.3) incompatible profiles MUST NOT be 392 specified as alternatives. 394 If alternative RTP profiles are to be specified for a single RTP 395 session, each alternative needs to be included on a separate media 396 line in SDP. However, with only basic SDP, it is not possible to 397 communicate that the two m= lines are meant as alternatives (as 398 opposed to specifying different media sessions of the same type). 399 A mechanism to indicate semantic equivalence between the individual 400 sessions and ensure that any receiver only joins one of them, such 401 as the grouping framework [9], is being defined in the MMUSIC WG. 403 RTP profiles MAY be mixed arbitrarily across different RTP 404 sessions. 406 3.4 Examples 408 Example 1: The following session description indicates a secure 409 session made up from audio and DTMF for point-to-point 410 communication in which the DTMF stream uses Generic NACKs. The key 411 management protocol indicated is MIKEY. This session description 412 (the offer) could be contained in a SIP INVITE or 200 OK message to 413 indicate that its sender is capable of and willing to receive 414 feedback for the DTMF stream it transmits. The corresponding 415 answer may be carried in a 200 OK or an ACK. The parameters for 416 the security protocol are negotiated as described by the SDP 417 extensions defined in [7]. 419 v=0 420 o=alice 3203093520 3203093520 IN IP4 host.example.com 421 s=Media with feedback 422 t=0 0 423 c=IN IP4 host.example.com 424 m=audio 49170 RTP/SAVPF 0 96 425 a=rtpmap:0 PCMU/8000 426 a=rtpmap:96 telephone-event/8000 427 a=fmtp:96 0-16 428 a=rtcp-fb:96 nack 429 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 431 Example 2: This example shows the same feedback parameters as 432 example 1 but uses the secure descriptions syntax [8]. Note that 433 the key part of the a=crypto attribute is not protected against 434 eavesdropping and thus the session description needs to be 435 exchanged over a secure communication channel. 437 v=0 438 o=alice 3203093520 3203093520 IN IP4 host.example.com 439 s=Media with feedback 440 t=0 0 441 c=IN IP4 host.example.com 442 m=audio 49170 RTP/SAVPF 0 96 443 a=rtpmap:0 PCMU/8000 444 a=rtpmap:96 telephone-event/8000 445 a=fmtp:96 0-16 446 a=rtcp-fb:96 nack 447 a=crypto:AES_CM_128_HMAC_SHA1_32 448 inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1 449 :32 451 Example 3: This example is replicated from example 1 above but 452 shows the interaction between the offerer and the answered in an 453 offer/answer exchange, again using MIKEY to negotiate the keying 454 material: 456 Offer: 458 v=0 459 o=alice 3203093520 3203093520 IN IP4 host.example.com 460 s=Media with feedback 461 t=0 0 462 c=IN IP4 host.example.com 463 a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD... 464 m=audio 49170 RTP/SAVPF 0 96 465 a=rtpmap:0 PCMU/8000 466 a=rtpmap:96 telephone-event/8000 467 a=fmtp:96 0-16 468 a=rtcp-fb:96 nack 470 Answer: 472 v=0 473 o=alice 3203093521 3203093521 IN IP4 host.another.example.com 474 s=Media with feedback 475 t=0 0 476 c=IN IP4 host.another.example.com 477 a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD... 478 m=audio 53012 RTP/SAVPF 0 96 479 a=rtpmap:0 PCMU/8000 480 a=rtpmap:96 telephone-event/8000 481 a=fmtp:96 0-16 482 a=rtcp-fb:96 nack 484 Example 4: This example shows the exchange for video streaming 485 controlled via RTSP. A client inquires a media description from a 486 server using DESCRIBE and obtains a static SDP description without 487 any keying parameters but the media description shows that both 488 secure and non-secure media sessions using (S)AVPF are available. 489 Note that a future grouping mechanism will allow to explicitly 490 identify these as alternatives in the session description. The 491 client then issues a SETUP request and indicates its choice by 492 including the respective profile in the Transport parameter. 493 Furthermore, the client includes a KeyMgmt: header to convey its 494 security parameters which is matched by a corresponding KeyMgmt 495 header from the server in the response. Only a single media 496 session is chosen so that the aggregate RTSP URI is sufficient for 497 identification; if several media sessions shall use different 498 keying material, the a=control: attribute needs to be included in 499 the SDP description. 501 RTSP DESCRIBE request-response pair (optional): 503 DESCRIBE rtsp://movies.example.org/example RTSP/2.0 504 CSeq: 314 505 Accept: application/sdp 507 200 OK 508 CSeq: 314 509 Date: 25 Nov 2005 22:09:35 GMT 510 Content-Type: application/sdp 511 Content-Length: 316 513 v=0 514 o=alice 3203093520 3203093520 IN IP4 movies.example.com 515 s=Media with feedback 516 t=0 0 517 c=IN IP4 0.0.0.0 518 m=video 49170 RTP/SAVPF 96 519 a=rtpmap:96 H263-2000/90000 520 a=rtcp-fb:96 nack 521 m=video 49172 RTP/AVPF 96 522 a=rtpmap:96 H263-2000/90000 523 a=rtcp-fb:96 nack 525 RTSP SETUP request-response pair 527 SETUP rtsp://movies.example.org/example RTSP/2.0 528 CSeq: 315 529 Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013" 530 KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example"; 531 data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..." 533 200 OK 534 CSeq: 315 535 Date: 25 Nov 2005 22:09:36 GMT 536 Session: 4711 537 Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"; 538 src_addr="10.0.12.15:60000"/"10.0.12.15:60001" 539 KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example"; 540 data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..." 541 Accept-Ranges: NPT, SMPTE 543 Example 5: The following session description indicates a multicast 544 audio/video session (using PCMU for audio and either H.261 or 545 H.263+) with the video source accepting Generic NACKs for both 546 codecs and Reference Picture Selection for H.263. The parameters 547 for the security protocol are negotiated as described by the SDP 548 extensions defined in [7], used at the session level. Such a 549 description may have been conveyed using the Session Announcement 550 Protocol (SAP). 552 v=0 553 o=alice 3203093520 3203093520 IN IP4 host.example.com 554 s=Multicast video with feedback 555 t=3203130148 3203137348 556 a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD... 557 m=audio 49170 RTP/SAVP 0 558 c=IN IP4 224.2.1.183 559 a=rtpmap:0 PCMU/8000 560 m=video 51372 RTP/SAVPF 98 99 561 c=IN IP4 224.2.1.184 562 a=rtpmap:98 H263-1998/90000 563 a=rtpmap:99 H261/90000 564 a=rtcp-fb:* nack 565 a=rtcp-fb:98 nack rpsi 567 4 Interworking of AVP, SAVP, AVPF, and SAVPF Entities 569 The SAVPF profile defined in this document is a combination of the 570 SAVP profile [4] and the AVPF profile [3](which in turn is an 571 extension of the RTP profile as defined in [2]). 573 SAVP and SAVPF use SRTP [4] to achieve security. AVP and AVPF use 574 plain RTP [1] and hence do not provide security (unless external 575 security mechanisms are applied as discussed in section 9.1 of 576 [1]). SRTP and RTP are not meant to interoperate, the respective 577 protocol entities are not supposed to be part of the same RTP 578 session. Hence, AVP and AVPF on one side and SAVP and SAVPF on the 579 other MUST NOT be mixed. 581 RTP entities using the SAVP and the SAVPF profiles MAY be mixed in 582 a single RTP session. The interworking considerations defined in 583 section 5 of [3] apply. 585 5 Security Considerations 587 The SAVPF profile inherits its security properties from the SAVP 588 profile; therefore it is subject to the security considerations 589 discussed in [4]. The SAVP profile does not add, nor take away, 590 any security services compared to SAVP. 592 There is a desire to support security for media streams and, at the 593 same time, for backward compatibility with non-SAVP(F) nodes. 594 Application designers should be aware that security SHOULD NOT be 595 traded for interoperability. If information is to be distributed 596 to closed groups (i.e. confidentially protected), it is RECOMMENDED 597 not to offer alternatives for a media session other than SAVP and 598 SAVPF as described in sections 3.3 and 3.4, unless other security 599 mechanisms will be used, e.g. the ones described in Section 9.1 of 600 [1]. Similarly, if integrity protection is considered important, it 601 is RECOMMENDED not to offer the alternatives other than SAVP and 602 SAVPF, unless other mechanisms are known to be in place that can 603 guarantee it, e.g. lower-layer mechanisms as described in Section 9 604 of [1]. 606 Offering secure and insecure profiles simultaneously may open to 607 bidding down attacks. Therefore, such a mix of profile offer SHOULD 608 NOT be made. 610 Note that the rules for sharing master keys apply as described in 611 [4] (e.g., Section 9.1). In particular, the same rules for avoiding 612 the two-time pad (keystream reuse) apply: a master key MUST NOT be 613 shared among different RTP sessions if the SSRCs used are unique 614 across all the RTP streams of the RTP sessions that share the same 615 master key. 617 The key management MUST be called to provide new master key(s) 618 (previously stored and used keys MUST NOT be used again), or the 619 session MUST be terminated, when 2^48 SRTP packets or 2^31 SRTCP 620 packets have been secured with the same key (whichever occurs 621 before). 623 Different media sessions may use a mix of different profiles, 624 particularly including a secure profile and an insecure profile. 625 However, mixing secure and insecure media sessions may reveal 626 information to third parties and thus the decision to do so MUST be 627 in line with a local security policy. For example, the local 628 policy MUST specify whether it is acceptable to have e.g. the audio 629 stream not secured and the related video secured. 631 The security considerations in [3] are valid too. Note in 632 particular, applying the SAVPF profile implies mandatory integrity 633 protection on RTCP. While this solves the problem of false packets 634 from members not belonging to the group, it does not solve the 635 issues related to a malicious member acting improperly. 637 6 IANA Considerations 639 The following contact information shall be used for all 640 registrations included here: 642 Contact: Joerg Ott 643 mailto:jo@acm.org 644 tel:+358-9-451-2460 646 The secure RTP feedback profile as a combination of Secure RTP and 647 the feedback profile needs to be registered for the Session 648 Description Protocol (specifically the type "proto"): "RTP/SAVPF". 650 SDP Protocol ("proto"): 652 Name: RTP/SAVPF 653 Long form: Secure RTP Profile with RTCP-based Feedback 654 Type of name: proto 655 Type of attribute: Media level only 656 Purpose: RFC XXXX 657 Reference: RFC XXXX 659 All the SDP attribute defined for RTP/SAVP and RTP/AVPF are valid 660 for RTP/SAVPF, too. 662 NOTE TO THE RFC EDITOR: Please replace all occurrences of RFC XXXX by 663 the RFC number assigned to this document. 665 7 Acknowledgements 667 This document is a product of the Audio-Visual Transport (AVT) 668 Working Group of the IETF. The authors would like to thank Magnus 669 Westerlund and Colin Perkins for their comments. 671 8 Authors' Addresses 673 Joerg Ott {sip,mailto}:jo@netlab.hut.fi 674 Helsinki University of Technology tel:+358-9-451-2460 675 Otakaari 5A 676 FI-02150 Espoo 677 Finland 679 Elisabetta Carrara mailto: carrara@kth.se 680 Royal Institute of Technology 681 Stockholm 682 Sweden 684 9 Bibliography 686 9.1 Normative references 688 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP 689 - A Transport Protocol for Real-time Applications," RFC 3550 690 (STD0064), July 2003. 692 [2] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video 693 Conferences with Minimal Control," RFC 3551 (STD0065), March 694 2003. 696 [3] J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended 697 RTP Profile for RTCP-based Feedback (RTP/AVPF), July 2006. 699 [4] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 700 "The Secure Real-time Transport Protocol", RFC 3711, March 701 2004. 703 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 704 Levels," RFC 2119, March 1997. 706 [6] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session 707 Description Protocol", RFC 4566, July 2006. 709 [7] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman, 710 "Key Management Extensions for Session Description Protocol 711 (SDP) and Real Time Streaming Protocol (RTSP)," RFC 4567, July 712 2006. 714 [8] F. Andreassen, M. Baugher, and D. Wing, "Session Description 715 Protocol Security Descriptions for Media Streams," RFC 4568, 716 July 2006. 718 [9] G. Camarillo, J. Holler, G. Eriksson, H. Schulzrinne, 719 "Grouping of media lines in SDP," RFC 3388, December 2002. 721 [10] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 722 SDP," RFC 3264, June 2002. 724 [11] H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming 725 Protocol (RTSP)," RFC 2326, April 1998. 727 9.2 Informative References 729 [12] M. Handley, C. Perkins, and E. Whelan, "Session Announcement 730 Protocol," RFC 2974, October 2000. 732 [13] B. Ramsdell (ed.), " S/MIME Version 3 Message Specification," 733 RFC 2633, June 1999. 735 [14] E.Rescorla, "HTTP Over TLS," RFC 2818, May 2000. 737 10 IPR Notice 739 The IETF takes no position regarding the validity or scope of any 740 Intellectual Property Rights or other rights that might be claimed 741 to pertain to the implementation or use of the technology described 742 in this document or the extent to which any license under such 743 rights might or might not be available; nor does it represent that 744 it has made any independent effort to identify any such rights. 745 Information on the procedures with respect to rights in RFC 746 documents can be found in BCP 78 and BCP 79. 748 Copies of IPR disclosures made to the IETF Secretariat and any 749 assurances of licenses to be made available, or the result of an 750 attempt made to obtain a general license or permission for the use 751 of such proprietary rights by implementers or users of this 752 specification can be obtained from the IETF on-line IPR repository 753 at http://www.ietf.org/ipr. 755 The IETF invites any interested party to bring to its attention any 756 copyrights, patents or patent applications, or other proprietary 757 rights that may cover technology that may be required to implement 758 this standard. Please address the information to the IETF at ietf- 759 ipr@ietf.org. 761 11 Disclaimer of Validity 763 This document and the information contained herein are provided on 764 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 765 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 766 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 767 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 768 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 769 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 770 PARTICULAR PURPOSE. 772 12 Full Copyright Statement 774 Copyright (C) The Internet Society (2006). This document is 775 subject to the rights, licenses and restrictions contained in BCP 776 78, and except as set forth therein, the authors retain all their 777 rights. 779 13 Acknowledgment 781 Funding for the RFC Editor function is currently provided by the 782 Internet Society.