One document matched: draft-jennings-behave-rtcweb-firewall-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.26 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-jennings-behave-rtcweb-firewall-00" category="info">

  <front>
    <title abbrev="WebRTC Firewall">Firewall Traversal for WebRTC</title>

    <author initials="C." surname="Jennings" fullname="Cullen Jennings">
      <organization>Cisco</organization>
      <address>
        <email>fluffy@iii.ca</email>
      </address>
    </author>
    <author initials="S." surname="Nandakumar" fullname="Suhas Nandakumar">
      <organization>Cisco</organization>
      <address>
        <email>snandaku@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg">
      <organization>Cisco</organization>
      <address>
        <email>jdrosen@cisco.com</email>
      </address>
    </author>

    <date year="2015" month="July" day="06"/>

    <area>Art</area>
    <workgroup>rtcweb</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Traversal of RTP through corporate firewalls has traditionally been
complex, requiring the deployment of Session Border Controllers (SBCs)
or wide open pinholes. This draft proposes a simple technique that
allows WebRTC based RTP traffic to traverse firewalls without complex
firewall configuration and without deployment of SBCs or other
middleboxes.</t>



    </abstract>


  </front>

  <middle>


<section anchor="problem-statement" title="Problem Statement">

<t>WebRTC <xref target="I-D.ietf-rtcweb-overview"/> based voice and video
communications systems are becoming far more common inside
enterprises, which often
need voice and video media to traverse the enterprise firewall. This
can happen when a device inside the firewall such as a web browser
or phone is exchanging media with a conference bridge or gateway
outside the firewall, or it can happen when a device inside the
firewall is talking to a device in another enterprise or behind a
different firewall.</t>

<t>This problem is not unique to WebRTC media of course. It is common
practice for enterprise administrators to block outbound UDP through
the corporate firewall. This is done for several reasons:</t>

<t><list style="numbers">
  <t>The lack of any kind of return messages means that there is no way
to know that the recipient of the UDP traffic really wants
it. Infected computers within the enterprise could utilize UDP as the
source of a DDoS attack. If the firewall permitted such outbound
traffic, the enterprise could in effect be a contributing source to
such an attack. By blocking UDP, the enterprise IT admin ensures that
this cannot happen - at least not to external targets.</t>
  <t>There have been prior attacks that have utilized UDP as a
command and control channel for orchestrating DDoS attacks. At the
time, UDP had little usage within enterprises (most VoIP was
internal to the enterprise when it existed at all). Consequently,
infosec departments have deemed it safer to block UDP outright in order to
prevent such further incidents.</t>
  <t>Many IT administrators enable various packet inspection operations
on traffic flowing through the firewall. High volume UDP traffic -
such as voice or video - can
be costly to inspect. As such, in cases where there is a need for
traversal of such traffic, IT has preferred to deploy an SBC that, in
essence, verifies that the traffic is VoIP and authorizes its
egress. The IT administrator then enables traffic to/from the SBC
through the firewall. In other words, VoIP authorization is delegated
to an outsourced SBC.</t>
</list></t>

<t>As more and more IP communications services move to the cloud, there is an
increased need for VoIP traffic to traverse the enterprise
firewall. At the same time, the entire point of a cloud service is
that it does not require the deployment of on premises
infrastructure, making SBC-based solutions less desirable. An
alternative solution that has been historically used is to enable
outbound UDP in the firewall to specific IP addresses, corresponding
to the external service (TURN servers or conference servers) that the
enterprise wishes to authorize. With more applications running on
virtual machines within cloud compute platforms like Amazon EC2, IP
addresses are decreasingly usable as identifiers for a
service. VMs running TURN servers or conferencing servers may be
established and torn down by the day, hour or even minute, with
continuously changing IP addresses. Given the multitenant nature of
such providers, IT departments are unwilling to whitelist the IP
addresses for the entire block used by such providers.</t>

<t>Consequently, there is a growing need for solutions
that allow VoIP traversal through the corporate firewall that
alleviate the concerns above. This issue is further exacerbated by the
growing adoption of WebRTC by enterprise applications, which provide a
ready source of RTP traffic which often needs to traverse the
firewall.</t>

</section>
<section anchor="solution-requirements" title="Solution Requirements">

<t>We believe the solution must meet the following requirements:</t>

<t>REQ-1: The solution must enable traversal of real-time media without
requiring deployment of additional media intermediaries on premise
(e.g., no SBC required)</t>

<t>REQ-2: The solution must not require the whitelisting of specific
external IP addresses</t>

<t>REQ-3: The solution must enable the enterprise to be sure that the
receiving party of the traffic desires the traffic</t>

<t>REQ-4: The solution must work with P2P calls between users in
different enterprises without requiring a TURN server</t>

