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

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 15 May 2013 16:14:50 +0000

This is an interesting addition to the debate about how best to achieve connectivity for RTCWeb when the client is behind a restrictive firewall.

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?

Regarding F37 then this does need some rewording as I think the WG previously discussed as it needs to talk about the need for traffic to originate from the HTTP Proxy rather than allowing http traffic. That is probably worth a separate thread.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chenxin (Xin)
> Sent: 15 May 2013 02:40
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [rtcweb] FW: New Version Notification for draft-chenxin-
> behave-turn-websocket-00.txt
> 
> This draft defines a websocket extension to TURN to make TURN data have
> the ability to transport over the websocket connection.
> 
> This method could be a option to solve the Http-fallback requirement in
> RTCWEB.
> 
>     F37            The browser MUST be able to send streams and
>                    data to a peer in the presence of FWs that only
>                    allows http(s) traffic.
> 
> Besides, Turn server with websokcet extension could be a general relay
> server for some over websocket protocol, such as BFCP over websocket or
> MSRP over websocket. This could satisfy some Peer to Peer scene when
> using these protocol in the web environment , without a specific center
> server.
> 
> Comments and suggestions are welcome.
> 
> Best Regards,
>      Xin
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 14, 2013 9:15 AM
> To: Chenxin (Xin); Chenxin (Xin)
> Subject: New Version Notification for draft-chenxin-behave-turn-
> websocket-00.txt
> 
> 
> A new version of I-D, draft-chenxin-behave-turn-websocket-00.txt
> has been successfully submitted by Xin Chen and posted to the
> IETF repository.
> 
> Filename:	 draft-chenxin-behave-turn-websocket
> Revision:	 00
> Title:		 Traversal Using Relays around NAT (TURN) Extensions
> for Websocket Allocations
> Creation date:	 2013-05-13
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-chenxin-
> behave-turn-websocket-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-chenxin-behave-
> turn-websocket
> Htmlized:        http://tools.ietf.org/html/draft-chenxin-behave-turn-
> websocket-00
> 
> 
> Abstract:
>    This document defines an extension to TURN that allows it to run
> over
>    a Websocket [RFC6455] channel.  This will allow a client in a
>    restrictive network to exchange and relay media or data over the
>    websocket.
> 
> 
> 
> 
> The IETF Secretariat
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 May 2013 10:19:53 -0700

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

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Wed, 15 May 2013 01:40:05 +0000

This draft defines a websocket extension to TURN to make TURN data have the ability to transport over the websocket connection.

This method could be a option to solve the Http-fallback requirement in RTCWEB. 

Besides, Turn server with websokcet extension could be a general relay server for some over websocket protocol, such as BFCP over websocket or MSRP over websocket. This could satisfy some Peer to Peer scene when using these protocol in the web environment , without a specific center server.

Best Regards,
     Xin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, May 14, 2013 9:15 AM
To: Chenxin (Xin); Chenxin (Xin)
Subject: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Filename:	 draft-chenxin-behave-turn-websocket
Revision:	 00
Title:		 Traversal Using Relays around NAT (TURN) Extensions for Websocket Allocations
Creation date:	 2013-05-13
Group:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-chenxin-behave-turn-websocket-00.txt
Status:          http://datatracker.ietf.org/doc/draft-chenxin-behave-turn-websocket
Htmlized:        http://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-00

Abstract:
   This document defines an extension to TURN that allows it to run over
   a Websocket [RFC6455] channel.  This will allow a client in a
   restrictive network to exchange and relay media or data over the
   websocket.

The IETF Secretariat

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 16 May 2013 04:55:54 +0000

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Wednesday, May 15, 2013 10:50 PM
To: Hutton, Andrew; Chenxin (Xin); [email-masked]; [email-masked]
Subject: Re: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

[TR] Firewalls with restrictive policies in addition to DPI use various other mechanisms like reputation, heuristics, HTTPS proxy etc to classify the traffic and block it.

