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

["Hutton, Andrew" <[e-mail]>]

Hi Simon

I believe all possible solutions deserve attention however my feeling is that the HTTP Connect based mechanism for connecting to the TURN server via TURN/TCP/TLS has a good chance of being implemented by browsers.

What I would really like to happen is for draft-hutton-rtcweb-nat-firewall-considerations to be adopted and progressed by the WG to describe the preferred solution whatever it might be.

In the next update we could add some text describing the alternatives to the HTTP CONNECT based mechanism to promote further discussion at least we seem to have some agreement that a solution is needed.

Regards
Andy


From: Simon Pietro Romano [mailto:[e-mail]]
Sent: 20 May 2013 18:12
To: Hutton, Andrew
Cc: Lorenzo Miniero; Gustavo García; [e-mail]; [e-mail]
Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

I keep on thinking that the solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt deserves attention.

Simon

Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto:


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:[e-mail]]
Sent: 20 May 2013 10:15
To: Gustavo García
Cc: Hutton, Andrew; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
Sent: 15 May 2013 18:20
To: Hutton, Andrew; Chenxin (Xin); [e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb

                                                                         _\\|//_
                                                              ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                                                        Simon Pietro Romano
                                                Universita' di Napoli Federico II
                                Computer Engineering Department
                     Phone: [phone] -- Fax: [phone]
                                           e-mail: [e-mail]<mailto:[e-mail]>

                      <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli
                      idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                                                          oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                \ (            (   )
                                                             \_)          ) /
                                                                       (_/