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

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

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

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

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

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

    <author initials="P." surname="Patel" fullname="Pradeep Patel">
      <organization>Cisco</organization>
      <address>
        
        
        <email>pradpate@cisco.com</email>
        
      </address>
    </author>
    <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>
    <author initials="D." surname="Wing" fullname="Dan Wing">
      <organization>Cisco</organization>
      <address>
        
        
        <email>dwing@cisco.com</email>
        
      </address>
    </author>

    <date year="2015" month="August" day="27"/>

    <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, and so on.</t>

<t>REQ-6: The solution must not require decryption of either signaling
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 inspection 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 WebRTC media or data 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.</t>

<t>The firewall looks for an initial STUN transaction to learn which
applications is using the port (based on the STUN ORIGIN
attribute). Next the firewall watches the outbound ICE connectivity
check on that port and allows inbound ICE connectivity checks that are
going to the same location that sent the outbound request and that
have the correct random ufrag value that was created by the client
inside the firewall.  After a successful ICE connectivity check, the
firewall allows other media to flow on the same 5 tuple that had the
successful ICE connectivity check.  Timers are used to removed the
various pinholes created.</t>

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

<t>The end result is a system where:</t>

<t><list style='symbols'>
  <t>STUN packets are only allowed “in” if they know the crypto random
username generated by a client inside the firewall</t>
  <t>Non STUN packets are only allowed “in” if they match a 5 tuple that
a client inside the firewall sent a packet too</t>
  <t>Non STUN packets are only allowed “out” if the destination they are
sending to did a stun consent handshake</t>
</list></t>

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

<t>The firewall processing is broken into four stages: recognizing STUN
packets, mapping to an application, 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="terminology" title="Terminology">

<t>The key  words defined in <xref target="RFC2119"/> are used in this specification.</t>

<t>The term 3-tuple is used to refer to IP address, protocol (which is
always UPD), and port that the firewall sees as the address of the
client inside the firewall.</t>

<t>The term 4-tuple is used to refer to 3-tuple plus the ice ufrag that
was send in the STUN request message for the client inside the
firewall.</t>

<t>The term 5-tuple is used to refer to the 3-tuple plus the IP address
and port of the device outside the firewall.</t>

<t>When matching a ufrag, if it is a STUN request that came from outside
the firewall, the two halves of the username on either side of the “:”
need to be swapped before matching.</t>

</section>
<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>Option A: Firewalls SHOULD look at outbound UDP packets and if they
have the correct magic cookie they can classify them as STUN packets.</t>

<t>Option B: The firewall looks for any outgoing STUN requests to the
STUN port (3478). When it finds one, it stores the 3 tuple of the
source address port and protocol=UDP and for the next 30 seconds
checks any packets from this 3 tuple to see if they are ICE
connectivity checks. </t>

<t>Open Issues:</t>

<t><list style='symbols'>
  <t>decide between option A and B. A requires looking at all UDP packets
but will likely work better than B. Most firewalls look at all TCP
packets so probably not too big of a deal.</t>
  <t>MAY, MUST, MUST NOT look at FINGERPRINT - what do we want here. If we
put MAY or MUST, then browsers MUST include this. If browsers are not
required to provide this then I think we are more in the MUST NOT
category. If we do not use the fingerprint, there will be some small
number of false positives.</t>
  <t>Should do the analysis to see what harm comes of treating random
packets as STUN packets.</t>
  <t>CJ Proposal: Browsers MUST send the fingerprint when sending STUN
messages to STUN server but MAY use it when doing ICE connectivity
checks. This is to help save bandwidth as Justin Uberti was
suggesting that change from approximately 50kbps to 100 kbps for ICE
makes big difference for mobile devices.</t>
  <t>Do we want to discuss TURN over DTLS and using ALPN to
detect TURN traffic along with SNI in place or the ORGIN attribute. </t>
</list></t>

</section>
<section anchor="application-mapping" title="Application Mapping">

<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 have the value example.com if the STUN server
was named appropriately. So if a web applications such as example.com
is starts a WebRTC session, and has appropriate named STUN servers,
then then the firewall can detect this session is associated with
example.com. Systems other than WebRTC can do the same thing. This
allows the firewall to map the stun port to the application using it
and use that for logging and policy decisions.</t>

<t>Open Issue:</t>

<t><list style='symbols'>
  <t>Make sure the drafts are modified to actually say what is
claimed in above paragraph but this was agreed to at IETF 93.</t>
</list></t>

