idnits 2.17.1 draft-ietf-mmusic-sdp4nat-05.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 15 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 30, 2003) is 7599 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 341 looks like a reference -- Missing reference section? 'RFC2766' on line 337 looks like a reference -- Missing reference section? 'RFC2327' on line 314 looks like a reference -- Missing reference section? 'RTP-NEW' on line 317 looks like a reference -- Missing reference section? 'RFC1889' on line 321 looks like a reference -- Missing reference section? 'RFC2119' on line 325 looks like a reference -- Missing reference section? 'RFC3489' on line 331 looks like a reference -- Missing reference section? 'RFC3424' on line 348 looks like a reference -- Missing reference section? 'RFC3369' on line 345 looks like a reference -- Missing reference section? 'Bradner' on line 280 looks like a reference -- Missing reference section? '1996' on line 280 looks like a reference -- Missing reference section? 'RFC2234' on line 328 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 Expires November 30, 2003 May 30, 2003 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 by the various 53 media. Audio and video are typically sent using RTP [RTP-NEW], 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." RTCP port numbers were necessarily derived from the base 59 media port in older versions of RTP (such as [RFC1889]), but now 60 that this restriction has been lifted, there is a need to specify 61 RTCP ports explicitly in SDP. Note, however, that implementations of 62 RTP adhering to the earlier [RFC1889] specification may not be able 63 to make use of the SDP attributes specified in this document. 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. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Description of the solution 81 The main part of our solution is the declaration of an SDP attribute 82 for documenting the port used by RTCP. 84 2.1. The RTCP attribute 86 The RTCP attribute is used to document the RTCP port used for media 87 stream, when that port is not the next higher (odd) port number 88 following the RTP port described in the media line. The RTCP 89 attribute is a "value" attribute, and follows the general syntax 90 specified page 18 of [RFC2327]: "a=:". For the 91 RTCP attribute: 93 * the name is the ascii string "rtcp" (lower case), 95 * the value is the RTCP port number and optional address. 97 The formal description of the attribute is defined by the following 98 ABNF syntax: 100 rtcp-attribute = "a=rtcp:" port [nettype space addrtype space 101 connection-address] CRLF 103 In this description, the "port", "nettype", "addrtype" and 104 "connection-address" tokens are defined as specified in "Appendix A: 105 SDP Grammar" of [RFC2327]. 107 Example encodings could be: 109 m=audio 49170 RTP/AVP 0 110 a=rtcp:53020 112 m=audio 49170 RTP/AVP 0 113 a=rtcp:53020 IN IP4 126.16.64.4 115 m=audio 49170 RTP/AVP 0 116 a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD 118 The RTCP attribute MAY be used as a media level attribute; it MUST 119 NOT be used as a session level attribute. 121 3. Discussion of the solution 123 The implementation of the solution is fairly straightforward. The 124 questions that have been most often asked regarding this solution 125 are whether this is useful, i.e. whether a host can actually 126 discover port numbers in an unmodified NAT, whether it is 127 sufficient, i.e. whether or not there is a need to document more 128 than one ancillary port per media type, and whether why should not 129 change the media definition instead of adding a new attribute. 131 3.1. How do we discover port numbers? 133 The proposed solution is only useful if the host can discover the 134 "translated port numbers", i.e. the value of the ports as they 135 appear on the "external side" of the NAT. One possibility is to ask 136 the cooperation of a well connected third party that will act as a 137 server according to STUN [RFC3489]. We thus obtain a four step 138 process: 140 1- The host allocates two UDP ports numbers for an RTP/RTCP pair, 142 2- The host sends a UDP message from each port to the STUN server, 144 3- The STUN server reads the source address and port of the packet, 145 and copies them in the text of a reply, 147 4- The host parses the reply according to the STUN protocol and 148 learns the external address and port corresponding to each of the 149 two UDP port. 151 This algorithm supposes that the NAT will use the same translation 152 for packets sent to the third party and to the "SDP peer" with which 153 the host wants to establish a connection. There is no guarantee that 154 all NAT boxes deployed on the Internet have this characteristic. 155 Implementers are referred to the STUN specification [RFC3489] for an 156 extensive discussion of the various types of NAT. 158 3.2. Do we need to support multiple ports? 160 Most media streams are transmitted using a single pair of RTP and 161 RTCP ports. It is possible, however, to transmit a single media over 162 several RTP flows, for example using hierarchical encoding. In this 163 case, SDP will encode the port number used by RTP on the first flow, 164 and the number of flows, as in: 166 m=video 49170/2 RTP/AVP 31 168 In this example, the media is sent over 2 consecutive pairs of 169 ports, corresponding respectively to RTP for the first flow (even 170 number, 49170), RTCP for the first flow (odd number, 49171), RTP for 171 the second flow (even number, 49172), and RTCP for the second flow 172 (odd number, 49173). 174 In theory, it would be possible to modify SDP and document the many 175 ports corresponding to the separate encoding layers. However, 176 layered encoding is not much used in practice, and when used is 177 mostly used in conjunction with multicast transmission. The 178 translation issues documented in this memo apply uniquely to unicast 179 transmission, and thus there is no short term need for the support 180 of multiple port descriptions. It is more convenient and more robust 181 to focus on the simple case in which a media is sent over exactly 182 one RTP/RTCP stream. 184 3.3. Why not expand the media definition? 186 The RTP ports are documented in the media description line, and it 187 would seem convenient to document the RTCP port at the same place, 188 rather than create an RTCP attribute. We considered this design 189 alternative and rejected it for two reasons: adding an extra port 190 number and an option address in the media description would be 191 awkward, and more importantly it would create problems with existing 192 applications, which would have to reject the entire media 193 description if they did not understand the extension. On the 194 contrary, adding an attribute has a well defined failure mode: 195 implementations that don't understand the "a=rtcp" attribute will 196 simply ignore it; they will fail to send RTCP packets to the 197 specified address, but they will at least be able to receive the 198 media in the RTP packets. 200 4. UNSAF considerations 202 The RTCP attribute in SDP is used to enable establishment of 203 RTP/RTCP flows through NAT. This mechanism can be used in 204 conjunction with an address discovery mechanism such as STUN 205 [RFC3489]. STUN is a short term fix to the NAT traversal problem, 206 which requires thus consideration of the general issues linked to 207 "Unilateral self-address fixing" [RFC3424]. 209 The RTCP attribute addresses a very specific problem, the 210 documentation of port numbers as they appear after address 211 translation by a port-mapping NAT. The RTCP attribute SHOULD NOT be 212 used for other applications. 214 We expect that, with time, one of two exit strategies can be 215 developed. The IETF may develop an explicit "middlebox control" 216 protocol that will enable applications to obtain a pair of port 217 numbers appropriate for RTP and RTCP. Another possibility is the 218 deployment of IPv6, which will enable use of "end to end" addressing 219 and guarantee that the two hosts will be able to use appropriate 220 ports. In both cases, there will be no need for documenting a "non 221 standard" RTCP port with the RTCP attribute. 223 5. Security Considerations 225 This SDP extension is not believed to introduce any significant 226 security risk to multi-media applications. One could conceive that a 227 malevolent third party would use the extension to redirect the RTCP 228 fraction of an RTP exchange, but this requires intercepting and 229 rewriting the signaling packet carrying the SDP text; if an 230 interceptor can do that, many more attacks are available, including 231 a wholesale change of the addresses and port numbers at which the 232 media will be sent. 234 In order to avoid attacks of this sort, when SDP is used in a 235 signaling packet where it is of the form application/sdp, end-to-end 236 integrity using S/MIME [RFC3369] is the technical method to be 237 implemented and applied. This is compatible with SIP [RFC3261]. 239 6. IANA Considerations 241 This document defines a new SDP parameter, the attribute field 242 "rtcp", which per [RFC2327] should be registered by IANA. This 243 attribute field is designed for use at media level only. 245 7. Copyright 247 The following copyright notice is copied from RFC 2026 [Bradner, 248 1996], Section 10.4, and describes the applicable copyright for this 249 document. 251 Copyright (C) The Internet Society March 21, 2001. All Rights 252 Reserved. 254 This document and translations of it may be copied and furnished to 255 others, and derivative works that comment on or otherwise explain it 256 or assist in its implementation may be prepared, copied, published 257 and distributed, in whole or in part, without restriction of any 258 kind, provided that the above copyright notice and this paragraph 259 are included on all such copies and derivative works. However, this 260 document itself may not be modified in any way, such as by removing 261 the copyright notice or references to the Internet Society or other 262 Internet organizations, except as needed for the purpose of 263 developing Internet standards in which case the procedures for 264 copyrights defined in the Internet Standards process must be 265 followed, or as required to translate it into languages other than 266 English. 268 The limited permissions granted above are perpetual and will not be 269 revoked by the Internet Society or its successors or assignees. 271 This document and the information contained herein is provided on an 272 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 273 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 274 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 275 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 276 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 278 8. Intellectual Property 280 The following notice is copied from RFC 2026 [Bradner, 1996], 281 Section 10.4, and describes the position of the IETF concerning 282 intellectual property claims made against this document. 284 The IETF takes no position regarding the validity or scope of any 285 intellectual property or other rights that might be claimed to 286 pertain to the implementation or use other technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; neither does it represent that it 289 has made any effort to identify any such rights. Information on the 290 IETF's procedures with respect to rights in standards-track and 291 standards-related documentation can be found in BCP-11. Copies of 292 claims of rights made available for publication and any assurances 293 of licenses to be made available, or the result of an attempt made 294 to obtain a general license or permission for the use of such 295 proprietary rights by implementers or users of this specification 296 can be obtained from the IETF Secretariat. 298 The IETF invites any interested party to bring to its attention any 299 copyrights, patents or patent applications, or other proprietary 300 rights which may cover technology that may be required to practice 301 this standard. Please address the information to the IETF Executive 302 Director. 304 9. Acknowledgements 306 The original idea for using the "rtcp" attribute was developed by 307 Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working 308 groups of the IETF. 310 10. References 312 Normative references 314 [RFC2327] Handley, M., and V. Jacobson, "SDP: Session Description 315 Protocol", RFC 2327, April 1998. 317 [RTP-NEW] Schulzrinne, H., Casner, S., Frederick, R., and V. 318 Jacobson. "RTP: A Transport Protocol for Real-Time Applications", 319 Work in progress, March 2003. 321 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. 322 Jacobson. "RTP: A Transport Protocol for Real-Time Applications", 323 RFC 1889, January 1996. 325 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 326 Requirement Levels", RFC 2119, March 1997. 328 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 329 Specifications: ABNF", RFC 2234, November 1997. 331 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy. 332 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through 333 Network Address Translators (NATs)". RFC 3489, March 2003 335 Informative references 337 [RFC2766] Tsirtsis, G., and P. Srisuresh. "Network Address 338 Translation - Protocol Translation (NAT-PT)", RFC 2766, February 339 2000. 341 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 342 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler. SIP: 343 Session Initiation Protocol. RFC 3261, June 2002. 345 [RFC3369] R. Housley. Cryptographic Message Syntax (CMS). RFC 3369, 346 August 2002. 348 [RFC3424] L. Daigle, "IAB considerations for UNilateral Self-Address 349 Fixing (UNSAF) across network address translation," RFC 3424, 350 November 2002. 352 11. Author's Address 354 Christian Huitema 355 Microsoft Corporation 356 One Microsoft Way 357 Redmond, WA 98052-6399 359 Email: huitema@microsoft.com