Re: [pntaw] draft-hutton-rtcweb-nat-firewall-considerations

[Bernard Aboba <[e-mail]>]

Here are some comments on the document.  Overall, I like the approach taken, which is to articulate use cases and the potential solutions to them.  However, I think it could be a bit clearer about the overall recommendations and normative dependencies. 
Section 1
   If an organization wants to support RTCWEB such a TURN server may be
   located in the DMZ of the private network of that organization where
   it is still under administrative control.

   In certain environments with very restrictive FW policies a TURN
   server in the public internet may not be sufficient to establish
   connectivity towards the RTCWEB peer for RTP-based media [RFC3550].
   Such policies can include blocking of all UDP based traffic and
   allowing only HTTP(S) traffic to the TCP ports 80/443.  In addition
   access to the World Wide Web from inside an organization is often
   only possible via a HTTP proxy.
[BA] I think the above sentences miss an important distinction, which is the difference between use of WebRTC internal to an organization and use to communicate externally.  In the internal scenario, employees of an organization use WebRTC to communicate with each other, and the corporate IT shop endeavors to configure the corporate NATs, Firewalls, TURN servers, etc. to support that.  In the external scenario, organization employees use WebRTC to communicate with customers or partners whose IT group may or may not be aware of WebRTC.  It is in this external scenario that many of the thorniest issues are likely to arise. An example would be a company sales associate inviting a potential customer to a screen sharing session to demonstrate a new product. 
Section 2.2

   In the first case the browser needs to use ICE-TCP [RFC6544] and
   provide active, passive and/or simultaneous-open TCP candidates.
   Assuming the peer also provides TCP candidates, a connectivity check
   for a TCP connection between the two peers should be successful.
[BA] Not sure whether "should be successful" is trying to imply that statistically this is expected to succeed in the majority of RTP over TCP cases.  That is not my experience - "simultaneous open" isn't supported widely enough for that to be the case. 
   Note that the second case is not to be mixed up with TURN/TCP
   [RFC6062], which deals with how to establish a TCP connection to the
   peer.  For this document we assume that the TURN server can reach the
   peer always via UDP, possibly via a second TURN server.
[BA] In an external scenario, a "second TURN server" is not likely, because the WebRTC application will only provide a single TURN server.  So it seems to me that TURN/TCP [RFC6062] might still be needed (and at least in my experience, it ends up being used). Section 2.3
   In addition the RTCWEB
   clients need to be configured to contact the TURN server over the
   HTTP(S) ports and/or needs to be able to tell the browser accordingly. 

[BA] At least in my experience, attempting to contact the TURN server over the HTTP port tends to run afoul of DPI.  So while I don't object to this as a requirement, I've not found it particularly useful.  
Section 3.3.1
   Afterwards, the RTCWEB client could upgrade the connection to use
   TLS, forward STUN/TURN traffic via the HTTP proxy and use the TURN
   server as media relay.  Note that upgrading in this case is not to be
   misunderstood as usage of the HTTP UPGRADE method as specified in
   [RFC2817] as this would require the TURN server to support HTTP. 
 [BA] Can you clarify whether you are advocating support for this native in the browser, or rather application implementation?  I'm assuming you mean browser native (so as to be able to take advantage of this in ICE), but it also seems that an application might be able to take advantage of this (possibly to do something malicous). 
Section 4.3
   However, the expected benefit in form of an increased success
   rate for establishment of a media stream seems rather small, thus
   HTTP fallback is left for further study.
[BA] At least in my experience, the failure rate for ICE/ICE-TCP is not so small in enterprise use cases (can be as high as 5 percent).  Even if it is 1 percent and you are talking about a service handling hundreds of millions of users that kind of failure rate will generate a very big support burden, particularly if the cost of service is small or negligible.  So I'd suggest that some testing of the recommendations might be helpful to quantify what the risk is; even "small" failure rates can be a big deal. 
9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
[BA] Only one normative reference?? Based on the recommendations in Section 5, I was expecting some of the following references to be normative: 
   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.


   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
              "TCP Candidates with Interactive Connectivity
              Establishment (ICE)", RFC 6544, March 2012.
Also (although Section 5 doesn't recommend this), you might want to consider: 
   [RFC6062]  Perreault, S. and J. Rosenberg, "Traversal Using Relays
              around NAT (TURN) Extensions for TCP Allocations", RFC
              6062, November 2010.
IMHO, if you're going to support RTP over TCP (not really sure that this needs to be mandated for WebRTC), then you'll need RFC 6062 in addition to RFC 6544. 






From: [e-mail]
To: [e-mail]
Date: Fri, 30 Aug 2013 14:16:15 +0000
Subject: [pntaw] draft-hutton-rtcweb-nat-firewall-considerations










One of the reasons for establishing the pntaw mailing list was to discuss http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01
 
This draft discusses the interaction between webrtc browsers and Web Proxies, Firewalls and TURN servers and makes some proposals on what needs to be implemented in webrtc browsers.  We have already received a few comments both on the rtcweb list and off
list so we are working on an update which we hope to submit within the next couple of weeks. 
 
As some people have recently stated on the rtcweb list this is an important aspect of webrtc that needs to be tackled to enable webrtc deployments in many restricted environments.
 
The draft discusses the use of HTTP CONNECT in environments with web proxies to enable a tunnel to be established to the TURN server but this does not require any TURN enhancements which some people seem to have thought to be the case.  A small number
of people have told me that this might be controversial but the way I see it is that webrtc brings new types of media to web applications we need to specify the interaction between webrtc browsers and proxies in the same was as is done for HTTP (See http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-4.3.6).
 
Look forward to your comments.
 
Regards
Andy
 
 




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