idnits 2.17.1 draft-ietf-mmusic-sdp4nat-04.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? == There are 10 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 367 lines 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 16 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2234], [RFC2327], [RFC3489], [RFC3369], [RFC2119], [RFC3424], [RTP-NEW], [RFC2766], [RFC3261], [Bradner,1996], [RFC1889]), 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 (May 12, 2003) is 7655 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 340 looks like a reference -- Missing reference section? 'RFC2766' on line 337 looks like a reference -- Missing reference section? 'RFC2327' on line 318 looks like a reference -- Missing reference section? 'RTP-NEW' on line 321 looks like a reference -- Missing reference section? 'RFC1889' on line 325 looks like a reference -- Missing reference section? 'RFC2119' on line 329 looks like a reference -- Missing reference section? 'RFC3489' on line 351 looks like a reference -- Missing reference section? 'RFC3424' on line 347 looks like a reference -- Missing reference section? 'RFC3369' on line 344 looks like a reference -- Missing reference section? 'Bradner' on line 284 looks like a reference -- Missing reference section? '1996' on line 284 looks like a reference -- Missing reference section? 'RFC2234' on line 332 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT RTCP attribute in SDP May 12, 2003 3 INTERNET DRAFT C. Huitema 4 Microsoft 5 Expires November 12, 2003 May 12, 2003 7 RTCP attribute in SDP 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The session description protocol (SDP) is used to describe the 33 parameters of media streams used in multimedia sessions. When a 34 session requires multiple ports, SDP assumes that these port have 35 consecutive numbers. However, when the session crosses a network 36 address translation device that also uses port mapping, the ordering 37 of ports can be destroyed by the translation. To handle this, we 38 propose an extension attribute to SDP. 40 1. Introduction 42 The session invitation protocol (SIP, [RFC3261]) is often used to 43 establish multi-media sessions on the Internet. There are often 44 cases today in which one or both end of the connection are hidden 45 behind a network address translation device [RFC2766]. In this case, 46 the SDP text must document the IP addresses and UDP ports as they 47 appear on the 'public Internet' side of the NAT; in this memo, we 48 will suppose that the host located behind a NAT has a way to obtain 49 these numbers; a possible way to learn these numbers is briefly 50 outlined in section 3. However, just learning the numbers is not 51 enough. 53 The SIP messages use the encoding defined in SDP [RFC2327] to 54 describe the IP addresses and TCP or UDP ports used my the various 55 media. Audio and video are typically sent using RTP [RTP-NEW], which 56 requires two UDP ports, one for the media and one for the control 57 protocol (RTCP). SDP carries only one port number per media, and 58 states that 'other ports used by the media application (such as the 59 RTCP port) should be derived algorithmically from the base media 60 port.' RTCP port numbers were necessarily derived from the base 61 media port in older versions of RTP (such as [RFC1889]), but now 62 that this restriction has been lifted, there is a need to specify 63 RTCP ports explicitly in SDP. Note, however, that implementations of 64 RTP adhering to the earlier [RFC1889] specification may not be able 65 to make use of the SDP attributes specified in this document. 67 When the NAT device performs port mapping, there is no guarantee 68 that the mappings of two separate ports reflects the sequencing and 69 the parity of the original port numbers; in fact, when the NAT 70 manages a pool of IP addresses, it is even possible that the RTP and 71 the RTCP ports may be mapped to different addresses. In order to 72 successfully establish connections despite the misordering of the 73 port numbers and the possible parity switches caused by the NAT, we 74 propose to use a specific SDP attribute to document the RTCP port 75 and optionally the RTCP address, and we also propose to make the 76 behavior of RTP implementations more conforming to the robustness 77 principle. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Description of the solution 85 The main part of our solution is the declaration of an SDP attribute 86 for documenting the port used by RTCP. 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 3. Discussion of the solution 127 The implementation of the solution is fairly straightforward. The 128 three questions that have been most often asked regarding this 129 solution are whether this is useful, i.e. whether a host can 130 actually discover port numbers in an unmodified NAT, whether it is 131 sufficient, i.e. whether or not there is a need to document more 132 than one ancillary port per media type, and whether relaxing the RTP 133 requirements is legitimate. 135 3.1. How do we discover port numbers? 137 The proposed solution is only useful if the host can discover the 138 �translated port numbers�, i.e. the value of the ports as they 139 appear on the 'external side' of the NAT. One possibility is to ask 140 the cooperation of a well connected third party that will act as a 141 server according to STUN [RFC3489]. We thus obtain a four step 142 process: 144 1- The host allocate two UDP ports numbers for an RTP/RTCP pair, 146 2- The host sends a UDP message from each port to the STUN server, 148 3- The STUN server reads the source address and port of the packet, 149 and copies them in the text of a reply, 151 4- The host parses the reply according to the STUN protocol and 152 learns the external address and port corresponding to each of the 153 two UDP port. 155 This algorithm supposes that the NAT will use the same translation 156 for packets sent to the third party and to the �SDP peer� with which 157 the host wants to establish a connection. There is no guarantee that 158 all NAT boxes deployed on the Internet have this characteristic. 159 Implementers are referred to the STUN specification [RFC3489] for an 160 extensive discussion of the various types of NAT. 162 3.2. Do we need to support multiple ports? 164 Most media streams are transmitted using a single pair of RTP and 165 RTCP ports. It is possible, however, to transmit a single media over 166 several RTP flows, for example using hierarchical encoding. In this 167 case, SDP will encode the port number used by RTP on the first flow, 168 and the number of flows, as in: 170 m=video 49170/2 RTP/AVP 31 172 In this example, the media is sent over 2 consecutive pairs of 173 ports, corresponding respectively to RTP for the first flow (even 174 number, 49170), RTCP for the first flow (odd number, 49171), RTP for 175 the second flow (even number, 49172), and RTCP for the second flow 176 (odd number, 49173). 178 In theory, it would be possible to modify SDP and document the many 179 ports corresponding to the separate encoding layers. However, 180 layered encoding is not much used in practice, and when used is 181 mostly used in conjunction with multicast transmission. The 182 translation issues documented in this memo apply uniquely to unicast 183 transmission, and thus there is no short term need for the support 184 of multiple port descriptions. It is more convenient and more robust 185 to focus on the simple case in which a media is sent over exactly 186 one RTP/RTCP stream. 188 3.3. Why not expand the media definition? 190 The RTP ports are documented in the media description line, and it 191 would seem convenient to document the RTCP port at the same place, 192 rather than create an RTCP attribute. We considered this design 193 alternative and rejected it for two reasons: adding an extra port 194 number and an option address in the media description would be 195 awkward, and more importantly it would create problems with existing 196 applications, which would have to reject the entire media 197 description if they did not understand the extension. On the 198 contrary, adding an attribute has a well defined failure mode: 199 implementations that don�t understand the 'a=rtcp' attribute will 200 simply ignore it; they will fail to send RTCP packets to the 201 specified address, but they will at least be able to receive the 202 media in the RTP packets. 204 4. UNSAF considerations 206 The RTCP attribute in SDP is used to enable establishment of 207 RTP/RTCP flows through NAT. This mechanism can be used in 208 conjunction with an address discovery mechanism such as STUN 209 [RFC3489]. STUN is a short term fix to the NAT traversal problem, 210 which requires thus consideration of the general issues linked to 211 'Unilateral self-address fixing' [RFC3424]. 213 The RTCP attribute addresses a very specific problem, the 214 documentation of port numbers as they appear after address 215 translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be 216 used for other applications. 218 We expect that, with time, one of two exit strategies can be 219 developed. The IETF may develop an explicit 'middlebox control' 220 protocol that will enable applications to obtain a pair of port 221 numbers appropriate for RTP and RTCP. Another possibility is the 222 deployment of IPv6, which will enable use of 'end to end' addressing 223 and guarantee that the two hosts will be able to use appropriate 224 ports. In both cases, there will be no need for documenting a �non 225 standard� RTCP port with the RTCP attribute. 227 5. Security Considerations 229 This SDP extension is not believed to introduce any significant 230 security risk to multi-media applications. One could conceive that a 231 malevolent third party would use the extension to redirect the RTCP 232 fraction of an RTP exchange, but this require intercepting and 233 rewriting the signaling packet carrying the SDP text; if an 234 interceptor can do that, many more attacks are available, including 235 a wholesale change of the addresses and port numbers at which the 236 media will be sent. 238 In order to avoid attacks of this sort, when SDP is used in a 239 signaling packet where it is of the form application/sdp, end-to-end 240 integrity using S/MIME [RFC3369] is the technical method to be 241 implemented and applied. This is compatible with SIP [RFC3261]. 243 6. IANA Considerations 245 This document defines a new SDP parameter, the attribute field 246 'rtcp', which per [RFC2327] should be registered by IANA. This 247 attribute field is designed for use at media level only. 249 7. Copyright 251 The following copyright notice is copied from RFC 2026 [Bradner, 252 1996], Section 10.4, and describes the applicable copyright for this 253 document. 255 Copyright (C) The Internet Society March 21, 2001. All Rights 256 Reserved. 258 This document and translations of it may be copied and furnished to 259 others, and derivative works that comment on or otherwise explain it 260 or assist in its implementation may be prepared, copied, published 261 and distributed, in whole or in part, without restriction of any 262 kind, provided that the above copyright notice and this paragraph 263 are included on all such copies and derivative works. However, this 264 document itself may not be modified in any way, such as by removing 265 the copyright notice or references to the Internet Society or other 266 Internet organizations, except as needed for the purpose of 267 developing Internet standards in which case the procedures for 268 copyrights defined in the Internet Standards process must be 269 followed, or as required to translate it into languages other than 270 English. 272 The limited permissions granted above are perpetual and will not be 273 revoked by the Internet Society or its successors or assignees. 275 This document and the information contained herein is provided on an 276 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 277 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 278 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 279 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 280 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 282 8. Intellectual Property 284 The following notice is copied from RFC 2026 [Bradner, 1996], 285 Section 10.4, and describes the position of the IETF concerning 286 intellectual property claims made against this document. 288 The IETF takes no position regarding the validity or scope of any 289 intellectual property or other rights that might be claimed to 290 pertain to the implementation or use other technology described in 291 this document or the extent to which any license under such rights 292 might or might not be available; neither does it represent that it 293 has made any effort to identify any such rights. Information on the 294 IETF's procedures with respect to rights in standards-track and 295 standards-related documentation can be found in BCP-11. Copies of 296 claims of rights made available for publication and any assurances 297 of licenses to be made available, or the result of an attempt made 298 to obtain a general license or permission for the use of such 299 proprietary rights by implementers or users of this specification 300 can be obtained from the IETF Secretariat. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights which may cover technology that may be required to practice 305 this standard. Please address the information to the IETF Executive 306 Director. 308 9. Acknowledgements 310 The original idea for using the 'rtcp' attribute was developed by 311 Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working 312 groups of the IETF. 314 10. References 316 Normative references 318 [RFC2327] M. Handley, V. Jacobson, 'SDP: Session Description 319 Protocol', RFC 2327, April 1998. 321 [RTP-NEW] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: 322 A Transport Protocol for Real-Time Applications", Work in progress, 323 March 2003. 325 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: 326 A Transport Protocol for Real-Time Applications", RFC 1889, January 327 1996. 329 [RFC2119] S. Bradner, 'Key words for use in RFCs to Indicate 330 Requirement Levels', RFC 2119, March 1997. 332 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 333 Specifications: ABNF", RFC 2234, November 1997. 335 Informative references 337 [RFC2766] G. Tsirtsis, P. Srisuresh. 'Network Address Translation - 338 Protocol Translation (NAT-PT)', RFC 2766, February 2000. 340 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 341 J. Peterson, R. Sparks, M. Handley, E. Schooler. SIP: Session 342 Initiation Protocol. RFC 3261, June 2002. 344 [RFC3369] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369, 345 August 2002. 347 [RFC3424] L. Daigle, "IAB considerations for UNilateral self-address 348 fixing (UNSAF) across network address translation," RFC 3424, 349 November 2002. 351 [RFC3489] J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. �STUN - 352 Simple Traversal of User Datagram Protocol (UDP) Through Network 353 Address Translators (NATs)�. RFC 3489, March 2003 355 11. Author's Address 357 Christian Huitema 358 Microsoft Corporation 359 One Microsoft Way 360 Redmond, WA 98052-6399 362 Email: huitema@microsoft.com