draft-ietf-mmusic-sdp-srcfilter-03.txt   draft-ietf-mmusic-sdp-srcfilter-04.txt 
INTERNET-DRAFT Bob Quinn Network Working Group Bob Quinn
Celox Networks; INTERNET-DRAFT Celox Networks
Ross Finlayson Category: Standards Track Ross Finlayson
LIVE.COM Expires: October 2003 LIVE.COM
Expires 15 August 2003 15 February 2003 April 15, 2003
Session Description Protocol (SDP) Source Filters Session Description Protocol (SDP) Source Filters
<draft-ietf-mmusic-sdp-srcfilter-03.txt> <draft-ietf-mmusic-sdp-srcfilter-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all 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
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Copyright Notice
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [REQMNT]. Copyright (C) The Internet Society (2003). All Rights Reserved.
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
and semantics for an SDP "source-filter" attribute that may reference syntax and semantics for an SDP "source-filter" attribute that may
either IPv4 or IPv6 address(es) as either an inclusive or exclusive reference either IPv4 or IPv6 address(es) as either an inclusive or
source list for either multicast or unicast destinations. In particular, exclusive source list for either multicast or unicast destinations.
an inclusive source-filter can be used to specify a Source-Specific In particular, an inclusive source-filter can be used to specify a
Multicast (SSM) session. Source-Specific Multicast (SSM) session.
Receiver applications are expected use the SDP source-filter 1. Terminology
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).
1 Introduction 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].
2. 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.
not define a protocol, but only the syntax to describe a multimedia SDP does not define a protocol, but only the syntax to describe a
session with sufficient information to discover and participate in that multimedia session with sufficient information to discover and
session. Session descriptions may be sent using any number of existing participate in that session. Session descriptions may be sent using
application protocols for transport (e.g., SAP, SIP, RTSP, email, HTTP, any number of existing application protocols for transport
etc.). (e.g., SAP, SIP, RTSP, email, HTTP, etc.).
Typically, session descriptions reference an IP multicast address for Typically, session descriptions reference an IP multicast address for
the "connection-address" (destination), though unicast addresses or the "connection-address" (destination), though unicast addresses or
fully qualified domain names (FQDNs) MAY also be used. The "source- fully qualified domain names (FQDNs) MAY also be used. The "source-
filter" attribute defined in this document defines qualifies the session filter" attribute defined in this document qualifies the session
traffic by identifying the address (or FQDN) of legitimate source(s) traffic by identifying the address (or FQDN) of legitimate source(s)
(senders). The intent is for receivers to use the source and (senders). The intent is for receivers to use the source and
destination address pair(s) to filter traffic, so applications receive destination address pair(s) to filter traffic, so that applications
only legitimate session traffic. receive only legitimate session traffic.
1.1 Motivation 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.
2.1. Motivation
The purpose of a source-filter is to help protect receivers from The purpose of a source-filter is to help protect receivers from
traffic sent from illegitimate source addresses. Filtering traffic can traffic sent from illegitimate source addresses. Filtering traffic
help to preserve content integrity and protect against denial of can help to preserve content integrity and protect against denial of
service (DoS) attacks. service (DoS) attacks.
For multicast destination addresses, receiver applications MAY apply For multicast destination addresses, receiver applications MAY apply
source-filters using the Multicast Source Filter APIs [MSF API]. Hosts source-filters using the Multicast Source Filter APIs [MSF API].
are likely to implement these APIs using protocol mechanisms to convey Hosts are likely to implement these APIs using protocol mechanisms to
the source filters to local multicast routers. Other "upstream" convey the source filters to local multicast routers. Other
multicast routers MAY apply the filters and thereby provide more "upstream" multicast routers MAY apply the filters and thereby
explicit multicast group management and efficient utilization of provide more explicit multicast group management and efficient
network resources. The protocol mechanisms to enable these operations utilization of network resources. The protocol mechanisms to enable
are beyond the scope of this document, but their potential provided these operations are beyond the scope of this document, but their
motivation for SDP source-filters. potential provided motivation for SDP source-filters.
2 The "source-filter" Attribute 3. The "source-filter" Attribute
The SDP source-filter attribute does not change any existing SDP syntax The SDP source-filter attribute does not change any existing SDP
or semantics, but defines a format for additional session description syntax or semantics, but defines a format for additional session
information. Specifically, source-filter syntax can prescribe one or description information. Specifically, source-filter syntax can
more unicast addresses as either legitimate or illegitimate sources for prescribe one or more unicast addresses as either legitimate or
any (or all) SDP session description "connection-address" field values. illegitimate sources for any (or all) SDP session description
"connection-address" field values.
The source-filter attribute has the following syntax: The source-filter attribute has the following syntax:
a=source-filter: <filter-mode> <filter-spec> a=source-filter: <filter-mode> <filter-spec>
The <filter-mode> is either "incl" or "excl" (for inclusion or The <filter-mode> is either "incl" or "excl" (for inclusion or
exclusion, respectively). The <filter-spec> has four sub-components: exclusion, respectively). The <filter-spec> has four sub-components:
<nettype> <address-types> <dest-address> <src-list> <nettype> <address-types> <dest-address> <src-list>
A <filter-mode> of "incl" means that an incoming packet is accepted 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>. 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 A <filter-mode> of "excl" means that an incoming packet is rejected
if its source address is in the set specified by <src-list>. if its source address is in the set specified by <src-list>.
The first sub-field <nettype> indicates the network type, since SDP is The first sub-field <nettype> indicates the network type, since SDP
protocol independent. This document is most relevant to the value is 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 The second sub-field <address-types> identifies the address family,
the purpose of this document may be either <addrtype> values "IP4" or and for the purpose of this document may be either <addrtype> value
"IP6". Alternately, when <dest-address> is an FQDN, the value MAY be "IP4" or "IP6". Alternately, when <dest-address> is an FQDN
"*" to apply to both address types, since either address can be (fully-qualified domain name), the value MAY be "*" to apply to both
returned from a DNS lookup. 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 third sub-field <dest-address> is the destination address, which
MUST correspond to one or more of the session's "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,
(fully-qualified domain name), or the "*" wildcard to match any/all of a FQDN, or the "*" wildcard to match any/all of the session's
the session's "connection-address" values. "connection-address" values.
The fourth sub-field <src-list> is the list of source 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 space characters. unicast addresses or FQDNs, separated by space characters.
The format and content of these semantic elements are derived from and The format and content of these semantic elements are derived from
compatible with those defined in [SDP]. For more detail, see Appendix and compatible with those defined in [SDP]. For more detail, see
A in this document. Appendix A of this document.
2.1 Processing Rules 3.1. Processing Rules
There are a number of details to consider when parsing the SDP source- There are a number of details to consider when parsing the SDP
filter syntax. source-filter syntax.
The <dest-address> value in a "source-filter" attribute MUST correspond The <dest-address> value in a "source-filter" attribute MUST
to an existing <connection-field> value in the session description. correspond to an existing <connection-field> value in the session
The only exception to this is when a "*" wildcard is used to indicate description. The only exception to this is when a "*" wildcard is
that the source-filter applies to all <connection-field> values. 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 When the <dest-address> value is a multicast address, the field value
MUST NOT include the sub-fields <ttl> and <number of addresses> from MUST NOT include the sub-fields <ttl> and <number of addresses> from
the <connection-address> value. The <number of addresses> is implied, the <connection-address> value. If the <connection-address>
and all unicast addresses in the <src-list> are valid sources for any specifies more than one multicast address (in the
of the multicast addresses in the address series implied by the <number <number of addresses> field), then a source filter, if any, for each
of addresses>. 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 When the <addrtype> value is the "*" wildcard, the <dest-address>
be either an FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6 MUST be either a FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6
address). See section 2.2.5 for an example. address). See section 3.2.6 for an example.
As has always been the case, the default behavior when a source-filter As has always been the case, the default behavior when a
attribute is not provided in a session description is that all traffic source-filter attribute is not provided in a session description is
sent to the specified <connection-address> value should be accepted that all traffic sent to the specified <connection-address> value
(i.e., from any source address). The source-filter grammar does not should be accepted (i.e., from any source address). The
include syntax to express either "exclude none" or "include all." 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 Like the standard <connection-field> described in [SDP], the location
of the "source-filter" attribute determines whether it applies to the of the "source-filter" attribute determines whether it applies to the
entire session or only to a specific medium (i.e., "session-level" or entire session or only to a specific medium (i.e., "session-level" or
"media-level"). A media-level source-filter will always completely "media-level"). A media-level source-filter will always completely
override a session-level source-filter. override a session-level source-filter.
A "source-filter" need not be located at the same hierarchy level as A "source-filter" need not be located at the same hierarchy level as
its corresponding <connection-field>. So, a media-level <source- its corresponding <connection-field>. So, a media-level <source-
filter> can reference a session-level <connection-field> value, and a filter> can reference a session-level <connection-field> value, and a
session-level "source-filter" can be applied to all matching media- session-level "source-filter" can be applied to all matching media-
level <connection-field> values. See section 2.2.3 for an example. level <connection-field> values. See section 3.2.3 for an example.
A SDP description MUST NOT contain more than one session-level An SDP description MUST NOT contain more than one session-level
"source-filter" attribute, nor more than one media-level "source-filter" attribute, nor more than one media-level
"source-filter" attribute for the same medium. "source-filter" attribute for the same medium.
There is no specified limit to the number of entries allowed in the There is no specified limit to the number of entries allowed in the
<src-list>, however there are practical limits that should be <src-list>, however there are practical limits that should be
considered. For example, depending on the transport to be used for the considered. For example, depending on the transport to be used for
session description, there may be a limit to the total size of the the session description, there may be a limit to the total size of
session description (e.g., as determined by the maximum payload in a the session description (e.g., as determined by the maximum payload
single datagram). Also, when the source-filter is applied to control in a single datagram). Also, when the source-filter is applied to
protocols, there may be a limit to the number of source addresses that control protocols, there may be a limit to the number of source
can be sent. These limits are outside the scope of this document, but addresses that can be sent. These limits are outside the scope of
should be considered when defining source-filter values for SDP. this document, but should be considered when defining source-filter
values for SDP.
2.2 Examples 3.2. Examples
Here are a number of examples that illustrate how to use the source- Here are a number of examples that illustrate how to use the source-
filter attribute in some common scenarios. We use the following filter attribute in some common scenarios. We use the following
session description components as the starting point for the examples session description components as the starting point for the examples
to follow. For each example, we show the source filter with additional to follow. For each example, we show the source filter with
relevant information, and provide a brief explanation. additional relevant information, and provide a brief explanation.
<session-description> = <session-description> =
v=0 v=0
o=The King <Elvis@example.com> o=The King <Elvis@example.com>
s=Elvis Impersonation s=Elvis Impersonation
i=All Elvis, all the time i=All Elvis, all the time
u=http://www.example.com/ElvisLive/ u=http://www.example.com/ElvisLive/
t=0 0 t=0 0
a=recvonly a=recvonly
<media-description 1> = <media-description 1> =
m=audio 54320 RTP/AVP 0 m=audio 54320 RTP/AVP 0
<media-description 2> = <media-description 2> =
m=video 54322 RTP/AVP 34 m=video 54322 RTP/AVP 34
2.2.1 Source-Specific Multicast Example 3.2.1. Source-Specific Multicast Example
Multicast addresses in the Source-Specific Multicast [SSM] range Multicast addresses in the Source-Specific Multicast [SSM] range
require a single unicast sender address for each multicast destination, require a single unicast sender address for each multicast
so the source-filter specification provides a natural fit. In this destination, so the source-filter specification provides a natural
example, a session member should receive only traffic sent from fit. In this example, a session member should receive only traffic
192.168.9.10 to the multicast session address 232.3.4.5. sent from 192.168.9.10 to the multicast session address 232.3.4.5.
<session-description> <session-description>
c=IN IP4 232.3.4.5/127 c=IN IP4 232.3.4.5/127
a=source-filter: incl IN IP4 232.3.4.5 192.168.9.10 a=source-filter: incl IN IP4 232.3.4.5 192.168.9.10
<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
skipping to change at line 243 skipping to change at line 259
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 Furthermore, if the SDP description specifies a RTP session
(e.g., its "m=" line(s) specify "RTP/AVP" as the transport protocol), (e.g., its "m=" line(s) specify "RTP/AVP" as the transport protocol),
then the "incl" specification will apply not only to RTP packets, then the "incl" specification will apply not only to RTP packets,
but also to any RTCP packets that are sent to the specified multicast but also to any RTCP packets that are sent to the specified multicast
address. This means that, as a side effect of the "incl" address. This means that, as a side effect of the "incl"
specification, the only possible multicast RTCP packets will be specification, the only possible multicast RTCP packets will be
"Sender Report" (SR) packets sent from the specified source address. "Sender Report" (SR) packets sent from the specified source address.
Because of this, a SDP description for a Source-Specific Multicast Because of this, an SDP description for a Source-Specific Multicast
(SSM) RTP session SHOULD also include a (SSM) RTP session SHOULD also include a
a=rtcp:unicast ... a=rtcp:unicast ...
attribute, as described in [RTCP-SSM]. This specifies that RTCP attribute, as described in [RTCP-SSM] (section 10.1). This specifies
"Reception Report" (RR) packets are to be sent back via unicast. that RTCP "Reception Report" (RR) packets are to be sent back via
unicast.
2.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 or FQDN. This example illustrates a scenario whereby a session address or FQDN. This example illustrates a scenario whereby a
description indicates the unicast source address 192.168.9.10 in an session description indicates the unicast source address 192.168.9.10
exclusion filter. In effect, this sample source-filter says, "host in an exclusion filter. In effect, this sample source-filter says,
192.168.10.11 destination should accept traffic from any sender "destination 192.168.10.11 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=source-filter: excl IN IP4 192.168.10.11 192.168.9.10 a=source-filter: excl IN IP4 192.168.10.11 192.168.9.10
<media-description 1> <media-description 1>
2.2.3 Multiple Session Address Example 3.2.3. Multiple Session Address Example
This source-filter example uses the wildcard "*" value for <dest-addr> This source-filter example uses the wildcard "*" value for
to correspond to any/all <connection-address> values. Hence, the only <dest-addr> to correspond to any/all <connection-address> values.
legitimate source for traffic sent to either 232.2.2.2 or 232.4.4.4 Hence, the only legitimate source for traffic sent to either
multicast addresses is 192.168.9.10. Traffic sent from any other 232.2.2.2 or 232.4.4.4 multicast addresses is 192.168.9.10.
unicast source address should be discarded by the receiver. Traffic sent from any other unicast source address should be
discarded by the receiver.
<session-description> <session-description>
a=source-filter: incl IN IP4 * 192.168.9.10 a=source-filter: incl IN IP4 * 192.168.9.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
2.2.4 IPv6 Multicast Source-Filter Example 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.168.9.10
a=source-filter: incl IN IP4 224.2.1.3 192.168.9.42
<media-description 1>
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 IP references a single IPv6 multicast destination and source pair. The
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:210:1:2:240:96FF:FE25:8EC9 source address 2001:210: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:210:1:2:240:96FF:FE25:8EC9 a=source-filter incl IN IP6 FF0E::11A 2001:210:1:2:240:96FF:FE25:8EC9
<media-description 1> <media-description 1>
2.2.5 IPv4 and IPv6 FQDN Example 3.2.6. IPv4 and IPv6 FQDN Example
This example illustrates use of the <addrtype> "*" wildcard, along with This example illustrates use of the <addrtype> "*" wildcard, along
multicast and source FQDNs that may resolve to either an IPv6 or IPv4 with multicast and source FQDNs that may resolve to either an IPv6
address, or both. Although typically both the multicast and source or IPv4 address, or both. Although typically both the multicast and
addresses will be the same (either both IPv4 or IPv6), using the source addresses will be the same (either both IPv4 or IPv6), using
wildcard for addrtype in the source filter allows asymmetry between the the wildcard for addrtype in the source filter allows asymmetry
two addresses (so an IPv4 source address may be used with an IPv6 between the two addresses (so an IPv4 source address may be used
multicast address). with 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 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) model, as originally described in [IGMPv1]. The ASM 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
undesirable) senders, which lends itself more to one-to-many or few-to- or undesirable) senders, which lends itself more to one-to-many or
few type multicast applications. few-to-few type multicast applications.
Although these two models have contrasting operational characteristics Although these two models have contrasting operational
and requirements, they can coexist on the same network using the same characteristics and requirements, they can coexist on the same
protocols. Use of source-filters do not corrupt the ASM semantics but network using the same protocols. Use of source-filters do not
provide more control for receivers, at their discretion. corrupt the ASM semantics but provide more control for receivers,
at their discretion.
4 Normative References 5. Normative References
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF," RFC 2234, November 1997 Specifications: ABNF," RFC 2234, November 1997.
[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] J. Chesterfield, et al. [RTCP-SSM] Chesterfield, J., E. Schooler, J. Ott,
"RTCP Extensions for Single-Source Multicast Sessions "RTCP Extensions for Single-Source Multicast Sessions
with Unicast Feedback," Work in progress, November 2002 with Unicast Feedback," Work in progress, March 2003.
[SDP] M. Handley, V. Jacobson, "SDP: Session Description [SDP] Handley, M., V. Jacobson, C. Perkins,
Protocol," RFC 2327, April 1998 "SDP: Session Description Protocol,"
Work in Progress, March 2003.
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode
and ISO 10646," RFC 2044, October 1996 and ISO 10646," RFC 2044, October 1996.
5 Informative References 6. Informative References
[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.
[IGMPv1] S. Deering, "Host Extensions for IP Multicasting," RFC [IGMPv1] Deering, S., "Host Extensions for IP Multicasting,"
1112 (STD 5), August 1989 RFC 1112 (STD 5), August 1989.
[IGMPv3] B. Cain et al. "Internet Group Management Protocol, [IGMPv3] Cain, B. et al. "Internet Group Management Protocol,
Version 3,", Work in progress, May 2002. Version 3,", Work in progress, May 2002.
[MSF API] D. Thaler, B. Fenner, B. Quinn, "Socket Interface [MSF API] Thaler, D., B. Fenner, B. Quinn, "Socket Interface
Extensions for Multicast Source Filters," Extensions for Multicast Source Filters,"
Work in progress, July 2002. Work in progress, July 2002.
[SSM] Bhattacharyya, S. et al., "An Overview of Source-Specific [SSM] Bhattacharyya, S. et al., "An Overview of Source-Specific
Multicast (SSM)", Work in progress, October 2002. Multicast (SSM)," Work in progress, October 2002.
6 Security Considerations 7. 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 using Description Protocol in general. The central issue relevant to
unicast source address filters is the question of address authenticity. using 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
are often dynamically assigned and it is possible for a sender to addresses are often dynamically assigned and it is possible for a
"spoof" its source address (use one other than its own) in datagrams sender to "spoof" its source address (i.e., use one other than its
it sends. Proper router configuration can reduce the likelihood of own) in datagrams that it sends. Proper router configuration,
"spoofed" source addresses being sent to or from a network, however. however, can reduce the likelihood of "spoofed" source addresses
Specifically, border routers are encouraged to filter traffic so being sent to or from a network. Specifically, border routers are
datagrams with invalid source addresses are not forwarded (e.g., encouraged to filter traffic so that datagrams with invalid source
routers drop datagrams if the source address is non-local) [CA-96.21]. addresses are not forwarded (e.g., routers drop datagrams if the
source address is non-local) [CA-96.21].
Use of FQDNs for either <dest-address> or <src-list> values provides a Use of FQDNs for either <dest-address> or <src-list> values provides
layer of indirection that provides great flexibility. However, it also a layer of indirection that provides great flexibility. However, it
exposes the source-filter to any security inadequacies that the DNS also exposes the source-filter to any security inadequacies that the
system may have (if any). 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.
7 IANA Considerations 8. IANA Considerations
As recommended by [SDP] (in Appendix B), the new "source-filter" As recommended by [SDP] (Appendix B), the new attribute name
attribute described in this document should be registered with IANA. "source-filter" should be registered with IANA, as follows:
8 Acknowledgements The following contact information shall be used for all
registrations included here:
Contact: Ross Finlayson
email: finlayson (at) live.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
In addition, a new sub-registry needs to be set up for the
"filter-mode" values of the "source-filter" attribute, with the
following registrations created initially: "incl", "excl", as defined
in this document:
Source Filter Mode ("filter-mode"):
Value name: incl
Long name: Inclusion
Reference: This document
Value name: excl
Long name: Exclusion
Reference: This document
9. 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. Also, input provided much of the substance of this document. Magnus
Magnus Westerlund provided valuable feedback during editing. Westerlund also provided valuable feedback during editing.
9 Authors' Addresses 10. Authors' Addresses
Bob Quinn Bob Quinn
Celox Networks Celox Networks
2 Park Central Drive 2 Park Central Drive
Southborough, MA 01772 Southborough, MA 01772
phone: 508-305-7000 phone: 508-305-7000
email: bquinn (at) celoxnetworks.com email: bquinn (at) celoxnetworks.com
Ross Finlayson Ross Finlayson
Live Networks, Inc. (LIVE.COM) Live Networks, Inc. (LIVE.COM)
650 Castro St., suite 120-196 650 Castro St., suite 120-196
Mountain View, CA 94041 Mountain View, CA 94041
email: finlayson (at) live.com email: finlayson (at) live.com
Appendix A: Source-Filter Attribute Syntax 11. IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Copyright Notice
Copyright (C) The Internet Society (2003). 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.
Appendix A. Source-Filter Attribute Syntax
This appendix provides an Augmented BNF [ABNF] grammar for expressing This appendix provides an Augmented BNF [ABNF] grammar for expressing
an exclusion or inclusion list of one or more (IPv4 or IPv6) unicast 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 source addresses. It is intended as an extension to the grammar for
the Session Description Protocol, as defined in [SDP]. Specifically, the Session Description Protocol, as defined in [SDP]. Specifically,
it describes the syntax for the new "source-filter" attribute field, it describes the syntax for the new "source-filter" attribute field,
which MAY be either a session-level or media-level attribute. which MAY be either a session-level or media-level attribute.
The "connection-address" value in each source filter field MUST match The "connection-address" value in each source filter field MUST match
an existing connection-field value, unless the wildcard connection- an existing connection-field value, unless the wildcard connection-
address value "*" is specified. address value "*" is specified.
source-filter = "source-filter" ":" filter-mode filter-spec source-filter = "source-filter" ":" filter-mode filter-spec
filter-mode = "excl" | "incl" filter-mode = "excl" / "incl"
; either exclusion or inclusion mode ; either exclusion or inclusion mode
filter-spec = nettype address-types dest-address src-list filter-spec = nettype address-types dest-address src-list
; nettype is as defined in [SDP]. ; nettype is as defined in [SDP].
address-types = "*" | addrtype address-types = "*" / addrtype
; "*" for all address types (both IP4 and IP6), ; "*" for all address types (both IP4 and IP6),
; but only when <dest-address> and <src-list> ; but only when <dest-address> and <src-list>
; reference FQDNs. ; reference FQDNs.
; addrtype is as defined in [SDP]. ; addrtype is as defined in [SDP].
dest-address = "*" | IP4-address | IP6-address | FQDN dest-address = "*" / IP4-address / IP6-address / FQDN
; "*" applies to all connection-address values. ; "*" applies to all connection-address values.
; IP4-address, IP6-address, FQDN are as defined ; IP4-address, IP6-address, FQDN are as defined
; in [SDP]. ; in [SDP].
src-list = *(addr SP) addr src-list = *(addr SP) addr
; one or more unicast source addresses (in standard ; one or more unicast source addresses (in
; IPv4 or IPv6 ASCII-notation form) or FQDNs. ; standard IPv4 or IPv6 ASCII-notation form)
; SP is the ASCII 'space' character (0x20). ; or FQDNs.
; addr is as defined in [SDP]. ; addr is as defined in [SDP].
; SP is the ASCII 'space' character
; (0x20, defined in [ABNF]).
Expires 15 August 2003 15 February 2003 Expires: October 2003 April 15, 2003
 End of changes. 

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