--Tiru.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 May 2013 08:28:03 +0000

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

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: 15 May 2013 18:20
> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin-
> > 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.
> >
> [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.

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Thu, 16 May 2013 11:42:21 +0000

Reply inline

Best Regards,
     Xin

From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, May 16, 2013 1:20 AM
To: Hutton, Andrew; Chenxin (Xin); [email-masked]; [email-masked]
Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

[Xin]   With the development of websocket, there will be more and more web servers which support websocket. That means websocket will be treated the same as HTTP in the policy of FW or proxy server. Comparing with transporting the TCP packet directly on the Http port, Upgrade the HTTP to websocket and transport the data over it is more friendly to FW and proxy server. The possibility of the block of  the websocket data by the DPI is less than the TCP data.  So I think the benefit of turn over websocket is that it will increase the success rate when the rtcweb is used in the restrictive network, such as in airport or some hotel.

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.
[Xin]  If DPI can't inspect the content of TLS data, there is no difference. But considering DPI-SSL, which could inspect the TLS session, the turn over websocket will be has the benefit which has been said before.

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Thu, 16 May 2013 11:52:17 +0000

>From: Hutton, Andrew [mailto:[email-masked]]
>Sent: Thursday, May 16, 2013 4:28 PM
>To: Bernard Aboba; Chenxin (Xin); [email-masked]; [email-masked]
>Subject: RE: [rtcweb] FW: New Version Notification for
>draft-chenxin-behave-turn-websocket-00.txt
>
>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.
>

Yes, we could not stop the use of DPI, but we should consider this scene. I think that is the purpose of F37. Besides, websocket is friendly to http proxy too. I agree that draft-hutton-rtcweb-nat-firewall-considerations-00 should be a baseline to solve the traverse problem of nat and fireward. But I think the turn over websocket solution should also be considered as a option to solve some corner use case and requirement.

Best Regards,
     Xin 

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 May 2013 11:06:35 +0000

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

> From: Lorenzo Miniero [mailto:[email-masked]]
> Sent: 20 May 2013 10:15
> To: Gustavo García
> Cc: Hutton, Andrew; [email-masked]; [email-masked]
> Subject: Re: [rtcweb] New Version Notification for draft-chenxin-
> Il giorno Sun, 19 May 2013 23:20:41 -0700
> Gustavo García <[email-masked]> 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
> > >
> > >
> > >> draft-chenxin- behave-turn-websocket-00.txt
> > >>
> > >> Andrew Hutton said:
> > >> 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?
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >
> > >
> > >
> > >

---

From: Gustavo García <[email-masked]>
Date: Sun, 19 May 2013 23:20:41 -0700

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 20 May 2013 11:15:22 +0200

Lorenzo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 May 2013 13:34:09 +0000

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:[email-masked]]
Sent: 20 May 2013 18:12
To: Hutton, Andrew
Cc: Lorenzo Miniero; Gustavo García; [email-masked]; [email-masked]
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:

Regards
Andy

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]]
Sent: 20 May 2013 10:15
To: Gustavo García
Cc: Hutton, Andrew; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] New Version Notification for draft-chenxin-

Il giorno Sun, 19 May 2013 23:20:41 -0700
Gustavo García <[email-masked]<mailto:[email-masked]>> ha scritto:

Lorenzo

