Re: [rtcweb] Resolving RTP/SDES question in Paris

[Hadriel Kaplan <[e-mail]>]

comments inline…

On Mar 22, 2012, at 9:31 PM, Roman Shpount wrote:

> I would say that this activity would be covered by:

Did you mean to have a #1 before #2 below?  Your email was missing a #1.

> 2. Define a security model that describes the security and privacy
> goals and specifies the security protocol mechanisms necessary
> to achieve those goals. 

We've got that:
http://tools.ietf.org/html/draft-ietf-rtcweb-security
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch


> 3. Define the solution - protocols and API requirements - for
> firewall and NAT traversal.

We've got that, though not in one doc:
http://tools.ietf.org/html/draft-ietf-rtcweb-overview
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements
http://tools.ietf.org/html/draft-ietf-rtcweb-jsep


> I do consider ability to enforce the enterprise or location communications policy on WebRTC clients to be one of the requirements for security and privacy.

OK, so what you're really saying is we have #2 and #3, but you don't agree they cover the needs, and you want more added to #2 (and ultimately #3), right?


> I expect that unless ability to enforce such communication policy within enterprises or other organizations is provided, WebRTC would be simply disabled. 
> In practical terms, I expect that an organization that enforces a communication policy disables routing to public internet and only allows communications via a company controlled HTTP proxy. Such setup would effectively prevent WebRTC from operations. What I am suggesting is to provide a complimentary protocol for inspection and modification of WebRTC SDP messages which would allow WebRTC enabled browser to control an enterprise edge media proxy and would allow WebRTC media traffic to traverse the enterprise firewall and to operate in such environment.

Well... if they really can't enforce their policies, then by definition they *should* disable it.  That's a feature, not a bug.  And luckily it *can* be disabled, which is also a feature of WebRTC.  

Having said that, I don't understand why you think an organization that has strict monitoring policies can't monitor and enforce WebRTC traffic, both the HTTP *and* the media/data channels.  They *can* do it.  It's just not "automagic", and not cheap.  But that's ok - I don't think we need to optimize the deployment complexity or cost structure for that model.

-hadriel