<t>REQ-5: The solution must work with cloud services external to the
enterprise which terminate media on servers, such as conference
servers, voicemail servers, recording servers, and so on.</t>

<t>REQ-6: The solution must not require decryption of either signalling or
media traffic at the firewall or at any other intermediary</t>

<t>REQ-7: The solution must allow the IT department to easily make policy
decisions about which applications are allowed, or not allowed, to
traverse the firewall</t>

<t>REQ-8: The solution must not require DPI of every single UDP packet
that traverses the firewall</t>

<t>REQ-9: The solution must provide a minimum level of proof that the
traffic is RTP and not something else</t>

<t>REQ-10: The solution must work with WebRTC traffic. Note that solving
this for non-WebRTC is a non-requirement.</t>

</section>
<section anchor="solution-overview" title="Solution Overview">

<t>Many of the reasons for blocking UDP at the corporate firewall have
their origins in the lack of a three-way handshake for UDP
traffic. TCP’s three-way handshake ensures that the receiving party of
the connection desires the traffic. Similarly, HTTP traffic easily
traverses the firewall since it provides application identification
information in the URL.</t>

<t>Consequently, the solution proposed here relies on the ICE
connectivity checks, which provide a similar handshake and ensure
consent of the remote party. When a firewall sees an outbound UDP
packet on a 5-tuple which is not yet authorized, it begins looking for
STUN packets (as identified by the STUN magic cookie). Any outbound
packet that is not a STUN packet is discarded. Once an outbound STUN
packet is identified, the 5-tuple is put in a pending state, and the
firewall begins looking for STUN packets among inbound UDP
packets. When it sees one, it matches the transaction IDs to ensure
that they are correlated. Once matched, the 5-tuple is placed into an
authorized state, and UDP traffic is allowed to freely traverse.</t>

<t>In addition, the initial outbound STUN packets contain the STUN ORIGIN
field which the firewall can use to make an authorization decision on
the application.</t>

</section>
<section anchor="firewall-processing" title="Firewall Processing">

<t>The firewall processing is broken into three stages: recognizing STUN
packets, making a policy decision as to whether each STUN packet should
trigger a pinhole to be created, and managing the lifetime of any
pinholes that are created.</t>

<section anchor="recognizing-stun-packets" title="Recognizing STUN packets">

<t>STUN messages all have a magic cookie value of 0x2112A442 in the 4th
to 8th byte. This can be used to quickly filter nearly all UDP packets
that are not STUN packets. Many firewalls are capable of doing this
in hardware. STUN supports an optional FINGERPRINT attribute that provides
a 32 bit CRC over the message.</t>

<t>Firewalls SHOULD look at outbound UDP packets and if they have the
correct magic cookie they can classify them as STUN packets. Firewalls
that desire fewer false positives MAY also check that the FINGERPRINT
attribute is correct.</t>

</section>
<section anchor="policy-decision" title="Policy decision">

<t>Once the firewall has received a STUN packet from inside the firewall,
it needs to decide if the packet is acceptable. For most situations
the firewall SHOULD accept all outbound STUN packets. This is similar
to allowing all outbound TCP flows. Some firewalls may choose to look at
other factors including the outside UDP port and the ORIGIN attribute
in the STUN packet.</t>

<t>In general WebRTC media can be sent on a wide range of UDP ports but
the two ports that are commonly used are the the RTP port (5004) and
TURN port (3478). Some firewalls MAY choose to only allow flows where
the destination port on the outside of the firewall is one of these.</t>

<t>The STUN ORIGIN attribute <xref target="I-D.ietf-tram-stun-origin"/> carries the
origin of the web page that caused the various STUN requests. So for
example, if a browser was on a page such as example.com and that page
used the WebRTC calls to set up a connection, the STUN request’s ORIGIN
attribute would include example.com. This allows the firewall to see the
web application (in this case, example.com) that is requesting the
pinhole be opened. The firewall MAY have a white list or black list
for domains in STUN ORIGIN.</t>

</section>
<section anchor="creating-the-pinhole-rules" title="Creating the pinhole rules">

<t>Once a STUN packet is accepted, the firewall MUST create a temporary
rule that allows incoming and outgoing packets for that 5-tuple for
at least 5 seconds. If in that 5 seconds, a response is received to
the STUN request, the lifetime of the rule must be extended to at
least 30 seconds from last accepted STUN packet from inside the
firewall. Once the rule has been extended to 30 seconds the first time, any additional UDP
packets from inside the firewall MUST extend the lifetime of the rule
by at least 30 seconds from the time that packet was received. The
procedures in <xref target="I-D.ietf-rtcweb-stun-consent-freshness"/> will ensure
that an outbound packet is sent at least every 30 seconds.</t>

</section>
<section anchor="tracking-media-vs-data" title="Tracking media vs data">

