draft-ietf-mmusic-sdp-srcfilter-05.txt   draft-ietf-mmusic-sdp-srcfilter-06.txt 
Network Working Group Bob Quinn Network Working Group Bob Quinn
INTERNET-DRAFT Celox Networks INTERNET-DRAFT Celox Networks
Category: Standards Track Ross Finlayson Category: Standards Track Ross Finlayson
Expires: November 2003 LIVE.COM Expires: January 2005 LIVE.COM
May 15, 2003 July 18, 2004
Session Description Protocol (SDP) Source Filters Session Description Protocol (SDP) Source Filters
<draft-ietf-mmusic-sdp-srcfilter-05.txt> <draft-ietf-mmusic-sdp-srcfilter-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups 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 time. It is inappropriate to use Internet-Drafts as reference
material or 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
Copyright Notice
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 one or more destination "connection" addresses. It defines the
syntax and semantics for an SDP "source-filter" attribute that may syntax and semantics for an SDP "source-filter" attribute that may
reference either IPv4 or IPv6 address(es) as either an inclusive or reference either IPv4 or IPv6 address(es) as either an inclusive or
exclusive source list for either multicast or unicast destinations. exclusive source list for either multicast or unicast destinations.
In particular, an inclusive source-filter can be used to specify a In particular, an inclusive source-filter can be used to specify a
Source-Specific Multicast (SSM) session. Source-Specific Multicast (SSM) session.
skipping to change at line 108 skipping to change at line 106
3. The "source-filter" Attribute 3. The "source-filter" Attribute
The SDP source-filter attribute does not change any existing SDP The SDP source-filter attribute does not change any existing SDP
syntax or semantics, but defines a format for additional session syntax or semantics, but defines a format for additional session
description information. Specifically, source-filter syntax can description information. Specifically, source-filter syntax can
prescribe one or more unicast addresses as either legitimate or prescribe one or more unicast addresses as either legitimate or
illegitimate sources for any (or all) SDP session description illegitimate sources for any (or all) SDP session description
"connection-address" field values. "connection-address" field values.
Note that the unicast source addresses specified by this attribute
are those that are seen by a receiver. 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 - MUST be translated accordingly.
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
skipping to change at line 352 skipping to change at line 357
with an IPv6 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.3 Offer-Answer Model Considerations
The "source-filter" attribute is not intended to be used as an
'offer' in a SDP offer-answer exchange [OFFER], because sets of
source addresses do not represent 'capabilities' or 'limitations'
of the offerer, and because the offerer does not, in general, have
'a priori' knowledge of which IP source address(es) will be included
in an answer. While an answerer may include the "source-filter"
attribute in his answer (e.g., to designate a SSM session), he SHOULD
ignore any "source-filter" attribute that was present 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) 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 (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 or undesirable) senders, which lends itself more to one-to-many or
few-to-few type multicast applications. few-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 their discretion. at 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 unicast source address filters is the question of address using 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) [CA-96.21]. source address is non-local) [CA-96.21]. This, however, does not
prevent IP source addresses from being spoofed on a LAN.
Also, as noted in section 3 above, tunneling or NAT mechanisms
may require corresponding translation of the addresses specified in
the SDP "source-filter" attribute, and furthermore, may cause a set
of original source addresses to be translated to a smaller set of
source addresses as seen by the receiver.
Use of FQDNs for either <dest-address> or <src-list> values provides 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.
For these reasons, receivers SHOULD NOT treat the SDP "source-filter"
attribute as being its sole mechanism for protecting the integrity
of 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" should be registered with IANA, as follows:
The following contact information shall be used for all The following contact information shall be used for all
registrations included here: registrations included here:
Contact: Ross Finlayson Contact: Ross Finlayson
email: finlayson (at) live.com email: finlayson (at) live.com
skipping to change at line 453 skipping to change at line 481
[IGMPv1] Deering, S., "Host Extensions for IP Multicasting," [IGMPv1] Deering, S., "Host Extensions for IP Multicasting,"
RFC 1112 (STD 5), August 1989. RFC 1112 (STD 5), August 1989.
[IGMPv3] Cain, B. 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] Thaler, D., 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.
[OFFER] Rosenberg, J., H. Schulzrinne, "An Offer/Answer Model
with the Session Description Protocol (SDP)",
RFC 3264, June 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.
10. 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
skipping to change at line 474 skipping to change at line 506
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
11. IPR Notice 11. IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; neither does it represent that it under such rights might or might not be available; nor does it
has made any effort to identify any such rights. Information on the represent that it has made any independent effort to identify any
IETF's procedures with respect to rights in standards-track and such rights. Information on the procedures with respect to rights
standards-related documentation can be found in BCP-11. Copies of in RFC documents can be found in BCP 78 and BCP 79.
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 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.
Copyright (C) The Internet Society (2003). All Rights Reserved. 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.
This document and translations of it may be copied and 12. Copyright Notice
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 Copyright (C) The Internet Society (2004). This document is subject
not be revoked by the Internet Society or its successors or to the rights, licenses and restrictions contained in BCP 78, and
assigns. except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided This document and the information contained herein are provided on an
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A. Source-Filter Attribute Syntax 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.
skipping to change at line 563 skipping to change at line 581
; in [SDP]. ; in [SDP].
src-list = *(addr SP) addr src-list = *(addr SP) addr
; one or more unicast source addresses (in ; one or more unicast source addresses (in
; standard IPv4 or IPv6 ASCII-notation form) ; standard IPv4 or IPv6 ASCII-notation form)
; or FQDNs. ; or FQDNs.
; addr is as defined in [SDP]. ; addr is as defined in [SDP].
; SP is the ASCII 'space' character ; SP is the ASCII 'space' character
; (0x20, defined in [ABNF]). ; (0x20, defined in [ABNF]).
Expires: November 2003 May 15, 2003 Expires: January 2005 July 18, 2004
 End of changes. 

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