Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-srcfilter-03.txt

[Magnus Westerlund <[e-mail]>]

Hi Ross,

See below:

Ross Finlayson wrote:

> Magnus,
>
> Thanks for the feedback.  Addressing the substantive (i.e., 
> non-syntactic) comments:
>
>> 6. Section 2.1, paragraph three: Does it really work to imply the 
>> number of address part of this source filter. Is it totally 
>> unforeseeable that a multi-layered media stream using multiple 
>> multicast addresses actually has different filters? If not, the case 
>> where one source filter contains the first address and another the 
>> third is ambiguous. It can either be that the first filter apply to 
>> the second address or it is not specified. Please clarify this rule.
>
>
> Good point.  The issue here is how to specify source filters if the 
> SDP 'connection address' specifies multiple multicast addresses, e.g.
>         c=IN IP4 224.2.1.1/127/3
>
> There are a number of possible ways to deal with this:
>
> 1/ Specify that the source filter line must use the first multicast 
> address only, but that it applies to all of the possible multicast 
> addresses in the range.  (E.g., in the example above, it would not be 
> possible to specify different source filters for 224.2.1.1 and 
> 224.2.1.3.  Also, it would be illegal for the source filter line to 
> use any multicast address other than 224.2.1.1.)
>
> 2/ Specify that the source filter line contains individual multicast 
> addresses only.  To specify source filters for a range of multicast 
> addresses, there must be an individual source filter line for each one 
> - e.g.,
>         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
> Note that in this example, there would *not* be any source filter for 
> 224.2.1.3.2
>
> 3/ Change the source filter specification to include the 
> "/<number-of-addresses>" field.  But then, for consistency, should we 
> also require the "/<ttl>" field, even though it's useless?  Also, what 
> would the following mean:
>         a=source-filter: incl IN IP4 224.2.1.2/127/2 192.168.9.10
>         a=source-filter: incl IN IP4 224.2.1.1/127/3 192.168.9.42
> and would the meaning change if the order of these two lines were 
> reversed?
>
> Personally, I think that option 1 is too restrictive, and option 3 far 
> too complicated, and too difficult to understand.  For this reason, 
> I'd prefer option 2: Require individual source filters for each 
> multicast address in a range.  Any comments?

I am fine with two. It will be clear and simple at the small cost of 
possibly  having to duplicate lines in cases the same filter applies to 
several address in a range.

>
>
>> 7. Is it never interesting to define the filters based on ports or 
>> port ranges?
>
>
> (Presumably you mean *source* ports here, right?)  Noone has ever 
> expressed an interest in specifying this, but if someone wanted this, 
> I guess they could define a separate attribute for this - e.g., 
> "a=source-port-filter:" or something...
>
Actually, no. I was thinking of destination ports. It was around the 
same lines of the multiple addresses in one line. I think it is very 
common that a single multicast address is used to deliver both audio and 
video. In this case these streams may be produced on different entities 
and would still likes to be the only valid source. It is a corner case, 
however I think it should be addressed in someway. Either by 
acknowledging that it is not possible or fix so that it works. I have no 
real view on the usefulness of these, I just want to ensure that it as 
been thought through.

>
>> 9. Section 6: One important security problem for this is how easy it 
>> is to do DOS by specifying filters that exclude the correct source. 
>> Therefore there is strong need for authentication and also a general 
>> warning that SDPs not coming from the session source may not be trusted.
>
>
> If one could generate a fake SDP description that specified a bogus 
> source filter, then they could have just as easily specified bogus 
> *destination address(es)*.  I.e., a SDP description always needs to be 
> 'trusted', and the presence of source filter lines doesn't make any 
> this more (or less) important

Okay, you might be right that it is no different than changing the 
destination address to one that any attacker control. The point being 
that SDPs should be authenticated.

Best Regards


Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]




_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic