idnits 2.17.1 draft-jennings-sipping-multipart-02.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 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. ** 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 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 5, 2006) is 6599 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) == Unused Reference: '11' is defined on line 422, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '9') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '10') (Obsoleted by RFC 4566) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-06 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft D. Wing 4 Expires: September 6, 2006 Cisco Systems 5 March 5, 2006 7 Session Initiation Protocol (SIP) Offer/Answer with Multipart 8 Alternative 9 draft-jennings-sipping-multipart-02 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 months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 SIP needs a mechanism for general backwards compatibility for moving 43 from SDP to SDPng or moving from non end-to-end encrypted SDP to end- 44 to-end encrypted SDP. This document specifies how a SIP offer uses 45 multipart/alternative, and how an answer indicates which part was 46 selected. 48 Table of Contents 50 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Sending Offers . . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Receiving Offers and Sending Answers . . . . . . . . . . . 4 55 3.3. Receiving Answers . . . . . . . . . . . . . . . . . . . . 5 56 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Example SIP SRTP Call . . . . . . . . . . . . . . . . . . . . 6 58 6. Example SIP SDPng Call . . . . . . . . . . . . . . . . . . . . 9 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 64 10.2. Informational References . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 66 Intellectual Property and Copyright Statements . . . . . . . . . . 14 68 1. Introduction and Overview 70 SIP (RFC 3261 [5]) uses an offer/answer negotiation mechanism 71 described in [6]. This system carries offers in formats such as SDP 72 [10] and various signed and encrypted versions of SDP. However, the 73 current offer/answer scheme does not allow a backwards compatibility 74 mode in which a SIP User Agent can make both old and new types of 75 offers and allow the other User Agent to select the type of offer 76 that it supports. This specification extends SIP to allow for these 77 backwards compatible offer/answer schemes. 79 The mechanism for doing this is based on multipart alternative MIME 80 types[2]. The User Agent making the offer uses a multipart 81 alternative and includes a unique Content-ID for each of the body 82 parts. The User Agent receiving the offer selects one of the parts 83 in the offer and sends an answer based on that part. When the User 84 Agent sends the answer, it indicates the Content-ID of the selected 85 offer part. 87 The indication is done by using a new header field, Content- 88 Answering-CID, defined in this document. This new header is similar 89 to In-Reply-To (RFC822 [9]) but instead of indicating the Message-ID 90 that elicited the email reply, Content-Answering-CID indicates the 91 Content-ID of the body part that was interpreted and that generated 92 the SIP answer. 94 This approach can allow a single offer to contain both SDP and 95 SDPng[12][13]. It can also allow migration from offers that are not 96 S/MIME protected (as described in RFC 3261 [5]) to ones that are, and 97 allow SRTP [14] keying material to be passed in the S/MIME protected 98 SDP using a mechanism such as sdescriptions [14]. As with all 99 offers, the offerer's local policy and local capabilities would 100 determine if an offer would, in fact, contain multiple alternatives. 102 2. Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [3]. 108 3. Mechanisms 110 The mechanisms described below apply only to SIP Offer/Answer [6] 111 exchanges. As currently defined, SIP Offer/Answer exchanges have a 112 Content-Disposition of "session" (either implied or explicit -- see 113 section 20.11 of [5]) or "early-session" [8]. Unless specified 114 otherwise, other extensions to SIP Offer/Answer are allowed to 115 interwork with the mechanisms described below. 117 3.1. Sending Offers 119 A User Agent that can support multiple types of offers SHOULD 120 construct a multipart/alternative body with a body for each type it 121 supports. Each body MUST include a Content-ID header that MUST be 122 unique within this SIP dialog. It is RECOMMENDED that the Content-ID 123 be generated by a combination of a random string and the User Agent's 124 host name or IP address, in order to make them globally unique. 126 It is critical that multipart/alternative offers follow the semantics 127 of multipart/alternative, notably the following text from RFC2046 128 [2]: 130 "THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each 131 part of a "multipart/alternative" entity represents the same 132 data, but the mappings between the two are not necessarily 133 without information loss. For example, information is lost 134 when translating ODA to PostScript or plain text. It is 135 recommended that each part should have a different Content-ID 136 value in the case where the information content of the two 137 parts is not identical." 139 Because support for MIME multipart isn't mandated by SIP, User Agents 140 should expect to receive error responses that indicate multipart/ 141 alternative wasn't supported ("415 Unsupported Media Type"). In such 142 events, User Agents MAY retry the request using an offer that 143 consists of only an SDP body (that is, without the multipart/ 144 alternative described in this document). See also Section 7. 146 Note: SIP forking may cause a problem with the above. 148 Per section 2.9 of [4] the top-level Content-Disposition header 149 applies to all parts of a multipart. The body parts of a multipart/ 150 alternative MUST NOT have their own Content-Disposition, as this 151 severely complicates the selection of the appropriate part by the 152 receiver. 154 3.2. Receiving Offers and Sending Answers 156 If a User Agent receives multiple SDP offers in an multipart/ 157 alternative body, it MUST interpret these as it would a normal 158 multipart alternative, as defined in RFC 2046 [2], which describes 159 the User Agent starting from the last part, attempting to interpret 160 it, and working backwards to the next-to-last part, and so on, until 161 it can interpret a part. Interpreting a part requires being able to 162 successfully decrypt the part (if encrypted) and being able to 163 understand the Content-Type. 165 If the multipart/alternative body doesn't contain a Content- 166 Disposition header, a Content-Disposition of "handling=required" MUST 167 be assumed, as with other MIME types that lack a Content-Disposition 168 header (section 3.3 of [7]). If this header includes a "handling" 169 parameter, or if "handling=required" was assumed, the "handling" 170 parameter applies only to the part that the user agent chose to 171 interpret. Specifically, the "handling" parameter does not apply to 172 the parts that the user agent could not interpret or chose not to 173 interpret, but rather to the ability to "handle" the multipart/ 174 alternative part as a whole. 176 When the User Agent constructs the answer, it MUST include a Content- 177 Answering-CID header field as defined in Section 4 with the same 178 value as the Content-ID of the offer that was selected. If the 179 answer itself is a multipart MIME message[8], the Content-Answering- 180 CID header field MUST be in the same MIME part of the answer. To 181 reduce complexity, only one answer is allowed even if the offer 182 contained multiple alternatives; that is, the answer MUST NOT be a 183 multipart/alternative. If the answer is being rejected, the User 184 Agent SHOULD indicate its capabilities (section 21.4.26 of [5]). 186 3.3. Receiving Answers 188 When the User Agent receives an answer, it MUST look at the Content- 189 Answering-CID header field value to find which answer has been used. 190 If the answer is a multipart/alternative, the User Agent MUST reject 191 the answer as malformed. It then proceeds with normal offer/answer 192 processing. 194 When a UA offers a multipart session, and the user might reasonably 195 be expected to behave differently depending on the part that was 196 answered, the UA SHOULD inform the user of the part that was 197 answered. For example, a multipart/alternative offer might contain 198 one part with SDP for only audio, and another encrypted part with SDP 199 for audio and video. If the second part, containing the audio and 200 video stream, is answered, it is reasonable to illuminate an LED on 201 the video camera. 203 4. Syntax 204 This specification defines a new MIME header called "Content- 205 Answering-CID". This updates RFC 2045 [1] with: 207 answering-cid := "Content-Answering-CID" ":" msg-id 209 and adds "[answering-cid CRLF]" to the Identity headers in RFC 2045. 211 The Content-Answering-CID header is used in answers and has a msg-id 212 value that is the same as the Content-ID value of the offer to which 213 this answer is related 215 5. Example SIP SRTP Call 217 In this example, large parts of the message are omitted to highlight 218 what is relevant to this specification. The lines in the example 219 that are prefixed by $ represent encrypted blocks of data. 221 In this example, Alice calls Bob and offers both an RTP and an SRTP 222 session. The SDP for the SRTP session contains the SRTP keying 223 material, and the SDP is encrypted with S/MIME. It is assumed that 224 Alice has Bob's public key. 226 Alice sends an INVITE to Bob that offers two alternative SDP bodies: 227 the first part contains SDP for an RTP audio stream and the second 228 encrypted part contains SDP for an SRTP audio and SRTP video stream. 229 Per multipart/alternative semantics, the encrypted version is 230 preferred because it is the last part. Both parts contain unique 231 Content-ID headers. The top-most part indicates the disposition is 232 "session", which applies to all of the parts within that top-most 233 part. 235 The "$" indicates encrypted data. The a=crypto line is shown wrapped 236 because of document formatting restrictions; it is actually one long 237 line. 239 INVITE sip:bob@biloxi.example.com SIP/2.0 240 ... 241 Content-Type: multipart/alternative; boundary=yradnuob 242 Content-Disposition: session 244 --yradnuob 245 Content-ID: <83rqjqef3.218.1@10.1.1.1> 246 Content-Type: application/sdp 248 v=0 249 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 250 s=- 251 c=IN IP4 192.168.47.11 252 t=0 0 253 m=audio 51400 RTP/AVP 0 254 a=rtpmap:0 PCMU/8000 256 --yradnuob 257 Content-ID: <83rqjqef3.218.2@10.1.1.1> 258 Content-Type: application/pkcs7-mime 260 $ Content-Type: application/sdp 261 $ 262 $ v=0 263 $ o=alice 2890844526 2890844526 IN IP4 192.168.47.11 264 $ s=- 265 $ c=IN IP4 192.168.47.11 266 $ t=0 0 267 $ m=video 51372 RTP/SAVP 31 268 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 269 $ inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 270 $ m=audio 49170 RTP/SAVP 0 271 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 272 $ inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 274 --yradnuob-- 276 Assuming that Bob's User Agent supports encryption and had Alice's 277 public key, Bob would be able to decode and interpret Alice's second 278 alternative body part. Bob would use this body part to construct an 279 answer. Bob's answer includes the Content-Reply-to-CID header which 280 indicates which alternative body part was chosen. 282 200 OK 283 ... 284 Content-Answering-CID: <83rqjqef3.218.2@10.1.1.1> 285 Content-Type: application/pkcs7-mime 286 Content-Disposition: session 288 $ Content-Type: application/sdp 289 $ 290 $ v=0 291 $ o=bob 2890844526 2890844526 IN IP4 192.168.47.11 292 $ s=- 293 $ c=IN IP4 192.168.51.1 294 $ t=0 0 295 $ m=video 27350 RTP/SAVP 31 296 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 297 $ inline:xiNb96JefmqJ8JneiqjqXqizje334+jkeiq298fA|2^20|1:32 298 $ m=audio 27352 RTP/SAVP 0 299 $ a=crypto:1 AES_CM_128_HMAC_SHA1_80 300 $ inline:eu23cfnze++jejekqnQQjefiuwfj938ejefQQfec|2^20|1:32 302 6. Example SIP SDPng Call 304 This shows an offer containing SDP and SDPng: 306 INVITE sip:bob@biloxi.example.com SIP/2.0 307 ... 308 Content-Type: multipart/alternative; boundary=yradnuob 309 Content-Disposition: session 311 --yradnuob 312 Content-ID: <98efj3.1@10.1.1.1> 313 Content-Type: application/sdp 315 v=0 316 o=alice 2890844526 2890844526 IN IP4 192.168.47.11 317 s=- 318 c=IN IP4 192.168.47.11 319 t=0 0 320 m=audio 51400 RTP/AVP 0 33 321 a=rtpmap:0 PCMU/8000 322 a=rtpmap:3 GSM/8000 324 --yradnuob 325 Content-ID: <98efj3.2@10.1.1.1> 326 Content-Type: application/sdpng 328 329 333 --yradnuob-- 335 Here is the answer which indicates via the Content-Answering-CID that 336 the SDP body part was interpreted. 338 200 OK 339 ... 340 Content-Answering-CID: <98efj3.1@10.1.1.1> 341 Content-Type: application/sdp 342 Content-Disposition: session 344 v=0 345 o=bob 990821536 1230844577 IN IP4 bob.example.com 346 s=- 347 c=IN IP4 192.168.1.2 348 t=0 0 349 m=audio 55111 RTP/AVP 0 33 350 a=rtpmap:0 PCMU/8000 351 a=rtpmap:3 GSM/8000 353 7. Security Considerations 355 In SIP, there is a risk of an active bid-down attack. The active 356 attacker can modify an SRTP offer, or SRTP answer, in order to make 357 the offerer believe the answerer cannot understand SRTP. Such an 358 attack is possible with or without multipart/alternative offers 359 described in this paper. In such an attack without a multipart/ 360 alternative offer, the offerer might send a new RTP offer. In such 361 an attack with a multipart/alternative offer (containing both an RTP 362 offer and an encrypted offer), an attacker might guess the encrypted 363 offer is an SRTP offer and might reasonably assume the offerer's 364 policy allows an RTP session. To protect against such an attack, the 365 offer can be protected (e.g., using the SIPS URI or using 366 Identity[15]), and the answer can be similarly protected. The 367 addition of multipart/alternative doesn't change this risk, or the 368 requirement to appropriately protect such offers and answers, rather 369 it only provides a hint about the offerer's policy which might allow 370 an RTP session to be established. See also Section 3.3 for user 371 interface guidance. 373 8. IANA Considerations 375 The MIME Content-Answering-CID header does not require any IANA 376 actions. 378 9. Acknowledgments 379 Thanks for comments from Flemming Andreasen, Paul Kyzivat, and Mark 380 Baugher. 382 10. References 384 10.1. Normative References 386 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 387 Extensions (MIME) Part One: Format of Internet Message Bodies", 388 RFC 2045, November 1996. 390 [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 391 Extensions (MIME) Part Two: Media Types", RFC 2046, 392 November 1996. 394 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 395 Levels", BCP 14, RFC 2119, March 1997. 397 [4] Troost, R., Dorner, S., and K. Moore, "Communicating 398 Presentation Information in Internet Messages: The Content- 399 Disposition Header Field", RFC 2183, August 1997. 401 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 402 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 403 Session Initiation Protocol", RFC 3261, June 2002. 405 [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 406 Session Description Protocol (SDP)", RFC 3264, June 2002. 408 [7] Burger, E., "Critical Content Multi-purpose Internet Mail 409 Extensions (MIME) Parameter", RFC 3459, January 2003. 411 [8] Camarillo, G., "The Early Session Disposition Type for the 412 Session Initiation Protocol (SIP)", RFC 3959, December 2004. 414 10.2. Informational References 416 [9] Crocker, D., "Standard for the format of ARPA Internet text 417 messages", STD 11, RFC 822, August 1982. 419 [10] Handley, M. and V. Jacobson, "SDP: Session Description 420 Protocol", RFC 2327, April 1998. 422 [11] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 423 Methodology for Network Address Translator (NAT) Traversal for 424 Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in 425 progress), October 2005. 427 [12] Kutscher, D., Ott, J., and C. Bormann, "Session Description and 428 Capability Negotiation", draft-ietf-mmusic-sdpng-08 (work in 429 progress), February 2005. 431 [13] Ott, J. and C. Perkins, "SDPng Transition", 432 draft-ietf-mmusic-sdpng-trans-04 (work in progress), May 2003. 434 [14] Andreasen, F., "Session Description Protocol Security 435 Descriptions for Media Streams", 436 draft-ietf-mmusic-sdescriptions-12 (work in progress), 437 September 2005. 439 [15] Peterson, J. and C. Jennings, "Enhancements for Authenticated 440 Identity Management in the Session Initiation Protocol (SIP)", 441 draft-ietf-sip-identity-06 (work in progress), October 2005. 443 Authors' Addresses 445 Cullen Jennings 446 Cisco Systems 447 170 West Tasman Drive 448 MS: SJC-21/2 449 San Jose, CA 95134 450 USA 452 Phone: +1 408 902-3341 453 Email: fluffy@cisco.com 455 Dan Wing 456 Cisco Systems 457 170 West Tasman Drive 458 MS: SJC-21/2 459 San Jose, CA 95134 460 USA 462 Email: dwing@cisco.com 464 Intellectual Property Statement 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Disclaimer of Validity 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 493 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 494 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 495 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Copyright Statement 500 Copyright (C) The Internet Society (2006). This document is subject 501 to the rights, licenses and restrictions contained in BCP 78, and 502 except as set forth therein, the authors retain all their rights. 504 Acknowledgment 506 Funding for the RFC Editor function is currently provided by the 507 Internet Society.