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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/