Session Description Protocol (SDP) Source Filters
Extracted elements (23)
The primary motivation for SDP source-filters is to protect receivers from traffic sent from illegitimate source addresses, preserving content integrity and protecting against Denial of Service (DoS) attacks, particularly in multicast sessions where receivers can also share filter information with network elements (e.g., IGMPv3 routers).
The 'source-filter' attribute is not intended to be used as an 'offer' in SDP offer-answer exchanges because sets of source addresses do not represent capabilities or limitations of the offerer, and the offerer generally has no a priori knowledge of which IP source address(es) will appear in an answer.
The source-filter grammar intentionally does not include syntax to express 'exclude none' or 'include all'; the default behavior when no source-filter attribute is present is that all traffic sent to the connection-address is accepted (from any source).
Defining a list of legitimate sources departs from the Any-Source Multicast (ASM) model (RFC 1112); however, source-filters do not corrupt ASM semantics and can coexist with ASM on the same network using the same protocols. Use of source-filters is better suited to one-to-many or few-to-few multicast applications than to anonymous many-to-many sessions.
Source addresses specified in the 'source-filter' attribute are those seen by a receiver. If addresses undergo translation en route (e.g., via NAT or tunneling), the attribute will not be accurate unless the addresses therein are also translated accordingly.
A media-level source-filter will always completely override a session-level source-filter. The location of the 'source-filter' attribute (session vs. media level) determines whether it applies to the entire session or only to a specific medium.
An SDP description MUST NOT contain more than one session-level 'source-filter' attribute that covers the same destination address, or more than one media-level 'source-filter' attribute that covers the same destination address.
For SSM RTP sessions that use an 'incl' source-filter on a multicast address, the SDP description SHOULD also include an 'a=rtcp-unicast' attribute so that RTCP Reception Report packets are sent via unicast rather than multicast.
If a connection-address specifies more than one multicast address via the <number of addresses> field, a source filter for each address must be stated explicitly using a separate 'a=source-filter' line per address, unless the '*' wildcard is used for <dest-address>.
In an SDP offer-answer exchange, the answerer SHOULD ignore any 'source-filter' attribute present in the original offer, because source addresses do not represent capabilities or limitations of the offerer.
Receivers SHOULD NOT treat the SDP 'source-filter' attribute as their sole mechanism for protecting the integrity of received content, given the weakness of IP source address authentication.
The <dest-address> value in a 'source-filter' attribute MUST correspond to an existing <connection-field> value in the session description, unless the '*' wildcard is used to indicate applicability to all connection-field values.
When the <addrtype> value is the '*' wildcard, the <dest-address> MUST be either an FQDN or '*'; it MUST NOT be an IPv4 or IPv6 address.
When the <dest-address> value is a multicast address, it MUST NOT include the <ttl> and <number of addresses> subfields from the <connection-address> value.
The <address-types> subfield identifies the address family ('IP4' or 'IP6'). The wildcard value '*' may be used when <dest-address> is an FQDN, allowing the filter to apply to whichever address type is returned by DNS lookup.
The <dest-address> subfield identifies the destination to be filtered and may be a unicast address, multicast address, FQDN, or the '*' wildcard to match all connection-address values in the session description.
The <filter-mode> field takes one of two values: 'incl' (inclusion — accept only traffic from listed sources) or 'excl' (exclusion — reject traffic from listed sources). All other traffic disposition follows the default any-source multicast behavior.
The SDP 'source-filter' attribute specifies one or more unicast source addresses as either legitimate (inclusive) or illegitimate (exclusive) sources for a session's connection-address values. Its syntax is: a=source-filter: <filter-mode> <filter-spec>, where <filter-spec> consists of <nettype> <address-types> <dest-address> <src-list>.
RFC 4570 registers the new SDP attribute 'source-filter' with IANA as an att-field. It is applicable at both session level and media level, is not subject to charset, and its values are as defined in this document.
If source-filtering is implemented by sharing filter information with network elements (e.g., IGMPv3 routers), the security of those protocols becomes important to ensure that only legitimate traffic is received.
Use of FQDNs in <dest-address> or <src-list> exposes the source-filter to DNS security vulnerabilities; an unsecured DNS server could return illegitimate addresses, undermining the filter's effectiveness.
Using IP source addresses for authentication is weak because addresses are often dynamically assigned and senders can spoof their source address in datagrams. Border routers implementing ingress filtering (BCP 38) can reduce but not eliminate spoofed source addresses, particularly on LANs.
The ABNF grammar defines source-filter as: 'source-filter' ':' SP filter-mode SP filter-spec, where filter-spec = nettype SP address-types SP dest-address SP src-list, and src-list is one or more space-separated unicast addresses or FQDNs. The basic-multicast-address form omits the /<ttl> and /<number of addresses> fields present in the SDP connection-address.