[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4570

Network Working Group                                          Bob Quinn
INTERNET-DRAFT                                            Celox Networks
Category: Standards Track                                 Ross Finlayson
Expires: October 2003                                           LIVE.COM
                                                           April 15, 2003

           Session Description Protocol (SDP) Source Filters
                <draft-ietf-mmusic-sdp-srcfilter-04.txt>


Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    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
    and may be updated, replaced, or obsoleted by other documents at any
    time. It is inappropriate to use Internet-Drafts as reference
    material or cite them other than as "work in progress".

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

Copyright Notice

    Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

    This document describes how to adapt the Session Description Protocol
    (SDP) to express one or more source addresses as a source filter for
    one or more destination "connection" addresses.  It defines the
    syntax and semantics for an SDP "source-filter" attribute that may
    reference either IPv4 or IPv6 address(es) as either an inclusive or
    exclusive source list for either multicast or unicast destinations.
    In particular, an inclusive source-filter can be used to specify a
    Source-Specific Multicast (SSM) session.


1. Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [REQMNT].


2. Introduction

    The Session Description Protocol [SDP] provides a general-purpose
    format for describing multimedia sessions in announcements or
    invitations. SDP uses an entirely textual data format (the US-ASCII
    subset of [UTF-8]) to maximize portability among transports.
    SDP does not define a protocol, but only the syntax to describe a
    multimedia session with sufficient information to discover and
    participate in that session.  Session descriptions may be sent using
    any number of existing application protocols for transport
    (e.g., SAP, SIP, RTSP, email, HTTP, etc.).

    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 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
    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
    traffic sent from illegitimate source addresses. Filtering traffic
    can help to preserve content integrity and protect against denial of
    service (DoS) attacks.

    For multicast destination addresses, receiver applications MAY apply
    source-filters using the Multicast Source Filter APIs [MSF API].
    Hosts are likely to implement these APIs using protocol mechanisms to
    convey the source filters to local multicast routers.  Other
    "upstream" multicast routers MAY apply the filters and thereby
    provide more explicit multicast group management and efficient
    utilization of network resources.  The protocol mechanisms to enable
    these operations are beyond the scope of this document, but their
    potential provided motivation for SDP source-filters.


3. The "source-filter" Attribute

    The SDP source-filter attribute does not change any existing SDP
    syntax or semantics, but defines a format for additional session
    description information.  Specifically, source-filter syntax can
    prescribe one or more unicast addresses as either legitimate or
    illegitimate sources for any (or all) SDP session description
    "connection-address" field values.

    The source-filter attribute has the following syntax:

        a=source-filter: <filter-mode> <filter-spec>

    The <filter-mode> is either "incl" or "excl" (for inclusion or
    exclusion, respectively).  The <filter-spec> has four sub-components:

        <nettype> <address-types> <dest-address> <src-list>

    A <filter-mode> of "incl" means that an incoming packet is accepted
    only if its source address is in the set specified by <src-list>.
    A <filter-mode> of "excl" means that an incoming packet is rejected
    if its source address is in the set specified by <src-list>.

    The first sub-field <nettype> indicates the network type, since SDP
    is protocol independent.  This document is most relevant to the value
    "IN", which designates the Internet Protocol.

    The second sub-field <address-types> identifies the address family,
    and for the purpose of this document may be either <addrtype> value
    "IP4" or "IP6".  Alternately, when <dest-address> is an FQDN
    (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
    MUST correspond to one or more of the session's "connection-address"
    field values.  It may be either a unicast or multicast address,
    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
    hosts/interfaces in the source-filter, and consists of one or more
    unicast addresses or FQDNs, separated by space characters.

    The format and content of these semantic elements are derived from
    and compatible with those defined in [SDP].  For more detail, see
    Appendix A of this document.


3.1. Processing Rules

    There are a number of details to consider when parsing the SDP
    source-filter syntax.

    The <dest-address> value in a "source-filter" attribute MUST
    correspond to an existing <connection-field> value in the session
    description.  The only exception to this is when a "*" wildcard is
    used to indicate that the source-filter applies to all
    <connection-field> values.

    When the <dest-address> value is a multicast address, the field value
    MUST NOT include the sub-fields <ttl> and <number of addresses> from
    the <connection-address> value.  If the <connection-address>
    specifies more than one multicast address (in the
    <number of addresses> field), then a source filter, if any, for each
    such address must be stated explicitly, using a separate
    "a=source-filter" line for each address (unless a "*" wildcard is
    used for <dest-address>).  See section 3.2.4 for an example.

    When the <addrtype> value is the "*" wildcard, the <dest-address>
    MUST be either a FQDN or "*" (i.e., it MUST NOT be an IPv4 or IPv6
    address).  See section 3.2.6 for an example.

    As has always been the case, the default behavior when a
    source-filter attribute is not provided in a session description is
    that all traffic sent to the specified <connection-address> value
    should be accepted (i.e., from any source address).  The
    source-filter grammar does not include syntax to express either
    "exclude none" or "include all."

    Like the standard <connection-field> described in [SDP], the location
    of the "source-filter" attribute determines whether it applies to the
    entire session or only to a specific medium (i.e., "session-level" or
    "media-level").  A media-level source-filter will always completely
    override a session-level source-filter.

    A "source-filter" need not be located at the same hierarchy level as
    its corresponding <connection-field>.  So, a media-level <source-
    filter> can reference a session-level <connection-field> value, and a
    session-level "source-filter" can be applied to all matching media-
    level <connection-field> values.  See section 3.2.3 for an example.

    An SDP description MUST NOT contain more than one session-level
    "source-filter" attribute, nor more than one media-level
    "source-filter" attribute for the same medium.

    There is no specified limit to the number of entries allowed in the
    <src-list>, however there are practical limits that should be
    considered.  For example, depending on the transport to be used for
    the session description, there may be a limit to the total size of
    the session description (e.g., as determined by the maximum payload
    in a single datagram).  Also, when the source-filter is applied to
    control protocols, there may be a limit to the number of source
    addresses that can be sent.  These limits are outside the scope of
    this document, but should be considered when defining source-filter
    values for SDP.


3.2. Examples

    Here are a number of examples that illustrate how to use the source-
    filter attribute in some common scenarios.  We use the following
    session description components as the starting point for the examples
    to follow.  For each example, we show the source filter with
    additional relevant information, and provide a brief explanation.

    <session-description> =
         v=0
         o=The King <Elvis@example.com>
         s=Elvis Impersonation
         i=All Elvis, all the time
         u=http://www.example.com/ElvisLive/
         t=0 0
         a=recvonly

    <media-description 1> =
         m=audio 54320 RTP/AVP 0

    <media-description 2> =
         m=video 54322 RTP/AVP 34


3.2.1. Source-Specific Multicast Example

    Multicast addresses in the Source-Specific Multicast [SSM] range
    require a single unicast sender address for each multicast
    destination, so the source-filter specification provides a natural
    fit.  In this example, a session member should receive only traffic
    sent from 192.168.9.10 to the multicast session address 232.3.4.5.

         <session-description>

         c=IN IP4 232.3.4.5/127
         a=source-filter: incl IN IP4 232.3.4.5 192.168.9.10

         <media-description 1>

    This source filter example uses an inclusion list with a single
    multicast "connection-address" as the destination and single unicast
    address as the source.  Note that the value of the connection-address
    matches the value specified in the connection-field.

    Also note that since the connection-field is located in the session-
    description section, the source-filter applies to all media.

    Furthermore, if the SDP description specifies a RTP session
    (e.g., its "m=" line(s) specify "RTP/AVP" as the transport protocol),
    then the "incl" specification will apply not only to RTP packets,
    but also to any RTCP packets that are sent to the specified multicast
    address.  This means that, as a side effect of the "incl"
    specification, the only possible multicast RTCP packets will be
    "Sender Report" (SR) packets sent from the specified source address.

    Because of this, an SDP description for a Source-Specific Multicast
    (SSM) RTP session SHOULD also include a
        a=rtcp: unicast ...
    attribute, as described in [RTCP-SSM] (section 10.1).  This specifies
    that RTCP "Reception Report" (RR) packets are to be sent back via
    unicast.


3.2.2. Unicast Exclusion Example

    Typically, an SDP session <connection-address> value is a multicast
    address, although it is also possible to use either a unicast
    address or FQDN.  This example illustrates a scenario whereby a
    session description indicates the unicast source address 192.168.9.10
    in an exclusion filter.  In effect, this sample source-filter says,
    "destination 192.168.10.11 should accept traffic from any sender
    *except* 192.168.9.10."

         <session-description>

         c=IN IP4 192.168.10.11
         a=source-filter: excl IN IP4 192.168.10.11 192.168.9.10

         <media-description 1>


3.2.3. Multiple Session Address Example

    This source-filter example uses the wildcard "*" value for
    <dest-addr> to correspond to any/all <connection-address> values.
    Hence, the only legitimate source for traffic sent to either
    232.2.2.2 or 232.4.4.4 multicast addresses is 192.168.9.10.
    Traffic sent from any other unicast source address should be
    discarded by the receiver.

         <session-description>

         a=source-filter: incl IN IP4 * 192.168.9.10

         <media-description 1>

         c=IN IP4 232.2.2.2/127

         <media-description 2>

         c=IN IP4 232.4.4.4/63


3.2.4. Multiple Multicast Address Example

    In this example, the <connection-address> specifies three multicast
    addresses: 224.2.1.1, 224.2.1.2, and 224.2.1.3.  The first and third
    of these addresses are given source filters.  However, in this
    example the second address - 224.2.1.2 - is *not* given a
    source filter.

         <session-description>

         c=IN IP4 224.2.1.1/127/3
         a=source-filter: incl IN IP4 224.2.1.1 192.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
    references a single IPv6 multicast destination and source pair.  The
    IP multicast traffic sent to FFOE::11A is valid only from the unicast
    source address 2001:210:1:2:240:96FF:FE25:8EC9

    <session-description>

    c=IN IP6 FF0E::11A/127
    a=source-filter incl IN IP6 FF0E::11A 2001:210:1:2:240:96FF:FE25:8EC9

    <media-description 1>


3.2.6. IPv4 and IPv6 FQDN Example

    This example illustrates use of the <addrtype> "*" wildcard, along
    with multicast and source FQDNs that may resolve to either an IPv6
    or IPv4 address, or both.  Although typically both the multicast and
    source addresses will be the same (either both IPv4 or IPv6), using
    the wildcard for addrtype in the source filter allows asymmetry
    between the two addresses (so an IPv4 source address may be used
    with an IPv6 multicast address).

       <session-description>

       c=IN IP4 channel-1.example.com/127
       c=IN IP6 channel-1.example.com/127
       a=source-filter: incl IN * channel-1.example.com src-1.example.com

       <media-description 1>


4. Interoperability Issues

    Defining a list of legitimate sources for a multicast destination
    address represents a departure from the Any-Source Multicast
    (ASM) model, as originally described in [IGMPv1].  The ASM model
    supports anonymous senders, and all types of multicast applications
    (e.g., many-to-many).  Use of a source-filter excludes some (unknown
    or undesirable) senders, which lends itself more to one-to-many or
    few-to-few type multicast applications.

    Although these two models have contrasting operational
    characteristics and requirements, they can coexist on the same
    network using the same protocols. Use of source-filters do not
    corrupt the ASM semantics but provide more control for receivers,
    at their discretion.


5. Normative References

    [ABNF]      Crocker, D., P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF," RFC 2234, November 1997.

    [REQMNT]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels," BCP 14, RFC 2119, March 1997.

    [RTCP-SSM]  Chesterfield, J., E. Schooler, J. Ott,
                "RTCP Extensions for Single-Source Multicast Sessions
                with Unicast Feedback," Work in progress, March 2003.

    [SDP]       Handley, M., V. Jacobson, C. Perkins,
                "SDP: Session Description Protocol,"
                Work in Progress, March 2003.

    [UTF-8]     Yergeau, F., "UTF-8, a transformation format of Unicode
                and ISO 10646," RFC 2044, October 1996.


6. Informative References

    [CA-96.21]  CERT Advisory CA-96.21, "TCP SYN Flooding and IP
                Spoofing Attacks," September 1996.

    [IGMPv1]    Deering, S., "Host Extensions for IP Multicasting,"
                RFC 1112 (STD 5), August 1989.

    [IGMPv3]    Cain, B. et al. "Internet Group Management Protocol,
                Version 3,", Work in progress, May 2002.

    [MSF API]   Thaler, D., B. Fenner, B. Quinn, "Socket Interface
                Extensions for Multicast Source Filters,"
                Work in progress, July 2002.

    [SSM]       Bhattacharyya, S. et al., "An Overview of Source-Specific
                Multicast (SSM)," Work in progress, October 2002.


7. Security Considerations

    See [SDP] for security considerations specific to the Session
    Description Protocol in general.  The central issue relevant to
    using unicast source address filters is the question of address
    authenticity.

    Using the source IP address for authentication is weak, since
    addresses are often dynamically assigned and it is possible for a
    sender to "spoof" its source address (i.e., use one other than its
    own) in datagrams that it sends.  Proper router configuration,
    however, can reduce the likelihood of "spoofed" source addresses
    being sent to or from a network.  Specifically, border routers are
    encouraged to filter traffic so that datagrams with invalid source
    addresses are not forwarded (e.g., routers drop datagrams if the
    source address is non-local) [CA-96.21].

    Use of FQDNs for either <dest-address> or <src-list> values provides
    a layer of indirection that provides great flexibility.  However, it
    also exposes the source-filter to any security inadequacies that the
    DNS system may have.  If unsecured, it is conceivable that the DNS
    server could return illegitimate addresses.


8. IANA Considerations

    As recommended by [SDP] (Appendix B), the new attribute name
    "source-filter" should be registered with IANA, as follows:

    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
    input provided much of the substance of this document.  Magnus
    Westerlund also provided valuable feedback during editing.


10. Authors' Addresses

    Bob Quinn
    Celox Networks
    2 Park Central Drive
    Southborough, MA 01772
    phone: 508-305-7000
    email: bquinn (at) celoxnetworks.com

    Ross Finlayson
    Live Networks, Inc. (LIVE.COM)
    650 Castro St., suite 120-196
    Mountain View, CA 94041
    email: finlayson (at) live.com


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
    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 "connection-address" value in each source filter field MUST match
    an existing connection-field value, unless the wildcard connection-
    address value "*" is specified.

    source-filter =     "source-filter" ":" filter-mode filter-spec

    filter-mode =       "excl" / "incl"
                        ; either exclusion or inclusion mode

    filter-spec =       nettype address-types dest-address src-list
                        ; nettype is as defined in [SDP].

    address-types =     "*" / addrtype
                        ; "*" for all address types (both IP4 and IP6),
                        ;  but only when <dest-address> and <src-list>
                        ;  reference FQDNs.
                        ; addrtype is as defined in [SDP].

    dest-address =      "*" / IP4-address / IP6-address / FQDN
                        ; "*" applies to all connection-address values.
                        ; IP4-address, IP6-address, FQDN are as defined
                        ;  in [SDP].

    src-list =          *(addr SP) addr
                        ; one or more unicast source addresses (in
                        ;  standard IPv4 or IPv6 ASCII-notation form)
                        ;  or FQDNs.
                        ; addr is as defined in [SDP].
                        ; SP is the ASCII 'space' character
                        ;  (0x20, defined in [ABNF]).


Expires: October 2003                                     April 15, 2003


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/