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

["Ali C. Begen (abegen)" <[e-mail]>]

On Apr 27, 2013, at 12:02 AM, Ari Keränen <[e-mail]> wrote:

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

If someone is signaling and sending way too many streams to you, you gotta discontinue this stream. E.g., if you see an SDP that signals 5 dup streams, there is likely something wrong. This could be a bug or an attack, either case, you should not accept this stream. I think this is pretty obvious. 

> 
> 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 SDP is hacked into, sky is the limit in terms of what harm you can cause. 

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

I would not change this text since it is a pretty standard text for sdp attributes.

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