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

[Roman Shpount <[e-mail]>]

inline

On Fri, Mar 23, 2012 at 12:29 AM, Hadriel Kaplan <[e-mail]>wrote:

> 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.
>
>
No, I did not mean to have #1 before #2 and #3. I was quoting the exact
language in the chapter definition that should cover the activity related
to WebRTC specific proxy.


> > 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
>
>
These documents do not cover scenario when organization forces all the
traffic to go through HTTP proxy to enforce its communication policy.

> 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
>
>
Once again, these documents do not cover scenario when organization forces
all the traffic to go through HTTP proxy. In such cases WebRTC simply will
not work. At best, we can advise such organizations to deploy their own
TURN server, but this allow all traffic to traverse into public internet,
not just webrtc related one, which might be undesirable.



> > 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 think we are currently missing one of the common network deployment
scenarios for web browsers, where web browsers are deployed on a network
non-routable to public internet with an HTTP proxy used to allow access to
the web. I believe that we should add capabilities necessary to support
such deployments.


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

The reason is that with custom signaling protocols implementing monitoring
or enforcing policies would be very hard. BTW, this is not only and not
primarily about recording traffic. This can be used to force all the
traffic outside of the enterprise to be DTLS-SRTP only, but still allow
DES-SRTP (or RTP if WebRTC will support it) within the enterprise network.
_____________
Roman Shpount