Regards
Andy

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: 15 May 2013 18:20
To: Hutton, Andrew; Chenxin (Xin); [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Subject: RE: [rtcweb] FW: New Version Notification for
draft-chenxin- behave-turn-websocket-00.txt

Andrew Hutton said:

[BA] In my experience,  institutions with very restrictive
security

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

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

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

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

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 20 May 2013 19:11:31 +0200

Simon

                     					       _\\|//_
                           				      ( O-O )
                                           e-mail: [email-masked]

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 22 May 2013 01:02:40 +0200

All,

Isn’t such a low quality fallback channel for penetrating restrictive
NAT/Firewalls NEGATIVE for RTCweb?

QUALITY: Any tunneling of RTP through the “always open” HTTP 80 or HTTPS 443
ports is RTP over an error correcting TCP channel. Thus, lost packets will
be retransmitted, resulting in second long packet delays. Jitter buffers
don’t handle that and if they did, we will not be happy with second long
delays in RTC, i.e. two-way real-time communications. That is why we run RTP
over UDP.

(When discussing QoS, some will stand up and tell that sound quality really
was good – it is all about bandwidth, etc. Yes, quality in an IP network is
good when you don’t fill the pipe – even this TCP-pipe is. But in today’s
data crowded networks, where you are not alone, the pipe is filled at every
email or click on a webpage. Then packets are lost, and with the fallback
discussed you don’t even have the benefit of UDP over TCP transport.)

SKYPE: Yes, I know Skype has a similar fallback – same low quality - and I
have heard the argument “Otherwise we will have to continue answering for
another 10 years "why is this app not working if skype does". But why should
that be the ambition of the RTCweb standards?

DECIDING NETWORK USAGE: Doesn’t the network administrator that configured
the firewall have a legitimate right to decide what traffic should be on his
network? If he only wants internal traffic and surfing, shouldn’t it be his
choice to be able to configure just that? And if a service provider (SP)
blocks all but surfing on his access, the user can get another subscription
if he wants to benefit from using  RTCweb (and that SP will go out of
business…or can just offer his access at a very low cost for surfing only
usage).

Not getting RTCweb through a restrictive firewall, may rather encourage the
network administer to resolve the problem properly, than if we provide a
fallback with lousy quality. Then the user may not be interested in the “bad
RTCweb” and won’t ask his network administrator to “enable it”.

BETTER THAN BEST EFFORT: Actually, it we “enable networks for RTCweb”, we
could quality wise get a BETTER pipes for RTCweb media than for surfing! The
STUN/TURN server address provided actually allows ICE/TURN/STUN media to be
routed another path than data traffic – a better path, maybe even with level
3 QoS (diffserve or RSVP if we are lucky).

Remember, that we finally are stepping up from 100 years old 3,5 kHz voice
only to potentially telepresence HiFi HD 3.5 Mbps quality. We should
encourage that the networks support this potential, rather than providing a
low quality fallback, that will bring a bad user experience to RTCweb.

NEW VIEW ON ICE: I think it is time to view the ICE/TURN/STUN protocol suit
in an alternative way. Instead of being a way to fool or trick media through
a NAT/Firewall that is unaware of what is happening, regard ICE/TURN/STUN as
a protocol to Request Access for RTC through the firewall. Firewalls – if
combined with the STUN/TURN server – could then respond not just by opening
a path for RTC, but could also prioritize and shape the traffic in the
firewall for much better quality. (A firewall is often the point where
congestion can be controlled.) And the firewall could request quality over
the transport network for the RTC media (heard cable operators were
interested to do that with their reservation type of QoS they use for voice)
– others could use diffserve.

TURN and STUN servers also include authentication – Maybe they were intended
for “Request pass trough” rather than “Fool media through”, were they?

/Karl

Från:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] För Hutton,
Andrew
Skickat: den 21 maj 2013 15:34
Till: Simon Pietro Romano
Kopia:  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked]
Ämne: Re: [rtcweb] New Version Notification for
draft-chenxin-behave-turn-websocket-00.txt

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:[email-masked]] 
Sent: 20 May 2013 18:12
To: Hutton, Andrew
Cc: Lorenzo Miniero; Gustavo García; [email-masked]; [email-masked]
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

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

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

Sent: 20 May 2013 10:15

To: Gustavo García

if skype does".

 

Lorenzo

Regards

Andy

-----Original Message-----

Sent: 15 May 2013 18:20

To: Hutton, Andrew; Chenxin (Xin); [email-masked];

[email-masked]

Andrew Hutton said:

transport

option for TURN?

security

moment.

 

rtcweb mailing list

[email-masked]

rtcweb mailing list

[email-masked]

 
_\\|//_

                                                              ( O-O )

                                                        Simon Pietro Romano

                                                Universita' di Napoli
Federico II

                      <<Molti mi dicono che lo scoraggiamento Ë l'alibi
degli 

                      idioti. Ci rifletto un istante; e mi scoraggio>>.
Magritte.

                                                          oooO

                                                                \ (
(   )

                                                             \_)          )
