diff options
Diffstat (limited to 'doc/rfc/rfc4570.txt')
| -rw-r--r-- | doc/rfc/rfc4570.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4570.txt b/doc/rfc/rfc4570.txt new file mode 100644 index 0000000..0bc8dc3 --- /dev/null +++ b/doc/rfc/rfc4570.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group B. Quinn +Request for Comments: 4570 BoxnArrow.com +Category: Standards Track R. Finlayson + Live Networks, Inc. + July 2006 + + + Session Description Protocol (SDP) Source Filters + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes how to adapt the Session Description Protocol + (SDP) to express one or more source addresses as a source filter for + one or more destination "connection" addresses. It defines the + syntax and semantics for an SDP "source-filter" attribute that may + reference either IPv4 or IPv6 address(es) as either an inclusive or + exclusive source list for either multicast or unicast destinations. + In particular, an inclusive source-filter can be used to specify a + Source-Specific Multicast (SSM) session. + +1. Introduction + + The Session Description Protocol [SDP] provides a general purpose + format for describing multimedia sessions in announcements or + invitations. SDP uses an entirely textual data format (the US-ASCII + subset of [UTF-8]) to maximize portability among transports. SDP + does not define a protocol, but only the syntax to describe a + multimedia session with sufficient information to discover and + participate in that session. Session descriptions may be sent using + any number of existing application protocols for transport (e.g., + Session Announcement Protocol (SAP), SIP, Real Time Streaming + Protocol (RTSP), email, and HTTP). + + Typically, session descriptions reference an IP multicast address for + the "connection-address" (destination), though unicast addresses or + fully qualified domain names (FQDNs) MAY also be used. The "source- + + + +Quinn, et al. Standards Track [Page 1] + +RFC 4570 SDP Source Filters July 2006 + + + filter" attribute defined in this document qualifies the session + traffic by identifying the address (or FQDN) of legitimate sources + (senders). The intent is for receivers to use the source and + destination address pair(s) to filter traffic, so that applications + receive only legitimate session traffic. + + Receiver applications are expected to use the SDP source-filter + information to identify traffic from legitimate senders, and discard + traffic from illegitimate senders. Applications and hosts may also + share the source-filter information with network elements (e.g., with + routers using [IGMPv3]) so they can potentially perform the traffic + filtering operation further "upstream," closer to the source(s). + + The "source-filter" attribute can appear at the session level and/or + the media level. + +1.1. Motivation + + The purpose of a source-filter is to help protect receivers from + traffic sent from illegitimate source addresses. Filtering traffic + can help to preserve content integrity and protect against Denial of + Service (DoS) attacks. + + For multicast destination addresses, receiver applications MAY apply + source-filters using the Multicast Source Filter APIs [MSF-API]. + Hosts are likely to implement these APIs using protocol mechanisms to + convey the source filters to local multicast routers. Other + "upstream" multicast routers MAY apply the filters and thereby + provide more explicit multicast group management and efficient + utilization of network resources. The protocol mechanisms to enable + these operations are beyond the scope of this document, but their + potential provided motivation for SDP source-filters. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [REQMNT]. + +3. The "source-filter" Attribute + + The SDP source-filter attribute does not change any existing SDP + syntax or semantics, but defines a format for additional session + description information. Specifically, source-filter syntax can + prescribe one or more unicast addresses as either legitimate or + illegitimate sources for any (or all) SDP session description + "connection-address" field values. + + + + +Quinn, et al. Standards Track [Page 2] + +RFC 4570 SDP Source Filters July 2006 + + + Note that the unicast source addresses specified by this attribute + are those that are seen by a receiver. Therefore, if source + addresses undergo translation en route from the original sender to + the receiver - e.g., due to Network Address Translation (NAT) or some + tunneling mechanism - then the SDP "source-filter" attribute, as + presented to the receiver, will not be accurate unless the source + addresses therein are also translated accordingly. + + The source-filter attribute has the following syntax: + + a=source-filter: <filter-mode> <filter-spec> + + The <filter-mode> is either "incl" or "excl" (for inclusion or + exclusion, respectively). The <filter-spec> has four sub-components: + + <nettype> <address-types> <dest-address> <src-list> + + A <filter-mode> of "incl" means that an incoming packet is accepted + only if its source address is in the set specified by <src-list>. A + <filter-mode> of "excl" means that an incoming packet is rejected if + its source address is in the set specified by <src-list>. + + The first sub-field, <nettype>, indicates the network type, since SDP + is protocol independent. This document is most relevant to the value + "IN", which designates the Internet Protocol. + + The second sub-field, <address-types>, identifies the address family, + and for the purpose of this document may be either <addrtype> value + "IP4" or "IP6". Alternately, when <dest-address> is an FQDN, the + value MAY be "*" to apply to both address types, since either address + type can be returned from a DNS lookup. + + The third sub-field, <dest-address>, is the destination address, + which MUST correspond to one or more of the session's "connection- + address" field values. It may be either a unicast or multicast + address, an FQDN, or the "*" wildcard to match any/all of the + session's "connection-address" values. + + The fourth sub-field, <src-list>, is the list of source + hosts/interfaces in the source-filter, and consists of one or more + unicast addresses or FQDNs, separated by space characters. + + The format and content of these semantic elements are derived from + and compatible with those defined in [SDP]. For more detail, see + Appendix A of this document. + + + + + + +Quinn, et al. Standards Track [Page 3] + +RFC 4570 SDP Source Filters July 2006 + + +3.1. Processing Rules + + There are a number of details to consider when parsing the SDP + source-filter syntax. + + The <dest-address> value in a "source-filter" attribute MUST + correspond to an existing <connection-field> value in the session + description. The only exception to this is when a "*" wildcard is + used to indicate that the source-filter applies to all + <connection-field> values. + + When the <dest-address> value is a multicast address, the field value + MUST NOT include the sub-fields <ttl> and <number of addresses> from + the <connection-address> value. If the <connection-address> + specifies more than one multicast address (in the <number of + addresses> field), then a source filter, if any, for each such + address must be stated explicitly, using a separate "a=source-filter" + line for each address (unless a "*" wildcard is used for + <dest-address>). See section 3.2.4 for an example. + + When the <addrtype> value is the "*" wildcard, the <dest-address> + MUST be either an FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6 + address). See section 3.2.6 for an example. + + As has always been the case, the default behavior when a source- + filter attribute is not provided in a session description is that all + traffic sent to the specified <connection-address> value should be + accepted (i.e., from any source address). The source-filter grammar + does not include syntax to express either "exclude none" or "include + all." + + Like the standard <connection-field> described in [SDP], the location + of the "source-filter" attribute determines whether it applies to the + entire session or only to a specific medium (i.e., "session-level" or + "media-level"). A media-level source-filter will always completely + override a session-level source-filter. + + A "source-filter" need not be located at the same hierarchy level as + its corresponding <connection-field>. So, a media-level + <source-filter> can reference a session-level <connection-field> + value, and a session-level "source-filter" can be applied to all + matching media-level <connection-field> values. See section 3.2.3 + for an example. + + An SDP description MUST NOT contain more than one session-level + "source-filter" attribute that covers the same destination address, + or more than one media-level "source-filter" attribute that covers + the same destination address. + + + +Quinn, et al. Standards Track [Page 4] + +RFC 4570 SDP Source Filters July 2006 + + + There is no specified limit to the number of entries allowed in the + <src-list>; however, there are practical limits that should be + considered. For example, depending on the transport to be used for + the session description, there may be a limit to the total size of + the session description (e.g., as determined by the maximum payload + in a single datagram). Also, when the source-filter is applied to + control protocols, there may be a limit to the number of source + addresses that can be sent. These limits are outside the scope of + this document, but should be considered when defining source-filter + values for SDP. + +3.2. Examples + + Here are a number of examples that illustrate how to use the source- + filter attribute in some common scenarios. We use the following + session description components as the starting point for the examples + to follow. For each example, we show the source filter with + additional relevant information and provide a brief explanation. + + <session-description> = + v=0 + o=The King <Elvis@example.com> + s=Elvis Impersonation + i=All Elvis, all the time + u=http://www.example.com/ElvisLive/ + t=0 0 + a=recvonly + + <media-description 1> = + m=audio 54320 RTP/AVP 0 + + <media-description 2> = + m=video 54322 RTP/AVP 34 + +3.2.1. Source-Specific Multicast Example + + Multicast addresses in the Source-Specific Multicast [SSM] range + require a single unicast sender address for each multicast + destination, so the source-filter specification provides a natural + fit. In this example, a session member should receive only traffic + sent from 192.0.2.10 to the multicast session address 232.3.4.5. + + <session-description> + + c=IN IP4 232.3.4.5/127 + a=source-filter: incl IN IP4 232.3.4.5 192.0.2.10 + + <media-description 1> + + + +Quinn, et al. Standards Track [Page 5] + +RFC 4570 SDP Source Filters July 2006 + + + This source-filter example uses an inclusion list with a single + multicast "connection-address" as the destination and single unicast + address as the source. Note that the value of the connection-address + matches the value specified in the connection-field. + + Also note that since the connection-field is located in the session- + description section, the source-filter applies to all media. + + Furthermore, if the SDP description specifies an RTP session (e.g., + its "m=" line(s) specify "RTP/AVP" as the transport protocol), then + the "incl" specification will apply not only to RTP packets, but also + to any RTCP packets that are sent to the specified multicast address. + This means that, as a side effect of the "incl" specification, the + only possible multicast RTCP packets will be "Sender Report" (SR) + packets sent from the specified source address. + + Because of this, an SDP description for a Source-Specific Multicast + (SSM) RTP session SHOULD also include an + + a=rtcp-unicast ... + + attribute, as described in [RTCP-SSM] (section 10.1). This specifies + that RTCP "Reception Report" (RR) packets are to be sent back via + unicast. + +3.2.2. Unicast Exclusion Example + + Typically, an SDP session <connection-address> value is a multicast + address, although it is also possible to use either a unicast address + or FQDN. This example illustrates a scenario whereby a session + description indicates the unicast source address 192.0.2.10 in an + exclusion filter. In effect, this sample source-filter says, + "destination 192.0.2.11 should accept traffic from any sender + *except* 192.0.2.10." + + <session-description> + + c=IN IP4 192.0.2.11 + a=source-filter: excl IN IP4 192.0.2.11 192.0.2.10 + + <media-description 1> + +3.2.3. Multiple Session Address Example + + This source-filter example uses the wildcard "*" value for + <dest-addr> to correspond to any/all <connection-address> values. + Hence, the only legitimate source for traffic sent to either + + + + +Quinn, et al. Standards Track [Page 6] + +RFC 4570 SDP Source Filters July 2006 + + + 232.2.2.2 or 232.4.4.4 multicast addresses is 192.0.2.10. Traffic + sent from any other unicast source address should be discarded by the + receiver. + + <session-description> + + a=source-filter: incl IN IP4 * 192.0.2.10 + + <media-description 1> + + c=IN IP4 232.2.2.2/127 + + <media-description 2> + + c=IN IP4 232.4.4.4/63 + +3.2.4. Multiple Multicast Address Example + + In this example, the <connection-address> specifies three multicast + addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3. The first and third + of these addresses are given source filters. However, in this + example the second address - 224.2.1.2 - is *not* given a source + filter. + + <session-description> + + c=IN IP4 224.2.1.1/127/3 + a=source-filter: incl IN IP4 224.2.1.1 192.0.2.10 + a=source-filter: incl IN IP4 224.2.1.3 192.0.2.42 + + <media-description 1> + +3.2.5. IPv6 Multicast Source-Filter Example + + This simple example defines a single session-level source-filter that + references a single IPv6 multicast destination and source pair. The + IP multicast traffic sent to FFOE::11A is valid only from the unicast + source address 2001:DB8:1:2:240:96FF:FE25:8EC9. + + <session-description> + + c=IN IP6 FF0E::11A/127 + a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9 + + <media-description 1> + + + + + + +Quinn, et al. Standards Track [Page 7] + +RFC 4570 SDP Source Filters July 2006 + + +3.2.6. IPv4 and IPv6 FQDN Example + + This example illustrates use of the <addrtype> "*" wildcard, along + with multicast and source FQDNs that may resolve to either an IPv6 or + IPv4 address, or both. Although typically both the multicast and + source addresses will be the same (either both IPv4 or both IPv6), + using the wildcard for addrtype in the source filter allows asymmetry + between the two addresses (so an IPv4 source address may be used with + an IPv6 multicast address). + + <session-description> + + c=IN IP4 channel-1.example.com/127 + c=IN IP6 channel-1.example.com/127 + a=source-filter: incl IN * channel-1.example.com src-1.example.com + + <media-description 1> + +3.3. Offer-Answer Model Considerations + + The "source-filter" attribute is not intended to be used as an + 'offer' in an SDP offer-answer exchange [OFFER], because sets of + source addresses do not represent 'capabilities' or 'limitations' of + the offerer, and because the offerer does not, in general, have a + priori knowledge of which IP source address(es) will be included in + an answer. While an answerer may include the "source-filter" + attribute in his/her answer (e.g., to designate a SSM session), the + answerer SHOULD ignore any "source-filter" attribute that was present + in the original offer. + +4. Interoperability Issues + + Defining a list of legitimate sources for a multicast destination + address represents a departure from the Any-Source Multicast (ASM) + model, as originally described in [IGMPv1]. The ASM model supports + anonymous senders and all types of multicast applications (e.g., + many-to-many). Use of a source-filter excludes some (unknown or + undesirable) senders, which lends itself more to one-to-many or few- + to-few type multicast applications. + + Although these two models have contrasting operational + characteristics and requirements, they can coexist on the same + network using the same protocols. Use of source-filters do not + corrupt the ASM semantics but provide more control for receivers, at + their discretion. + + + + + + +Quinn, et al. Standards Track [Page 8] + +RFC 4570 SDP Source Filters July 2006 + + +5. Security Considerations + + See [SDP] for security considerations specific to the Session + Description Protocol in general. The central issue relevant to using + source address filters is the question of address authenticity. + + Using the source IP address for authentication is weak, since + addresses are often dynamically assigned and it is possible for a + sender to "spoof" its source address (i.e., use one other than its + own) in datagrams that it sends. Proper router configuration, + however, can reduce the likelihood of "spoofed" source addresses + being sent to or from a network. Specifically, border routers are + encouraged to filter traffic so that datagrams with invalid source + addresses are not forwarded (e.g., routers drop datagrams if the + source address is non-local) [FILTERING]. This, however, does not + prevent IP source addresses from being spoofed on a Local Area + Network (LAN). + + Also, as noted in section 3 above, tunneling or NAT mechanisms may + require corresponding translation of the addresses specified in the + SDP "source-filter" attribute, and furthermore, may cause a set of + original source addresses to be translated to a smaller set of source + addresses as seen by the receiver. + + Use of FQDNs for either <dest-address> or <src-list> values provides + a layer of indirection that provides great flexibility. However, it + also exposes the source-filter to any security inadequacies that the + DNS system may have. If unsecured, it is conceivable that the DNS + server could return illegitimate addresses. + + In addition, if source-filtering is implemented by sharing the + source-filter information with network elements, then the security of + the protocol(s) that are used for this (e.g., [IGMPv3]) becomes + important, to ensure that legitimate traffic (and only legitimate + traffic) is received. + + For these reasons, receivers SHOULD NOT treat the SDP "source-filter" + attribute as being its sole mechanism for protecting the integrity of + received content. + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 9] + +RFC 4570 SDP Source Filters July 2006 + + +6. IANA Considerations + + As recommended by [SDP] (Appendix B), the new attribute name + "source-filter" has been registered with IANA, as follows: + + The following contact information shall be used for all registrations + included here: + + Contact: Ross Finlayson + email: finlayson (at) live555.com + phone: +1-650-254-1184 + + SDP Attribute ("att-field"): + Attribute name: source-filter + Long form: Source Filter + Type of name: att-field + Type of attribute: Session level or media level + Subject to charset: No + Purpose: See this document + Reference: This document + Values: See this document, and registrations below + +7. Acknowledgements + + The authors would like to thank Dave Thaler and Mark Handley, whose + input provided much of the substance of this document. Magnus + Westerlund also provided valuable feedback during editing. + +8. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October 2005. + + [REQMNT] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + + + + + + + + + +Quinn, et al. Standards Track [Page 10] + +RFC 4570 SDP Source Filters July 2006 + + +9. Informative References + + [FILTERING] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP + Source Address Spoofing", BCP 38, RFC 2827, May 2000. + + [IGMPv1] Deering, S., "Host extensions for IP multicasting", STD + 5, RFC 1112, August 1989. + + [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. + + [MSF-API] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface + Extensions for Multicast Source Filters", RFC 3678, + January 2004. + + [OFFER] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, June + 2002. + + [RTCP-SSM] Chesterfield, J., E. Schooler, J. Ott, "RTCP Extensions + for Single-Source Multicast Sessions with Unicast + Feedback", Work in Progress, October 2004. + + [SSM] Bhattacharyya, S., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + + + + + + + + + + + + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 11] + +RFC 4570 SDP Source Filters July 2006 + + +Appendix A. Source-Filter Attribute Syntax + + This appendix provides an Augmented BNF [ABNF] grammar for expressing + an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast + source addresses. It is intended as an extension to the grammar for + the Session Description Protocol, as defined in [SDP]. Specifically, + it describes the syntax for the new "source-filter" attribute field, + which MAY be either a session-level or media-level attribute. + + The "dest-address" value in each source-filter field MUST match an + existing connection-field value, unless the wildcard connection- + address value "*" is specified. + + source-filter = "source-filter" ":" SP filter-mode SP filter-spec + ; SP is the ASCII 'space' character + ; (0x20, defined in [ABNF]). + + filter-mode = "excl" / "incl" + ; either exclusion or inclusion mode. + + filter-spec = nettype SP address-types SP dest-address SP src-list + ; nettype is as defined in [SDP]. + + address-types = "*" / addrtype + ; "*" for all address types (both IP4 and IP6), + ; but only when <dest-address> and <src-list> + ; reference FQDNs. + ; addrtype is as defined in [SDP]. + + dest-address = "*" / basic-multicast-address / unicast-address + ; "*" applies to all connection-address values. + ; unicast-address is as defined in [SDP]. + + src-list = *(unicast-address SP) unicast-address + ; one or more unicast source addresses (in + ; standard IPv4 or IPv6 ASCII-notation form) + ; or FQDNs. + ; unicast-address is as defined in [SDP]. + + basic-multicast-address = basic-IP4-multicast / basic-IP6-multicast + / FQDN / extn-addr + ; i.e., the same as multicast-address + ; defined in [SDP], except that the + ; /<ttl> and /<number of addresses> + ; fields are not included. + ; FQDN and extn-addr are as defined + ; in [SDP]. + + + + +Quinn, et al. Standards Track [Page 12] + +RFC 4570 SDP Source Filters July 2006 + + + basic-IP4-multicast = m1 3( "." decimal-uchar ) + ; m1 and decimal-uchar are as defined + ; in [SDP]. + + basic-IP6-multicast = hexpart + ; hexpart is as defined in [SDP]. + +Authors' Addresses + + Bob Quinn + BoxnArrow.com + 31 Caldwell Road + Waltham, MA 02453 + + Phone: +1-781-577-1539 + EMail: rcq@boxnarrow.com + + + Ross Finlayson + Live Networks, Inc. + 650 Castro St., suite 120-196 + Mountain View, CA 94041 + + EMail: finlayson@live555.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Quinn, et al. Standards Track [Page 13] + +RFC 4570 SDP Source Filters July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Quinn, et al. Standards Track [Page 14] + |