<t>WebRTC can send audio and video as well as carry a data
channel. Confidential data could leave an enterprise by a video camera
being pointed at a document, but IT departments are often more
concerned about the data channel. It is easy for the firewall to
separately track the amount of RTP media and non-media data for each
WebRTC flow. If the first byte of the UDP message is 23, it is non-media data; if it is in the range 127 to 192 
it is audio or video data. More information about this can be found in
<xref target="I-D.ietf-avtcore-rfc5764-mux-fixes"/>. Network management systems on 
the firewall can track these two separately which can help identify 
unusual usage.</t>

</section>
</section>
<section anchor="webrtc-browsers" title="WebRTC Browsers">

<t>This specification would require browsers to include the FINGERPRINT
and ORIGIN attributes in STUN for this to work correctly.</t>

<t>Open Issue: Does adding the ORIGIN reduce user privacy? Consider the
following case. The user goes to https://facebook.com and initiates a
call with another Facebook user. The domain facebook.com will appear
(unencrypted) in the STUN packets sent from the browser to
Facebook’s TURN server. Anyone along the network path could tell that
the user is using Facebook’s TURN server. However, when the original
TLS connection for the HTTP was made, the Server Name Indication (SNI)
in the TLS of the HTTPS connection also revealed facebook.com,
largely for the same reasons - so that the firewall would be able
to see which applications are using the network.</t>

</section>
<section anchor="blocking-media-hiding-in-http" title="Blocking Media Hiding in HTTP">

<t>The IETF is designing systems to send interactive audio and video such
that it looks like HTTPS and HTTP to the proxies and firewalls.  The
reasons for doing this is that sometimes the proxies and firewalls
allow this to work when the mechanisms and channels designed for
sending audio and video data have been explicitly disabled by the
firewall administrators. Many firewall administrators feel this
circumvents the policy they are trying to enforce and desire a way to
prevent this. Any scheme for preventing this has some risk of
impacting normal HTTP traffic, so there is a desire to provide guidance
around ways to do that in this draft.</t>

<t>Any HTTP or HTTPS connection that sends more than 10 requests per
second for longer than 10 seconds should be paused for 1 second, and
any HTTP/S requests from that client’s IP address in the 1 second pause
time should be buffered or simply dropped. This strategy ensures there
is no impact to clients other than the one exceeding the rate limit and
minimizes the impact to other applications on the device while still
reducing the incentive to try and run calls this way.</t>

</section>
<section anchor="deployment-advice" title="Deployment Advice">

<section anchor="webrtc-servers" title="WebRTC Servers">

<t>WebRTC media servers and TURN servers with public IP address(es) that
can receive incoming packets from anywhere on the Internet are
suggested to listen for UDP on ports 53 (DNS), 123 (NTP), and 5004
for RTP media servers and 3478 for TURN servers. UDP destined for port
53 or 123 if often allowed by firewalls that otherwise block UDP.</t>

</section>
<section anchor="firewall-admins" title="Firewall Admins">

<t>Often the approach has been to lock down everything, so that all UDP is blocked. This simply
causes applications to do things like embed the data in normal looking
HTTP or HTTPS requests. Malware and viruses use similar
approaches. Just turning off all UDP results in a poor user experience
some of the time, which results in users moving to applications and
devices outside the firewall. The IT department loses the visibility
into what is going on and can no longer protect its users when their
computers become compromised. Allowing things that users want to use
to work and monitoring them to detect when things have gone wrong is very valuable.</t>

</section>
</section>
<section anchor="design-consideration" title="Design Consideration">

<section anchor="why-not-just-use-tcp" title="Why not just use TCP?">

<t>TODO</t>

</section>
</section>
<section anchor="security-concerns" title="Security Concerns">

<t>Enterprises have a range of concerns around WebRTC traffic traversal
of the firewall. The major concerns that are raised include:</t>

<t><list style="numbers">
  <t>Unlike TCP, UDP does not have a connection where a device inside
the firewall has confirmed that it wants to talk to the thing
outside.</t>
  <t>Incoming UDP pinholes allow out of band packets to be spoofed into
  connecting as there is no equivalent of a TCP sequence number to
check.</t>
  <t>UDP has been used by malware command and control protocols so we
block it.</t>
  <t>We do not want enable ways for data to be exfiltrated outside the
firewall with no monitoring.</t>
  <t>An encrypted data channel in WebRTC can be used to bring malware
into the company.</t>
  <t>An encrypted media or data channel in WebRTC can be used as a command
and control channel for malware inside the firewall.</t>
  <t>An encrypted data channel in WebRTC can be used by an outside
attacker to exfiltrate private files from inside the firewall.</t>
</list></t>

</section>
<section anchor="alternate-approaches" title="Alternate Approaches">

<section anchor="firewall-auth-tokens" title="Firewall Auth Tokens">