/

                                                                       (_/

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 May 2013 10:00:23 +0200

Le 2013-05-22 01:02, Karl Stahl a écrit :
> Doesn’t the network administrator that configured the firewall have
> a legitimate right to decide what traffic should be on his network?

IMHO this is the strongest argument.

STUN/TURN/ICE have always been about NAT traversal. Firewall traversal
is a completely different beast. It implies a kind of battle between the
client and the firewall, where the client implementer is trying to be
smarter than the firewall administrator. This is a battle the IETF
should not engage in. Let the vendors play that game.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 May 2013 11:30:51 +0200

Le 2013-05-22 11:04, Karl Stahl a écrit :
>> Firewall traversal is a completely different beast.
>
> Not really. There are always firewall functions included in "a NAT" (e.g.
> open for traffic from inside to outside and you can then get traffic back
> the same path - with some timeout), even if the RFCs only call the box "a
> NAT". I prefer to say NAT/Firewall.

You're focusing on the technical aspect. The difference I'm considering 
is not technical.

NAT traversal is performed with the agreement of everyone involved, 
whereas firewall traversal is a battle between the client implementer 
and the firewall administrator. There's also a potential arms race: 
firewalls will evolve with the ability to block whatever we standardize, 
so we will need a newer traversal method, which firewalls will end up 
blocking as well, etc. etc. etc. We don't want to play that game.

NAT traversal: ok
Firewall traversal: not for the IETF

Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 22 May 2013 11:04:34 +0200

ICE/TURN/STUN handles both the NAT and firewall issues to a limit.

And the drafts behave-turn-websocket and other about tunneling through
http(s) ports are an attempt to extend the limit where the firewall function
(not NAT) is blocking RTCweb (in this case).

Actually I think ICE/TURN/STUN even works with a firewall that does not have
NAT enabled at all (as long as UDP ports from inside to outside are open to
use). 

Having said that, I of course agree that IETF should not extend TURN with
tunneling to pass through a restrictive firewall.

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Simon
Perreault
Skickat: den 22 maj 2013 10:00
Till: [email-masked]; [email-masked]
Ämne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for
draft-chenxin-behave-turn-websocket-00.txt

Le 2013-05-22 01:02, Karl Stahl a écrit :
> Doesn’t the network administrator that configured the firewall have a 
> legitimate right to decide what traffic should be on his network?

STUN/TURN/ICE have always been about NAT traversal. Firewall traversal is a
completely different beast. It implies a kind of battle between the client
and the firewall, where the client implementer is trying to be smarter than
the firewall administrator. This is a battle the IETF should not engage in.
Let the vendors play that game.

Simon

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 23 May 2013 13:08:53 +0000

At least with regard to draft-hutton-rtcweb-nat-firewall-considerations we are not attempting to enter or add to any existing arms race between clients and firewalls.

We are only describing how to use existing IETF protocols which already extensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet the RTCWEB requirements in this area which have existed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10 for almost two years now.

Of course if a network administer wants to block RTCWEB media they should be able to so and nobody is I believe suggesting that we try to prevent this.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: 22 May 2013 10:31
> To: Karl Stahl
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification
> for draft-chenxin-behave-turn-websocket-00.txt
> 
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Fri, 24 May 2013 02:26:22 +0000

I agree that we should not try to battle with network administrator, and we are not doing that. We just supply some technical tools to rtcweb implementer, to make the users could get benefit and convenience when using rtcweb. Fallback methods and proposals are for this purpose.  We could not decide that how will a kind of technique be used. Every technique could be used in a good way and a bad way.  I believe that rtcweb is a good and trustworthy technique which is different with the some harmful things which should be blocked by the administers. So let us back to the technical aspect: should we need to support a fallback method in rtcweb now? Which one should we support to MTI? Which one should we support to be a option? I think now there is three method to solve the fallback requirement：TURN/TLS, HTTP channel , TURN/WS or HTTP. I am willing to write a mail these days to make a simple conclusion and comparison between these methods, which will provide a material to WG for future discussion and decision.

Best Regards,
     Xin 

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Simon Perreault
>Sent: Wednesday, May 22, 2013 5:31 PM
>To: Karl Stahl
>Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 24 May 2013 07:36:41 +0100

I don't think it makes sense to lump TURN functionality (e.g. TURN over TCP, TLS or WS) in the same bucket as transport over HTTP/HTTPS or WS, since the former involves the PeerConnection API but the latter need not. 

If ICE fails, an application can try alternatives. As long as those alternatives don't involve peer to peer transport of media over http/https or WS, it isn't clear to me that we need a standard encapsulation. And if we are talking about peer-to-peer then this implies an http/https or WS server in the browser, which seems like it is out of scope, at least in this discussion.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 May 2013 13:19:59 +0200

Le 2013-05-24 12:19, Matthew Kaufman (SKYPE) a écrit :
> (Channeling Randy Bush for a moment)... I strongly encourage my competitors to not engage in this battle.

It's not about engaging or not, it's about standardizing.

In an arms race, there no point to standardizing your weapons du jour.

As a framework, ICE still allows whatever form of firewall traversal 
that vendors may think of.

Simon

> On May 22, 2013, at 9:00 AM, "Simon Perreault" <[email-masked]> wrote:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 24 May 2013 10:05:02 +0200

I do agree with SImon here. Firewall traversal in the sense "let's bypass the firewall admin policys" is not something for the IETF,

Why not focus on discussing best behaviour for firewalls, so we don't end up in the mess we have in SIP with most
firewalls breaking communication. We also have huge problems with firewall/CPE/routers that are starting to implement
broken SIP application layer gateways.

Maybe "run a TURN server on the firewall" is a good recommendation to start with.

/O

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 24 May 2013 10:51:05 +0200

I read the two drafts referenced.

http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10 
looks OK both regarding not fighting firewall restrictions, and not
introducing quality degradation.

The enterprise use case with a restrictive firewall not allowing UDP to the
Internet is described under 4.2.5.1 and suggests the use of a local TURN
server on the LAN that "enabling cases where peers are both on the internal
side
to connect without the traffic leaving the internal network." I don't see
that it pin points how rtcweb outside LAN - to the Internet - would happen,
but an additional firewall/router could be added between the LAN TURN server
and the Internet to handle that. 

That would result in a separate pipe for rtcweb media - that the network
administer himself arranges! And he has even the possibility to arrange
better quality (prioritizing etc.) on that pipe than via the ordinary
firewall where rtcweb remains blocked.

Both
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-0
0 and 
http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-00.txt 
describe ways of tunneling RTP traffic trough HTTP(S) TCP ports 80(443) that
are open in the firewall for surfing usage. 

Whether that tunneling has an extra framing from TURN/TCP, TURN/TLS or WS,
does not affect the discussion about trying to get rtcweb media through a
firewall that is configured to only allow surfing.

All of these fallbacks also results in RTP over TCP (instead of UDP as
usual) and therefore degrades quality due to the error correcting
retransmission. There is no way around that. (I believe the TURN/TLS is only
TCP half of the way - between the client and TURN server, but the firewall
being penetrated is often also the congestion point - so not much
improvement quality wise.) 

So, even if pushing RTC through the surf ports would not be considered
fighting the firewall restriction (How could it?), do we really want a
quality degraded fallback channel for rtcweb anyway? I'd say we should
encourage better quality networks to really step up from POTS quality voice
now that we have chance.

/Karl

-----Ursprungligt meddelande-----
Från: Hutton, Andrew [mailto:[email-masked]] 
Skickat: den 23 maj 2013 15:09
Till: Simon Perreault; Karl Stahl
Kopia: [email-masked]; [email-masked]
Ämne: RE: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for

At least with regard to draft-hutton-rtcweb-nat-firewall-considerations we
are not attempting to enter or add to any existing arms race between clients
and firewalls.

We are only describing how to use existing IETF protocols which already
extensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet the
RTCWEB requirements in this area which have existed in
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10
for almost two years now.

Of course if a network administer wants to block RTCWEB media they should be
able to so and nobody is I believe suggesting that we try to prevent this.

Regards
Andy

> You're focusing on the technical aspect. The difference I'm 
> considering is not technical.
> 
> firewalls will evolve with the ability to block whatever we 
> standardize, so we will need a newer traversal method, which firewalls 
> will end up blocking as well, etc. etc. etc. We don't want to play 
> that game.
> 
> NAT traversal: ok

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 24 May 2013 10:58:20 +0200

Leaving my quality concern of a such fallback channel for a moment...

How do you mean that tunneling rtcweb media through a firewall that is configured to only allow surfing is not to  "battle with network administrator"?

Isn't it exactly just that, whatever technique we chose to it with?

/Karl

-----Ursprungligt meddelande-----
Från: Chenxin (Xin) [mailto:[email-masked]] 
Skickat: den 24 maj 2013 04:26
Till: Simon Perreault; Karl Stahl
Kopia: [email-masked]; [email-masked]
Ämne: RE: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Best Regards,
     Xin 

>Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification 
>> open for traffic from inside to outside and you can then get traffic 
>> back the same path - with some timeout), even if the RFCs only call 
>> the box "a NAT". I prefer to say NAT/Firewall.
>
>will end up blocking as well, etc. etc. etc. We don't want to play that game.
>
>NAT traversal: ok

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 24 May 2013 11:06:56 +0200

