Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Regarding the HTTP fallback and whether this could be adapted to be a TURN over HTTP based solution then I think the same comments that were made on the TURN over websockets apply. What are the benefits of creating a new transport for TURN over what we can do using HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00.

Having said that I am really happy we are having this debate as we really need to find a solution here that the browser vendors will implement so I would really like to know which options they prefer.

I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to document whatever the working group agrees on being the right solution.

Regards
Andy

> -----Original Message-----
> From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]
> Sent: 20 May 2013 10:15
> To: Gustavo García
> Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org
> Subject: Re: [rtcweb] New Version Notification for draft-chenxin-
> behave-turn-websocket-00.txt
> 
> Il giorno Sun, 19 May 2013 23:20:41 -0700
> Gustavo García <ggb@tokbox.com> ha scritto:
> 
> > I agree that TURN over websockets doesn't solve much more scenarios
> > than TURN/TLS.   If trying to fix HTTP Proxy traversal why not doing
> > it over HTTP that aside of philosophical discussions would be the
> > solution with better success rate?  Otherwise we will have to
> > continue answering for another 10 years "why is this app not working
> > if skype does".
> >
> > Something like this draft sent some months ago but perhaps for TURN
> > instead of direct connections:
> > http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt
> >
> 
> 
> When I submitted that draft this summer, I had that exact purpose in
> mind, that is taking care of corner edge cases like restrictive proxies
> and the like. Of course it was not meant to be a solution, just a way
> to foster discussion in that direction. In that discussion I also
> mentioned some work we did about this in the past, which in part
> apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations:
> 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html
> 
> At the time most people in the ML thought it was either too useless,
> too complex or even harmful, considering it could be considered as a
> "sneaky" way to circumvent rules added by a network administrator, and
> so unacceptable. Anyway, as I said back then, a solution like this
> doesn't have to be sneaky, and it could very well be conceived in order
> to be admin-friendly rather than have a parrot and a wooden leg.
> 
> Whether we actually need something like this or TURN-over-443 is enough
> I don't know: I still think it may be useful to tackle scenarios where
> everything else fails (the "skype works here" effect), so I'd be glad
> to be of help in that direction if needed.
> 
> Lorenzo
> 
> 
> 
> > On 16/05/2013, at 01:28, Hutton, Andrew wrote:
> >
> > > I agree with Bernard's comments regarding the impact of DPI but of
> > > course such DPI devices do what they do and we can't and even don't
> > > want to stop them from doing it. However for the case when policy
> > > is such that the firewall will only allow traffic to traverse that
> > > comes from the HTTP Proxy or a network specific TURN server and
> > > there is no deliberate policy to block WebRTC media we need a
> > > solution and this is what
> > > draft-hutton-rtcweb-nat-firewall-considerations-00 addresses.
> > >
> > > So far I don't see the benefit that TURN over websockets would have
> > > in this scenario and it needs additional implementation in the
> > > browser and the TURN server.
> > >
> > > Regards
> > > Andy
> > >
> > >
> > >> -----Original Message-----
> > >> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > >> Sent: 15 May 2013 18:20
> > >> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org;
> rtcweb@ietf.org
> > >> Subject: RE: [rtcweb] FW: New Version Notification for
> > >> draft-chenxin- behave-turn-websocket-00.txt
> > >>
> > >> Andrew Hutton said:
> > >>> When we wrote the draft http://tools.ietf.org/html/draft-hutton-
> > >> rtcweb-nat-firewall-considerations-00 we did not include this
> > >> option because we did not see the benefit of additional transport
> > >> options for TURN given that the existing options (E.g. TURN/TCP
> > >> and TURN/TLS) seem to be meet our needs.
> > >>>
> > >>> So what would be the benefits that justify this addition
> transport
> > >> option for TURN?
> > >>
> > >> [BA] In my experience,  institutions with very restrictive
> security
> > >> policies (e.g. those that don't allow UDP in or out) also tend to
> > >> deploy other measures such as deep packet inspection.   So just
> > >> because some traffic is allowed in or out on port 80 does not mean
> > >> that TURN/TCP will be allowed on that port - a DPI box may examine
> > >> the traffic and complain if it doesn't see HTTP being used.  On
> > >> the other hand, unless the DPI box is upgraded, it will also
> > >> complain about websockets.  So I think draft-chenxin only helps in
> > >> a situation where TURN over Websockets would be allowed when
> > >> TURN/TCP would not be.  That scenario is rare, at least at the
> > >> moment.
> > >>
> > >> The argument for TURN over Websocket/TLS is even more difficult to
> > >> make. While DPI boxes may examine traffic destined to port 443
> > >> carefully to make sure that TLS is really being used,  assuming
> > >> that the DPI box does not see anything it considers fishy, the TLS
> > >> exchange will complete and the DPI box will lose visibility.
> > >> After TLS is running, the DPI box does not have much information
> > >> available to distinguish TURN/TLS from HTTP over TLS, with or
> > >> without websockets -- and those things it does have (such as
> > >> packet size) are as likely to result in an objection to websocket
> > >> transport as TURN/TLS.  So I'm not sure that draft-chenxin will
> > >> help in that situation either.
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb