Session Description Protocol (SDP) Source Filters
RFC 4570
Discuss
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Harald Alvestrand; former steering group member) Discuss
Sigh.
I really hate to approve documents that contain MUSTs that are impossible to implement. Consider the following two pieces of texts:
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.).
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.
To which I can only say.... "dream on".
If the document says something like:
"... then the receiver has to use a modified SDP description that uses local knowledge to figure out what the local representation of the address presented in the SDP "source-filter" attribute is"
then it's OK. But the text reads like "NATs have to go muck with SDP even if it's inside email", and I don't want to mandate that.
I do not understand this (3.1):
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.
in conjunction with this (3.2.4):
<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
Isn't this > 1 source-filter attribute at session level?
(Steven Bellovin; former steering group member) Discuss
RFC 2827 should be cited instead of [CA-96.21] There is no motivation provided for the "excl" feature. Either motivation should be provided or the feature should be removed. Beyond that, the security considerations section should discuss the risks of an unauthenticated mechanism --- IGMP -- that tells a router to block packets for a given source/dest pair.
(Jon Peterson; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) (was Discuss) No Objection
Addressed my concern for forged exclusions by: From Ross Finlayson: - Section 5 (security considerations) discusses the general importance of needing to ensure the integrity of the addresses mentioned in SDP "source-filter" attributes (of which a "excl" address is just one case).
(Bert Wijnen; former steering group member) (was Discuss) No Objection
(Bill Fenner; former steering group member) (was Discuss) No Objection
(Brian Carpenter; former steering group member) (was Discuss) No Objection
Inconsistency noted by Harald:
I do not understand this (3.1):
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.
in conjunction with this (3.2.4):
<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
Isn't this > 1 source-filter attribute at session level?
(David Kessens; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
Reading through the document it seemed like it would be possible to
have an address based filter that applied to one or more of the c= addresses
and a second FQDN-based filter that applied to all of them, e.g.:
<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 * channel-1.example.com src-1.example.com
<media-description 1>
An example of it might be useful if the draft will be revised for
other reasons.
(Thomas Narten; former steering group member) No Objection