> Maybe "run a TURN server on the firewall" is a good recommendation to start with.

That would include be the combination of the LAN TURN server and the additional firewall/router I just mentioned in another response:

"http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10
looks OK both regarding not fighting firewall restrictions, and not introducing quality degradation.

The enterprise use case with a restrictive firewall not allowing UDP to the Internet is described under 4.2.5.1 and suggests the use of a local TURN server on the LAN that "enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network." I don't see that it pin points how rtcweb outside LAN - to the Internet - would happen, but an additional firewall/router could be added between the LAN TURN server and the Internet to handle that."

And it has the potential to add quality rather than degenerate it.

/Karl

-----Ursprungligt meddelande-----
Från: Olle E. Johansson [mailto:[email-masked]] 
Skickat: den 24 maj 2013 10:05
Till: Chenxin (Xin)
Kopia: Olle E. Johansson; Simon Perreault; Karl Stahl; [email-masked]; [email-masked]
Ämne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Why not focus on discussing best behaviour for firewalls, so we don't end up in the mess we have in SIP with most firewalls breaking communication. We also have huge problems with firewall/CPE/routers that are starting to implement broken SIP application layer gateways.

/O

24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" <[email-masked]>:

>> standardize, so we will need a newer traversal method, which 
>> firewalls will end up blocking as well, etc. etc. etc. We don't want to play that game.
>> 
>> NAT traversal: ok

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 24 May 2013 10:19:58 +0000

