Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

["Karl Stahl" <[e-mail]>]

I want to point out that all methods suggested for RTP media through
firewalls that do not allow UDP traffic, by using "always open" https port
443 (or http port 80) result in tunneling RTP media over TCP. That gives
with severe quality problems from TCP retransmissions of dropped media
packet packets. Do we really want that for WebRTC?

A quality wise better solution is already pointed out in use case 3.2.5.1
mentioned below:
"An enterprise that uses a RTCWEB based web application for communication
desires to audit all RTCWEB based application session used from inside the
company towards any external peer. To be able to do this they deploy a TURN
server that straddle the boundary
between the internal network and the external"
 
I suggest the following is added to that use case:
"Such TURN server allows a media path, separated from the usually data
crowded enterprise Internet access, offering superior quality. This is a
better way to enable WebRTC on a network behind a restrictive firewall not
allowing UDP traffic, instead of tunneling RTP through always open http or
https ports resulting in RTP media over TCP – with severe quality problems
from TCP retransmissions of dropped packets. 

Such network administrator provided auditing TURN server would also put the
right party in control – The network administrator decides what is allowed
on his network."

Why should a network administrator that wants to block webrtc media, have to
do more than just closing his firewall for UDP, like below suggested
"configuring the browser not to do webrtc, normal HTTP black/white lists,
and solutions based on putting something in the HTTP Connect sent to the
proxy so the proxy can block it"?

Another thing in the second half of the same use case 3.2.5.1: 
Are NAT/firewalls inside the enterprise network assumed? If not, I think the
second half can be deleted.

" In cases where employees are using RTCWEB applications provided by an
   external service provider they still want to have the traffic to stay
   inside their internal network and in addition not load the straddling
   TURN server, "

ICE establishes a direct connection in this case, not using any TURN server
at all, doesn’t it? This is then not a problem.

/Karl

-----Ursprungligt meddelande-----
Från: [e-mail] [mailto:[e-mail]] För Hutton,
Andrew
Skickat: den 20 september 2013 19:58
Till: Magnus Westerlund; Cullen Jennings (fluffy); [e-mail];
[e-mail]
Ämne: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On: 17 September 2013 13:01 Magnus Westerlund Wrote:
> 3.2.3.1.  Description
> 
>    This use-case is almost identical to the Simple Video Communication
>    Service use-case (Section 3.2.1).  The difference is that one of the
>    users is behind a FW that only allows http traffic.
> 
> If a firewall only allows HTTP traffic, then can we really assume that 
> the firewall administrator per default will accept WebRTC Media and 
> Data traffic?
> 
> I am far from certain of this, and think on a requirement level needs 
> to express a situation where the firewall administrator allows WebRTC 
> across its FW, or at least can easily configure a rule to block it.
> Thus
> resulting in that any solution for this needs to be easily 
> identifiable and possible to block.
> 

Stefan already stated that this use case will be changed to take account of
my comments in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg08264.html. So the
"only allows HTTP traffic" is going to be removed and changed to describe
the use case when the firewall requires traffic to flow via a HTTP Proxy. 

We also have a use case when a network specific TURN server is deployed
(3.2.5.1).

In both cases I agree that a network administrator must have a way to block
webrtc but there are various ways of achieving this including just
configuring the browser not to do webrtc, normal HTTP black/white lists, and
also I can imagine solutions based on putting something in the HTTP Connect
sent to the proxy so the proxy can block it. 

So I agree that it must be possible to block webrtc traffic but we need to
careful not to specify the solution in the use case.  

Andy


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