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

From: Magnus Westerlund <[email-masked]>
Date: Sun, 16 Mar 2003 18:19:35 +0100

Hi,

A number of comments on this draft.

1. The title page headers looks bad. I would suggest that the author 
list is right justified. Also the expires date should be moved, see 
ID-nits for the recommendations.

2. The text in the whole draft should be indented in a good way. Normal 
running text is normally indented 3 characters. This makes the draft 
easier to read and find headings.

3. The conventions section is normally placed in its own section after 
the abstract. Location in regards to introduction varies and depends on 
content.

4. The short copyright statement is missing, see ID-nits

5. Section 2. This section should early declare if the attribute is 
allowed on session or media level or both.

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. It can become problematic if one 
does not want to specify any address as forbidden and still becomes 
required to include the attribute. It might just be easier to include 
the number of addresses and explicit about it.

7. Is it never interesting to define the filters based on ports or port 
ranges?

8. Section 4 & 5. It is customary to have the reference list last to be 
easy to find. I would appreciate if it is moved to just before 
copy-right and IPR statements.

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.

10. The formulation of the IANA section might be better. See 
draft-ietf-avt-rtcp-feedback for a good IANA section.

11. Appendix A. The syntax used does not match the reference. ABNF 
according to 2234 uses "/" as alternative markers. Also SP is not 
defined in RFC 2327. Also the IPv6 address is not defined in RFC 2327. 
There exist other reference that can be used. See rfc 3266 or you could 
make this draft dependent on the SDP new draft which contains all the 
missing ABNF tags I think.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Ross Finlayson <[email-masked]>
Date: Sun, 16 Mar 2003 13:40:42 -0800

Magnus,

Thanks for the feedback.  Addressing the substantive (i.e., non-syntactic) 
comments:

>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?

>7. Is it never interesting to define the filters based on ports or port 

(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...

>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

         Ross.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Mar 2003 17:07:12 +0100

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
>
> 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.)
>
> "/<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:
> 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. 
> 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