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

> 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:oej@edvina.net] 
Skickat: den 24 maj 2013 10:05
Till: Chenxin (Xin)
Kopia: Olle E. Johansson; Simon Perreault; Karl Stahl; behave@ietf.org; rtcweb@ietf.org
Ämne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

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

24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>:

>   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
> 
> 
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
>> Behalf Of Simon Perreault
>> Sent: Wednesday, May 22, 2013 5:31 PM
>> To: Karl Stahl
>> Cc: rtcweb@ietf.org; behave@ietf.org
>> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification 
>> for draft-chenxin-behave-turn-websocket-00.txt
>> 
>> 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
>> _______________________________________________
>> 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