Subject: [rtcweb] Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 May 2012 16:10:39 +0200

WG,

This is an individual contribution on how to do codec control in WebRTC.

Ericsson has an current IPR statment on the referenced Codec Operation
Points RTCP extension. This statement will be updated, hopefully next
week, with new terms making it a non-asssert statement for
implementation in webbrowsers and FRAND for other usages. I will send a
pointer when the official statement is available.

Cheers

Magnus

Subject: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 16 May 2012 16:02:28 +0200
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Codec Control for WebRTC
	Author(s)       : Magnus Westerlund
                          Bo Burman
	Filename        : draft-westerlund-rtcweb-codec-control-00.txt
	Pages           : 18
	Date            : 2012-05-16

   This document proposes how WebRTC should handle media codec control
   between peers.  With media codec control we mean such parameters as
   video resolution and frame-rate.  This includes both initial
   establishment of capabilities using the SDP based JSEP signalling and
   during ongoing real-time interactive sessions in response to user and
   application events.  The solution uses SDP for initial boundary
   establishment that are rarely, if ever changed.  During the session
   the RTCP based Codec Operations Point (COP) signaling solution is
   used for dynamic control of parameters enabling timely and responsive
   controls.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westerlund-rtcweb-codec-control-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-westerlund-rtcweb-codec-control-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-westerlund-rtcweb-codec-control/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 May 2012 08:58:36 +0200

On 2012-05-21 03:44, 邓灵莉/denglingli wrote:
> Hi, Magnus
> 
> It seems to me that there may be another security threat in multi-party
> applications of COP, where an entity needs to combine multiple sets of
> requested parameters, than the one discussed in the draft. 
> That the initial downgrading of the combined potential ceiling for collected
> parameters for media quality (codec capabilities plus COP parameters as
> stated in Section 5) through SDP transaction by a malicious participant.
> Unlike the one stated in Section 8, the latter behavior only happens once
> and could neither been distinguished afterwards as "actively harmful" nor to
> be ignored in order to serve actually poorly-equipped users.
> Would that be an issue?
> 

Yes, this is clearly a security threat to the complete solution. Not
that it is specific to codec control. It is a threat to all things
expressed in the SDP, like which codecs being used, security mechanism
is negotiated etc.

In the WebRTC security architecture my undestanding is that it so far
are a deliberate choice of allowing the JavaScript and the web browser
to be allowed to modify the SDP if desired by them. Thus a security
model based on hop by hop security for the JSEP/SDP messages has been
selected. For example the usage of HTTPS / Websocket over TLS can
provide the security to prevent third parties not directly addressed
from seeing and affecting the JSEP/SDP messages.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Mon, 21 May 2012 17:37:01 +0800

Agreed.

-----邮件原件-----
发件人: Magnus Westerlund [mailto:[email-masked]] 
发送时间: 2012年5月21日 14:59
收件人: 邓灵莉/denglingli
抄送: [email-masked]
主题: Re: 答复: [rtcweb] Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

On 2012-05-21 03:44, 邓灵莉/denglingli wrote:
> Hi, Magnus
> 
> It seems to me that there may be another security threat in 
> multi-party applications of COP, where an entity needs to combine 
> multiple sets of requested parameters, than the one discussed in the draft.
> That the initial downgrading of the combined potential ceiling for 
> collected parameters for media quality (codec capabilities plus COP 
> parameters as stated in Section 5) through SDP transaction by a malicious participant.
> Unlike the one stated in Section 8, the latter behavior only happens 
> once and could neither been distinguished afterwards as "actively 
> harmful" nor to be ignored in order to serve actually poorly-equipped users.
> Would that be an issue?
> 

Yes, this is clearly a security threat to the complete solution. Not that it is specific to codec control. It is a threat to all things expressed in the SDP, like which codecs being used, security mechanism is negotiated etc.

In the WebRTC security architecture my undestanding is that it so far are a deliberate choice of allowing the JavaScript and the web browser to be allowed to modify the SDP if desired by them. Thus a security model based on hop by hop security for the JSEP/SDP messages has been selected. For example the usage of HTTPS / Websocket over TLS can provide the security to prevent third parties not directly addressed from seeing and affecting the JSEP/SDP messages.

Cheers

Magnus Westerlund

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7138 (20120515) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 May 2012 08:42:42 -0700

>> stated in Section 5) through SDP transaction by a malicious participant.

As Magnus pointed out, this is true of anything that can be signaled.
The application can do anything up to (and including) a complete
denial of service.  The fact that the application is effectively the
victim of this attack means that we probably shouldn't concern
ourselves overmuch.

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Tue, 22 May 2012 09:25:56 +0800

Hi, Martin

You are right. According to the current discussion, I would suggest two options about the security threat statement: 
1, remove the item c from Section 8; or
2, add a few words to notify what is left out and may be of concern in the field and people would know what to expect in reality.
Would you agree?

