idnits 2.17.1 draft-ietf-avt-rtcp-port-for-ssm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC5760, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC5760, updated by this document, for RFC5378 checks: 2002-02-27) -- 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 (December 15, 2010) is 4873 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: 'RFCXXXX' is mentioned on line 205, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft Cisco 4 Updates: 5760 (if approved) December 15, 2010 5 Intended status: Standards Track 6 Expires: June 18, 2011 8 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) 9 Sessions 10 draft-ietf-avt-rtcp-port-for-ssm-04 12 Abstract 14 The Session Description Protocol (SDP) has an attribute that allows 15 RTP applications to specify an address and a port associated with the 16 RTP Control Protocol (RTCP) traffic. In RTP-based source-specific 17 multicast (SSM) sessions, the same attribute is used to designate the 18 address and the RTCP port of the Feedback Target in the SDP 19 description. However, the RTCP port associated with the SSM session 20 itself cannot be specified by the same attribute to avoid ambiguity, 21 and thus, is required to be derived from the "m=" line of the media 22 description. Deriving the RTCP port from the "m=" line imposes an 23 unnecessary restriction. This document removes this restriction by 24 introducing a new SDP attribute. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 18, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 62 3. The 'multicast-rtcp' Attribute . . . . . . . . . . . . . . . . 3 63 4. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Registration of SDP Attributes . . . . . . . . . . . . . . 6 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The Session Description Protocol (SDP) [RFC4566] has an attribute 76 that allows RTP applications [RFC3550] to specify an address and a 77 port associated with the RTP Control Protocol (RTCP) traffic 78 [RFC3605]. This attribute is called 'rtcp'. 80 Now consider a network where one or more media senders send RTP 81 packets to a distribution source, which then multicasts these RTP 82 packets to multicast receivers using a source-specific multicast 83 (SSM) arrangement [RFC5760]. The distribution source also multicasts 84 the forward RTCP traffic (i.e., RTCP sender reports and receiver 85 reports or their summaries) to the receivers in the same SSM session. 87 In RTP-based SSM sessions, the 'rtcp' attribute is used to designate 88 the address and the RTCP port of the Feedback Target in the SDP 89 description [RFC5760]. However, the RTCP port associated with the 90 SSM session itself cannot be specified by the same attribute since it 91 could potentially cause ambiguity. Thus, the multicast RTCP port is 92 required to be derived from the "m=" line of the media description 93 (See Section 10.2 of [RFC5760]) by following the +1 rule. However, 94 [RFC3550] lifted the requirement for the +1 rule since it imposed an 95 unnecessary restriction on RTCP port selection. 97 In this specification, we introduce a new SDP attribute to remove 98 this restriction. The new attribute allows the multicast sender to 99 use its desired port in the RTCP session. This document updates 100 [RFC5760]. 102 2. Requirements Notation 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 [RFC2119]. 108 3. The 'multicast-rtcp' Attribute 110 In RTP-based SSM sessions, the distribution source can use different 111 multicast RTP and RTCP ports to send the RTP and RTCP packets, 112 respectively. Alternatively, the distribution source can use RTP/ 113 RTCP port muxing [RFC5761], in which case the RTP and RTCP packets 114 are sent to the same destination port in the SSM session. 116 For the cases when the distribution source does not want to use the 117 one higher port for the RTCP traffic, this document defines a new SDP 118 attribute, called 'multicast-rtcp'. By using this attribute, the 119 distribution source uses a desired port for the SSM RTCP session. In 120 the absence of the 'multicast-rtcp' attribute, the +1 rule applies 121 following [RFC5760]. 123 The following ABNF [RFC5234] syntax formally describes the 124 'multicast-rtcp' attribute: 126 rtcp-attribute = "a=multicast-rtcp:" port CRLF 128 Figure 1: ABNF syntax for the 'multicast-rtcp' attribute 130 Here, the 'port' token is defined as specified in Section 9 of 131 [RFC4566]. 133 The 'multicast-rtcp' attribute is defined as both a media-level and 134 session-level attribute. Except where stated otherwise in this 135 document, the rules of [RFC3550] apply. 137 4. SDP Example 139 In the session description shown in Figure 2, a source stream is 140 multicast from a distribution source (with a source IP address of 141 198.51.100.1) to the multicast destination address of 233.252.0.2 and 142 port 41000. The forward RTCP traffic is multicast in the same 143 multicast group but to port 42000 as specified by the "a=multicast- 144 rtcp:42000" line. A feedback target with an address of 192.0.2.1 and 145 port of 43000 is specified by the 'rtcp' attribute. 147 v=0 148 o=ali 1122334455 1122334466 IN IP4 ssm.example.com 149 s='multicast-rtcp' Example 150 t=0 0 151 a=rtcp-unicast:rsi 152 m=video 41000 RTP/AVPF 98 153 i=Multicast Stream 154 c=IN IP4 233.252.0.2/255 155 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 156 a=rtpmap:98 MP2T/90000 157 a=multicast-rtcp:42000 158 a=rtcp:43000 IN IP4 192.0.2.1 159 a=mid:1 161 Figure 2: Example SDP showing the use of the 'multicast-rtcp' 162 attribute 164 5. Security Considerations 166 The 'multicast-rtcp' attribute is not believed to introduce any 167 significant security risk to multimedia applications. A malevolent 168 third party could use this attribute to redirect the RTCP traffic, 169 but this requires intercepting and rewriting the packets carrying the 170 SDP description; and if an interceptor can do that, many more attacks 171 are possible, including a wholesale change of the addresses and port 172 numbers at which the media will be sent. 174 In order to avoid attacks of this sort, the SDP description needs to 175 be integrity protected and provided with source authentication. This 176 can, for example, be achieved on an end-to-end basis using S/MIME 177 [RFC5652] when SDP is used in a signaling packet using MIME types 178 (application/sdp). Alternatively, HTTPS [RFC2818] or the 179 authentication method in the Session Announcement Protocol (SAP) 180 [RFC2974] could be used as well. 182 6. IANA Considerations 184 The following contact information shall be used for all registrations 185 in this document: 187 Ali Begen 188 abegen@cisco.com 190 Note to the RFC Editor: In the following, replace "XXXX" with the 191 number of this document prior to publication as an RFC. 193 6.1. Registration of SDP Attributes 195 This document registers a new attribute name in SDP. 197 SDP Attribute ("att-field"): 198 Attribute name: multicast-rtcp 199 Long form: Port in the multicast RTCP session 200 Type of name: att-field 201 Type of attribute: Media or session level 202 Subject to charset: No 203 Purpose: Specifies the port for the SSM RTCP session 204 Reference: [RFCXXXX] 205 Values: See [RFCXXXX] 207 7. Acknowledgments 209 Thanks to Colin Perkins amd Magnus Westerlund for suggesting the name 210 for the 'multicast-rtcp' attribute and providing text for portions of 211 this specification. Some parts of this specification are based on 212 [RFC3605] and [RFC5760]. So, also thanks to those who contributed to 213 those specifications. 215 8. References 217 8.1. Normative References 219 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 220 Jacobson, "RTP: A Transport Protocol for Real-Time 221 Applications", STD 64, RFC 3550, July 2003. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 227 Description Protocol", RFC 4566, July 2006. 229 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 230 Protocol (RTCP) Extensions for Single-Source Multicast 231 Sessions with Unicast Feedback", RFC 5760, February 2010. 233 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 234 Specifications: ABNF", STD 68, RFC 5234, January 2008. 236 8.2. Informative References 238 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 239 in Session Description Protocol (SDP)", RFC 3605, 240 October 2003. 242 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 243 Control Packets on a Single Port", RFC 5761, April 2010. 245 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 246 RFC 5652, September 2009. 248 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 250 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 251 Announcement Protocol", RFC 2974, October 2000. 253 Author's Address 255 Ali Begen 256 Cisco 257 181 Bay Street 258 Toronto, ON M5J 2T3 259 Canada 261 Email: abegen@cisco.com