idnits 2.17.1 draft-ietf-mmusic-sdp4nat-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 22 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2234], [RFC2327], [RFC3369], [RFC2119], [RFC2766], [RFC3261], [Bradner,1996], [UNSAF], [RFC1889], [STUN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 20, 2002) is 7888 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) -- Missing reference section? 'RFC3261' on line 350 looks like a reference -- Missing reference section? 'RFC2766' on line 364 looks like a reference -- Missing reference section? 'RFC2327' on line 354 looks like a reference -- Missing reference section? 'RFC1889' on line 360 looks like a reference -- Missing reference section? 'RFC2119' on line 367 looks like a reference -- Missing reference section? 'STUN' on line 158 looks like a reference -- Missing reference section? 'UNSAF' on line 373 looks like a reference -- Missing reference section? 'RFC3369' on line 357 looks like a reference -- Missing reference section? 'Bradner' on line 318 looks like a reference -- Missing reference section? '1996' on line 318 looks like a reference -- Missing reference section? 'RFC2234' on line 370 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires March 20, 2002 September 20, 2002 5 RTCP attribute in SDP 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The session description protocol (SDP) is used to describe the 31 parameters of media streams used in multimedia sessions. When a 32 session requires multiple ports, SDP assumes that these port have 33 consecutive numbers. However, when the session crosses a network 34 address translation device that also uses port mapping, the ordering 35 of ports can be destroyed by the translation. To handle this, we 36 propose an extension attribute to SDP. 38 1 Introduction 40 The session invitation protocol (SIP, [RFC3261]) is often used to 41 establish multi-media sessions on the Internet. There are often 42 cases today in which one or both end of the connection are hidden 43 behind a network address translation device [RFC2766]. In this case, 44 the SDP text must document the IP addresses and UDP ports as they 45 appear on the "public Internet" side of the NAT; in this memo, we 46 will suppose that the host located behind a NAT has a way to obtain 47 these numbers; a possible way to learn these numbers is briefly 48 outlined in section 3. However, just learning the numbers is not 49 enough. 51 The SIP messages use the encoding defined in SDP [RFC2327] to 52 describe the IP addresses and TCP or UDP ports used my the various 53 media. Audio and video are typically sent using RTP [RFC1889], which 54 requires two UDP ports, one for the media and one for the control 55 protocol (RTCP). SDP carries only one port number per media, and 56 states that "other ports used by the media application (such as the 57 RTCP port) should be derived algorithmically from the base media 58 port." When the media is transmitted using RTP [RFC1889], the choice 59 of the port number is very specific: "for UDP and similar protocols, 60 RTP uses an even port number and the corresponding RTCP stream uses 61 the next higher (odd) port number; if an application is supplied 62 with an odd number for use as the RTP port, it should replace this 63 number with the next lower (even) number." 65 When the NAT device performs port mapping, there is no guarantee 66 that the mappings of two separate ports reflects the sequencing and 67 the parity of the original port numbers; in fact, when the NAT 68 manages a pool of IP addresses, it is even possible that the RTP and 69 the RTCP ports may be mapped to different addresses. In order to 70 successfully establish connections despite the misordering of the 71 port numbers and the possible parity switches caused by the NAT, we 72 propose to use a specific SDP attribute to document the RTCP port 73 and optionally the RTCP address, and we also propose to make the 74 behavior of RTP implementations more conforming to the robustness 75 principle. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2 Description of the solution 83 The main part of our solution is the declaration of an SDP attribute 84 for documenting the port used by RTCP. In order for the solution to 85 be useful, the RTP implementation must be made more tolerant than 86 specified in [RFC1889]. 88 2.1 The RTCP attribute 90 The RTCP attribute is used to document the RTCP port used for media 91 stream, when that port is not the next higher (odd) port number 92 following the RTP port described in the media line. The RTCP 93 attribute is a "value" attribute, and follows the general syntax 94 specified page 18 of [RFC2327]: "a=:". For the 95 RTCP attribute: 97 * the name is the ascii string "rtcp" (lower case), 99 * the value is the RTCP port number and optional address. 101 The formal description of the attribute is defined by the following 102 ABNF syntax: 104 rtcp-attribute = "a=rtcp:" port [nettype space addrtype space 105 connection-address] CRLF 107 In this description, the "port", "nettype", "addrtype" and 108 "connection-address" tokens are defined as specified in "Appendix A: 109 SDP Grammar" of [RFC2327]. 111 Example encodings could be: 113 m=audio 49170 RTP/AVP 0 114 a=rtcp:53020 116 m=audio 49170 RTP/AVP 0 117 a=rtcp:53020 IN IP4 126.16.64.4 119 m=audio 49170 RTP/AVP 0 120 a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD 122 The RTCP attribute MAY be used as a media level attribute; it MUST 123 NOT be used as a session level attribute. 125 2.2 Oddity tolerant RTP 127 In order to successfully exchange RTP packets with a host located 128 behind a NAT, a corresponding RTP implementation should be more 129 tolerant than specified in [RFC1889]. If it receives an SDP text 130 specifying the use of a specific port number for RTP, and another 131 specific port number for RTCP, the implementation SHOULD send 132 packets to exactly these port numbers, regardless of whether the 133 numbers are odd or even, in sequence or separate. 135 For compatibility with existing implementations, the modified RTP 136 behavior MUST NOT be used if the RTCP port is not explicitly 137 specified. An implementation that wishes to receive RTP packets on 138 an odd port number MUST document both the RTP and the RTCP ports in 139 the SDP description, even if the RTCP port is immediately 140 consecutive to the RTP port. 142 3 Discussion of the solution 144 The implementation of the solution is fairly straightforward. The 145 three questions that have been most often asked regarding this 146 solution are whether this is useful, i.e. whether a host can 147 actually discover port numbers in an unmodified NAT, whether it is 148 sufficient, i.e. whether or not there is a need to document more 149 than one ancillary port per media type, and whether relaxing the RTP 150 requirements is legitimate. 152 3.1 How do we discover port numbers? 154 The proposed solution assumes that we can discover the "translated 155 port numbers", i.e. the value of the ports as they appear on the 156 "external side" of the NAT. There are multiple ways to achieve this 157 result. One possibility is to ask the cooperation of a well 158 connected third party that will act as a server according to [STUN]. 160 We thus obtain a three step process: 162 1) The host allocate two UDP ports numbers for an RTP/RTCP pair, 164 2) The host sends a UDP message from each port to the STUN server, 166 3) The STUN server reads the source address and port of the packet, 167 and copies them in the text of a reply, 169 4) The host parses the reply according to the STUN protocol and 170 learns the external address and port corresponding to each of the 171 two UDP port. 173 This algorithm supposes that the NAT will use the same translation 174 for packets sent to the third party and to the "SDP peer" with which 175 the host wants to establish a connection. The experience shows that 176 this is the case for a large fraction of NATs. 178 3.2 Do we need to support multiple ports? 180 Most media streams are transmitted using a single pair of RTP and 181 RTCP ports. It is possible, however, to transmit a single media over 182 several RTP flows, for example using hierarchical encoding. In this 183 case, SDP will encode the port number used by RTP on the first flow, 184 and the number of flows, as in: 186 m=video 49170/2 RTP/AVP 31 188 In this example, the media is sent over 2 consecutive pairs of 189 ports, corresponding respectively to RTP for the first flow (even 190 number, 49170), RTCP for the first flow (odd number, 49171), RTP for 191 the second flow (even number, 49172), and RTCP for the second flow 192 (odd number, 49173). 194 In theory, it would be possible to modify SDP and document the many 195 ports corresponding to the separate encoding layers. However, 196 layered encoding is not much used in practice, and when used is 197 mostly used in conjunction with multicast transmission. The 198 translation issues documented in this memo apply uniquely to unicast 199 transmission, and thus there is no short term need for the support 200 of multiple port descriptions. It is more convenient and more robust 201 to focus on the simple case in which a media is sent over exactly 202 one RTP/RTCP stream. 204 3.3 Why not expand the media definition? 206 The RTP ports are documented in the media description line, and it 207 would seem convenient to document the RTCP port at the same place, 208 rather than create an RTCP attribute. We considered this design 209 alternative and rejected it for two reasons: adding an extra port 210 number and an option address in the media description would be 211 awkward, and more importantly it would create problems with existing 212 applications, which would have to reject the entire media 213 description if they did not understand the extension. On the 214 contrary, adding an attribute has a well defined failure mode: 215 implementations that don't understand the "a=rtcp" attribute will 216 simply ignore it; they will fail to send RTCP packets to the 217 specified address, but they will at least be able to receive the 218 media in the RTP packets. 220 3.4 Is a tolerant RTP legitimate? 222 Our solution explicitly asks implementers to disregard a part of the 223 RTP specification that mandates use of even port numbers for RTP and 224 the consecutive odd port number for RTCP. We believe that this is 225 very much in the spirit of the robustness principle attributed to 226 Jon Postel, i.e. "Be conservative in what you do, be liberal in what 227 you accept from others." 229 This approach has been validated with the AVT working group of the 230 IETF, which is in charge of maintaining the RTP standard. We expect 231 that the revised version of the RTP standard will lift the 232 restrictions on port numbers imposed in [RFC1889], e.g. specify that 233 for applications in which the RTP and RTCP destination port numbers 234 are specified via explicit, separate parameters (using a signaling 235 protocol or other means), the application MAY disregard the 236 restrictions that the port numbers be even/odd and consecutive 237 although the use of an even/odd port pair is still encouraged. 239 4 UNSAF considerations 241 The RTCP attribute in SDP is used to enable establishment of 242 RTP/RTCP flows through NAT, in conjunction with an address discovery 243 mechanism such as STUN. This mechanism is a short term fix to the 244 NAT traversal problem, which requires thus consideration of the 245 general issues linked to "Unilateral self-address fixing" [UNSAF]. 247 The RTCP attribute addresses a very specific problem, the 248 documentation of port numbers as they appear after address 249 translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be 250 used for other applications. 252 We expect that, with time, one of two exit strategies can be 253 developed. The IETF may develop an explicit "middlebox control" 254 protocol, that will enable applications to obtain a pair of port 255 numbers appropriate for RTP and RTCP. Another possibility is the 256 deployment of IPv6, which will enable use of "end to end" 257 addressing, and guarantee that the two hosts will be able to use 258 appropriate ports. In both cases, there will be no need for 259 documenting a "non standard" RTCP port with the RTCP attribute. 261 5 Security Considerations 263 This SDP extension is not believed to introduce any significant 264 security risk to multi-media applications. One could conceive that a 265 malevolent third party would use the extension to redirect the RTCP 266 fraction of an RTP exchange, but this require intercepting and 267 rewriting the signaling packet carrying the SDP text; if an 268 interceptor can do that, many more attacks are available, including 269 a wholesale change of the addresses and port numbers at which the 270 media will be sent. 272 In order to avoid attacks of this sort, when SDP is used in a 273 signaling packet where it is of the form application/sdp, end-to-end 274 integrity using S/MIME [RFC3369] is the technical method to be 275 implemented and applied. This is compatible with SIP [RFC3261]. 277 6 IANA Considerations 279 This document defines a new SDP parameter, the attribute field 280 "rtcp", which per [RFC2327] should be registered by IANA. This 281 attribute field is designed for use at media level only. 283 7 Copyright 285 The following copyright notice is copied from RFC 2026 [Bradner, 286 1996], Section 10.4, and describes the applicable copyright for this 287 document. 289 Copyright (C) The Internet Society March 21, 2001. All Rights 290 Reserved. 292 This document and translations of it may be copied and furnished to 293 others, and derivative works that comment on or otherwise explain it 294 or assist in its implementation may be prepared, copied, published 295 and distributed, in whole or in part, without restriction of any 296 kind, provided that the above copyright notice and this paragraph 297 are included on all such copies and derivative works. However, this 298 document itself may not be modified in any way, such as by removing 299 the copyright notice or references to the Internet Society or other 300 Internet organizations, except as needed for the purpose of 301 developing Internet standards in which case the procedures for 302 copyrights defined in the Internet Standards process must be 303 followed, or as required to translate it into languages other than 304 English. 306 The limited permissions granted above are perpetual and will not be 307 revoked by the Internet Society or its successors or assignees. 309 This document and the information contained herein is provided on an 310 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 311 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 312 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 313 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 314 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 8 Intellectual Property 318 The following notice is copied from RFC 2026 [Bradner, 1996], 319 Section 10.4, and describes the position of the IETF concerning 320 intellectual property claims made against this document. 322 The IETF takes no position regarding the validity or scope of any 323 intellectual property or other rights that might be claimed to 324 pertain to the implementation or use other technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; neither does it represent that it 327 has made any effort to identify any such rights. Information on the 328 IETF's procedures with respect to rights in standards-track and 329 standards-related documentation can be found in BCP-11. Copies of 330 claims of rights made available for publication and any assurances 331 of licenses to be made available, or the result of an attempt made 332 to obtain a general license or permission for the use of such 333 proprietary rights by implementers or users of this specification 334 can be obtained from the IETF Secretariat. 336 The IETF invites any interested party to bring to its attention any 337 copyrights, patents or patent applications, or other proprietary 338 rights which may cover technology that may be required to practice 339 this standard. Please address the information to the IETF Executive 340 Director. 342 9 Acknowledgements 344 The original idea for using the "rtcp" attribute was developed by 345 Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working 346 groups of the IETF. 348 10 References 350 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 351 J. Peterson, R. Sparks, M. Handley, E. Schooler. SIP: Session 352 Initiation Protocol. RFC 3261, June 2002. 354 [RFC2327] M. Handley, V. Jacobson, "SDP: Session Description 355 Protocol", RFC 2327, April 1998. 357 [RFC3369] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369, 358 August 2002. 360 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: 361 A Transport Protocol for Real-Time Applications", RFC 1889, January 362 1996. 364 [RFC2766] G. Tsirtsis, P. Srisuresh. "Network Address Translation - 365 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 367 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 368 Requirement Levels", RFC 2119, March 1997. 370 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 371 Specifications: ABNF", RFC 2234, November 1997. 373 [UNSAF] L. Daigle, "IAB considerations for UNilateral self-address 374 fixing (UNSAF) across network address translation," Internet Draft, 375 Internet Engineering Task Force, Approved Sep 2002. 376 draft-iab-unsaf-considerations-02.txt 378 11 Author's Addresses 380 Christian Huitema 381 Microsoft Corporation 382 One Microsoft Way 383 Redmond, WA 98052-6399 385 Email: huitema@microsoft.com 386 Table of Contents: 388 1 Introduction .................................................... 1 389 2 Description of the solution ..................................... 2 390 2.1 The RTCP attribute ............................................ 2 391 2.2 Oddity tolerant RTP ........................................... 3 392 3 Discussion of the solution ...................................... 3 393 3.1 How do we discover port numbers? .............................. 3 394 3.2 Do we need to support multiple ports? ......................... 4 395 3.3 Why not expand the media definition? .......................... 4 396 3.4 Is a tolerant RTP legitimate? ................................. 5 397 4 UNSAF considerations ............................................ 5 398 5 Security Considerations ......................................... 5 399 6 IANA Considerations ............................................. 6 400 7 Copyright ....................................................... 6 401 8 Intellectual Property ........................................... 7 402 9 Acknowledgements ................................................ 7 403 10 References ..................................................... 7 404 11 Author's Addresses ............................................. 8