<t>Once the Firewall receives as STUN packet from the inside to the
outside on a new 3-tuple. It MUST create an internal record to track
any additional traffic on this 3-tuple. If the STUN packets contains
an ORIGIN attribute then the value it contains is saved in this record
and referred to as the applications name. Firewall might wish to put
the application name in the log files for this 3-tuple.</t>

<t>It is important to realize that any application inside the firewall
can lie about the value of the ORIGIN attribute. However, a web
browser that is trusted will not allow the Javascript running in the
web browser lie about the value of the ORIGIN. </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 application
name for this 3-tuple.</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>Some firewalls MAY decide to white or blacklist media based on the
application name. </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 causes the firewall to allow any inbound or outbound ICE
messages on this 4-tuple. This pinhole MUST to be valid for at least 5
seconds from the time of creation.</t>

<t>The firewall keeps track of the STUN transaction ID for all STUN
requests messages that traverse the 4 tuple along with the 5 tuple
they were sent on and direction (inbound or outbound). If the firewall
sees a STUN Success binding responses, with the same transaction ID,
and on the same 5 tuple but in the opposite direction as the STUN
request, then a valid ICE connectivity check has happened and the
firewall MUST create a pinhole for this 5 tuple that allows any UDP
traffic to flow across that 5 tuple. This pinhole MUST to be valid for
at least 30 seconds from the time of creation.</t>

<t>The firewall continues watching ICE connectivity checks across this
5-tuple as described in the previous paragraph and anytime the a valid
ICE connectivity check happens, this effectively extends the lifetime of
the pinhole by 30 seconds. The procedures in
<xref target="I-D.ietf-rtcweb-stun-consent-freshness"/> will ensure that an ICE
connectivity check is done more often than every 30 seconds. This is
designed to make things work with behave compliant NATS and Firewalls as
specified in <xref target="RFC4787"/>.</t>

</section>
<section anchor="media-vs-data-statistics" title="Media vs Data Statistics">

<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>Open Issue: how much randomness for ICE ufrag</t>

<t><list style='symbols'>
  <t>ICE mandates at least 24 bits of randomness but we could require the
browsers produce 64 bits of randomness?</t>
</list></t>

<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?</t>

<t><list style='symbols'>
  <t>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>
  <t>This proposal is now based on the idea that the web browser would
only include a ORIGIN attribute when the STUN server name matched the
name of the HTTP ORIGIN. This further reduces any privacy concerns.</t>
</list></t>

<t>Open Issue:</t>

<t><list style='symbols'>
  <t>Could redo ORIGIN based off a HOST attribute with match origin type
flag</t>
</list></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="iana-considerations" title="IANA Considerations">

<t>This draft does not require any IANA actions. </t>

</section>
<section anchor="security-considerations" title="Security Considerations">

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

<t>TODO - Describe to what degree theses are addressed. Be clear about attacks due
to Javascript inside the firewall and attacks due to executables inside the
firewall.</t>

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

<section anchor="sdn-control-of-firewall" title="SDN Control of Firewall">

<t>An alternative ways of solving this problem is for the Web Application
running in the browser to inform the web site what ports and IP
addresses it is using then the web site to contact the appropriate SDN
controller and request t4he SDN controller tell the appropriate firewall
what pinholes to open.  This can be made to work in some deployments
but not all as it is often not clear how to find the correct SDN
controller or set up a relationship such that the SDN controller
trusts a website outside the firewall wall enough to let it tell the
controller to open wholes in the Firewall.</t>

<t>SDN based approaches should be pursued as well as this approach as they
compliment each other.</t>

</section>
<section anchor="any-cast-white-list" title="Any Cast White List">

<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 review from Shaun Cooley, Teh Cheng, 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>



<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</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='August' day='13' year='2015' />

<abstract><t>To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic 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-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-stun-consent-freshness-16.txt' />
</reference>



<reference  anchor='RFC4787' target='http://www.rfc-editor.org/info/rfc4787'>
<front>
<title>Network Address Translation (NAT) Behavioral Requirements for Unicast UDP</title>
<author initials='F.' surname='Audet' fullname='F. Audet' role='editor'><organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author>
<date year='2007' month='January' />
<abstract><t>This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently.  Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='127'/>
<seriesInfo name='RFC' value='4787'/>
<seriesInfo name='DOI' value='10.17487/RFC4787'/>
</reference>




    </references>



  </back>
</rfc>