Matthew Kaufman

(Sent from my iPhone)

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 24 May 2013 09:02:27 -0700

On 05/20/2013 02:15 AM, Lorenzo Miniero wrote:
> Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo García <[email-masked]>
> 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".
>> 
> 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:
> 
> 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.

About circumventing rules added by a network administrator, I do think that
using TURN over Websocket or HTTP is doing in fact the opposite:  It is the
only way to obey the wish of the network administrator, as long as you
classify Webrtc is a *web* technology and not as a VoIP technology.

Think about it this way:  An administrator restricting UDP but authorizing
HTTP is basically saying: All web applications are fine, and Webrtc being a
Web application, it should just work fine, and should not be a collateral
damage of restricting UDP.  So TURN over Websocket/HTTP should be a mandatory
part of Webrtc.

Now the administrator should also have access to tools to restrict some
classes of web applications, and Webrtc should be one of these classes.  But
that should not be done as a side-effect of closing the UDP ports.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 28 May 2013 15:03:54 +0000

> classify Webrtc is a *web* technology and not as a VoIP technology.

I certainly agree with this. WEBRtc is a new technology embedded in the browser for web applications to use so we need to define the mechanism used by the browser to handle firewall scenarios and give the network administrators the tools to do what they want.

This is not about circumventing rules but about putting tools in place so rules can be defined for this new web technology and we need to move on this otherwise webrtc will be unnecessarily restricted in where/how it can be used.

So far I still think the HTTP Connect mechanism described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations is the best option as it requires only browser implementation and existing infrastructure to work. 

However let's debate the merits of all solutions and move this forward.

Andy.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 May 2013 13:52:47 -0400

This is probably about the appropriate point in the thread to drop in a
reference to Firewall Enhancement Protocol, RFC 3093:
<http://tools.ietf.org/html/rfc3093>
FEP has the benefit that you don't even negotiate the connection, since it
tunnels the entire IP datagram, not just the UDP part.
</sarcasm>

On Fri, May 24, 2013 at 12:02 PM, Marc Petit-Huguenin <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> > Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo García <[email-masked]
> >
> > ha scritto:
> >
> mind,
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9
> dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr
> oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2
> 9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a
> zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv
> WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH
> 0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n
> 78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8
> tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe
> Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw
> xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53
> HJsMG1MkVKRwRBgLsM9S
> =HTew
> -----END PGP SIGNATURE-----