< draft-hutton-rtcweb-nat-firewall-considerations-01.txt   draft-hutton-rtcweb-nat-firewall-considerations-02.txt >
Internet Engineering Task Force T. Stach, Ed. Internet Engineering Task Force T. Stach, Ed.
Internet-Draft A. Hutton Internet-Draft A. Hutton
Intended status: Informational Siemens Enterprise Communications Intended status: Informational Siemens Enterprise Communications
Expires: December 29, 2013 J. Uberti Expires: March 24, 2014 J. Uberti
Google Google
June 27, 2013 September 20, 2013
RTCWEB Considerations for NATs, Firewalls and HTTP proxies RTCWEB Considerations for NATs, Firewalls and HTTP proxies
draft-hutton-rtcweb-nat-firewall-considerations-01 draft-hutton-rtcweb-nat-firewall-considerations-02
Abstract Abstract
This document describes mechanism to enable media stream This document describes mechanism to enable media stream
establishment for Real-Time Communication in WEB-browsers (RTCWEB) in establishment for Real-Time Communication in WEB-browsers (WebRTC) in
the presence of network address translators, firewalls and HTTP the presence of network address translators, firewalls and HTTP
proxies. HTTP proxy and firewall policies applied in many private proxies. HTTP proxy and firewall deployed in many private network
network domains introduce obstacles to the successful establishment domains introduce obstacles to the successful establishment of media
of media stream via RTCWEB. This document examines some of these stream via WebRTC. This document examines some of these deployment
policies and develops requirements on the web browsers designed to scenarios and develops requirements on the web browsers designed to
provide the best possible chance of media connectivity between RTCWEB provide the best possible chance of media connectivity between WebRTC
peers. peers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2013. This Internet-Draft will expire on March 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Considerations for NATs/Firewalls independent of HTTP proxies 3 2. Considerations for NATs/Firewalls independent of HTTP proxies 4
2.1. NAT/Firewall open for outgoing UDP and TCP traffic . . . 3 2.1. NAT/Firewall open for outgoing UDP and TCP traffic . . . 4
2.2. NAT/Firewall open only for TCP traffic . . . . . . . . . 4 2.2. NAT/Firewall open only for TCP traffic . . . . . . . . . 4
2.3. NAT/Firewall open only for TCP-based HTTP(s) traffic . . 4 2.3. NAT/Firewall open only for TCP on restricted ports . . . 5
3. Considerations for NATs/Firewalls in presence of HTTP proxies 5 3. Considerations for NATs/Firewalls in presence of HTTP proxies 6
3.1. HTTP proxy with NAT/Firewall open for 3.1. HTTP proxy with NAT/Firewall open for
outgoing UDP and TCP traffic . . . . . . . . . . . . . . 5 outgoing UDP and TCP traffic . . . . . . . . . . . . . . 6
3.2. HTTP proxy with NAT/Firewall open only for TCP traffic . 5 3.2. HTTP proxy with NAT/Firewall open only for TCP traffic . 6
3.3. HTTP proxy assisted TURN server connection . . . . . . . 5 3.3. HTTP proxy assisted TURN server connection . . . . . . . 6
3.3.1. TURN server connection via TCP . . . . . . . . . . . 5 3.3.1. TURN server connection via TCP . . . . . . . . . . . 6
3.3.2. TURN server connection via UDP . . . . . . . . . . . 7 3.3.2. TURN server connection via UDP . . . . . . . . . . . 8
4. Other Approaches . . . . . . . . . . . . . . . . . . . . . . 7 4. Other Approaches . . . . . . . . . . . . . . . . . . . . . . 8
4.1. TURN server connection via WebSocket . . . . . . . . . . 7 4.1. TURN server connection via WebSocket . . . . . . . . . . 8
4.2. Port Control Protocol . . . . . . . . . . . . . . . . . . 7 4.2. Port Control Protocol . . . . . . . . . . . . . . . . . . 9
4.3. HTTP Fallback for RTP Media Streams . . . . . . . . . . . 7 4.3. HTTP Fallback for RTP Media Streams . . . . . . . . . . . 9
5. Requirements for RTCWEB-enabled browsers . . . . . . . . . . 8 5. Requirements for RTCWEB-enabled browsers . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
WebRTC is a web-based technique for direct interactive rich
communication using audio, video, and data between two peer browsers.
Many organizations, e.g. an enterprise, a public service agency or a Many organizations, e.g. an enterprise, a public service agency or a
university, deploy Network Address Translators (NAT) and firewalls university, deploy Network Address Translators (NAT) and firewalls
(FW) at the border to the public internet. RTCWEB relies on ICE (FW) at the border to the public internet. WebRTC relies on ICE
[RFC5245] in order to establish a media path between two RTCWEB peers [RFC5245] in order to establish a media path between two WebRTC peers
in the presence of such NATs/FWs. As last resort in order to cater in the presence of such NATs/FWs.
for NAT/FWs with address and port dependent filtering characteristics
[RFC4787], the peers will introduce a TURN server [RFC5766] in the When WebRTC is deployed by the corporate IT department one can assume
public internet as a media relay. Some use cases and requirements that the corporate IT configures the corporate NATs, Firewalls, DPI
relating to RTCWEB NAT/FW traversal can be found in units, TURN servers accordingly. If so desired by the organization
WebRTC media streams can then be established to WebRTC peers outside
of the organization subject to the applied policies. In order to
cater for NAT/FWs with address and port dependent mapping
characteristics [RFC4787], the peers will introduce a TURN server
[RFC5766] in the public internet as a media relay. Such a TURN
server could be deployed by the organization wanting to assert policy
on WebRTC traffic.
However, there are also environments that are not prepared for WebRTC
and have NAT/FW deployed that prevent the media stream establishment
although such blocking is not intentional. These environments
include e.g. internet cafes or hotels offering their customers access
to the web and have opened the well-known HTTP(S) ports but nothing
else. In such an environment ICE will fail to establish
connectivity. Re-configuration of the NAT/FW is also often
impracticable or not possible.
In such an environment a WebRTC user may easily reach its WebRTC
server possibly via an HTTP proxy and start establishing a WEBTRTC
session, but will become frustrated when a media connection cannot be
established. A corresponding use case and its requirements relating
to WebRTC NAT/FW traversal can be found in
[draft-ietf-rtcweb-use-cases-and-requirements]. [draft-ietf-rtcweb-use-cases-and-requirements].
If an organization wants to support RTCWEB such a TURN server may be The TURN server in the public internet is not sufficient to establish
located in the DMZ of the private network of that organization where connectivity for RTP-based media [RFC3550] and the WebRTC data
it is still under administrative control. channel [draft-ietf-rtcweb-data-channel] towards external WebRTC
peers since the FW policies include blocking of all UDP based traffic
and allowing only traffic to the TCP ports 80/443 with the intent to
support HTTP(S) [RFC2616].
In certain environments with very restrictive FW policies a TURN We explicitly don't address even more restricted environments, that
server in the public internet may not be sufficient to establish deploy HTTP traffic validation. This could e.g. be done by means of
connectivity towards the RTCWEB peer for RTP-based media [RFC3550]. DPI validation or traffic pattern analysis to determine the contents
Such policies can include blocking of all UDP based traffic and of the packets that the traffic is, in fact, HTTP or HTTPS-looking or
allowing only HTTP(S) traffic to the TCP ports 80/443. In addition by an HTTP proxy that breaks into the TLS exchange and looks for HTTP
access to the World Wide Web from inside an organization is often in the traffic. However we want to address the case when access to
only possible via a HTTP proxy. the World Wide Web from inside an organization is only possible via a
transparent HTTP Proxy that just tunnels traffic after e.g. enforcing
an acceptable use policy.
This document examines impact of NAT/FW policies in Section 2. This document examines impact of NAT/FW policies in Section 2.
Additional impacts due to the presence of a HTTP proxy are examined Additional impacts due to the presence of a HTTP proxy are examined
in Section 3. in Section 3.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Considerations for NATs/Firewalls independent of HTTP proxies 2. Considerations for NATs/Firewalls independent of HTTP proxies
This section covers aspects of how NAT/FW characteristic influence This section covers aspects of how NAT/FW characteristic influence
the establishment of a media stream. Additional aspects introduced the establishment of a media stream. Additional aspects introduced
by the presence of a HTTP proxy are covered in Section 3. by the presence of a HTTP proxy are covered in Section 3.
If the NATs serving caller and callee both show port and address If the NATs serving caller and callee both show port and address
dependent filtering behavior the need for a TURN server arises in dependent mapping behavior the need for a TURN server arises in order
order to establish connectivity for media streams. The TURN server to establish connectivity for media streams. The TURN server will
will relay the RTP packet to the RTCWEB peer using UDP. How the RTP relay the RTP packet to the WebRTC peer using UDP. How the RTP
packets can be transported from the RTCWEB client within the private packets can be transported from the WebRTC client within the private
network to the TURN server depends on what the firewall will let pass network to the TURN server depends on what the firewall will let pass
through. through.
Other types of NATs do not require using the TURN relay. Other types of NATs do not require using the TURN relay.
Nevertheless, the FW rules and policies still affect how media Nevertheless, the FW rules and policies still affect how media
streams can be established. streams can be established.
2.1. NAT/Firewall open for outgoing UDP and TCP traffic 2.1. NAT/Firewall open for outgoing UDP and TCP traffic
This scenario assumes that the NAT/FW is transparent for all outgoing This scenario assumes that the NAT/FW is transparent for all outgoing
traffic independent of using UDP or TCP as transport protocol. This traffic independent of using UDP or TCP as transport protocol. This
case is used as starting point for introduction of more restrictive case is used as starting point for introduction of more restrictive
firewall policies. It presents the least critical example with firewall policies. It presents the least critical example with
respect to the establishment of the media streams. respect to the establishment of the media streams.
The TURN server can be reached directly from within the private The TURN server can be reached directly from within the private
network via the NAT/FW and the ICE procedures will reveal that media network via the NAT/FW and the ICE procedures will reveal that media
can be sent via the TURN server. The TURN client will send its media can be sent via the TURN server. The TURN client will send its media
to the allocated resources at the TURN server via UDP. to the allocated resources at the TURN server via UDP.
Dependent on the port range that is used for RTCWEB media streams, Dependent on the port range that is used for WebRTC media streams,
the same statement would be true if the NAT/Firewall would allow UDP the same statement would be true if the NAT/Firewall would allow UDP
traffic for a restricted UDP port range only. traffic for a restricted UDP port range only.
2.2. NAT/Firewall open only for TCP traffic 2.2. NAT/Firewall open only for TCP traffic
This scenario assumes that the NAT/FW is transparent for outgoing This scenario assumes that the NAT/FW is transparent for outgoing
traffic only using TCP as transport protocol. This gives two options traffic only using TCP as transport protocol. Theoretically, this
for media stream establishment dependent on the NAT's filtering gives two options for media stream establishment dependent on the
characteristics. Either transport RTP over TCP or contacting the NAT's mapping characteristics. Either transporting RTP over TCP
TURN server via TCP. directly to the peer or contacting a TURN server via TCP that then
relays RTP.
In the first case the browser needs to use ICE-TCP [RFC6544] and In the first case the browser does not use any TURN server to get
provide active, passive and/or simultaneous-open TCP candidates. through its NAT/FW. However, the browser needs to use ICE-TCP
Assuming the peer also provides TCP candidates, a connectivity check [RFC6544] and provide active, passive and/or simultaneous-open TCP
for a TCP connection between the two peers should be successful. candidates. Assuming the peer also provides TCP candidates, a
connectivity check for a TCP connection between the two peers should
be successful.
In the second case the browser needs to contact the TURN server via In the second case the browser contacts the TURN server via TCP for
TCP for allocation of an UDP-based relay address at the TURN server. allocation of an UDP-based relay address at the TURN server. The ICE
The ICE procedures will reveal that RTP media can be sent via the procedures will reveal that RTP media can be sent via the TURN relay
TURN relay using the TCP connection between TURN client and TURN using the TCP connection between TURN client and TURN server. The
server. The TURN server would then relay the RTP packets using UDP, TURN server would then relay the RTP packets using UDP, as well as
as well as other UDP-based protocols. ICE-TCP is not needed in this other UDP-based protocols. ICE-TCP is not needed in this context.
context.
Note that the second case is not to be mixed up with TURN/TCP Note that the second case is not to be confused with TURN/TCP
[RFC6062], which deals with how to establish a TCP connection to the [RFC6062], which deals with how to establish a TCP connection from a
peer. For this document we assume that the TURN server can reach the TURN server to the peer. For this document we assume that the TURN
peer always via UDP, possibly via a second TURN server. server can reach the peer always via UDP, possibly via a second TURN
server, in case the WebRTC peer is located in a similar environment
as described in this section.
2.3. NAT/Firewall open only for TCP-based HTTP(s) traffic We don't see a need to support TURN/TCP since all WebRTC media is
transported over UDP. For the same reason we also prefer using TCP
just as transport to the TURN server over using the ICE-TCP with an
end-to-end TCP connection
In this case the firewall blocks all outgoing traffic except for TCP 2.3. NAT/Firewall open only for TCP on restricted ports
traffic to port 80 for HTTP or 443 for HTTPS. A TURN server
listening to its default ports (3478 for TCP/UDP, 5349 for TLS) would
not be reachable in this case.
In this case the firewall blocks all outgoing traffic except for TCP
traffic to specific ports, for example port 80 (HTTP) for HTTP or 443
for HTTPS(HTTPS). A TURN server listening to its default ports (3478
for TCP/UDP, 5349 for TLS) would not be reachable in this case.
However, the TURN server can still be reached when it is configured However, the TURN server can still be reached when it is configured
to listen to the HTTP(S) ports as well. In addition the RTCWEB to listen to e.g. the HTTP(S) ports.
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 Open issue: Although
accordingly. [draft-ietf-rtcweb-use-cases-and-requirements] considers only a
restriction to HTTP(S) similar consideration apply to other ports
or port ranges. A change to req F37 to "The browser must be able
to send streams and data to a peer in the presence of FWs that
only allows traffic via a HTTP Proxy." has been agreed and will be
in the next update does this solve the issue.
In addition the browser needs to be configured to contact the TURN
server over the HTTP(S) ports and/or the WebRTC client has to tell
the browser accordingly.
3. Considerations for NATs/Firewalls in presence of HTTP proxies 3. Considerations for NATs/Firewalls in presence of HTTP proxies
This section considers a scenario where all HTTP(S) traffic is routed This section considers a scenario where all HTTP(S) traffic is routed
via an HTTP proxy. Note: If both RTCWEB clients are located behind via an HTTP proxy. We assume that the HTTP proxy is tranparent and
the same HTTP proxies, we, of course, assume that ICE would give us a just tunnels traffic after e.g. enforcing an acceptable use policy
direct media connection within the private network. We consider this with respect to domains that are allowed to be reached. We don't
case as out of the scope of this document. consider cases where the HTTP proxy is used to deploy HTTP traffic
validation. This includes DPI validation that the traffic is, in
fact, HTTP or HTTPS-looking or a HTTP proxy that breaks into the TLS
exchange and looks for HTTP in the traffic.
Note: If both WebRTC clients are located behind the same HTTP proxy,
we, of course, assume that ICE would give us a direct media
connection within the private network. We don't consider this case
in detail within this document.
3.1. HTTP proxy with NAT/Firewall open for outgoing UDP and TCP traffic 3.1. HTTP proxy with NAT/Firewall open for outgoing UDP and TCP traffic
As in Section 2.1 we assume that the NAT/FW is transparent for all As in Section 2.1 we assume that the NAT/FW is transparent for all
outgoing traffic independent of using UDP or TCP as transport outgoing traffic independent of using UDP or TCP as transport
protocol. The HTTP proxy has no impact on the transport of media protocol. The HTTP proxy has no impact on the transport of media
streams in this case. Consequently, the same considerations as in streams in this case. Consequently, the same considerations as in
Section 2.1 apply with respect to the traversal of the NAT/FW. Section 2.1 apply with respect to the traversal of the NAT/FW.
3.2. HTTP proxy with NAT/Firewall open only for TCP traffic 3.2. HTTP proxy with NAT/Firewall open only for TCP traffic
skipping to change at page 5, line 34 skipping to change at page 6, line 42
outgoing TCP traffic. The HTTP proxy has no impact on the transport outgoing TCP traffic. The HTTP proxy has no impact on the transport
of media streams in this case. Consequently, the same considerations of media streams in this case. Consequently, the same considerations
as in Section 2.2 apply with respect to the traversal of the NAT/FW. as in Section 2.2 apply with respect to the traversal of the NAT/FW.
3.3. HTTP proxy assisted TURN server connection 3.3. HTTP proxy assisted TURN server connection
3.3.1. TURN server connection via TCP 3.3.1. TURN server connection via TCP
Different from the previous scenarios, we assume that the NAT/FW Different from the previous scenarios, we assume that the NAT/FW
accepts outgoing traffic only via a TCP connection that is initiated accepts outgoing traffic only via a TCP connection that is initiated
from the HTTP proxy. Consequently, a RTCWEB client would have to use from the HTTP proxy. Consequently, a browser would have to use the
the HTTP CONNECT method [RFC2616] in order to get access to the TURN HTTP CONNECT method [RFC2817] and request that the HTTP proxy
server via the HTTP proxy. The HTTP CONNECT request needs to convey establishes a tunnel connection on its behalf in order to get access
the TURN Server URI or transport address. As a result the HTTP Proxy to the TURN server. The HTTP CONNECT request needs to convey the
will establish a TCP connection to the TURN server, i.e. the TURN TURN Server URI or transport address. As a result the HTTP Proxy
server only has to handle a standard TCP connection and an update to will establish a TCP connection to the TURN server and when
successful the HTTP Proxy will answer the HTTP CONNECT request with a
200OK response. In case of a transparent proxy, the HTTP proxy will
now switch into tunneling mode and will transparently relay the
traffic to the TURN server.
We want to emphasize that by using the HTTP CONNECT method, the TURN
server only has to handle a standard TCP connection. An update to
the TURN protocol or the TURN software is not needed. the TURN protocol or the TURN software is not needed.
Afterwards, the RTCWEB client could upgrade the connection to use Open Issue: This assumes that the HTTP Proxy can handle
TLS, forward STUN/TURN traffic via the HTTP proxy and use the TURN establishing the TCP connection to the STUN ports 3478/5349. The
server as media relay. Note that upgrading in this case is not to be syntax of the Request-URI certainly allows this, but is this also
supported in the major HTTP proxy implementations? Section 4.3.6
of [draft-ietf-httpbis-p2-semantics] describes tunneling to ports
other than 80/443 and the corresponding security impacts.
Afterwards, the browser 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 misunderstood as usage of the HTTP UPGRADE method as specified in
[RFC2817] as this would require the TURN server to support HTTP. We [RFC2817] as this would require the TURN server to support HTTP. We
rather envisage the following sequence: rather envisage the following sequence:
o the browser opens a TCP connection to the HTTP proxy, o the browser opens a TCP connection to the HTTP proxy,
o the browser issues a HTTP CONNECT request to the HTTP proxy with o the browser issues a HTTP CONNECT request to the HTTP proxy with
the TURN server address in the Request URI, the TURN server address in the Request URI, for example
CONNECT turn_server.example.com:5349 HTTP/1.1 Host:
turn_server.example.com:5349
o the HTTP proxy opens a TCP connection to the TURN server and o the HTTP proxy opens a TCP connection to the TURN server and
"bridges" the incoming and outgoing TCP connections together, "bridges" the incoming and outgoing TCP connections together,
forming a virtual end-to-end TCP connection, forming a virtual end-to-end TCP connection,
o the browser can do a TLS handshake over the virtual end-to-end TCP o the browser can do a TLS handshake over the virtual end-to-end TCP
connection with the TURN server. connection with the TURN server.
If it is not possible to use HTTP CONNECT in this way it will not be If it is not possible to use HTTP CONNECT in this way it will not be
possible to establish connectivity between the RTCWEB peers and the possible to establish connectivity between the WebRTC peers and the
ICE connectivity checks will fail. ICE connectivity checks will fail.
Strictly speaking the TLS upgrade is not necessary, but using TLS Strictly speaking the TLS upgrade is not necessary, but using TLS
would also prevent the HTTP proxy from sniffing into the data stream would also prevent the HTTP proxy from sniffing into the data stream
and provides the same flow as HTTPS and might improve and provides the same flow as HTTPS and might improve
interoperability with proxy servers. Some tests (done a while ago) interoperability with proxy servers. Some tests (done a while ago)
indicated that there are proxies performing Deep Packet inspection indicated that there are proxies performing Deep Packet inspection
(DPI) that expect to see at least a SSL handshake and, possibly, (DPI) that expect to see at least a TLS handshake and, possibly,
valid SSL records. The application has the ability to control valid TLS records. The application has the ability to control
whether SSL is used by the parameters it supplies to the TURN URI whether TLS is used by the parameters it supplies to the TURN URI
(e.g. turns: vs. turn:), so the decision to do TURN/TCP to port 443 (e.g. turns: vs. turn:), so the decision to access the TURN server
versus TURN/TLS to port 443 could be left up to the application or via TCP versus TLS could be left up to the application or possibly
possibly the browser configuration script. the browser configuration script.
In contrast to using UDP or TCP for transporting the STUN messages, In contrast to using UDP or TCP for transporting the STUN messages,
the browser would now need to first establish a HTTP over TCP the browser would now need to first establish a HTTP over TCP
connection to the HTTP proxy, upgrade to using TLS and then switch to connection to the HTTP proxy, upgrade to using TLS and then switch to
using this TLS connection for transport of STUN messages. It is also using this TLS connection for transport of STUN messages. It is also
desirable that the browser detects the need to connect to the TURN desirable that the browser detects the need to connect to the TURN
server through a HTTP proxy automatically in order to achieve server through a HTTP proxy automatically in order to achieve
seamless deployment and interoperability. The browser should use the seamless deployment and interoperability. The browser should use the
same proxy selection procedure for TURN as currently done for HTTP. same proxy selection procedure for TURN as currently done for HTTP.
The user or network administrator should not be required to change The user or network administrator should not be required to change
browser or proxy script configuration. browser or proxy script configuration.
Further considerations apply to the default connection timeout of the Further considerations apply to the default connection timeout of the
HTTP proxy connection to the TURN server and the timeout of the TURN HTTP proxy connection to the TURN server and the timeout of the TURN
server allocation. Whereas [RFC5766] specifies a 10 minutes default server allocation. Whereas [RFC5766] specifies a 10 minutes default
lifetime of the TURN allocation, typical proxy connection lifetimes lifetime of the TURN allocation, typical proxy connection lifetimes
are in the range of 60 seconds if no activity is detected. Thus, if are in the range of 60 seconds if no activity is detected. Thus, if
the RTCWEB client wants to pre-allocate TURN ressources it needs to the WebRTC client wants to pre-allocate TURN ressources it needs to
refresh TURN allocations more frequently in order to keep the TCP refresh TURN allocations more frequently in order to keep the TCP
connection to its TURN server alive. connection to its TURN server alive.
3.3.2. TURN server connection via UDP 3.3.2. TURN server connection via UDP
If a local TURN server under administrative control of the If a local TURN server under administrative control of the
organization is deployed it is desirable to reach this TURN server organization is deployed it is desirable to reach this TURN server
via UDP. The TURN server could be specified in the proxy via UDP. The TURN server could be specified in the proxy
configuration script, giving the browser the possibility to learn how configuration script, giving the browser the possibility to learn how
to access it. Then, when gathering candidates, this TURN server to access it. Then, when gathering candidates, this TURN server
would always be used such that the RTCWEB client application could would always be used such that the WebRTC client application could
get UDP traffic out to the internet. get UDP traffic out to the internet.
4. Other Approaches 4. Other Approaches
4.1. TURN server connection via WebSocket 4.1. TURN server connection via WebSocket
The RTCWEB client could connect to a TURN server via WebSocket The WebRTC client could connect to a TURN server via WebSocket
[RFC6455] as described in [draft-chenxin-behave-turn-WebSocket]. [RFC6455] as described in [draft-chenxin-behave-turn-WebSocket].
This might have benefits in very restrictive environments where HTTPS This might have benefits in very restrictive environments where HTTPS
is not permitted through the proxy. However, such environments are is not permitted through the proxy. However, such environments are
also likely to deploy DPI boxes which would eventually complain also likely to deploy DPI boxes which would eventually complain
against usage of WebSocket or block RTCWEB traffic based on other against usage of WebSocket or block WebRTC traffic based on other
heuristic means. It is also to be expected that an environment that heuristic means. It is also to be expected that an environment that
does not allow HTTPS will also forbid usage of WebSocket over TLS. does not allow HTTPS will also forbid usage of WebSocket over TLS.
In addition, usage of TURN over WebSocket puts an additional burden In addition, usage of TURN over WebSocket puts an additional burden
on existing TURN server implementation to support HTTP and WebSocket. on existing TURN server implementation to support HTTP and WebSocket.
The resulting benefit seems rather small, thus TURN over WebSocket is The resulting benefit seems rather small, thus TURN over WebSocket is
left for further study. left for further study.
4.2. Port Control Protocol 4.2. Port Control Protocol
skipping to change at page 8, line 7 skipping to change at page 9, line 28
relay. However, it uses HTTP GET and POST requests to receive and relay. However, it uses HTTP GET and POST requests to receive and
send RTP packets. send RTP packets.
Despite a number of open issues, the proposal addreses some corner Despite a number of open issues, the proposal addreses some corner
cases. However, the expected benefit in form of an increased success cases. However, the expected benefit in form of an increased success
rate for establishment of a media stream seems rather small, thus rate for establishment of a media stream seems rather small, thus
HTTP fallback is left for further study. HTTP fallback is left for further study.
5. Requirements for RTCWEB-enabled browsers 5. Requirements for RTCWEB-enabled browsers
For the purpose of relaying RTCWEB media streams or data channels a For the purpose of relaying WebRTC media streams or data channels a
browser needs to be able to browser needs to be able to
o connect to a TURN server via UDP, TCP and TLS, o connect to a TURN server via UDP, TCP and TLS,
o connect to a TURN server via a HTTP proxy using the HTTP connect o support the HTTP CONNECT method and request that a proxy establish
method, a tunneled TCP connection to a TURN server on its behalf,
o connect to a TURN server via the HTTP(s) ports 80/443 instead of o connect to a TURN server through this HTTP proxy-tunnelled TCP
the default STUN ports 3478/5349, connection,
o upgrade the HTTP proxy-relayed connection to the TURN server to o connect to the TURN server via application specified ports other
than the default STUN ports including the HTTP(s) ports,
Open issue: Do we want to allow the TURN server to relay data
received via the HTTP(S) ports? Is this a change to the TURN
protocol, that needs work to be done in the BEHAVE WG?
o upgrade the HTTP proxy-tunneled connection to the TURN server to
use TLS, use TLS,
o use the same proxy selection procedure for TURN as currently done o use the same proxy selection procedure for TURN as currently done
for HTTP, for HTTP (e.g. Web Proxy Autodiscovery Protocol (WPAD) and .pac-
files for Proxy-Auto-Config),
o switch the usage of the HTTP proxy-relayed connection with the o switch the usage of the HTTP proxy-tunneled connection with the
TURN server from HTTP to STUN/TURN, TURN server from HTTP to STUN/TURN,
Note: Usually, the browser would send further HTTP requests
over HTTP proxy-tunneled connection. Here, the connection in
just established using HTTP CONNECT, but afterwards used for
STUN/TURN messages.
o use a preconfigured or standardized port range for UDP-based media o use a preconfigured or standardized port range for UDP-based media
streams or data channels, streams or data channels,
o learn from the proxy configuration script about the presence of a o learn from the proxy configuration script about the presence of a
local TURN server and use it for sending UDP traffic to the local TURN server and use it for sending UDP traffic to the
internet, internet,
o support ICE-TCP for TCP-based direct media connection to the o as an option and if needed, support ICE-TCP for TCP-based direct
RTCWEB peer. media connection to the WebRTC peer.
6. Acknowledgements 6. Acknowledgements
The authors want to thank Heinrich Haager for all his input during The authors want to thank Heinrich Haager for all his input during
many valuable discussions. many valuable discussions.
Furthermore, the authors want to thank for comments and suggestions Furthermore, the authors want to thank for comments and suggestions
received from ... received from Bernard Aboba, Xavier Marjou, Dan Wing, ...
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
TBD TBD
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/
1.1", RFC 2817, May 2000. 1.1", RFC 2817, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
skipping to change at page 9, line 38 skipping to change at page 11, line 22
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
9.2. Informative References
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", RFC around NAT (TURN) Extensions for TCP Allocations", RFC
6062, November 2010. 6062, November 2010.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, December 2011. 6455, December 2011.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012. Establishment (ICE)", RFC 6544, March 2012.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013. 2013.
[draft-chenxin-behave-turn-WebSocket] [draft-chenxin-behave-turn-WebSocket]
Xin. Chen , "Traversal Using Relays around NAT (TURN) Xin. Chen , "Traversal Using Relays around NAT (TURN)
Extensions for WebSocket Allocations ", 2013, <http:// Extensions for WebSocket Allocations ", 2013, <http://
tools.ietf.org/html/draft-chenxin-behave-turn-WebSocket>. tools.ietf.org/html/draft-chenxin-behave-turn-WebSocket>.
[draft-ietf-httpbis-p2-semantics]
R. Fielding, J. Reschke , "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content ", 2013, <http://
tools.ietf.org/html/draft-ietf-
httpbis-p2-semantics-23#section-4.3.6>.
[draft-ietf-rtcweb-data-channel]
R. Jesup, S. Loreto, M. Tuexen , "RTCWeb Data Channels ",
2013, <http://tools.ietf.org/html/draft-ietf-rtcweb-data-
channel>.
[draft-ietf-rtcweb-use-cases-and-requirements] [draft-ietf-rtcweb-use-cases-and-requirements]
C. Holmberg, S. Hakansson, G. Eriksson , "Web Real-Time C. Holmberg, S. Hakansson, G. Eriksson , "Web Real-Time
Communication Use-cases and Requirements ", 2012, <http:// Communication Use-cases and Requirements ", 2013, <http://
tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and- tools.ietf.org/html/draft-ietf-WebRTC-use-cases-and-
requirements>. requirements>.
[draft-miniero-rtcweb-http-fallback] [draft-miniero-rtcweb-http-fallback]
L. Miniero , "HTTP Fallback for RTP Media Streams ", 2012, L. Miniero , "HTTP Fallback for RTP Media Streams ", 2012,
<http://tools.ietf.org/html/draft-miniero-rtcweb-http- <http://tools.ietf.org/html/draft-miniero-rtcweb-http-
fallback>. fallback>.
Authors' Addresses Authors' Addresses
Thomas Stach (editor) Thomas Stach (editor)
 End of changes. 47 change blocks. 
122 lines changed or deleted 217 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/