draft-ietf-mmusic-sdp-srcfilter-00.txt   draft-ietf-mmusic-sdp-srcfilter-01.txt 
Internet-Draft Bob Quinn
INTERNET-DRAFT B.Quinn Celox Networks;
Stardust.com Ross Finlayson
Expires 4 November 2000 4 May 2000 LIVE.COM
Expires 1 Jan 2003 1 July 2002
SDP Source-Filters SDP Source-Filters
<draft-ietf-mmusic-sdp-srcfilter-00.txt> <draft-ietf-mmusic-sdp-srcfilter-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes how to adapt the Session Description Protocol This document describes how to adapt the Session Description Protocol
(SDP) to express one or more source addresses as a source filter for (SDP) to express one or more source addresses as a source filter for
one or more destination "connection" addresses. It defines the syntax one or more destination "connection" addresses. It defines the syntax
and semantics for an SDP "source-filter" attribute that may reference and semantics for an SDP "source-filter" attribute that may reference
either IPv4 or IPv6 address(es) as either an inclusive or exclusive either IPv4 or IPv6 address(es) as either an inclusive or exclusive
source list for either multicast or unicast destinations. 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.
Receiver applications are expected use the SDP source-filter Receiver applications are expected use the SDP source-filter
information to identify traffic from legitimate senders and discard information to identify traffic from legitimate senders and discard
traffic from illegitimate senders. Applications and hosts may also traffic from illegitimate senders. Applications and hosts may also
share the source-filter information with network elements (e.g., with share the source-filter information with network elements (e.g., with
routers using IGMPv3) so they can potentially perform the traffic routers using IGMPv3) so they can potentially perform the traffic
filtering operation further "upstream," closer to the source(s). filtering operation further "upstream," closer to the source(s).
Table of Contents
1 Introduction.................................................2
1.1 Motivation...................................................2
2 Source-filter Attribute......................................3
2.1 Processing Rules.............................................4
2.2 Examples.....................................................5
2.2.1 Source-Specific Multicast Example............................5
2.2.2 Unicast Exclusion Example....................................6
2.2.3 Multiple Session Address Example.............................6
2.2.4 Multiple Source and Destination Example......................6
2.2.5 IPv6 Multicast Source-Filter Example.........................7
2.2.6 IPv4 and IPv6 FQDN Example...................................7
3 Interoperability Issues......................................7
4 Security Considerations......................................8
5 IANA Considerations..........................................8
Acknowledgements......................................................8
Appendix A: Source-Filter Attribute Syntax............................8
References............................................................9
Author's Address.....................................................10
1 Introduction 1 Introduction
The Session Description Protocol [SDP] provides a general-purpose The Session Description Protocol [SDP] provides a general-purpose
format for describing multimedia sessions in announcements or format for describing multimedia sessions in announcements or
invitations. SDP uses an entirely textual data format (the US-ASCII invitations. SDP uses an entirely textual data format (the US-ASCII
subset of [UTF-8]) to maximize portability among transports. SDP does subset of [UTF-8]) to maximize portability among transports. SDP does
not define a protocol, but only the syntax to describe a multimedia not define a protocol, but only the syntax to describe a multimedia
session with sufficient information to discover and participate in that session with sufficient information to discover and participate in that
session. Session descriptions may be sent using any number of existing session. Session descriptions may be sent using any number of existing
application protocols for transport (e.g., SAP, SIP, RTSP, email, HTTP, application protocols for transport (e.g., SAP, SIP, RTSP, email, HTTP,
skipping to change at page 3, line 44 skipping to change at line 115
protocol independent. This document is most relevant to the value protocol independent. This document is most relevant to the value
"IN", which designates the Internet Protocol. "IN", which designates the Internet Protocol.
Second sub-field <address-types> identifies the address family and for Second sub-field <address-types> identifies the address family and for
the purpose of this document may be either <addrtype> values "IP4" or the purpose of this document may be either <addrtype> values "IP4" or
"IP6". Alternately, when <dest-address> is an FQDN, the value may be "IP6". Alternately, when <dest-address> is an FQDN, the value may be
"*" to apply to both address types, since either address may be "*" to apply to both address types, since either address may be
returned from a DNS lookup. returned from a DNS lookup.
The third sub-field <dest-address> is the destination address, which The third sub-field <dest-address> is the destination address, which
must correspond to one or more of the sessions "connection-address" 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 field values. It may be either a unicast or multicast address, an FQDN
(fully-qualified domain name), or the "*" wildcard to match any/all of (fully-qualified domain name), or the "*" wildcard to match any/all of
the sessions "connection-address" values. the session's "connection-address" values.
And the fourth sub-field <src-list> is the list of source And the fourth sub-field <src-list> is the list of source
hosts/interfaces in the source-filter, and consists of one or more hosts/interfaces in the source-filter, and consists of one or more
unicast addresses or FQDNs, separated by (email-safe) whitespace. unicast addresses or FQDNs, separated by (email-safe) whitespace.
The format and content of these semantic elements are derived from and The format and content of these semantic elements are derived from and
compatible with those defined in [SDP]. For more detail, see Appendix compatible with those defined in [SDP]. For more detail, see Appendix
A in this document. A in this document.
2.1 Processing Rules 2.1 Processing Rules
skipping to change at page 6, line 8 skipping to change at line 228
<media-description 1> <media-description 1>
This source filter example uses an inclusion list with a single This source filter example uses an inclusion list with a single
multicast "connection-address" as the destination and single unicast multicast "connection-address" as the destination and single unicast
address as the source. Note that the value of the connection-address address as the source. Note that the value of the connection-address
matches the value specified in the connection-field. matches the value specified in the connection-field.
Also note that since the connection-field is located in the session- Also note that since the connection-field is located in the session-
description section, the source-filter applies to all media. description section, the source-filter applies to all media.
Furthermore, if the SDP description specifies a RTP session
(e.g., it's "m=" line(s) specify "RTP/AVP" as the transport protocol),
then the "a=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 "a=incl:"
specification, the only possible multicast RTCP packets will be
"Sender Report" (SR) packets sent from the specified source address.
Because of this, a SDP description for a Source-Specific Multicast
(SSM) session SHOULD also include a
a=rtcp:unicast ...
attribute, as described in [RTCP-SSM]. This specifies that RTCP
"Reception Report" (RR) packets are to be sent back via unicast.
2.2.2 Unicast Exclusion Example 2.2.2 Unicast Exclusion Example
Typically an SDP session <connection-address> value is a multicast Typically, an SDP session <connection-address> value is a multicast
address, although it is also possible to use of either a unicast address, although it is also possible to use either a unicast
address or FQDN. This example illustrates a scenario whereby a session address or FQDN. This example illustrates a scenario whereby a session
description indicates the unicast source address 192.168.9.10 in an description indicates the unicast source address 192.168.9.10 in an
exclusion filter. In effect, this sample source-filter says, "host exclusion filter. In effect, this sample source-filter says, "host
192.168.10.11 destination should accept traffic from any sender 192.168.10.11 destination should accept traffic from any sender
*except* 192.168.9.10." *except* 192.168.9.10."
<session-description> <session-description>
c=IN IP4 192.168.10.11 c=IN IP4 192.168.10.11
a=excl:IN IP4 192.168.10.11 192.168.9.10 a=excl:IN IP4 192.168.10.11 192.168.9.10
skipping to change at page 7, line 43 skipping to change at line 330
c=IN IP4 Channel-1.ipmulticast.com/127 c=IN IP4 Channel-1.ipmulticast.com/127
c=IN IP6 Channel-1.ipmulticast.com/127 c=IN IP6 Channel-1.ipmulticast.com/127
a=incl:IN * Channel-1.ipmulticast.com Src-1.ipmulticast.com a=incl:IN * Channel-1.ipmulticast.com Src-1.ipmulticast.com
<media-description 1> <media-description 1>
3 Interoperability Issues 3 Interoperability Issues
Defining a list of legitimate sources for a multicast destination Defining a list of legitimate sources for a multicast destination
address represents a departure from the Internet Standard Multicast address represents a departure from the Any-Source Multicast
(ISM) model, as originally described in [IGMPv1]. The ISM model (ASM) model, as originally described in [IGMPv1]. The ASM model
supports anonymous senders, and all types of multicast applications supports anonymous senders, and all types of multicast applications
(e.g., many-to-many). Use of a source-filter excludes some (unknown or (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- undesirable) senders, which lends itself more to one-to-many or few-to-
few type multicast applications. few type multicast applications.
Although these two models have contrasting operational characteristics Although these two models have contrasting operational characteristics
and requirements, they can coexist on the same network using the same and requirements, they can coexist on the same network using the same
protocols. Use of source-filters do not corrupt the ASM semantics but
protocols. Use of source-filters do not corrupt the ISM semantics but
provide more control for receivers, at their discretion. provide more control for receivers, at their discretion.
4 Security Considerations 4 Security Considerations
See [SDP] for security other considerations specific to the Session See [SDP] for security other considerations specific to the Session
Description Protocol in general. The central issue relevant to using Description Protocol in general. The central issue relevant to using
unicast source address filters is the question of address authenticity. unicast source address filters is the question of address authenticity.
Using the source IP address for authentication is weak, since addresses Using the source IP address for authentication is weak, since addresses
are often dynamically assigned and it is possible for a sender to are often dynamically assigned and it is possible for a sender to
skipping to change at page 9, line 40 skipping to change at line 421
[CA-96.21] CERT Advisory CA-96.21, "TCP SYN Flooding and IP [CA-96.21] CERT Advisory CA-96.21, "TCP SYN Flooding and IP
Spoofing Attacks," September 1996 Spoofing Attacks," September 1996
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF," RFC 2234, November 1997 Specifications: ABNF," RFC 2234, November 1997
[IGMPv1] S. Deering, "Host Extensions for IP Multicasting," RFC [IGMPv1] S. Deering, "Host Extensions for IP Multicasting," RFC
1112 (STD 5), August 1989 1112 (STD 5), August 1989
[MSF API] D. Thaler, B. Fenner, B. Quinn, "Socket Interface [MSF API] D. Thaler, B. Fenner, B. Quinn, "Socket Interface
Extensions for Multicast Source Filters," draft-ietf- Extensions for Multicast Source Filters,"
idmr-igmpv3-api-00.txt, February 2000 Work in progress
[RTCP-SSM] J. Chesterfield, E. Schooler, J. Ott
RTCP Extensions for Single-Source Multicast Sessions
with Unicast Feedback, Work in progress, February 2002
[SDP] M. Handley, V. Jacobson, "SDP: Session Description [SDP] M. Handley, V. Jacobson, "SDP: Session Description
Protocol," RFC 2327, April 1998 Protocol," RFC 2327, April 1998
[SSM] Bhattacharyya, S. et al., "An Overview of Source-Specific
Multicast (SSM)", Work in progress, March 2002.
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646," RFC 2044, October 1996 and ISO 10646," RFC 2044, October 1996
Author's Address Authors' Addresses
Bob Quinn Bob Quinn
IP Multicast Initiative Celox Networks
Stardust.com 2 Park Central Drive
1901 S. Bascom Ave., Suite 333 Southborough, MA 01772
Campbell, CA 95008 phone: 508-305-7000
Phone: +1-408-879-8080 email: bquinn (at) celoxnetworks.com
Email: rcq@stardust.com
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Expires November 2000 Ross Finlayson
Live Networks, Inc. (LIVE.COM)
650 Castro St., suite 120-196
Mountain View, CA 94041
email: finlayson (at) live.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/