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

From: Ari Keränen <[email-masked]>
Date: Fri, 5 Apr 2013 20:03:47 +0300

This is to start a 2-week Working Group Last Call for

draft-ietf-mmusic-delayed-duplication-01

The WGLC ends on April 19th, 2013.

Please review the document send your comments both to the authors and to 
the MMUSIC mailing list. If you review the document but do not have any 
comments, please send a note to that effect as well.

The document is available here:
http://tools.ietf.org/html/draft-ietf-mmusic-delayed-duplication-01

Thanks,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Wed, 24 Apr 2013 01:27:41 +0300

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?

Cheers,
Ari (as individual)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 24 Apr 2013 06:32:26 +0000

On Apr 24, 2013, at 7:27 AM, Ari Keränen <[email-masked]> 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?

---

From: Ari Keränen <[email-masked]>
Date: Thu, 25 Apr 2013 00:07:35 +0300

On 4/24/13 9:32 AM, Ali C. Begen (abegen) wrote:
>> 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?

Cheers,
Ari

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 25 Apr 2013 07:55:30 +0000

On Apr 25, 2013, at 6:07 AM, Ari Keränen <[email-masked]> wrote:

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

---

From: Ari Keränen <[email-masked]>
Date: Fri, 26 Apr 2013 18:02:44 +0300

>     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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 26 Apr 2013 15:14:58 +0000

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

> 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

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

---

From: Ari Keränen <[email-masked]>
Date: Fri, 26 Apr 2013 18:33:57 +0300

> 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

---

From: "Dong Hsu (dohsu)" <[email-masked]>
Date: Fri, 26 Apr 2013 18:06:38 +0000

Here are the comments I have for this draft:

1. In the definition of duplication-delay attribute, it should clearly
state that the value is applied to the delay from previous stream. I knew
this is explained in the example but should be state here.

2. Can both attributes co-exist in media and session level? If not, please
state it somewhere. If so, does session level exceed media level?

3. For multiple delay values, I would prefer to use space to separate
multiple values such as

a=duplication-delay:50 100 150

This is more inline with other attributes with multiple values in SDP.

Best Regards,

-- Dong

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 26 Apr 2013 21:30:20 +0000

> Here are the comments I have for this draft:

Thanks.

> this is explained in the example but should be state here.

OK.

> state it somewhere. If so, does session level exceed media level?
This was discussed before. And it is not without problems if we wanted both media and session level attribute in the same SDP. I will make this clearer in the document.

> a=duplication-delay:50 100 150

I am in different. Does anybody else have an opinion on this?