One document matched: draft-wing-behave-nat-control-stun-usage-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-behave-rfc3489bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-rfc3489bis.xml">
<!ENTITY rfc4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY rfc3489 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml">
<!ENTITY rfc3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY I-D.ietf-behave-turn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-turn.xml">
<!ENTITY I-D.cheshire-nat-pmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-nat-pmp.xml">
<!ENTITY rfc3303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3303.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.ietf-sip-outbound SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-outbound.xml">
<!ENTITY I-D.ietf-nsis-nslp-natfw SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-nslp-natfw.xml">
<!ENTITY rfc4884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4884.xml">
<!ENTITY I-D.shore-tist-prot SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shore-tist-prot.xml">
<!ENTITY I-D.shore-nls-tl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shore-nls-tl.xml">
<!ENTITY rfc3424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3424.xml">
<!ENTITY rfc3948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml">
<!ENTITY I-D.wing-session-auth SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-session-auth.xml">
<!ENTITY rfc3947 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3947.xml">
<!ENTITY rfc4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY rfc4380 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-behave-nat-control-stun-usage-05"
ipr="full3978">
<front>
<title abbrev="STUN Control">Discovering, Querying, and Controlling
Firewalls and NATs</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Jonathan Rosenberg" initials="J." surname="Rosenberg">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city>Edison</city>
<region>NJ</region>
<code>07054</code>
<country>USA</country>
</postal>
<email>jdrosen@cisco.com</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H" surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2007" />
<area>Transport</area>
<workgroup>BEHAVE</workgroup>
<abstract>
<t>A drawback with many NAT UDP hole punching techniques is the
keepalive traffic necessary to keep the UDP binding open. It it
necessary to send keepalives frequently because it is not possible to
determine or modify the NAT's binding lifetime. This keepalive traffic
causes server load and additional network traffic, which is especially
problematic with battery-operated wireless devices.</t>
<t>This document describes two mechanisms to discover NATs and firewalls
and a mechanism to query and control their binding lifetime. With these
mechanisms, UDP binding discovery and UDP keepalive traffic can be
reduced to involve only the necessary NATs or firewalls. This eliminates
the keepalive traffic to servers, and vastly reduces keepalive traffic
across the network. At the same time, backwards compatibility with NATs
and firewalls that do not support this specification is retained, which
allows for incremental deployment of this mechanism.</t>
<t>This document is discussed on the SAFE mailing list,
<http://www1.ietf.org/mailman/listinfo/safe>.</t>
</abstract>
</front>
<middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Introduction">
<t></t>
<t>Two common usages of Simple Traversal Underneath NAT (STUN) (<xref
target="I-D.ietf-behave-rfc3489bis"></xref>,<xref
target="RFC3489"></xref>) are Binding Discovery and NAT Keepalive. The
Binding Discovery usage allows a STUN client to learn its public IP
address (from the perspective of the STUN server it contacted) and the
NAT keepalive usage allows a STUN client to keep an active NAT binding
alive. Unlike some other techniques (e.g., <xref target="UPnP-IGD">UPnP
IGD</xref>, <xref target="RFC3303">MIDCOM</xref>, <xref
target="I-D.cheshire-nat-pmp">NAT-PMP</xref>), <xref
target="I-D.ietf-nsis-nslp-natfw">NSIS-NSLP</xref>), STUN does not
interact directly with the NAT. Thus, STUN cannot request additional
services from the NAT, such as longer lifetimes which would reduce
keepalive messages. Furthermore, allocating new NAT bindings (e.g., each
phone call) requires communication with a STUN server located somewhere
on the Internet.</t>
<t>This document describes three mechanisms for the STUN client to
discover NATs and firewalls that are on path with its STUN server. After
discovering the NATs and firewalls, the STUN client can query and
control those devices using STUN. The STUN client needs to only ask
those STUN servers (embedded in the NATs and firewalls) for public IP
addresses and UDP ports, thereby offloading that traffic from the STUN
server on the Internet. Additionally, the STUN client can ask the NAT's
embedded STUN server to extend the NAT binding for the flow, and the
STUN client can learn the IP address of the next-outermost NAT. By
repeating this procedure with the next-outermost NAT, all of the NATs
along that path can have their bindings extended. By learning all of the
STUN servers on the path between the public Internet and itself, an
endpoint can optimize the path of peer-to-peer communications.</t>
</section>
<section title="Notational Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="benefits" title="Motivation and Benefits">
<t>There are a number of problems with existing NAT traversal
techniques, such as STUN, UPnP IGD, MIDCOM, NAT-PMP, and NSIS-NSLP:</t>
<t><list style="hanging">
<t hangText="nested NATs:"><vspace blankLines="0" />Today, many ISPs
provide their subscribers with modems that have embedded NATs or
within the ISP's network. These subscribers then install NATs behind
those devices to provide additional features, such as wireless
access. In these situations, UPnP IGD and NAT-PMP no longer
function, as those protocols can only control the first NAT closest
to the host. STUN continues to function, but is unable to optimize
network traffic behind those nested NATs (e.g., traffic that stays
within the same house or within the same apartment building).
<vspace blankLines="1" />One technique to avoid nested NATs is to
disable one of the NATs, as recommended by <xref
target="Vista-cert"></xref>. However, this merely sidesteps the
problem of nested NATs, as some NATs are installed for a reason
(e.g., reduce IP address consumption or provide a modicum of
security). Disabling the NAT is also ineffective if the ISP is
NATting subscribers within the ISP's network, as ISP NATs do not
typically support UPnP.<vspace blankLines="1" />The technique
described in this document allows optimization of the traffic behind
those NATs so that the traffic can traverse the fewest NATs
possible.</t>
<t hangText="keepalive chatter:"><vspace blankLines="0" />To keep
NAT bindings from timing out and to perform its binding discovery,
keepalive packets are sent to a server on the Internet. This
consumes bandwidth across the user's access network, which in some
cases is bandwidth constrained (e.g., wireless, satellite), creates
a load on the server, and (for battery-powered devices) consumes
battery power. This chattiness can be avoided by using a NAT control
mechanism such as UPnP IGD or NAT-PMP. However, relying on such NAT
control mechanisms exclusively for NAT traversal is problematic, as
they are not universally deployed. Thus, many UDP NAT traversal
techniques instead rely on UDP hole punching.<vspace
blankLines="1" />The technique described in this document provides a
significant reduction of keepalive traffic. The keepalive traffic
can be reduced in frequency and can even be sent to just the
necessary NAT or firewall (rather than the server).</t>
<t hangText="lack of incremental deployment:"><vspace
blankLines="0" />Many other NAT traversal techniques require the
endpoint and its NAT to both support the same NAT traversal
technique or else NAT traversal is not possible at all. Examples
include NSIS-NSLP, NAT-PMP, UPnP IGD, and MIDCOM.<vspace
blankLines="1" />The technique described in this document allows
incremental deployment of local endpoints and NATs that support STUN
Control. If the local endpoint, or its NATs, does not support the
STUN Control functionality, then STUN (see <xref
target="I-D.ietf-behave-rfc3489bis"></xref>), <xref
target="I-D.ietf-sip-outbound"></xref>, and <xref
target="I-D.ietf-mmusic-ice">ICE</xref> procedures are used to
traverse the NATs without the optimizations described in this
document.</t>
</list>The protocol described in this document retains the positive
features of STUN -- incremental deployment and support of nested NATs --
without introducing drawbacks inherent in other NAT traversal
techniques. The protocol optimizes the operation of STUN clients when
those STUN clients are behind a NAT that supports the protocol described
in this document. STUN clients that are behind a NAT that doesn't
support the protocol described in this document continue to function as
they do today, without those optimizations.</t>
<section title="Comparison with other NAT Traversal Techniques">
<t>STUN Control offers the following benefits over other NAT traversal
and NAT control techniques such as NSIS-NSLP, MIDCOM, NAT-PMP, and
UPnP IGD.</t>
<section title="Simple Security Model">
<t>Unlike other middlebox control techniques which have relatively
complex security models because a separate control channel is used,
STUN Control's is simple. It is simple because only flows
originating from the same source IP and UDP port can be controlled
(i.e., have its NAT timeout queried or extended). Other flows cannot
be created, queried, or controlled via STUN Control.</t>
</section>
<section title="Incremental Deployment">
<t>STUN Control can be incrementally deployed. If the outer-most NAT
does not support it, the STUN client behaves as normal -- it merely
isn't able to optimize its keepalive (see also Section <xref
target="legacy-nats"></xref>). If the outer-most NAT does support
STUN Control, the STUN client can gain some significant
optimizations as described in the following sections.</t>
<t>Likewise, there is no change required to applications if NATs are
deployed which support STUN Control: such applications will be
unaware of the additional functionality in the NAT, and will not be
subject to any worse security risks due to the additional
functionality in the NAT.</t>
</section>
</section>
<section title="Reduce Keepalive Messages">
<t>The primary value of the protocol and technique described in this
document is the reduction of UDP keepalive messages. This is helpful
for several protocols.</t>
<t>For each of the protocols below, STUN Control as described in this
document enables two optimizations:</t>
<t><list style="numbers">
<t>all of the on-path NATs can explicitly indicate their timeouts,
reducing the frequency of keepalive messages, and;</t>
<t>STUN keepalive messages need only be sent to the outer-most
NAT, rather than across the access link to the SIP proxy, which
vastly reduces the traffic to the SIP proxy.</t>
</list></t>
<section title="SIP Outbound">
<t>In <xref target="I-D.ietf-sip-outbound">SIP outbound</xref>, the
SIP proxy is also the STUN server. Through the initial STUN
request/response exchange with that server, the STUN client learns
it is behind a NAT, and learns that NAT's public IP address. Once it
has learned the NAT's public IP address, it can query and control
that NAT by following the procedures in <xref
target="query_and_control"></xref>.</t>
</section>
<section title="IKE/IPsec NAT Traversal">
<t>In both the <xref target="RFC3947">NAT traversal for IKEv1</xref>
and IKEv2 (Section 2.23 of <xref target="RFC4306"></xref>) the IKE
endpoints can only learn that a NAT is present, but cannot learn the
IP address of that NAT because the IP address is hashed. Thus, IKE
itself isn't usable to learn the IP address of the outer-most NAT.
STUN can be used to learn the IP address of the outer-most NAT, and
STUN Control can then be used to extend the binding lifetime for the
UDP port that is being used by IKE. Once this is done, the IPsec NAT
keepalive interval can be reduced (Section 4 of <xref
target="RFC3948"></xref>).</t>
<t>With IKE/IPsec NAT traversal, there are two ways to use STUN to
learn the outer-most NAT: <list style="symbols">
<t>STUN packets can be sent between the IKE peers on the same
port as IKE. IKE, IPsec ESP, and STUN can be demultiplexed.
However, this does require changing software in both IKE
peers.</t>
<t>STUN packets can be sent to STUN port of the IKE peer's IP
address. This does not require changing software on the remote
IKE peer, but requires a separate server process running on the
remote peer.</t>
</list></t>
</section>
<section title="Teredo">
<t>Endpoints that implement <xref target="RFC4380">Teredo</xref>
learn their outer-most NATs address as their Teredo Mapped Address.
Once learned, the Teredo client can utilize STUN Control to query
and control that NAT's (and nested NAT's) UDP keepalive timeout, and
thus reduce the refresh interval.</t>
<t>In contrast, Teredo's existing s refresh interval determination
procedure (Section 5.2.7 of <xref target="RFC4380"></xref>) allows
the Teredo host to learn (but not adjust) the NAT's binding
lifetime. There is also a small risk that the NAT will use different
refresh intervals for different ports (e.g., due to resource
constraints), which contributes to some brittleness.</t>
</section>
</section>
<section title="Optimize ICE">
<t>The STUN Control usage provides several opportunities to optimize
<xref target="I-D.ietf-mmusic-ice">ICE</xref>, as described in this
section.</t>
<section title="Candidate Gathering">
<t>During its candidate gathering phase, an ICE endpoint normally
contacts a STUN server on the Internet. If an ICE endpoint discovers
that its outer-most NAT runs a STUN server, the ICE endpoint can use
the outer-most NAT's STUN server rather than using the STUN server
on the Internet. This saves access bandwidth and reduces the
reliance on the STUN server on the Internet -- the STUN server on
the Internet need only be contacted once -- when the ICE endpoint
first initializes.</t>
</section>
<section anchor="ice-learn-stun-servers"
title="Learning STUN Servers without Configuration">
<t>ICE allows endpoints to have multiple STUN servers, but it is
difficult to configure all of the STUN servers in the ICE endpoint
-- it requires some awareness of network topology. By using the
'walk backward' technique described in this document, all the
on-path NATs and their embedded STUN servers can be learned without
additional configuration. By knowing the STUN servers at each
address domain, ICE endpoints can optimize the network path between
two peers.</t>
<t><figure>
<preamble>For example, if endpoint-1 is only configured with the
IP address of the STUN server on the left, endpoint-1 can learn
about NAT-B and NAT-A. Utilizing the STUN server in NAT-A,
endpoint-1 and endpoint-2 can optimize their media path so they
make the optimal path from endpoint-1 to NAT-A to
endpoint-2:</preamble>
<artwork align="center"><![CDATA[
+-------+ +-------+ +-------------+
endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server |
+-------+ | +-------+ +-------------+
|
endpoint-2]]></artwork>
</figure></t>
</section>
<section title="Reduce Media Keepalive Messages">
<t>While very minor, STUN Control makes it possible to optimize
media keepalives. This is useful if a video or audio stream is
placed on 'hold' or 'mute', but is expected to be resumed in the
future. ICE uses STUN Indications as its primary media stream
keepalive mechanism. This document enables two optimizations of
ICE's keepalive technique:<list style="numbers">
<t>STUN keepalive messages need only be sent to the outer-most
NAT, rather than across the access link to the remote peer,
and;</t>
<t>all of the on-path NATs can explicitly indicate their
timeouts, which allows reducing the keepalive frequency.</t>
</list></t>
</section>
</section>
</section>
<section anchor="overview" title="Overview of Operation">
<t>This document describes three functions, which are all implemented
using the STUN protocol:</t>
<t><list hangIndent="3" style="hanging">
<t hangText="Discovery of Middleboxes (NATs and Firewalls):"><vspace
blankLines="0" />This document describes two techniques for finding
NATs or firewalls (see <xref target="discovery"></xref>). These two
approaches are: <vspace blankLines="0" /> <list hangIndent="5"
style="hanging">
<t hangText="Outside-In:"><vspace blankLines="0" />Uses STUN or
Teredo to find the outer-most NAT. Then STUN is used to
communicate with that NAT and discover the other nested NATs (if
any) along that path towards the host by repeated use of STUN
with each of those NATs.</t>
<t hangText="Tagging:"><vspace blankLines="0" />Send a STUN
Request packet to your STUN server, and asks for compliant
firewalls along the path to indicate their presence by adding an
IP address to the STUN Response packet.</t>
</list></t>
<t hangText="Querying Discovered Middleboxes:"><vspace
blankLines="0" />After discovering a NAT or a firewall, it is useful
to determine characteristics of the NAT binding or the firewall
pinhole. Two of the most useful things to learn is the duration the
NAT binding or firewall pinhole will remain open if there is no
traffic, and the filtering applied to that binding or pinhole. This
is described in <xref target="query_and_control"></xref>.</t>
<t hangText="Controlling Discovered Middleboxes:"><vspace
blankLines="0" />A NAT or a firewall might default to a more
restrictive behavior than desired by an application (e.g.,
aggressive timeout, filtering). Requesting the NAT or firewall to
change its default behavior is useful for traffic optimization
(e.g., reduce keepalive traffic) and network optimization (e.g.,
adjust filters to eliminate the need for a media relay device <xref
target="I-D.ietf-behave-turn"></xref>). A discussion of this
functionality can be found in <xref
target="query_and_control"></xref>.</t>
</list></t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="discovery"
title="Discovery of Middleboxes (NATs and Firewalls)">
<t>This section describes two techniques to discover a NAT and a
firewall: outside-in and by tagging.</t>
<t>Ideally, a single technique could be selected as an outcome of the
standardization process. However, it is possible to combine these two
techniques.<!-- For example, if your
inner-most NAT supports STUN Control, and your public STUN server
returns the same IP address and port as your inner-most NAT, you know
you do not have a NAT between your inner-most NAT and the STUN server.
Otherwise, you know there is a NAT between your inner-most NAT and the
STUN server (e.g., an ISP-supplied device or whoever is providing your
Internet service). Knowing this allows optimizing NAT keepalives. --></t>
<section anchor="outside-in" title="Outside-In">
<t>The endpoint must first discover its outer-most NAT. This can be
accomplished using STUN or Teredo.</t>
<t><list style="hanging">
<t hangText="STUN:">When a STUN client sends a STUN Request to a
STUN server, it receives a STUN Response that indicates the IP
address and UDP port seen by the STUN server. If the IP address
and UDP port differs from the IP address and UDP port of the
socket used to send the request, the STUN client knows there is at
least one NAT between itself and the STUN server. The STUN client
also learns the 'public' IP address (and port) allocated by the
outermost NAT.</t>
<t hangText="Teredo:">As part of the Teredo qualification
procedure, the Teredo client learns the IP address of its
outer-most NAT. With that information, the Teredo client can
proceed to the next step.</t>
</list>After learning the public IP address of its outer-most NAT,
the endpoint sends a STUN packet to the STUN port (UDP/3478) of its
outer-most NAT's public IP address. The NAT will return a STUN Binding
Response message including two important STUN attributes:</t>
<t><list>
<t>XOR-MAPPED-ADDRESS, which indicates the public IP address and
UDP port for the mapping. As the endpoint just learned this
information via STUN or Teredo, this isn't terribly interesting to
the endpoint at this time. However, if the endpoint wants to
create a new UDP mapping (e.g., for a new UDP flow), the endpoint
need only send a STUN request to this outer-most NAT rather than
to a host on the Internet.</t>
<t>XOR-INTERNAL-ADDRESS, which indicates the IP address and UDP
port seen on the *internal* side of the NAT for that translation
(see <xref target="internal_diagram"></xref>). This allows the
endpoint to discover, query, and control multiple NATs (nested
NATs) along that path.</t>
</list></t>
<figure anchor="ladder_diagram" title="Communication Flow">
<artwork align="center" name="STUN Communication Flow"><![CDATA[
Endpoint NAT STUN Server
| | |
1. |-----Binding Request (UDP)--------------->|
2. |<----Binding Response (UDP)---------------|
| | |
3. |--Binding Request (UDP)------->| |
4. |<-Binding Response (UDP)-------| |
| | |
]]></artwork>
<postamble></postamble>
</figure>
<t>In the message flow above, steps 1 and 2 correspond to the STUN
behavior described in <xref
target="I-D.ietf-behave-rfc3489bis"></xref>:</t>
<t><list counter="flow" style="format %d:">
<t>The STUN client sends a UDP Binding Request to its STUN server
that is located on the Internet.</t>
<t>The STUN server on the Internet responds with a UDP Binding
Response.</t>
</list></t>
<t>After steps 1 and 2, the endpoint has learned the IP address of its
outer-most NAT. The endpoint could also have used Teredo to learn that
IP address.</t>
<t>The next steps are the additional steps performed by the endpoint
implementing STUN Control:</t>
<t><list counter="flow" style="format %d:">
<t>The endpoint sends a STUN Binding Request to the IP address of
its outer-most NAT. This will be received by the STUN server
embedded in that outer-most NAT.</t>
<t>The STUN server (embedded in the NAT) responds with a STUN
Binding Response.</t>
</list></t>
<t>The response obtained in message (4) contains the
XOR-MAPPED-ADDRESS attribute, which will have the same value as when
the STUN server on the Internet responded (in step 2). Thereafter, so
long as the BOOTNONCE value doesn't change, the STUN client can
perform steps (3) and (4) for any new UDP communication, without
needing to repeat steps (1) and (2). This meets the desire to reduce
chattiness. The STUN client also only needs to send keepalives towards
the outer-most NAT's IP address, as well (reduces chatter for SIP
outbound <xref target="I-D.ietf-sip-outbound"></xref>).</t>
<t>The response obtained in message (4) will also contain the
XOR-INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3)
and (4) in order to query or control those on-path NATs between itself
and its STUN server on the Internet. This is described in detail in
<xref target="walking_backwards"></xref>. This functionality allows
ICE to learn more NAT bindings <xref
target="ice-learn-stun-servers"></xref> and gives ICE the opportunity
to optimize traffic between nested NATs, without requiring
configuration of intermediate STUN servers.</t>
<t>The STUN client can request each NAT to increase the binding
lifetime for that source IP address and source UDP port, as described
in <xref target="refresh-interval"></xref>. The STUN client receives
positive confirmation that the binding lifetime has been extended,
allowing the STUN client to significantly reduces its NAT keepalive
traffic. Additionally, as long as the NAT complies with <xref
target="RFC4787"></xref> (which is indicated by its support of this
document), the STUN client's keepalive traffic need only be sent to
the outer-most NAT's IP address. This functionality meets the need to
reduce STUN's chattiness.</t>
<section anchor="walking_backwards" title="Nested NATs">
<t>Nested NATs are controlled individually. The nested NATs are
discovered, from outer-most NAT to the inner-most NAT, using the
XOR-INTERNAL-ADDRESS attribute.</t>
<t>If there is only one NAT between an endpoint and the Internet,
XOR-INTERNAL-ADDRESS will return the same IP address and UDP port
the endpoint is using. If there are multiple NATs between an
endpoint and the Internet, XOR-INTERNAL-ADDRESS will return a
different IP address than the endpoint is using, which points
towards the NAT closer to the endpoint. By repeating this procedure,
the endpoint can discover all of the NATs. Note, however, the
limitation described in <xref
target="limit_nested_nats"></xref>.</t>
<figure anchor="example_two_nats"
title="Two nested NATs with embedded STUN servers">
<preamble>The following figure shows two nested NATs:</preamble>
<artwork align="center" name="Two NATs"><![CDATA[
+------+ +--------+ +--------+
| 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+
| STUN +------+ NAT-B +-----+ NAT-A +---<Internet>---+STUN Server|
|Client| 192.168.1.1 | 10.1.1.1 | +-----------+
+------+ +--------+ +--------+
]]></artwork>
<postamble></postamble>
</figure>
<t>First, the endpoint would learn the outer-most NAT's IP address
via STUN or Teredo. The endpoint will then send a STUN binding
request to that outer-most NAT. With nested NATs, however, the IP
address and UDP port indicated by the XOR-INTERNAL-ADDRESS will not
be the STUN client's own IP address and UDP port -- rather, it is
the IP address and UDP port on the inside of NAT-A, which are the
same as the IP address and UDP port on the outside of the NAT-B --
10.1.1.2.</t>
<t>Because of this, the STUN client repeats the procedure and sends
another STUN Binding Request to that newly-learned address (the
*outer* side of NAT-B). NAT-B will respond with a STUN Binding
Response containing the XOR-INTERNAL-ADDRESS attribute, which will
match the STUN client's IP address and UDP port. The STUN client
then knows there are no other NATs between itself and NAT-B, and
finishes.</t>
<figure anchor="outside-in-2-nat-message-flow"
title="Message Flow for Outside-In with Two NATs">
<preamble>The message flow with two nested NATs is shown
below:</preamble>
<artwork align="center"
name="Message Flow for Outside-In with Two NATs"><![CDATA[
STUN Client NAT-B NAT-A STUN Server
| | | |
1. |-----Binding Request (UDP)--------------->|
2. |<----Binding Response (UDP)---------------|
| | | |
3. |--Binding Request (UDP)------->| | }
4. |<-Binding Response (UDP)-------| | } NAT Control
| | | | } STUN Usage
5. |--Binding Req (UDP)-->| | | }
6. |<-Binding Resp (UDP)--| | | }
| | | |
]]></artwork>
<postamble></postamble>
</figure>
<t>A BOOTNONCE value is obtained from each of these NATs, and is
validated whenever a subsequent STUN Binding Request is sent to any
of those learned NATs.</t>
</section>
</section>
<section anchor="tagging" title="Tagging">
<t>To discover an on-path firewall, the PLEASE-TAG attribute is used
with a STUN Binding Request (a STUN packet sent to UDP/3478) message.
A firewall would inspect bypassing Binding Request messages and
determine whether there is a PLEASE-TAG attribute. When the firewall
sees the associated Binding Response, the firewall appends a TAG
attribute as the last attribute of the Binding Response. This TAG
attribute contains the firewall's management IP address and UDP port.
Each on-path firewall would be able to insert its own TAG attribute.
In this way, the STUN Response would contain a pointer to each of the
on-path firewalls between the client and that STUN server.</t>
<t><list style="empty">
<t>Motivation for developing the Tagging mechanism: The Outside-In
discovery technique (<xref target="outside-in"></xref>) uses the
public IP address of the NAT to find the outer-most NAT that
supports STUN Control. Firewalls do not translate packets and
hence a different technique is needed to identify
firewalls.<vspace blankLines="1" /> Note that tagging is similar
to how <xref target="I-D.ietf-nsis-nslp-natfw">NSIS-NSLP</xref>,
<xref target="I-D.shore-tist-prot">TIST</xref>, and <xref
target="I-D.shore-nls-tl">NLS</xref> function.</t>
</list></t>
<figure anchor="tagging-message-flow" title="Tagging Message Flow">
<preamble>This figure shows how tagging functions.</preamble>
<artwork align="center"><![CDATA[
STUN Client firewall STUN Server
| | |
1. |--Binding Request->|------------------>|
2. | |<-Binding Response-|
3. | [inserts tag] |
4. |<-Binding Response-| |
5. [firewall discovered] | |
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="numbers">
<t>A Binding Request, containing the PLEASE-TAG attribute, is sent
to the IP address of the STUN server that is located somewhere on
the Internet. This is seen by the firewall, and the firewall
remembers the STUN transaction id, and permits the STUN Binding
Request packet.</t>
<t>When the firewall observes a STUN Binding Response packet it
checks its cache for the previously stored STUN transaction id. If
a previous STUN transaction id was found then the firewall inserts
the TAG attribute, which contains the firewall's management
address.</t>
<t>The firewall sends the (modified) STUN Binding Response towards
the STUN client.</t>
<t>The STUN client has now discovered the firewall, and can query
it or control it.</t>
</list></t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="query_and_control" title="Query and Control ">
<t>This section describes how to use STUN to query and control a NAT
that was discovered using the technique described in <xref
target="discovery"></xref>.</t>
<section anchor="client_procedures" title="Client Procedures">
<t>After discovering on-path NATs and firewalls with the procedure
described in <xref target="discovery"></xref>, the STUN client begins
querying and controlling those devices.<!-- The STUN client first
performs the Shared Secret Usage (as described in <xref
target="I-D.ietf-behave-rfc3489bis"></xref>) with the NAT or firewall
it discovered. After performing that usage, the STUN client now has a
STUN USERNAME and PASSWORD. The username and password are used,
thereafter, for all subsequent messages between the STUN client and
this NAT's STUN server. This procedure might be done, for example,
when the STUN client first initializes such as upon bootup or
initialization of the application.--></t>
<t>To modify an existing NAT mapping's attributes, or to request a new
NAT mapping for a new UDP port, the STUN client can now send a STUN
Binding Request to the IP address of address of the respective NAT or
firewall (using the STUN UDP port, 3478).</t>
<t>Client produces for handling the BOOTNONCE attribute can be found
in <xref target="bootnonce"></xref>.</t>
</section>
<section anchor="server_procedures" title="Server Procedures">
<!-- <t>The server should listen for STUN Shared Secret Requests and STUN
Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478) on
its public IP address(es) and its private IP address(es), and accept
such STUN packets from hosts connected to its private interface(s).
</t>
-->
<t>When receiving a STUN Binding Request the STUN controlled NAT will
respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS
attribute (which points at the NAT's public IP address and port --
just as if the STUN Binding Request had been sent to a STUN server on
the public Internet) and an XOR-INTERNAL-ADDRESS attribute (which
points to the source IP address and UDP port the packet STUN Binding
Request packet had prior to being NATted). See <xref
target="internal_diagram"></xref> which depicts how this might be
implemented in a NAT.</t>
<t>When receiving a STUN Binding Request the STUN controlled firewall
will respond with a STUN Binding Response containing an
XOR-MAPPED-ADDRESS attribute (which points at the public IP address
and port) and an XOR-INTERNAL-ADDRESS attribute (which points to the
source IP address of the interface and UDP port where the packet was
received, i.e., the internal interface).</t>
<t>Server procedures for handling the BOOTNONCE and REFRESH-INTERVAL
attributes can be found in <xref target="bootnonce"></xref> and <xref
target="refresh-interval"></xref>.</t>
<!--
<t>After receiving a STUN Shared Secret Request, the NAT follows the
procedures described in the Short-Term Usage section of <xref
target="I-D.ietf-behave-rfc3489bis"></xref>. The embedded STUN server
MUST store that username and password so long as any NAT bindings,
created or adjusted with that same STUN username, have active mappings
on the NAT, and for 60 seconds thereafter (to allow the STUN client to
obtain a new binding).</t>
<t>After receiving a STUN Binding Request containing the
REFRESH-INTERVAL attribute, the server SHOULD authenticate the request
using the USERNAME attribute and the previously-shared STUN password
(this is to defend against resource starvation attacks, see <xref
target="exhaustion"></xref>). If authenticated, the requested
lifetime can be maximized against the NAT's configured sanity check
and the lifetime indicated in the REFRESH-INTERVAL attribute of the
STUN Binding Response.</t>
<t>The Binding Response MUST
contain the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes.
The XOR-MAPPED-ADDRESS contains the public IP address and UDP port for
this binding, which is shared with the intended peer.</t>
<t>In case of a STUN controlled NAT the
XOR-INTERNAL-ADDRESS contains the IP address and UDP port of the STUN
Binding Request prior to the NAT translation, which is used by the
STUN client to walk backwards through nested NATs (see <xref
target="outside-in"></xref>). In case of a STUN controlled firewall the
XOR-INTERNAL-ADDRESS contains the IP of the interface where the message was
received, i.e., the internal interface.</t>
-->
<t>STUN Binding Requests, which arrived from its public interface(s),
MAY be handled as if the server is not listening on that port (e.g.,
return an ICMP error). This specification does not need them.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="New Attributes">
<section anchor="refresh-interval" title="REFRESH-INTERVAL Attribute">
<t>In a STUN request, the REFRESH-INTERVAL attribute indicates the
number of milliseconds that the client wants the NAT binding (or
firewall pinhole) to be opened. This applies to all bindings that
exist in that NAT from that same source IP address and same source UDP
port (see also <xref target="linux-specifics"></xref>). In a STUN
response, the REFRESH-INTERVAL attribute indicates the number of
milliseconds the STUN server (embedded in the NAT or firewall) will
keep the bindings open.</t>
<t>REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and
represents an interval measured in milliseconds (thus the maximum
value is approximately 50 days). This attribute can be present in
Binding Requests and in Binding Responses.<!-- In a request, the value
0xFFFF means it is a query and the refresh interval is not actually
changed. --></t>
</section>
<section title="XOR-INTERNAL-ADDRESS Attribute">
<t>This attribute MUST be present in a Binding Response and is
necessary to allow a STUN client to perform the outside-in discovery
technique, in order to discover all of the STUN Control-aware NATs
along the path.</t>
<figure anchor="xor-internal-address"
title="XOR-INTERNAL-ADDRESS Attribute">
<preamble>The format of the XOR-INTERNAL-ADDRESS attribute
is:</preamble>
<artwork align="center"
name="Format of XOR-INTERNAL-ADDRESS attribute"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (32 bits or 128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>The meaning of Family, X-Port, and X-Address are exactly as in
<xref target="I-D.ietf-behave-rfc3489bis"></xref>. The length of
X-Address depends on the address family (IPv4 or IPv6).</t>
</section>
<section title="PLEASE-TAG Attribute">
<t>If a STUN client wants to discover on-path firewalls, it MUST
include this attribute in its Binding Response when performing the
Binding Discovery usage.</t>
<t>STUN servers are not expected to understand this attribute; if they
return this attribute as an unknown attribute, it does not affect the
operation described in this document.</t>
<figure anchor="please-tag-attribute" title="PLEASE-TAG Attribute">
<preamble>The format of the PLEASE-TAG attribute is:</preamble>
<artwork align="center" name="Format of PLEASE-TAG Attribute"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Mech.|x x x x x x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>The 3-bit Mechanism field indicates the control mechanism desired.
Currently, the only defined mechanism is STUN Control, and is
indicated with all zeros. The intent of this field is to allow
additional control mechanisms (e.g., UPnP IGD, NAT-PMP, MIDCOM).</t>
</section>
<section title="TAG Attribute">
<t>The TAG attribute contains the XOR'd management transport address
of the middlebox. Typically, a firewall as well as a NAT may find this
technique useful as well.</t>
<t>If the associated STUN Request contained the PLEASE-TAG attribute,
a middlebox MUST append this attribute as the last attribute of the
STUN Response (with that same transaction-id). After appending this
attribute, the STUN length field MUST be also be adjusted.</t>
<figure anchor="tag-figure" title="TAG Attribute">
<preamble>The format of the TAG attribute is:</preamble>
<artwork align="center" name="Format of TAG Attribute"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Mech.|M|x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (32 bits or 128 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t>Mech: The 3-bit Mechanism field indicates the control mechanism
supported on the described port. Currently, the only defined mechanism
is STUN Control, and is indicated with 0x0. The intent of this field
is to allow additional control mechanisms (e.g., UPnP IGD, NAT-PMP,
MIDCOM).</t>
<t>The one-bit M field indicates if this firewall permits Mobility
Header packets to flow through it (<xref
target="RFC3775"></xref>).</t>
<t>The meaning of Family, X-Port, and X-Address are exactly as in
<xref target="I-D.ietf-behave-rfc3489bis"></xref>. The length of
X-Address depends on the address family (IPv4 or IPv6).</t>
</section>
<section anchor="bootnonce" title="BOOTNONCE Attribute">
<t>The BOOTNONCE attribute protects against the attack described in
<xref target="rogue_stun_server"></xref>.</t>
<t>Client procedures: The STUN client expects each NAT to return the
same BOOTNONCE value each time that NAT is contacted. If a NAT returns
a different value, the STUN client MUST NOT use any information
returned in the Binding Response and MUST re-run the STUN Control
procedures from the beginning (i.e., obtain its public IP address from
the STUN server on the Internet). This would only occur if an attack
is in progress or if the NAT rebooted. If the NAT rebooted, it is good
practice to re-run the STUN Control procedures anyway, as the network
topology could be different as well.</t>
<t>Server procedures: This attribute's value is a hash of the STUN
client's IP address and a value that is randomly-generated each time
the NAT is initialized. The STUN client's IP address is included in
this hash to thwart an attacker attaching to the NAT's internal
network and learning the BOOTNONCE value.</t>
<figure anchor="bootnonce-attribute" title="BOOTNONCE Attribute">
<preamble>The format of the BOOTNONCE attribute is:</preamble>
<artwork align="center" name="Format of BOOTNONCE attribute"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Boot Nonce value (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Limitations of STUN Control">
<section anchor="limit_nested_nats"
title="Overlapping IP Addresses with Nested NATs">
<figure anchor="nested_nats"
title="Overlapping Addresses with Nested NATs">
<preamble>If nested NATs have overlapping IP address space, there
will be undetected NATs on the path. When this occurs, the STUN
client will be unable to detect the presence of NAT-A if NAT-A
assigns the same UDP port. For example, in the following figure,
NAT-A and NAT-B are both using 10.1.1.x as their 'private'
network.</preamble>
<artwork align="center"
name="nested NATs with overlapping IP addresses"><![CDATA[
+------+ +--------+ +--------+
| 10.1.1.2 | 10.1.1.2 | 192.0.2.1
| STUN +-------+ NAT-A +-----+ NAT-B +------<Internet>
|client| 10.1.1.1 | 10.1.1.1 |
+------+ +--------+ +--------+
]]></artwork>
<postamble></postamble>
</figure>
<t>When this situation occurs, the STUN client can only learn the
outer-most address. This is not a problem -- the STUN client is still
able to communicate with the outer-most NAT and is still able to avoid
consuming access network bandwidth and avoid communicating with the
public STUN server. All that is lost is the ability to optimize paths
within the private network that has overlapped addresses.</t>
<t>Of course when such an overlap occurs the end host (STUN client)
cannot successfully establish bi-directional communication with hosts
in the overlapped network, anyway.</t>
</section>
<section title="Address Dependent NAT on Path">
<t>In order to utilize the mechanisms described in this document, a
STUN Request is sent from the same source IP address and source port
as the original STUN Binding Discovery message, but is sent to a
different destination IP address -- it is sent to the IP address of an
on-path NAT. If there is an on-path NAT, between the STUN client and
the STUN server, with 'address dependent' or 'address and
port-dependent' mapping behavior (as described in Section 4.1 of <xref
target="RFC4787"></xref>), that NAT will prevent a STUN client from
taking advantage of the technique described in this document. When
this occurs, the ports indicated by XOR-MAPPED-ADDRESS from the public
STUN server and the NAT's embedded STUN server will differ.</t>
<figure anchor="address_dep_mapping"
title="Address Dependant NAT on Path">
<preamble>An example of such a topology is shown in the following
figure:</preamble>
<artwork align="center" name="Address Dependent Mapping"><![CDATA[
+------+ +--------+ +--------+
| STUN | | 10.1.1.2 | 192.0.2.1
|client+-----+ NAT-A +---+ NAT-B +------<Internet>
| | 10.1.1.1 | 10.1.1.1 |
+------+ +--------+ +--------+
]]></artwork>
<postamble>In this figure, NAT-A is a NAT that has address dependent
mapping. Thus, when the STUN client sends a STUN Binding Request to
192.0.2.1 on UDP/3478, NAT-A will choose a new public UDP port for
that communication. NAT-B will function normally, returning a
different port in its XOR-MAPPED-ADDRESS, which indicates to the
STUN client that a symmetric NAT exists between the STUN client and
the STUN server it just queried (NAT-B, in this
example).</postamble>
</figure>
</section>
<section title="Address Dependent Filtering">
<t>If there is an NAT along the path that has address dependent
filtering (as described in section 5 of <xref
target="RFC4787"></xref>), and the STUN client sends a STUN packet
directly to any of the on-path NATs public addresses, the
address-dependent filtering NAT will filter packets from the remote
peer. Thus, after communicating with all of the on-path NATs the STUN
client MUST send a UDP packet to the remote peer, if the remote peer
is known.</t>
</section>
<section anchor="legacy-nats" title="Interacting with Legacy NATs">
<t>There will be cases where the STUN client attempts to communicate
with an on-path NAT, which does not support STUN Control. There are
two cases:</t>
<t><list style="symbols">
<t>the NAT does not run a STUN server on its public interface
(this will be the most common)</t>
<t>the NAT does run a STUN server on its public interface, but
does not return the XOR-INTERNAL-ADDRESS attribute defined in this
document</t>
</list></t>
<t>In both cases the optimizations described in this section will not
be available to the STUN client. This is no worse than the condition
today. This allows incremental upgrades of applications and NATs that
implement the technique described in this document.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="security_considerations" title="Security Considerations">
<t>This security considerations section will be expanded in a subsequent
version of this document. So far, the authors have identified the
following considerations:</t>
<section anchor="authorization" title="Authorization">
<t>Only hosts that are 'inside' a NAT, which a NAT is already
providing services for, can query or adjust the timeout of a NAT
mapping.</t>
<t>A discussion of additional authorization mechanisms that might be
needed for firewall traversal can be found at <xref
target="I-D.wing-session-auth"></xref>.</t>
</section>
<section anchor="exhaustion" title="Resource Exhaustion">
<t>A malicious STUN client could ask for absurdly long NAT bindings
(days) for many UDP sessions, which would exhaust the resources in the
NAT. The same attack is possible (without considering this document
and without considering STUN or other <xref
target="RFC3424">UNSAF</xref> NAT traversal techniques) -- a malicious
TCP (or UDP) client can open many TCP (or UDP) connections, and keep
them open, causing resource exhaustion in the NAT.</t>
</section>
<section title="Comparison to Other NAT Control Techniques">
<t>Like UPnP IGD, NAT-PMP, and host-initiated MIDCOM, the STUN usage
described in this document allows a host to learn its public IP
address and UDP port mapping, and to request a specific lifetime for
mappings from that same source IP address and same source UDP
port.</t>
<t>However, unlike other NAT traversal technologies, STUN Control
described in this document only allows each UDP port on the host to
create and adjust the mapping timeout of its own NAT mappings.
Specifically, an application on a host can only adjust the duration of
a NAT bindings for itself, and not for another application on that
same host, and not for other hosts. This provides security advantages
over other NAT control mechanisms where malicious software on a host
can surreptitiously create NAT mappings to another application or to
another host.</t>
</section>
<section anchor="rogue_stun_server" title="BOOTNONCE Attribute">
<t>Using the mechanisms described in this document, a STUN client
learns the public IP addresses of its NAT which supports the
mechanisms described in this document. However, without the STUN
client's knowledge, that NAT may acquire a new IP address (e.g., due
to DHCP lease expiration or network renumbering). When this occurs,
the STUN client will send a STUN Binding Request to the NAT's previous
public IP address. If an attacker were to run a rogue STUN server on
that address, the attacker will have effectively compromised the STUN
server, as described in Section 12.2.1 of <xref
target="RFC3489"></xref>. The attacker, upon receiving STUN Binding
Requests, will reply with STUN Binding Responses indicating an IP
address the attacker controls. The attacker will thus have access to
the subsequent flow established by the STUN client (e.g., RTP
traffic). This attack is possible because the STUN client is unable to
distinguish the attacker's replies from replies from the legitimate
NAT.</t>
<t>To defend against this attack, the STUN server embedded in the NAT
returns a BOOTNONCE value. The STUN client validates that it receives
the same BOOTNONCE value in each STUN Binding Response from that NAT.
If the STUN client receives a new BOOTNONCE value, the STUN client
discards information about NATs it has learned through the procedures
in this document, and restarts the procedure described in this
document.</t>
<t>A weakness of this approach is that an attacker can learn the
BOOTNONCE value if the attacker is able to connect to the NAT's
internal network prior to initiating the attack. This is plausible if
the internal network has no security (e.g., public WiFi network). For
this reason, it is RECOMMENDED that the BOOTNONCE value is hashed with
the STUN client's IP address. Doing so means that a successful
attacker must acquire both the same IP address as the victim from
behind the NAT (to learn the BOOTNONCE), and must also acquire the
NAT's previous public IP address, or needs to be on-path between the
victim and its NAT (in which case the attacker has no incentive to
redirect traffic elsewhere to observe such traffic; however, the
attacker might be interested in redirecting traffic towards another
endpoint on the Internet. To thwart that attack, the STUN client MUST
only honor STUN responses that have an X-MAPPED-ADDRESS that matches
the public IP address of the NAT-embedded STUN server.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Open Issues and Discussion Points">
<t><list style="symbols">
<t>Discussion Point: After discovering NATs and firewalls,
controlling those devices might also be done with a middlebox
control protocol (e.g., by using standard or slightly modified
versions of SIMCO, UPnP IGD, MIDCOM, or NAT-PMP). This is open for
discussion as this document is scoped within the IETF.</t>
<!--
<t>Discussion Point: Traditional traceroute provides similar functionality, and in many
cases traceroute survives traversing over a NAT that doesn't support STUN Control.
However, traceroute has significant disadvantages (induces a load on intermediate
devices to return ICMP error messages, and those ICMP messages are routinely or
inadvertently filtered). Unlike the Inside-Out technique described below, traceroute
doesn't rely on the default route.</t>
-->
<t>Discussion Point: Tagging would also be useful for the
Connectivity Check usage (which is used by ICE), especially
considering that a different firewall may be traversed for media
than for the initial Binding Discovery usage. In such a situation,
the new on-path firewall's policy might not allow a binding request
to leave the network or allow a binding response to return. In this
case, the firewall would need to indicate its presence to the STUN
client in another way. An ICMP error message may be appropriate, and
an <xref target="RFC4884">ICMP extension</xref> could indicate the
firewall is controllable.</t>
<t>Open issue: We could resolve the problem of address dependant
NATs along the path by introducing a new STUN attribute which
indicates the UDP port the STUN client wants to control. However,
this changes the security properties of STUN Control, so this seems
undesirable.<vspace blankLines="1" /> Open issue: When the STUN
client detects an address dependant NAT, should we recommend it
abandon the STUN Control usage, and revert to operation as if it
doesn't support the STUN Control usage?</t>
<t>Open issue: How many filter entries are in address dependent
filtering NATs? If only one, this does become a real limitation if
NATs are nested; if they're not nested, the outer-most NAT can avoid
overwriting its own address in its address dependent filter.</t>
<t>Discussion: One way to thwart a resource consumption attack is to
challenge the STUN client. This would allow the STUN server to delay
the establishment of resources before a return-routability test is
performed. This functionality is currently not provided by this
specification. The NONCE attribute <xref
target="I-D.ietf-behave-rfc3489bis"></xref> could be useful to
provide this function. However, the mere sending of a UDP packet
across a NAT creates a binding (for ~2 minutes), and there isn't a
return- routability check for that.</t>
<t>The inside-out discovery technique was removed with version -03
of this document. The procedure worked as follows: The STUN client
sends a STUN request to UDP/3478 of the IP address of its default
router. If there is a STUN server listening there, it will respond,
and will indicate its default route via the new DEFAULT-ROUTE
attribute. With that information, the STUN client can discover the
next-outermost NAT by repeating the procedure. More feedback is
needed to determine whether the functionality is needed.</t>
</list></t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="IANA Considerations">
<figure>
<preamble>This section registers new STUN attributes per the
procedures in <xref
target="I-D.ietf-behave-rfc3489bis"></xref>:</preamble>
<artwork><![CDATA[
Mandatory range:
0x0029 XOR-INTERNAL-ADDRESS
0x00.. BOOTNONCE
Optional range:
0x8024 REFRESH-INTERVAL
0x80.. PLEASE-TAG
0x80.. TAG
]]></artwork>
<postamble></postamble>
</figure>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgements">
<t>Thanks to Remi Denis-Courmont, Christian Dickmann, Bajko Gabor,
Markus Isomaki, Cullen Jennings, and Philip Matthews for their
suggestions which have improved this document.</t>
<t>Thanks to Christian Dickmann and Yan Sun for their initial
implementations of STUN Control.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
</middle>
<back>
<references title="Normative References">
&rfc2119;
&I-D.ietf-behave-rfc3489bis;
&rfc4787;
&rfc3489;
&rfc3775;
</references>
<references title="Informational References">
&I-D.ietf-behave-turn;
<reference anchor="UPnP-IGD"
target="http://www.upnp.org/standardizeddcps/igd.asp">
<front>
<title>Universal Plug and Play (UPnP) Internet Gateway Device
(IGD)</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date month="November" year="2001" />
</front>
</reference>
<reference anchor="Vista-cert"
target="http://download.microsoft.com/download/d/e/1/de1e0c8f-a222-47bc-b78b-1656d4cf3cf7/WLP-DeviceReqs_309.pdf">
<front>
<title>Windows Logo Program Device Requirements</title>
<author fullname="Microsoft" surname="Microsoft">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
&I-D.cheshire-nat-pmp;
&rfc3303;
&I-D.ietf-mmusic-ice;
&I-D.ietf-sip-outbound;
&I-D.ietf-nsis-nslp-natfw;
&rfc4884;
&I-D.shore-tist-prot;
&I-D.shore-nls-tl;
&rfc3424;
&rfc3948;
&I-D.wing-session-auth;
&rfc3947;
&rfc4306;
&rfc4380;
</references>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Changes">
<section title="Changes in -05">
<t><list style="symbols">
<t>Teredo is another mechanism to learn outer-most NAT, and Teredo
also benefits from STUN Control with reduced frequency of
keepalives.</t>
<t>Provided more detail in how IKE/IPsec-over-UDP would operate
with STUN Control.</t>
</list></t>
</section>
<section title="Changes in -04">
<t><list style="symbols">
<t>Clarified that all existing bindings, for that source IP
address and UDP port, are controlled with STUN Control.</t>
<t>Introduction now concentrates on the primary purpose of STUN
Control, namely reducing keepalive traffic for SIP-Outbound.</t>
</list></t>
</section>
<section title="Changes in -03">
<t><list style="symbols">
<t>Removed TLS from normal STUN operation (as few use it, and ICE
makes it unnecessary anyway)</t>
<t>BOOTNONCE attribute replaces STUN Control's previous use of
TLS.</t>
<t>Added "MIP-capable" bit to TAG attribute</t>
<t>Removed "inside-out" discovery technique.</t>
</list></t>
</section>
</section>
<section anchor="implementation details" title="Implementation Details">
<section title="Internal NAT Operation">
<t><figure anchor="internal_diagram"
title="Block Diagram of Internal NAT Operation">
<preamble>Internally, the NAT can be diagrammed to function like
this, where the NAT operation occurs before the STUN
server:</preamble>
<artwork align="center"><![CDATA[
|
| outside interface
|
+---------+---------------+
| | |
| | +--------+ |
| |----+ STUN | |
| | | Server | |
| | +---^----+ |
| | | |
| | API |
| | | |
| +-------+--------V----+ |
| | NAT Function | |
| +-------+-------------+ |
| | |
+---------+---------------+
|
| inside interface
|
|]]></artwork>
<postamble>The host on the 'inside' interface of the NAT sends
packets to the NAT's public interface, where the STUN server is
listening. This STUN server returns the same public IP address
(XOR-MAPPED-ADDRESS) as a STUN server that resides on a separate
server on the 'outside' interface. In order to query and to
control the NAT binding lifetimes, the STUN server uses an API
with the NAT function.</postamble>
</figure></t>
</section>
<section anchor="linux-specifics" title="Linux specifics">
<t>The Linux NAT implementation maintains a separate connection table
entry for every binding. When STUN Control is used to control the
binding lifetime (e.g., extend the lifetime), the binding lifetime for
each of those connection table entries is modified to the new
value.</t>
<figure>
<preamble>For example, with the following message flow:</preamble>
<artwork><![CDATA[ STUN Client NAT STUN Server
| | |
1. |-----Binding Request (UDP)--------------->|
2. |<----Binding Response (UDP)---------------|
| | |
3. |--Binding Request (UDP)------->| |
4. |<-Binding Response (UDP)-------| |
| | |]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble>the following two connection table entries are
created:</preamble>
<artwork><![CDATA[ udp 17 24 src=10.7.2.4 dst=10.7.1.2 sport=1024
dport=3478 packets=1 bytes=64 src=10.7.1.2
dst=10.7.1.3 sport=3478 dport=1024 packets=1
bytes=84 mark=0 use=1
udp 17 25 src=10.7.2.4 dst=10.7.1.3 sport=1024
dport=3478 packets=2 bytes=64 src=10.7.1.3
dst=10.7.2.4 sport=3478 dport=1024 packets=2
bytes=208 mark=0 use=1]]></artwork>
<postamble>the first src/dst/sport/dport combination is the internal
and the second one is the external version. Both are equal in the
second connection, as the NAT function wasn't active for the
"internal" message.</postamble>
</figure>
<t>s</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 04:38:11 |