idnits 2.17.1 draft-ietf-mmusic-sdp-srcfilter-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 603 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 10 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 7 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. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (April 15, 2003) is 7675 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTCP-SSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDP' ** Obsolete normative reference: RFC 2044 (ref. 'UTF-8') (Obsoleted by RFC 2279) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Quinn 2 INTERNET-DRAFT Celox Networks 3 Category: Standards Track Ross Finlayson 4 Expires: October 2003 LIVE.COM 5 April 15, 2003 7 Session Description Protocol (SDP) Source Filters 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or 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 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This document describes how to adapt the Session Description Protocol 37 (SDP) to express one or more source addresses as a source filter for 38 one or more destination "connection" addresses. It defines the 39 syntax and semantics for an SDP "source-filter" attribute that may 40 reference either IPv4 or IPv6 address(es) as either an inclusive or 41 exclusive source list for either multicast or unicast destinations. 42 In particular, an inclusive source-filter can be used to specify a 43 Source-Specific Multicast (SSM) session. 45 1. Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [REQMNT]. 51 2. Introduction 53 The Session Description Protocol [SDP] provides a general-purpose 54 format for describing multimedia sessions in announcements or 55 invitations. SDP uses an entirely textual data format (the US-ASCII 56 subset of [UTF-8]) to maximize portability among transports. 57 SDP does not define a protocol, but only the syntax to describe a 58 multimedia session with sufficient information to discover and 59 participate in that session. Session descriptions may be sent using 60 any number of existing application protocols for transport 61 (e.g., SAP, SIP, RTSP, email, HTTP, etc.). 63 Typically, session descriptions reference an IP multicast address for 64 the "connection-address" (destination), though unicast addresses or 65 fully qualified domain names (FQDNs) MAY also be used. The "source- 66 filter" attribute defined in this document qualifies the session 67 traffic by identifying the address (or FQDN) of legitimate source(s) 68 (senders). The intent is for receivers to use the source and 69 destination address pair(s) to filter traffic, so that applications 70 receive only legitimate session traffic. 72 Receiver applications are expected to use the SDP source-filter 73 information to identify traffic from legitimate senders, and discard 74 traffic from illegitimate senders. Applications and hosts may also 75 share the source-filter information with network elements (e.g., with 76 routers using [IGMPv3]) so they can potentially perform the traffic 77 filtering operation further "upstream," closer to the source(s). 79 The "source-filter" attribute can appear at the session level 80 and/or the media level. 82 2.1. Motivation 84 The purpose of a source-filter is to help protect receivers from 85 traffic sent from illegitimate source addresses. Filtering traffic 86 can help to preserve content integrity and protect against denial of 87 service (DoS) attacks. 89 For multicast destination addresses, receiver applications MAY apply 90 source-filters using the Multicast Source Filter APIs [MSF API]. 91 Hosts are likely to implement these APIs using protocol mechanisms to 92 convey the source filters to local multicast routers. Other 93 "upstream" multicast routers MAY apply the filters and thereby 94 provide more explicit multicast group management and efficient 95 utilization of network resources. The protocol mechanisms to enable 96 these operations are beyond the scope of this document, but their 97 potential provided motivation for SDP source-filters. 99 3. The "source-filter" Attribute 101 The SDP source-filter attribute does not change any existing SDP 102 syntax or semantics, but defines a format for additional session 103 description information. Specifically, source-filter syntax can 104 prescribe one or more unicast addresses as either legitimate or 105 illegitimate sources for any (or all) SDP session description 106 "connection-address" field values. 108 The source-filter attribute has the following syntax: 110 a=source-filter: 112 The is either "incl" or "excl" (for inclusion or 113 exclusion, respectively). The has four sub-components: 115 117 A of "incl" means that an incoming packet is accepted 118 only if its source address is in the set specified by . 119 A of "excl" means that an incoming packet is rejected 120 if its source address is in the set specified by . 122 The first sub-field indicates the network type, since SDP 123 is protocol independent. This document is most relevant to the value 124 "IN", which designates the Internet Protocol. 126 The second sub-field identifies the address family, 127 and for the purpose of this document may be either value 128 "IP4" or "IP6". Alternately, when is an FQDN 129 (fully-qualified domain name), the value MAY be "*" to apply to both 130 address types, since either address type can be returned from a DNS 131 lookup. 133 The third sub-field is the destination address, which 134 MUST correspond to one or more of the session's "connection-address" 135 field values. It may be either a unicast or multicast address, 136 a FQDN, or the "*" wildcard to match any/all of the session's 137 "connection-address" values. 139 The fourth sub-field is the list of source 140 hosts/interfaces in the source-filter, and consists of one or more 141 unicast addresses or FQDNs, separated by space characters. 143 The format and content of these semantic elements are derived from 144 and compatible with those defined in [SDP]. For more detail, see 145 Appendix A of this document. 147 3.1. Processing Rules 149 There are a number of details to consider when parsing the SDP 150 source-filter syntax. 152 The value in a "source-filter" attribute MUST 153 correspond to an existing value in the session 154 description. The only exception to this is when a "*" wildcard is 155 used to indicate that the source-filter applies to all 156 values. 158 When the value is a multicast address, the field value 159 MUST NOT include the sub-fields and from 160 the value. If the 161 specifies more than one multicast address (in the 162 field), then a source filter, if any, for each 163 such address must be stated explicitly, using a separate 164 "a=source-filter" line for each address (unless a "*" wildcard is 165 used for ). See section 3.2.4 for an example. 167 When the value is the "*" wildcard, the 168 MUST be either a FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6 169 address). See section 3.2.6 for an example. 171 As has always been the case, the default behavior when a 172 source-filter attribute is not provided in a session description is 173 that all traffic sent to the specified value 174 should be accepted (i.e., from any source address). The 175 source-filter grammar does not include syntax to express either 176 "exclude none" or "include all." 178 Like the standard described in [SDP], the location 179 of the "source-filter" attribute determines whether it applies to the 180 entire session or only to a specific medium (i.e., "session-level" or 181 "media-level"). A media-level source-filter will always completely 182 override a session-level source-filter. 184 A "source-filter" need not be located at the same hierarchy level as 185 its corresponding . So, a media-level can reference a session-level value, and a 187 session-level "source-filter" can be applied to all matching media- 188 level values. See section 3.2.3 for an example. 190 An SDP description MUST NOT contain more than one session-level 191 "source-filter" attribute, nor more than one media-level 192 "source-filter" attribute for the same medium. 194 There is no specified limit to the number of entries allowed in the 195 , however there are practical limits that should be 196 considered. For example, depending on the transport to be used for 197 the session description, there may be a limit to the total size of 198 the session description (e.g., as determined by the maximum payload 199 in a single datagram). Also, when the source-filter is applied to 200 control protocols, there may be a limit to the number of source 201 addresses that can be sent. These limits are outside the scope of 202 this document, but should be considered when defining source-filter 203 values for SDP. 205 3.2. Examples 207 Here are a number of examples that illustrate how to use the source- 208 filter attribute in some common scenarios. We use the following 209 session description components as the starting point for the examples 210 to follow. For each example, we show the source filter with 211 additional relevant information, and provide a brief explanation. 213 = 214 v=0 215 o=The King 216 s=Elvis Impersonation 217 i=All Elvis, all the time 218 u=http://www.example.com/ElvisLive/ 219 t=0 0 220 a=recvonly 222 = 223 m=audio 54320 RTP/AVP 0 225 = 226 m=video 54322 RTP/AVP 34 228 3.2.1. Source-Specific Multicast Example 230 Multicast addresses in the Source-Specific Multicast [SSM] range 231 require a single unicast sender address for each multicast 232 destination, so the source-filter specification provides a natural 233 fit. In this example, a session member should receive only traffic 234 sent from 192.168.9.10 to the multicast session address 232.3.4.5. 236 238 c=IN IP4 232.3.4.5/127 239 a=source-filter: incl IN IP4 232.3.4.5 192.168.9.10 241 243 This source filter example uses an inclusion list with a single 244 multicast "connection-address" as the destination and single unicast 245 address as the source. Note that the value of the connection-address 246 matches the value specified in the connection-field. 248 Also note that since the connection-field is located in the session- 249 description section, the source-filter applies to all media. 251 Furthermore, if the SDP description specifies a RTP session 252 (e.g., its "m=" line(s) specify "RTP/AVP" as the transport protocol), 253 then the "incl" specification will apply not only to RTP packets, 254 but also to any RTCP packets that are sent to the specified multicast 255 address. This means that, as a side effect of the "incl" 256 specification, the only possible multicast RTCP packets will be 257 "Sender Report" (SR) packets sent from the specified source address. 259 Because of this, an SDP description for a Source-Specific Multicast 260 (SSM) RTP session SHOULD also include a 261 a=rtcp: unicast ... 262 attribute, as described in [RTCP-SSM] (section 10.1). This specifies 263 that RTCP "Reception Report" (RR) packets are to be sent back via 264 unicast. 266 3.2.2. Unicast Exclusion Example 268 Typically, an SDP session value is a multicast 269 address, although it is also possible to use either a unicast 270 address or FQDN. This example illustrates a scenario whereby a 271 session description indicates the unicast source address 192.168.9.10 272 in an exclusion filter. In effect, this sample source-filter says, 273 "destination 192.168.10.11 should accept traffic from any sender 274 *except* 192.168.9.10." 276 278 c=IN IP4 192.168.10.11 279 a=source-filter: excl IN IP4 192.168.10.11 192.168.9.10 281 283 3.2.3. Multiple Session Address Example 285 This source-filter example uses the wildcard "*" value for 286 to correspond to any/all values. 287 Hence, the only legitimate source for traffic sent to either 288 232.2.2.2 or 232.4.4.4 multicast addresses is 192.168.9.10. 289 Traffic sent from any other unicast source address should be 290 discarded by the receiver. 292 294 a=source-filter: incl IN IP4 * 192.168.9.10 296 298 c=IN IP4 232.2.2.2/127 300 302 c=IN IP4 232.4.4.4/63 304 3.2.4. Multiple Multicast Address Example 306 In this example, the specifies three multicast 307 addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3. The first and third 308 of these addresses are given source filters. However, in this 309 example the second address - 224.2.1.2 - is *not* given a 310 source filter. 312 314 c=IN IP4 224.2.1.1/127/3 315 a=source-filter: incl IN IP4 224.2.1.1 192.168.9.10 316 a=source-filter: incl IN IP4 224.2.1.3 192.168.9.42 318 320 3.2.5. IPv6 Multicast Source-Filter Example 322 This simple example defines a single session-level source-filter that 323 references a single IPv6 multicast destination and source pair. The 324 IP multicast traffic sent to FFOE::11A is valid only from the unicast 325 source address 2001:210:1:2:240:96FF:FE25:8EC9 327 329 c=IN IP6 FF0E::11A/127 330 a=source-filter incl IN IP6 FF0E::11A 2001:210:1:2:240:96FF:FE25:8EC9 332 334 3.2.6. IPv4 and IPv6 FQDN Example 336 This example illustrates use of the "*" wildcard, along 337 with multicast and source FQDNs that may resolve to either an IPv6 338 or IPv4 address, or both. Although typically both the multicast and 339 source addresses will be the same (either both IPv4 or IPv6), using 340 the wildcard for addrtype in the source filter allows asymmetry 341 between the two addresses (so an IPv4 source address may be used 342 with an IPv6 multicast address). 344 346 c=IN IP4 channel-1.example.com/127 347 c=IN IP6 channel-1.example.com/127 348 a=source-filter: incl IN * channel-1.example.com src-1.example.com 350 352 4. Interoperability Issues 354 Defining a list of legitimate sources for a multicast destination 355 address represents a departure from the Any-Source Multicast 356 (ASM) model, as originally described in [IGMPv1]. The ASM model 357 supports anonymous senders, and all types of multicast applications 358 (e.g., many-to-many). Use of a source-filter excludes some (unknown 359 or undesirable) senders, which lends itself more to one-to-many or 360 few-to-few type multicast applications. 362 Although these two models have contrasting operational 363 characteristics and requirements, they can coexist on the same 364 network using the same protocols. Use of source-filters do not 365 corrupt the ASM semantics but provide more control for receivers, 366 at their discretion. 368 5. Normative References 370 [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax 371 Specifications: ABNF," RFC 2234, November 1997. 373 [REQMNT] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels," BCP 14, RFC 2119, March 1997. 376 [RTCP-SSM] Chesterfield, J., E. Schooler, J. Ott, 377 "RTCP Extensions for Single-Source Multicast Sessions 378 with Unicast Feedback," Work in progress, March 2003. 380 [SDP] Handley, M., V. Jacobson, C. Perkins, 381 "SDP: Session Description Protocol," 382 Work in Progress, March 2003. 384 [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode 385 and ISO 10646," RFC 2044, October 1996. 387 6. Informative References 389 [CA-96.21] CERT Advisory CA-96.21, "TCP SYN Flooding and IP 390 Spoofing Attacks," September 1996. 392 [IGMPv1] Deering, S., "Host Extensions for IP Multicasting," 393 RFC 1112 (STD 5), August 1989. 395 [IGMPv3] Cain, B. et al. "Internet Group Management Protocol, 396 Version 3,", Work in progress, May 2002. 398 [MSF API] Thaler, D., B. Fenner, B. Quinn, "Socket Interface 399 Extensions for Multicast Source Filters," 400 Work in progress, July 2002. 402 [SSM] Bhattacharyya, S. et al., "An Overview of Source-Specific 403 Multicast (SSM)," Work in progress, October 2002. 405 7. Security Considerations 407 See [SDP] for security considerations specific to the Session 408 Description Protocol in general. The central issue relevant to 409 using unicast source address filters is the question of address 410 authenticity. 412 Using the source IP address for authentication is weak, since 413 addresses are often dynamically assigned and it is possible for a 414 sender to "spoof" its source address (i.e., use one other than its 415 own) in datagrams that it sends. Proper router configuration, 416 however, can reduce the likelihood of "spoofed" source addresses 417 being sent to or from a network. Specifically, border routers are 418 encouraged to filter traffic so that datagrams with invalid source 419 addresses are not forwarded (e.g., routers drop datagrams if the 420 source address is non-local) [CA-96.21]. 422 Use of FQDNs for either or values provides 423 a layer of indirection that provides great flexibility. However, it 424 also exposes the source-filter to any security inadequacies that the 425 DNS system may have. If unsecured, it is conceivable that the DNS 426 server could return illegitimate addresses. 428 8. IANA Considerations 430 As recommended by [SDP] (Appendix B), the new attribute name 431 "source-filter" should be registered with IANA, as follows: 433 The following contact information shall be used for all 434 registrations included here: 436 Contact: Ross Finlayson 437 email: finlayson (at) live.com 438 phone: +1-650-254-1184 440 SDP Attribute ("att-field"): 441 Attribute name: source-filter 442 Long form: Source Filter 443 Type of name: att-field 444 Type of attribute: Session level or media level 445 Subject to charset: No 446 Purpose: See this document 447 Reference: This document 448 Values: See this document, and registrations below 450 In addition, a new sub-registry needs to be set up for the 451 "filter-mode" values of the "source-filter" attribute, with the 452 following registrations created initially: "incl", "excl", as defined 453 in this document: 455 Source Filter Mode ("filter-mode"): 456 Value name: incl 457 Long name: Inclusion 458 Reference: This document 460 Value name: excl 461 Long name: Exclusion 462 Reference: This document 464 9. Acknowledgements 466 The authors would like to thank Dave Thaler and Mark Handley, whose 467 input provided much of the substance of this document. Magnus 468 Westerlund also provided valuable feedback during editing. 470 10. Authors' Addresses 472 Bob Quinn 473 Celox Networks 474 2 Park Central Drive 475 Southborough, MA 01772 476 phone: 508-305-7000 477 email: bquinn (at) celoxnetworks.com 479 Ross Finlayson 480 Live Networks, Inc. (LIVE.COM) 481 650 Castro St., suite 120-196 482 Mountain View, CA 94041 483 email: finlayson (at) live.com 485 11. IPR Notice 487 The IETF takes no position regarding the validity or scope of any 488 intellectual property or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; neither does it represent that it 492 has made any effort to identify any such rights. Information on the 493 IETF's procedures with respect to rights in standards-track and 494 standards-related documentation can be found in BCP-11. Copies of 495 claims of rights made available for publication and any assurances of 496 licenses to be made available, or the result of an attempt made to 497 obtain a general license or permission for the use of such 498 proprietary rights by implementors or users of this specification can 499 be obtained from the IETF Secretariat. 501 The IETF invites any interested party to bring to its attention any 502 copyrights, patents or patent applications, or other proprietary 503 rights which may cover technology that may be required to practice 504 this standard. Please address the information to the IETF Executive 505 Director. 507 12. Copyright Notice 509 Copyright (C) The Internet Society (2003). All Rights Reserved. 511 This document and translations of it may be copied and 512 furnished to others, and derivative works that comment on or 513 otherwise explain it or assist in its implementation may be 514 prepared, copied, published and distributed, in whole or in 515 part, without restriction of any kind, provided that the above 516 copyright notice and this paragraph are included on all such 517 copies and derivative works. However, this document itself may 518 not be modified in any way, such as by removing the copyright 519 notice or references to the Internet Society or other Internet 520 organizations, except as needed for the purpose of developing 521 Internet standards in which case the procedures for copyrights 522 defined in the Internet Standards process must be followed, or 523 as required to translate it into languages other than English. 525 The limited permissions granted above are perpetual and will 526 not be revoked by the Internet Society or its successors or 527 assigns. 529 This document and the information contained herein is provided 530 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 531 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 532 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 533 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 534 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 535 PARTICULAR PURPOSE. 537 Appendix A. Source-Filter Attribute Syntax 539 This appendix provides an Augmented BNF [ABNF] grammar for expressing 540 an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast 541 source addresses. It is intended as an extension to the grammar for 542 the Session Description Protocol, as defined in [SDP]. Specifically, 543 it describes the syntax for the new "source-filter" attribute field, 544 which MAY be either a session-level or media-level attribute. 546 The "connection-address" value in each source filter field MUST match 547 an existing connection-field value, unless the wildcard connection- 548 address value "*" is specified. 550 source-filter = "source-filter" ":" filter-mode filter-spec 552 filter-mode = "excl" / "incl" 553 ; either exclusion or inclusion mode 555 filter-spec = nettype address-types dest-address src-list 556 ; nettype is as defined in [SDP]. 558 address-types = "*" / addrtype 559 ; "*" for all address types (both IP4 and IP6), 560 ; but only when and 561 ; reference FQDNs. 562 ; addrtype is as defined in [SDP]. 564 dest-address = "*" / IP4-address / IP6-address / FQDN 565 ; "*" applies to all connection-address values. 566 ; IP4-address, IP6-address, FQDN are as defined 567 ; in [SDP]. 569 src-list = *(addr SP) addr 570 ; one or more unicast source addresses (in 571 ; standard IPv4 or IPv6 ASCII-notation form) 572 ; or FQDNs. 573 ; addr is as defined in [SDP]. 574 ; SP is the ASCII 'space' character 575 ; (0x20, defined in [ABNF]). 577 Expires: October 2003 April 15, 2003