Session Description Protocol (SDP) Source Filters
draft-ietf-mmusic-sdp-srcfilter-10

[Ballot discuss]
[updated for -09]
src-list used to say "addr is as defined in [SDP]."; now it doesn't say at all where "addr" comes from.

dest-address might want to include extn-addr to allow the same kind of extensions as [SDP]? Alternately, it could be "*" / connection-address?  (Otherwise, if a connection-address extension is used in the m= line, you may not be able to match it in the filter).  [Revisiting this, it looks like the current definition doesn't permit IPv4 multicast addresses, which I thought was one of the main points of srcfilter -- making it even more likely that '"*" / connection-address' is actually what you mean here]

The second paragraph in Appendix A talks about 'The "connection-address" value in each source filter field', but it's not clear which value that is - is this "dest-address", maybe?

[Ballot comment]
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):

       

        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?

[Ballot discuss]
[updated for -08]
src-list used to say "addr is as defined in [SDP]."; now it doesn't say at all where "addr" comes from.

dest-address might want to include extn-addr to allow the same kind of extensions as [SDP]? Alternately, it could be "*" / connection-address?  (Otherwise, if a connection-address extension is used in the m= line, you may not be able to match it in the filter).  [Revisiting this, it looks like the current definition doesn't permit IPv4 multicast addresses, which I thought was one of the main points of srcfilter -- making it even more likely that '"*" / connection-address' is actually what you mean here]

The second paragraph in Appendix A talks about 'The "connection-address" value in each source filter field', but it's not clear which value that is - is this "dest-address", maybe?

[Ballot comment]
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).

[Ballot discuss]
This document does not provide descriptoin of the risks of a forged excl in the SDP - the
user could have a desired source blocked out by the forger -
needs to describe this risk and require integrity protection when excl is used.

[Ballot 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):

       

        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?

[Ballot discuss]
I believe that the IPv4 and IPv6 addresses (used as examples) in this document are not from the range of example addresses as specified in RFC3330 and RFC3849.

[Ballot comment]
In the references section:
  [UTF-8]    Yergeau, F., "UTF-8, a transformation format of Unicode
              and ISO 10646," RFC 2044, October 1996.
This one has been obsoleted twice already. Current document is RFC3629.

[Ballot discuss]
Further to Steve's Discuss:  neither this document nor RFC 3376 (IGMPv3) protects
against forged exclusions, which could result in desired traffic being blocked from
the user.  IGMPv3 can protect against forged filters  if the end user can use the IPSec AH
provided for its other security capabilities.  I mention this to forestall a view that IGMPv3
would be a broken link in the security chain, so it would not be worth preventing forgery
of SDP filters. 

If excl remains, it should have a strong applicability statements usage for SSM.  The
document needs to discuss the risks, and describe a security method.

[Ballot discuss]
The ABNF doesn't specify spaces between elements, e.g.

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

maps to, e.g.,

source-filter:inclINIPv4224.2.0.1128.118.5.4

I don't know if you want to use SP (exactly one space) or 1*SP (one or more spaces) but you need to use seperators.

src-list says "addr is as defined in [SDP]."  [SDP] says it's March 2003; I assume that this is actually a reference to draft-ietf-mmusic-sdp-new-19.txt (August 2004), which does not define "addr".  I suspect you may want "unicast-address".

dest-address might want to include extn-addr to allow the same kind of extensions as [SDP]? Alternately, it could be "*" / connection-address?

[Ballot 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.

[Ballot comment]
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.:

 


        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


       

An example of it might be useful if the draft will be revised for
other reasons.

Corresponded with authors about the applicability of srcfilters to unicast. While applicability to multicast is clear and quite valuable, the use of the mechanism with unicast streams might easily be conflated with the generic MMUSIC source address filtering work. In particular, removing section 3.2.2 seems justified in the absence of any credible use case for unicast source filters.