<t><xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> attempts to solve a similar
problem by proposing a new comprehension-optional FW-FLOWDATA STUN attribute
as part of ICE Connectivity checks enabling the firewall to permit outgoing
UDP flows across the firewall. FW-FLOWDATA STUN provides necessary
information, such as lifetime, and candidate information, enabling a firewall
to apply the required policy rules. However, <xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/>
requires establishing shared keys across the firewall(s) and the WebRTC server 
for successfully verifying the authenticity of the FW-FLOWDATA information.
In summary, we believe <xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> to have 
following short-comings</t>

<t><list style="numbers">
  <t>Requiring a tight coupling between the application server (WebRTC server) and
firewall(s)</t>
  <t>Requiring additional efforts for Firewall Admins within an enterprise to distribute 
and maintain the shared authentication keys needed to generate authentication
tags for the FW-FLOWDATA attribute.</t>
  <t><xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> doesn’t apply for 
distributing keys across firewalls in different administrative domains.</t>
</list></t>

</section>
<section anchor="any-cast-whitelist" title="Any Cast Whitelist">

<t>Deploying media or TURN servers on a single any-cast IP address also 
makes it easier for firewall administrators to whitelist the 
address. Concerns have been raised that two packets sent from the same 
host to a given any-cast address may get delivered to different 
servers.  This is certainly possible in theory but in practice it does 
not seem be happen in limited experiments done so far.</t>

</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Many thanks to Shaun Cooley and Alissa Cooper.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-tram-stun-origin'>
<front>
<title>An Origin Attribute for the STUN Protocol</title>

<author initials='A' surname='Johnston' fullname='Alan Johnston'>
    <organization />
</author>

<author initials='J' surname='Uberti' fullname='Justin Uberti'>
    <organization />
</author>

<author initials='J' surname='Yoakum' fullname='John Yoakum'>
    <organization />
</author>

<author initials='K' surname='Singh' fullname='Kundan Singh'>
    <organization />
</author>

<date month='February' day='19' year='2015' />

<abstract><t>STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive.  This specification defines the usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tram-stun-origin-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tram-stun-origin-05.txt' />
</reference>



<reference anchor='I-D.ietf-avtcore-rfc5764-mux-fixes'>
<front>
<title>Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)</title>

<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
    <organization />
</author>

<author initials='G' surname='Salgueiro' fullname='Gonzalo Salgueiro'>
    <organization />
</author>

<date month='March' day='24' year='2015' />

<abstract><t>This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) packets are multiplexed on a single receiving socket.  It overrides the guidance from SRTP Extension for DTLS [RFC5764], which suffered from three issues described and fixed in this document.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-avtcore-rfc5764-mux-fixes-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-avtcore-rfc5764-mux-fixes-02.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.ietf-rtcweb-overview'>
<front>
<title>Overview: Real Time Protocols for Browser-based Applications</title>

<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />
</author>

<date month='June' day='16' year='2015' />

<abstract><t>This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web".  It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track.  This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow.  This document is a work item of the RTCWEB working group.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-overview-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-14.txt' />
</reference>



<reference anchor='I-D.ietf-rtcweb-stun-consent-freshness'>
<front>
<title>STUN Usage for Consent Freshness</title>

<author initials='M' surname='Perumal' fullname='Muthu Perumal'>
    <organization />
</author>

<author initials='D' surname='Wing' fullname='Dan Wing'>
    <organization />
</author>

<author initials='R' surname='R' fullname='Ram R'>
    <organization />
</author>

<author initials='T' surname='Reddy' fullname='Tirumaleswar Reddy'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='June' day='22' year='2015' />

<abstract><t>To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.  This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-stun-consent-freshness-15' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-stun-consent-freshness-15.txt' />
</reference>



<reference anchor='I-D.reddy-rtcweb-stun-auth-fw-traversal'>
<front>
<title>STUN Extensions for Authenticated Firewall Traversal</title>

<author initials='T' surname='Reddy' fullname='Tirumaleswar Reddy'>
    <organization />
</author>

<author initials='M' surname='Perumal' fullname='Muthu Perumal'>
    <organization />
</author>

<author initials='D' surname='Wing' fullname='Dan Wing'>
    <organization />
</author>

<date month='July' day='8' year='2012' />

<abstract><t>Some networks deploy firewalls configured to block UDP traffic.  When SIP user agents or WebRTC endpoints are deployed behind such firewalls, media cannot be sent over UDP across the firewall, but must be sent using TCP (which causes a different user experience) or through a session border controller.  This draft describes an alternate model wherein extensions to ICE connectivity checks can be examined by the firewall to permit outgoing UDP flows across the firewall.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-reddy-rtcweb-stun-auth-fw-traversal-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-stun-auth-fw-traversal-00.txt' />
</reference>




    </references>



  </back>
</rfc>