One document matched: draft-jennings-behave-rtcweb-firewall-03.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-03" 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="October" day="18"/>
<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 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 a STUN server to
learn which application is using the port (based on the STUN HOST
attribute <xref target="sec-stun_host"/>). 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 HOST
attribute 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>STUN packers going “out” can be restricted by policy based on the
hostname of the STUN server they are using</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 UDP), 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>
</list></t>
</section>
<section anchor="application-mapping" title="Application Mapping">
<t>The STUN HOST attribute <xref target="sec-stun_host"/> carries the fully qualified
domain name of the STUN server that is being contacted in the 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 to
stun.example.com, the STUN request’s HOST attribute would have the value
stun.example.com. Similarly when contacting a STUN or TURN server over
TLS or DTLS, the TLS SNI <xref target="RFC6066"/> value provides the name of the
host. For systems that provide a unique STUN server name for each
application, this allows the firewall to map the stun port to the
application using it and use that for logging and making any policy decisions.</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 HOST
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 HOST attribute. However, a web browser that
is trusted will not allow the Javascript running in the web browser to
lie about the value of the HOST.</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 connections 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 matching 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. Then 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>This specification would require browsers to include the FINGERPRINT and
the HOST attributes in STUN requests to a STUN server used to gather
candidates for this to work correctly. Note they MUST not be
included in STUN requests sent peer to peer or sent to ensure media
consent.</t>
<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>Open Issue: Does adding the HOST 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 using facebook.com as the
name of the STUN server. 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>
</list></t>
<t>Open Issue: Would only including HOST when it matched the HTTP ORIGIN
improve privacy?</t>
<t><list style='symbols'>
<t>We could make this so that when used with WebRTC browsers, the HOST is
only included in the STUN messages when the name of the STUN servers
matches the HTTP ORIGIN of the web page initiating the STUN
request. It is not clear if this would improve privacy or not.</t>
</list></t>
</section>
<section anchor="sec-stun_host" title="STUN HOST attribute">
<t>This specification defines a new STUN attribute called HOST and uses the
syntax defined in Section 15 of <xref target="RFC5389"/>. This attribute is of type
comprehension-optional. The value of the HOST attribute is a variable
length value. It MUST contain a UTF-8 <xref target="RFC3629"/> encoded sequence of
characters.</t>
<t>The HOST attribute identifies the fully qualified domain name of the
application provider that is serving the WebRTC application and also
operating the STUN server. The WebRTC EndPoint MUST include this
attribute as part of the ICE candidate gathering phase and there MUST be only
one HOST attribute in a given STUN binding request.</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 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>IANA is requested to add the HOST attribute to the STUN attribute
registry. The values for HOST is to be allocated from the expert review
comprehension-optional range of (0xC000 - 0xFFFF).</t>
<texttable>
<ttcol align='left'>Value</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBD</c>
<c>HOST</c>
<c>RFCXXXX</c>
</texttable>
<t>This specification defines the HOST attribute in <xref target="sec-stun_host"/>.</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 anchor="privacy" title="Privacy">
<t>Unlike previous version of this draft, we think that using HOST instead
of ORIGIN minimizes any privacy concerns. The HOST is already known to
the operator of the STUN server as they run it. It often contains
exactly the same information as the existing STUN REALM attribute. It
has roughly the same information as the TLS SNI <xref target="RFC6066"/> when STUN is
run over DTLS.</t>
</section>
</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 the 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>
<t>The definition of HOST STUN attribute was motivated by discussion around
the draft-ietf-tram-stun-origin document and we want to thank Alan
Johnston, Justin Uberti, John Yoakum, and Kundan Singh.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<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>
<reference anchor='RFC5389' target='http://www.rfc-editor.org/info/rfc5389'>
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'><organization /></author>
<author initials='P.' surname='Matthews' fullname='P. Matthews'><organization /></author>
<author initials='D.' surname='Wing' fullname='D. Wing'><organization /></author>
<date year='2008' month='October' />
<abstract><t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.</t><t>STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.</t><t>This document obsoletes RFC 3489. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5389'/>
<seriesInfo name='DOI' value='10.17487/RFC5389'/>
</reference>
<reference anchor='RFC3629' target='http://www.rfc-editor.org/info/rfc3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></author>
<date year='2003' month='November' />
<abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract>
</front>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
<seriesInfo name='DOI' value='10.17487/RFC3629'/>
</reference>
</references>
<references title='Informative References'>
<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='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>
<reference anchor='RFC6066' target='http://www.rfc-editor.org/info/rfc6066'>
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2011' month='January' />
<abstract><t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6066'/>
<seriesInfo name='DOI' value='10.17487/RFC6066'/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:15 |