Re: [MMUSIC] WGLC for draft-ietf-mmusic-delayed-duplication-01

[Ari Keränen <[e-mail]>]

On 4/25/13 10:55 AM, Ali C. Begen (abegen) wrote:
>
> On Apr 25, 2013, at 6:07 AM, Ari Keränen <[e-mail]> wrote:
>
>> On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote:
>>>
>>> On Apr 24, 2013, at 7:27 AM, Ari Keränen <[e-mail]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I reviewed the draft and noticed that in the intro section you
>>>> mention a possible DoS attack using the delayed duplication
>>>> functionality, but it's not discussed at all in the security
>>>> considerations section. Should that be addressed too?
>>>>
>>>
>>> Really? the whole section talks about what could happen if someone
>>> could modify the SDP (number of dup streams, delays, etc.).
>>> Especially the last paragraph mentions this. is it not clear?
>>
>> Not really. I guess I was expecting something more for a "new series of denial-of-service attacks" than what was described in the security section. To make this more clear, perhaps you could use the term DoS also in the security section, where applicable.
>>
>> Especially the last section talks about software bug or misconfiguration, but couldn't an active attacker also do this?
>>
>
> I will change the text as follows. let me know if there are objections.
>
> OLD:
>
>     Another security risk is due to possible software misconfiguration or
>     a software bug where a large number of duplicates could be
>     unwillingly signaled in the 'duplication-delay' attribute.  In
>     applications where this attribute is to be used, it is a good
>     practice to put a hard limit both on the number of duplicate streams
>     and the total delay introduced due to duplication regardless of what
>     the SDP description specifies.
>
> NEW:
>
>     Another security risk is due to possible software misconfiguration or
>     a software bug where a large number of duplicates could be
>     unwillingly signaled in the 'duplication-delay' attribute. Similarly, an attacker can use this attribute to start a denial-of-service attack by signaling and sending too many duplicated streams. In
>     applications where this attribute is to be used, it is a good
>     practice to put a hard limit both on the number of duplicate streams
>     and the total delay introduced due to duplication regardless of what
>     the SDP description specifies.
>

What I was thinking is that can an attacker trick someone supporting 
this feature into sending big set of duplicate streams (instead of just 
a single stream) to a target? That is, is there possible amplification 
due to this extension? Probably not?

Or is there some additional DoS risk for signaling duplicate streams and 
then sending them (as the NEW text says) - instead of just sending if 
you can do that anyway? I'm guessing no..

If those aren't big DoS attack concerns, probably the first part of the 
security considerations is actually more DoS'ish. If that's the case, 
then maybe modify the text with something like:

OLD
    However, these
    require intercepting and rewriting the packets carrying the SDP [...]
NEW
    However, this kind of DoS attacks
    require intercepting and rewriting the packets carrying the SDP [...]


Or maybe the intro text just makes one more worried than you actually 
need to be with this extension.


Cheers,
Ari