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

["Hutton, Andrew" <[e-mail]>]

Hi Bernard,

Thanks for the comments some responses below.

Regards
Andy



> -----Original Message-----
> From: Bernard Aboba [mailto:[e-mail]]
> Sent: 01 September 2013 03:21
> To: Hutton, Andrew; [e-mail]
> 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: [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