[RTW] dearly love packet inspection

Justin Uberti juberti at google.com
Thu Jan 6 23:32:50 CET 2011


On Thu, Jan 6, 2011 at 2:00 PM, Ted Hardie <ted.ietf at gmail.com> wrote:

> On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti <juberti at google.com> wrote:
>
> > Right. The thinking was that since we need to do a fair amount of work to
> > allow audio and video to be exchanged safely and reliably peer-to-peer,
> we
> > should allow web applications (with some limits) to use this transport
> > mechanism for exchanging their own application data.
>
> From a practical perspective, once you say "application data", the ability
> to limit this seems to approach zero pretty quickly.  Even ignoring the
> network-based firewall, doesn't this now require me to have a browser-based
> firewall, to express my policies for what traffic I permit over this?
>

The connection is limited by the browser same-origin policy, so the
application can only connect to places blessed by the application server,
similar to XmlHttpRequest. We don't worry about apps making XmlHttpRequest
over TLS, where there is little ability to control the data, and I think we
should try to think of these transports the same way.


> > The plan also is to be able to leverage DTLS to allow the creation of
> secure
> > transports, which will have additional implications for DPI.
>
> Agreed.  More importantly, I think that reinforces the idea that this is
> not
> a simple add-on to audio/video functionality.  As I argued in
> draft-hardie-mdtls-session,
> you are really creating a multi-flow session layer.  I personally
> think that's a fine
> thing, but it is not an adjunct to a charter-it's the top-line bullet
> item in my view.
>
> regards,
>
> Ted
>
> PS.  As an aside, both Jake and I have since left Panasonic and the
> project mentioned in
> the draft cited above.  I do not believe that the sponsor lab will release
> the
> code created for it at this time so the discussion I had with some
> folks on that in Beijing
> will likely need to take other paths.
>
>
> >>
> >>                       Harald
> >>
> >> _______________________________________________
> >> RTC-Web mailing list
> >> RTC-Web at alvestrand.no
> >> http://www.alvestrand.no/mailman/listinfo/rtc-web
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110106/1577435a/attachment-0001.html>


More information about the RTC-Web mailing list