Session Description Protocol (SDP) Source Filters
RFC 4570
|
| Document |
Type |
|
RFC - Proposed Standard
(July 2006; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4570 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jon Peterson
|
|
Send notices to |
|
<jo@acm.org>, <csp@csperkins.org>
|
Network Working Group B. Quinn
Request for Comments: 4570 BoxnArrow.com
Category: Standards Track R. Finlayson
Live Networks, Inc.
July 2006
Session Description Protocol (SDP) Source Filters
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
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. 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.,
Session Announcement Protocol (SAP), SIP, Real Time Streaming
Protocol (RTSP), email, and HTTP).
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-
Quinn, et al. Standards Track [Page 1]
RFC 4570 SDP Source Filters July 2006
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.
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.
1.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.
2. 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].
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
Show full document text