BR 
Lingli

-----邮件原件-----
发件人: Martin Thomson [mailto:[email-masked]] 
发送时间: 2012年5月21日 23:43
收件人: Magnus Westerlund
抄送: 邓灵莉/denglingli; [email-masked]
主题: Re: [rtcweb] 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

As Magnus pointed out, this is true of anything that can be signaled.
The application can do anything up to (and including) a complete denial of service.  The fact that the application is effectively the victim of this attack means that we probably shouldn't concern ourselves overmuch.

http://www.eset.com

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 May 2012 19:51:09 -0700

On 21 May 2012 18:25, 邓灵莉/denglingli <[email-masked]> wrote:
> [...] I would suggest two options about the security threat statement:

I'm not sure about the full implications of these sorts of mechanisms
yet.  I was speaking more generally about rtcweb.  In general however,
it is true that a site (or any entity on the signaling path) can
degrade the experience.

Adding a mechanism like what Magnus proposes lets any participant in a
call perform the same sorts of degradations.  As a site operator, I
want to ensure that this doesn't happen, so that my users always get
the best experience from my site.  So that's not necessarily an
exposure that I like.  Of course, I haven't really analyzed the upside
of this particular trade-off yet...

--Martin

p.s. it might be possible for a mechanism like this to "fix"
downgrades chosen by the site, though that wouldn't be advisable.  The
proposal indicates otherwise: that the constraints set during
negotiation are firm.

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Tue, 22 May 2012 11:22:43 +0800

I don't think it is a good idea to loosen the firm constraints that the site/a third party would set to the media negotiation.
Looking at the other side, the browser may not know everything about the session as well as the other side of communication (as JSEP suggested).
Besides, there may be policies that a service provider would like to configure in order to regulate media behaviors of its users, especially when it comes to interworking with legacy networks.

Lingli

-----邮件原件-----
发件人: Martin Thomson [mailto:[email-masked]] 
发送时间: 2012年5月22日 10:51
收件人: 邓灵莉/denglingli
抄送: Magnus Westerlund; [email-masked]
主题: Re: 答复: [rtcweb] 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

On 21 May 2012 18:25, 邓灵莉/denglingli <[email-masked]> wrote:
> 1, remove the item c from Section 8; or 2, add a few words to notify 
> what is left out and may be of concern in the field and people would know what to expect in reality.
> Would you agree?

I'm not sure about the full implications of these sorts of mechanisms yet.  I was speaking more generally about rtcweb.  In general however, it is true that a site (or any entity on the signaling path) can degrade the experience.

Adding a mechanism like what Magnus proposes lets any participant in a call perform the same sorts of degradations.  As a site operator, I want to ensure that this doesn't happen, so that my users always get the best experience from my site.  So that's not necessarily an exposure that I like.  Of course, I haven't really analyzed the upside of this particular trade-off yet...

--Martin

p.s. it might be possible for a mechanism like this to "fix"
downgrades chosen by the site, though that wouldn't be advisable.  The proposal indicates otherwise: that the constraints set during negotiation are firm.

http://www.eset.com

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 May 2012 08:43:18 +0200

> 1, remove the item c from Section 8; or

I don't think this is an appropriate choice. The reason is that it
applies to multi-party cases where an given end-point targets the other
participants. Mitigation in the media plane central node for this attack
is something the implementation should have.

> 2, add a few words to notify what is left out and may be of concern in the field and people would know what to expect in reality.

I would like to make it clear that this documents security consideration
is a short summary of the most important attacks. The COP drafts
security consideration is not existing and that will be addressed in the
next version. That will clearly discuss the SDP angle and at least point
out the need for protection between the nodes. But also that in
multi-party there exist a potential for down-grading the general
constraints.

I will consider adding the SDP based downgrade into this document also.

Cheers

Magnus Westerlund

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Tue, 22 May 2012 15:24:05 +0800

Agreed. 

Thanks,
Lingli

-----邮件原件-----
发件人: Magnus Westerlund [mailto:[email-masked]] 
发送时间: 2012年5月22日 14:43
收件人: 邓灵莉/denglingli
抄送: 'Martin Thomson'; [email-masked]
主题: Re: 答复: [rtcweb] 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

> 1, remove the item c from Section 8; or

I don't think this is an appropriate choice. The reason is that it applies to multi-party cases where an given end-point targets the other participants. Mitigation in the media plane central node for this attack is something the implementation should have.

> 2, add a few words to notify what is left out and may be of concern in the field and people would know what to expect in reality.

I would like to make it clear that this documents security consideration is a short summary of the most important attacks. The COP drafts security consideration is not existing and that will be addressed in the next version. That will clearly discuss the SDP angle and at least point out the need for protection between the nodes. But also that in multi-party there exist a potential for down-grading the general constraints.

Cheers

Magnus Westerlund

http://www.eset.com