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

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 4 Sep 2013 13:33:44 +0000

Hi Bernard,

Thanks for the comments some responses below.

Regards
Andy

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: 01 September 2013 03:21
> To: Hutton, Andrew; [email-masked]
> Subject: RE: [pntaw] draft-hutton-rtcweb-nat-firewall-considerations
> 
> 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.
>

[AndyH] I agree the draft currently concentrates on the external scenario which as you say covers an organizations employee using a 3rd party WebRTC service but it also might apply to other scenarios such as using a webrtc service from hotels, coffee shops etc. 

We do need more text on the internal case and will need to do more work on that.

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

[AndyH] - Agree and this was included for completeness my preference is for using TCP to the TURN server and possible we don't even need to use ICE-TCP.

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

[AndyH] - I am assuming that the two peers could be using different TURN servers which is why the draft refers to a second TURN server. I am not sure sure I understand your comment or why this means that TURN/TCP might be needed could you expand on that?

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

[AndyH] - It could do and we don't want to try to get around this if DPI is deployed. However I believe that this provides a very significant increase to the chances of a successful webrtc connection. With regard to using the HTTP port then the port to be used is under the control of the webrtc application so any port could be used.

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

[AndyH] In the browser. I don't see how this opens up additional opportunities for the application to be malicious we are only talking about the transport for TURN allocations here.

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

[AndyH] Understood limited testing that we have done shows success with the HTTP Connect based mechanism but I would really like to hear from anybody with good stats.

> 
> 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: [email-masked]
> To: [email-masked]
> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/pntaw

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 4 Sep 2013 14:01:27 +0000

On: 01 September 2013 04:09 Bernard Aboba [mailto:[email-masked]] wrote:
> 
> I'd also mention that there is no reference to RFC 6156. With the
> deployment of IPv6 (and firewalls supporting it), scenarios requiring
> this are emerging, and we do want WebRTC to work in those cases.
> 

[AndyH] Agreed we will need to have a deeper look at IPV6 issues in a future update.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Sep 2013 08:12:19 -0700

[AndyH] - Agree and this was included for completeness my preference is for using TCP to the TURN server and possible we don't even need to use ICE-TCP.
[BA] As Harald has mentioned, support for ICE-TCP (RFC 6544) and TCP extensions to TURN (RFC 6062) is probably only needed for TCP peer-to-peer use.   However, many of the applications that could be implemented using P2P TCP (e.g. peer-to-peer chat, whiteboards, etc. ) can also be supported via the WebRTC data channel, and if done that way will be less likely to require a relay.  So while I can think of some things that might require TCP P2P (e.g. P2P websockets), it's hard to argue that these justify a MUST.   Overall, the recommendation in Section 5 requires more justification: 
   o  support ICE-TCP for TCP-based direct media connection to the
      RTCWEB peer.

> [AndyH] I am not sure sure I understand your comment or why this means that TURN/TCP might be needed could you expand on that?
[BA]  TURN over TCP/TLS with a UDP allocation (RFC 5766) can handle cases where the host cannot get UDP through the firewall, except perhaps in situations where the TURN allocations don't have UDP connectivity to each other (e.g. a firewall between them). 
However, if a WebRTC application hands out the same TURN server to both peers,  then you may end up with two TURN allocations on the same TURN server, so that a blockage is very unlikely. 

> [AndyH] - It could do and we don't want to try to get around this if DPI is deployed. However I believe that this provides a very significant increase to the chances of a successful webrtc connecti…
[BA]   Section 5 is entitled "Recommendations for RTCWEB-enabled browsers", but I think it needs to be a bit more specific about exactly what the browser needs to support.  For example:    o  connect to a TURN server via a HTTP proxy using the HTTP connect
      method,
[BA] How is the browser to know when it should do this? Is this to be configured in the API, or is it triggered automatically in certain conditions?   
   o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
      the default STUN ports 3478/5349,
Through use of the turn/turns URIs, the browser can be pointed to a different port.  Is this sufficient?  Are there implications for the TURN server as well?  As noted in RFC 5766, there are several ways to run TURN on a port different from the default:  
   By default, TURN runs on the same ports as STUN: 3478 for TURN over
   UDP and TCP, and 5349 for TURN over TLS.  However, TURN has its own
   set of Service Record (SRV) names: "turn" for UDP and TCP, and
   "turns" for TLS.  Either the SRV procedures or the ALTERNATE-SERVER
   procedures, both described in Section 6, can be used to run TURN on a
   different port.

> > Section 4.3> [AndyH] Understood limited testing that we have done shows success with the HTTP Connect based mechanism but I would really like to hear from anybody with good stats.
[BA] In my experience, the kind of customers who block UDP and TCP but allow HTTP are less permissive and therefore they also often deploy DPI as well.  So I am wondering whether that kind of customer is likely to support HTTP Connect.