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

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

On 4/26/13 6:14 PM, Ali C. Begen (abegen) wrote:
>
> 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.
>

OK, in that case the proposed text works for me.


Cheers,
Ari