< draft-wing-behave-nat-control-stun-usage-03.txt   draft-wing-behave-nat-control-stun-usage-04.txt >
BEHAVE D. Wing BEHAVE D. Wing
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 9, 2008 H. Tschofenig Expires: April 12, 2008 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
July 8, 2007 October 10, 2007
Discovering, Querying, and Controlling Firewalls and NATs using STUN Discovering, Querying, and Controlling Firewalls and NATs using STUN
draft-wing-behave-nat-control-stun-usage-03 draft-wing-behave-nat-control-stun-usage-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008. This Internet-Draft will expire on April 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Simple Traversal Underneath NAT (STUN) is a mechanism for traversing Simple Traversal Underneath NAT (STUN) is a mechanism for traversing
NATs. STUN requests are transmitted through a NAT to external STUN NATs. STUN requests are transmitted through a NAT to external STUN
servers. While this works very well, its two primary drawbacks are servers. While this works very well, its two primary drawbacks are
the inability to modify the properties of a NAT binding and the need the inability to modify the properties of a NAT binding and the need
to query a public STUN server for every new NAT binding (e.g., every to query a public STUN server for every new NAT binding (e.g., every
phone call). These drawbacks require frequent messages which present phone call). These drawbacks require frequent keepalive messages,
a load on servers (like SIP servers and STUN servers) and are bad for which contribute negatively to server and network load.
low speed access networks, such as cellular access.
This document describes two mechanisms to discover NATs and firewalls This document describes two mechanisms to discover NATs and firewalls
and a mechanism to query and control them. With these mechanisms, and a mechanism to query and control them. With these mechanisms,
binding discovery and keepalive traffic can be reduced to involve binding discovery and keepalive traffic can be reduced to involve
only the necessary NATs or firewalls. At the same time, backwards only the necessary NATs or firewalls. This eliminates the keepalive
compatibility with NATs and firewalls that do not support this traffic to servers, and vastly reduces keepalive traffic across the
document is retained, which allows for incremental deployment of network. At the same time, backwards compatibility with NATs and
these mechanisms. firewalls that do not support this specification is retained, which
allows for incremental deployment of these mechanisms.
This document is discussed on the SAFE mailing list, This document is discussed on the SAFE mailing list,
<http://www1.ietf.org/mailman/listinfo/safe>. <http://www1.ietf.org/mailman/listinfo/safe>.
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation and Benefits . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2.1. Comparison with other NAT Traversal Techniques . . . . . . 7
4. Discovery of Middleboxes (NATs and Firewalls) . . . . . . . . 6 2.1.1. Simple Security Model . . . . . . . . . . . . . . . . 7
4.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Incremental Deployment . . . . . . . . . . . . . . . . 7
4.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 8 2.2. Optimize STUN keepalive messages . . . . . . . . . . . . . 7
4.2. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 8
5. Query and Control . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Candidate Gathering . . . . . . . . . . . . . . . . . 8
5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 11 2.3.2. Learning STUN Servers without Configuration . . . . . 8
5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 11 2.3.3. Media Keepalive . . . . . . . . . . . . . . . . . . . 8
6. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4. Reduce IPsec keepalive messages . . . . . . . . . . . . . 9
6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 12 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9
6.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . . . 12 4. Discovery of Middleboxes (NATs and Firewalls) . . . . . . . . 10
6.3. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . . . 13 4.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. TAG Attribute . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 12
6.5. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 14 4.2. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Query and Control . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Simple Security Model . . . . . . . . . . . . . . . . . . 15 5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 14
7.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 15 5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 15
7.3. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 15 6. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 15
7.4. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 15
7.4.1. Candidate Gathering . . . . . . . . . . . . . . . . . 16 6.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . . . 16
7.4.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 16 6.3. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . . . 16
7.4.3. Learning STUN Servers without Configuration . . . . . 16 6.4. TAG Attribute . . . . . . . . . . . . . . . . . . . . . . 17
8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 18
8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 17 7. Limitations of STUN Control . . . . . . . . . . . . . . . . . 18
8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 17 7.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 19
8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 18 7.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 19
8.4. Interacting with Legacy NATs . . . . . . . . . . . . . . . 18 7.3. Address Dependent Filtering . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.4. Interacting with Legacy NATs . . . . . . . . . . . . . . . 20
9.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 19 8.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 21
9.3. Comparison to Other NAT Control Techniques . . . . . . . . 19 8.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 21
9.4. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 20 8.3. Comparison to Other NAT Control Techniques . . . . . . . . 21
10. Open Issues and Discussion Points . . . . . . . . . . . . . . 20 8.4. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Open Issues and Discussion Points . . . . . . . . . . . . . . 22
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Informational References . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 24 12.2. Informational References . . . . . . . . . . . . . . . . . 25
A.1. Changes between -03 and 02 . . . . . . . . . . . . . . . . 24 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Block Diagram of Internal NAT Operation . . . . . . . 24 A.1. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Appendix B. Implementation Details . . . . . . . . . . . . . . . 27
B.1. Internal NAT Operation . . . . . . . . . . . . . . . . . . 27
B.2. Linux specifics . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
Two common usages of Simple Traversal Underneath NAT (STUN) Two common usages of Simple Traversal Underneath NAT (STUN)
([I-D.ietf-behave-rfc3489bis],[RFC3489]) are Binding Discovery and ([I-D.ietf-behave-rfc3489bis],[RFC3489]) are Binding Discovery and
NAT Keepalive. The Binding Discovery usage allows a STUN client to NAT Keepalive. The Binding Discovery usage allows a STUN client to
learn its public IP address (from the perspective of the STUN server learn its public IP address (from the perspective of the STUN server
it contacted) and the NAT keepalive usage allows a STUN client to it contacted) and the NAT keepalive usage allows a STUN client to
keep an active NAT binding alive. Unlike some other techniques keep an active NAT binding alive. Unlike some other techniques
(e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour [Bonjour]), STUN does (e.g., UPnP [UPnP], MIDCOM [RFC3303], NAT-PMP
not interact directly with the NAT. Thus, STUN cannot request [I-D.cheshire-nat-pmp]), NSIS-NSLP [I-D.ietf-nsis-nslp-natfw], STUN
does not interact directly with the NAT. Thus, STUN cannot request
additional services from the NAT, such as longer lifetimes which additional services from the NAT, such as longer lifetimes which
would reduce keepalive messages. Furthermore, allocating new NAT would reduce keepalive messages. Furthermore, allocating new NAT
bindings (e.g., each phone call) requires communication with a STUN bindings (e.g., each phone call) requires communication with a STUN
server located somewhere on the Internet. server located somewhere on the Internet.
This document describes three mechanisms for the STUN client to This document describes three mechanisms for the STUN client to
discover NATs and firewalls that are on path with its STUN server. discover NATs and firewalls that are on path with its STUN server.
After discovering the NATs and firewalls, the STUN client can query After discovering the NATs and firewalls, the STUN client can query
and control those devices using STUN. The STUN client needs to only and control those devices using STUN. The STUN client needs to only
ask those STUN servers (embedded in the NATs and firewalls) for ask those STUN servers (embedded in the NATs and firewalls) for
public IP addresses and UDP ports, thereby offloading that traffic public IP addresses and UDP ports, thereby offloading that traffic
from the STUN server on the Internet. Additionally, the STUN client 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 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- the flow, and the STUN client can learn the IP address of the next-
outermost NAT. By repeating this procedure with the next-outermost outermost NAT. By repeating this procedure with the next-outermost
NAT, all of the NATs along that path can have their bindings NAT, all of the NATs along that path can have their bindings
extended. By learning all of the STUN servers on the path between extended. By learning all of the STUN servers on the path between
the public Internet and itself, an endpoint can optimize the path of the public Internet and itself, an endpoint can optimize the path of
peer-to-peer communications. peer-to-peer communications.
2. Motivation 2. Motivation and Benefits
There are a number of problems with existing NAT traversal There are a number of problems with existing NAT traversal
techniques, such as STUN [RFC3489], [UPnP], and [Bonjour]): techniques, such as STUN, UPnP, MIDCOM, NAT-PMP, and NSIS-NSLP:
nested NATs: nested NATs:
Today, many ISPs provide their subscribers with modems that have Today, many ISPs provide their subscribers with modems that have
embedded NATs, often with only one physical Ethernet port. These embedded NATs or within the ISP's network. These subscribers then
subscribers then install NATs behind those devices to provide install NATs behind those devices to provide additional features,
additional features, such as wireless access. Another example is such as wireless access. In these situations, UPnP and NAT-PMP no
a NAT in the basement of an apartment building or a campus longer function, as those protocols can only control the first NAT
dormitory, which combined with a NAT within the home or dormitory closest to the host. STUN continues to function, but is unable to
room also result in nested NATs. In both of these situations, optimize network traffic behind those nested NATs (e.g., traffic
UPnP and Bonjour no longer function at all, as those protocols can that stays within the same house or within the same apartment
only control the first NAT closest to the host. STUN continues to building).
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).
One technique to avoid nested NATs is to disable one of the NATs, One technique to avoid nested NATs is to disable one of the NATs,
if it obtains an RFC 1918 address on its WAN interface. This as recommended by [Vista-cert]. However, this merely sidesteps
merely sidesteps the problem. This technique is also ineffective the problem of nested NATs, as some NATs are installed for a
if the ISP is NATting its subscribers and the ISP restricts each reason (e.g., reduce IP address consumption or provide a modicum
subscriber to one IP address. 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.
The technique described in this document allows optimization of The technique described in this document allows optimization of
the traffic behind those NATs so that the traffic can traverse the the traffic behind those NATs so that the traffic can traverse the
fewest NATs possible. fewest NATs possible.
chattiness: chattiness:
To perform its binding discovery, a STUN client communicates to a To keep NAT bindings from timing out and to perform its binding
server on the Internet. This consumes bandwidth across the user's discovery, a STUN packets are sent to a server on the Internet.
access network, which in some cases is bandwidth constrained This consumes bandwidth across the user's access network, which in
(e.g., wireless, satellite). STUN's chattiness is often cited as some cases is bandwidth constrained (e.g., wireless, satellite)
a reason to use other NAT traversal techniques such as UPnP or and also creates a load on the server. STUN's chattiness is often
Bonjour. cited as a reason to use other NAT traversal techniques such as
UPnP or NAT-PMP.
The technique described in this document provides a significant The technique described in this document provides a significant
reduction in STUN's chattiness, to the point that the only time a reduction in STUN's chattiness, to the point that the only time a
STUN client needs to communicate with the STUN server on the STUN client needs to communicate with the STUN server on the
public Internet is when the STUN client is initialized. public Internet is when the STUN client is initialized.
incremental deployment: lack of incremental deployment:
Many other NAT traversal techniques require the endpoint and its Many other NAT traversal techniques require the endpoint and its
NAT to both support the new feature or else NAT traversal is not NAT to both support the same NAT traversal technique or else NAT
possible at all. traversal is not possible at all. Examples include NSIS-NSLP,
NAT-PMP, UPnP, and MIDCOM.
The technique described in this document allows incremental The technique described in this document allows incremental
deployment of local endpoints and NATs that support STUN Control. deployment of local endpoints and NATs that support STUN Control.
If the local endpoint, or its NATs, does not support the STUN If the local endpoint, or its NATs, does not support the STUN
Control functionality, then STUN (see Control functionality, then STUN (see
[I-D.ietf-behave-rfc3489bis]) and ICE [I-D.ietf-mmusic-ice] [I-D.ietf-behave-rfc3489bis]), [I-D.ietf-sip-outbound], and ICE
procedures are used to traverse the NATs without the optimizations [I-D.ietf-mmusic-ice] procedures are used to traverse the NATs
described in this document. without the optimizations described in this document.
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.
2.1. Comparison with other NAT Traversal Techniques
STUN Control offers the following benefits over other NAT traversal
and NAT control techniques such as NSIS-NSLP, MIDCOM, NAT-PMP, and
UPnP.
2.1.1. Simple Security Model
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.
2.1.2. Incremental Deployment
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 Section 7.4).
If the outer-most NAT does support STUN Control, the STUN client can
gain some significant optimizations as described in the following
sections.
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.
2.2. Optimize STUN keepalive messages
The primary value of the protocol and technique described in this
document is the reduction of STUN's chattiness.
In SIP outbound [I-D.ietf-sip-outbound], the SIP proxy is also the
STUN server, and a UDP keepalive message is sent every 30 seconds to
that server. STUN Control as described in this document enables two
optimizations of SIP-Outbound's keepalive mechanism:
1. all of the on-path NATs can explicitly indicate their timeouts,
reducing the frequency of keepalive messages.
2. 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, and;
2.3. Optimize ICE
The STUN Control usage provides several opportunities to optimize ICE
[I-D.ietf-mmusic-ice], as described in this section.
2.3.1. Candidate Gathering
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.
2.3.2. Learning STUN Servers without Configuration
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.
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:
+-------+ +-------+ +-------------+
endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server |
+-------+ | +-------+ +-------------+
|
endpoint-2
2.3.3. Media Keepalive
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:
1. STUN keepalive messages need only be sent to the outer-most NAT,
rather than across the access link to the remote peer, and;
2. all of the on-path NATs can explicitly indicate their timeouts,
which allows reducing the keepalive frequency.
2.4. Reduce IPsec keepalive messages
STUN Control is also able to reduce keepalive traffic for non-STUN
protocols. In Section 4 of [RFC3948], it is suggested that IPsec
keepalive packets be sent every 20 seconds if an on-path NAT is
detected. If a host and its NAT were to implement STUN Control, the
host can query and control the NAT's binding lifetime, and thus
reduce the NAT keepalive traffic. This reduction in keepalive
traffic would slightly reduce the load on its IPsec concentrator.
3. Overview of Operation 3. Overview of Operation
This document describes three functions, which are all implemented This document describes three functions, which are all implemented
using the STUN protocol: using the STUN protocol:
Discovery of Middleboxes (NATs and Firewalls): Discovery of Middleboxes (NATs and Firewalls):
This document describes two techniques for finding NATs or This document describes two techniques for finding NATs or
firewalls (see Section 4). These two approaches are: firewalls (see Section 4). These two approaches are:
skipping to change at page 7, line 4 skipping to change at page 10, line 25
standardization process. However, it is possible to combine these standardization process. However, it is possible to combine these
two techniques. two techniques.
4.1. Outside-In 4.1. Outside-In
When a STUN client sends a STUN Request to a STUN server, it receives 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 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 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 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 client knows there is at least one NAT between itself and the STUN
server, and knows the 'public' IP address (and port) allocated by the server. The STUN client also learns the 'public' IP address (and
outermost NAT. For example, in the following diagram, the STUN port) allocated by the outermost NAT. For example, in the following
client learns the public IP address of its NAT is 192.0.2.1: diagram, the STUN client learns the public IP address of its NAT is
192.0.2.1:
+--------+ +---------------+ +--------+ +---------------+
| STUN | | 192.0.2.1 +--------+ | STUN | | 192.0.2.1 +--------+
| Client +-------------+ +---<Internet>---+ STUN | | Client +-------------+ +---<Internet>---+ STUN |
| 10.1.1.2/4193 10.1.1.1 | | Server | | 10.1.1.2/4193 10.1.1.1 | | Server |
+--------+ | | +--------+ +--------+ | | +--------+
| NAT with | | NAT with |
| Embedded STUN | | Embedded STUN |
| Server | | Server |
+---------------+ +---------------+
Figure 1: One NAT with embedded STUN server Figure 2: One NAT with embedded STUN server
After learning the public IP address of its outer-most NAT, the STUN After learning the public IP address of its outer-most NAT, the STUN
client attempts to communicate with the STUN server embedded in that client attempts to communicate with the STUN server embedded in that
outer-most NAT. The STUN client does this by sending a STUN Binding outer-most NAT. The STUN client does this by sending a STUN Binding
Request to the NAT's public IP address. The NAT will return a STUN Request to the NAT's public IP address. The NAT will return a STUN
Binding Response message including the XOR-INTERNAL-ADDRESS Binding Response message including the XOR-INTERNAL-ADDRESS
attribute, which will indicate the IP address and UDP port seen on attribute, which will indicate the IP address and UDP port seen on
the *internal* side of the NAT for that translation (see Figure 14 in the *internal* side of the NAT for that translation (see Figure 14).
Appendix B). In the example above, the IP address and UDP port
indicated in XOR-INTERNAL-ADDRESS are the same as that used by the In the example above, the IP address and UDP port indicated in XOR-
STUN client (10.1.1.2/4193), which indicates there are no other NATs INTERNAL-ADDRESS are the same as that used by the STUN client
between the STUN client and that outer-most NAT. (10.1.1.2/4193), which indicates there are no other NATs between the
STUN client and that outer-most NAT.
STUN Client NAT STUN Server STUN Client NAT STUN Server
| | | | | |
1. |-----Binding Request (UDP)--------------->| 1. |-----Binding Request (UDP)--------------->|
2. |<----Binding Response (UDP)---------------| 2. |<----Binding Response (UDP)---------------|
| | | | | |
3. |--Binding Request (UDP)------->| | 3. |--Binding Request (UDP)------->| |
4. |<-Binding Response (UDP)-------| | 4. |<-Binding Response (UDP)-------| |
| | | | | |
Figure 2: Communication Flow Figure 3: Communication Flow
In the call flow above, steps 1 and 2 correspond to the STUN behavior In the call flow above, steps 1 and 2 correspond to the STUN behavior
described in [I-D.ietf-behave-rfc3489bis]: described in [I-D.ietf-behave-rfc3489bis]:
1: The STUN client sends a UDP Binding Request to its STUN server 1: The STUN client sends a UDP Binding Request to its STUN server
that is located on the Internet. that is located on the Internet.
2: The STUN server on the Internet responds with a UDP Binding 2: The STUN server on the Internet responds with a UDP Binding
Response. Response.
skipping to change at page 8, line 23 skipping to change at page 11, line 42
3: The STUN client sends a UDP Binding Request to the IP address 3: The STUN client sends a UDP Binding Request to the IP address
learned from the STUN server on the Internet. This will be learned from the STUN server on the Internet. This will be
received by the STUN server embedded in the outer-most NAT. received by the STUN server embedded in the outer-most NAT.
4: The STUN server (embedded in the NAT) responds with a UDP Binding 4: The STUN server (embedded in the NAT) responds with a UDP Binding
Response. Response.
The response obtained in message (4) contains the XOR-MAPPED-ADDRESS The response obtained in message (4) contains the XOR-MAPPED-ADDRESS
attribute, which will have the same value as when the STUN server on attribute, which will have the same value as when the STUN server on
the Internet responded (in step 2). The STUN client can perform the Internet responded (in step 2). Thereafter, so long as the
steps (3) and (4) for any new UDP communication, without needing to BOOTNONCE value doesn't change, the STUN client can perform steps (3)
repeat steps (1) and (2). This meets the desire to reduce and (4) for any new UDP communication, without needing to repeat
chattiness. The STUN client also only needs to send keepalives steps (1) and (2). This meets the desire to reduce chattiness. The
towards the outer-most NAT's IP address, as well (reduces chatter for STUN client also only needs to send keepalives towards the outer-most
SIP outbound [I-D.ietf-sip-outbound]). NAT's IP address, as well (reduces chatter for SIP outbound
[I-D.ietf-sip-outbound]).
The response obtained in message (4) will also contain the XOR- The response obtained in message (4) will also contain the XOR-
INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3) INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3)
and (4) in order to query or control those on-path NATs between 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 itself and its STUN server on the Internet. This is described in
detail in Section 4.1.1. This functionality meets the need to detail in Section 4.1.1. This functionality meets the need to
optimize traffic between nested NATs, without requiring configuration optimize traffic between nested NATs, without requiring configuration
of intermediate STUN servers. of intermediate STUN servers.
The STUN client can request each NAT to increase the binding The STUN client can request each NAT to increase the binding lifetime
lifetime, as described in Section 6.1. The STUN client receives for that source IP address and source UDP port, as described in
positive confirmation that the binding lifetime has been extended, Section 6.1. The STUN client receives positive confirmation that the
allowing the STUN client to significantly reduces its NAT keepalive binding lifetime has been extended, allowing the STUN client to
traffic. Additionally, as long as the NAT complies with [RFC4787] significantly reduces its NAT keepalive traffic. Additionally, as
(which is indicated by its support of this document), the STUN long as the NAT complies with [RFC4787] (which is indicated by its
client's keepalive traffic need only be sent to the outer-most NAT's support of this document), the STUN client's keepalive traffic need
IP address. This functionality meets the need to reduce STUN's only be sent to the outer-most NAT's IP address. This functionality
chattiness. meets the need to reduce STUN's chattiness.
4.1.1. Nested NATs 4.1.1. Nested NATs
Nested NATs are controlled individually. The nested NATs are Nested NATs are controlled individually. The nested NATs are
discovered, from outer-most NAT to the inner-most NAT, using the XOR- discovered, from outer-most NAT to the inner-most NAT, using the XOR-
INTERNAL-ADDRESS attribute. INTERNAL-ADDRESS attribute.
The example in Figure 3 shows how a STUN client iterates over the The example in Figure 4 shows how a STUN client iterates over the
NATs to communicate with all of the NATs in the path. NATs to communicate with all of the NATs in the path.
The following figure shows two nested NATs: The following figure shows two nested NATs:
+------+ +--------+ +--------+ +------+ +--------+ +--------+
| 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+ | 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+
| STUN +------+ NAT-B +-----+ NAT-A +---<Internet>---+STUN Server| | STUN +------+ NAT-B +-----+ NAT-A +---<Internet>---+STUN Server|
|Client| 192.168.1.1 | 10.1.1.1 | +-----------+ |Client| 192.168.1.1 | 10.1.1.1 | +-----------+
+------+ +--------+ +--------+ +------+ +--------+ +--------+
Figure 3: Two nested NATs with embedded STUN servers Figure 4: Two nested NATs with embedded STUN servers
First, the STUN client would learn the outer-most NAT's IP address by First, the STUN client would learn the outer-most NAT's IP address by
performing the steps shown in Figure 2. In the case below, however, performing the steps shown in Figure 3. In the case below, however,
the IP address and UDP port indicated by the XOR-INTERNAL-ADDRESS 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, will not be the STUN client's own IP address and UDP port -- rather,
it is the IP address and UDP port on the *outer* side of the NAT-B -- it is the IP address and UDP port on the *outer* side of the NAT-B --
10.1.1.2. 10.1.1.2.
Because of this, the STUN client repeats the procedure and sends Because of this, the STUN client repeats the procedure and sends
another STUN Binding Request to that newly-learned address (the another STUN Binding Request to that newly-learned address (the
*outer* side of NAT-B). NAT-B will respond with a STUN Binding *outer* side of NAT-B). NAT-B will respond with a STUN Binding
Response containing the XOR-INTERNAL-ADDRESS attribute, which will Response containing the XOR-INTERNAL-ADDRESS attribute, which will
match the STUN client's IP address and UDP port. The STUN client match the STUN client's IP address and UDP port. The STUN client
skipping to change at page 9, line 46 skipping to change at page 13, line 21
1. |-----Binding Request (UDP)--------------->| 1. |-----Binding Request (UDP)--------------->|
2. |<----Binding Response (UDP)---------------| 2. |<----Binding Response (UDP)---------------|
| | | | | | | |
3. |--Binding Request (UDP)------->| | } 3. |--Binding Request (UDP)------->| | }
4. |<-Binding Response (UDP)-------| | } NAT Control 4. |<-Binding Response (UDP)-------| | } NAT Control
| | | | } STUN Usage | | | | } STUN Usage
5. |--Binding Req (UDP)-->| | | } 5. |--Binding Req (UDP)-->| | | }
6. |<-Binding Resp (UDP)--| | | } 6. |<-Binding Resp (UDP)--| | | }
| | | | | | | |
Figure 4: Message Flow for Outside-In with Two NATs Figure 5: Message Flow for Outside-In with Two NATs
Once a shared secret has been obtained with each of the on-path NATs, Once a shared secret has been obtained with each of the on-path NATs,
the STUN client no longer needs the TLS/TCP connection -- all the STUN client no longer needs the TLS/TCP connection -- all
subsequent bindings for individual UDP streams (that is, for each subsequent bindings for individual UDP streams (that is, for each
subsequent call) are obtained by just sending a Binding Request to subsequent call) are obtained by just sending a Binding Request to
each of the NATs. By sending a Binding Request to both NAT-A and each of the NATs. By sending a Binding Request to both NAT-A and
NAT-B, the STUN client has the opportunity to optimize the packet NAT-B, the STUN client has the opportunity to optimize the packet
flow if their UDP peer is also behind the same NAT. flow if their UDP peer is also behind the same NAT.
4.2. Tagging 4.2. Tagging
skipping to change at page 10, line 28 skipping to change at page 13, line 50
Each on-path firewall would be able to insert its own TAG attribute. 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 In this way, the STUN Response would contain a pointer to each of the
on-path firewalls between the client and that STUN server. on-path firewalls between the client and that STUN server.
Motivation for developing the Tagging mechanism: The Outside-In Motivation for developing the Tagging mechanism: The Outside-In
discovery technique (Section 4.1) uses the public IP address of discovery technique (Section 4.1) uses the public IP address of
the NAT to find the outer-most NAT that supports STUN Control. the NAT to find the outer-most NAT that supports STUN Control.
Firewalls do not translate packets and hence a different technique Firewalls do not translate packets and hence a different technique
is needed to identify firewalls. is needed to identify firewalls.
Note that tagging is similar to how NSIS Note that tagging is similar to how NSIS-NSLP
[I-D.ietf-nsis-nslp-natfw], TIST [I-D.shore-tist-prot], and NLS [I-D.ietf-nsis-nslp-natfw], TIST [I-D.shore-tist-prot], and NLS
[I-D.shore-nls-tl] function. [I-D.shore-nls-tl] function.
This figure shows how tagging functions. This figure shows how tagging functions.
STUN Client firewall STUN Server STUN Client firewall STUN Server
| | | | | |
1. |--Binding Request->|------------------>| 1. |--Binding Request->|------------------>|
2. | |<-Binding Response-| 2. | |<-Binding Response-|
3. | [inserts tag] | 3. | [inserts tag] |
4. |<-Binding Response-| | 4. |<-Binding Response-| |
5. [firewall discovered] | | 5. [firewall discovered] | |
Figure 5: Tagging Message Flow Figure 6: Tagging Message Flow
1. A Binding Request, containing the PLEASE-TAG attribute, is sent 1. A Binding Request, containing the PLEASE-TAG attribute, is sent
to the IP address of the STUN server that is located somewhere on to the IP address of the STUN server that is located somewhere on
the Internet. This is seen by the firewall, and the firewall the Internet. This is seen by the firewall, and the firewall
remembers the STUN transaction id, and permits the STUN Binding remembers the STUN transaction id, and permits the STUN Binding
Request packet. Request packet.
2. When the firewall observes a STUN Binding Response packet it 2. When the firewall observes a STUN Binding Response packet it
checks its cache for the previously stored STUN transaction id. checks its cache for the previously stored STUN transaction id.
If a previous STUN transaction id was found then the firewall If a previous STUN transaction id was found then the firewall
inserts the TAG attribute, which contains the firewall's inserts the TAG attribute, which contains the firewall's
management address. management address.
3. The firewall sends the (modified) STUN Binding Response towards 3. The firewall sends the (modified) STUN Binding Response towards
the STUN client. the STUN client.
4. The STUN client has now discovered the firewall, and can query it 4. The STUN client has now discovered the firewall, and can query it
or control it. or control it.
skipping to change at page 11, line 29 skipping to change at page 15, line 4
5.1. Client Procedures 5.1. Client Procedures
After discovering on-path NATs and firewalls with the procedure After discovering on-path NATs and firewalls with the procedure
described in Section 4, the STUN client begins querying and described in Section 4, the STUN client begins querying and
controlling those devices. controlling those devices.
To modify an existing NAT mapping's attributes, or to request a new 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 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 Binding Request to the IP address of address of the respective NAT or
firewall (at STUN UDP port (3478)). firewall (using the STUN UDP port, 3478).
Client produces for handling the BOOTNONCE attribute can be found in Client produces for handling the BOOTNONCE attribute can be found in
Section 6.5. Section 6.5.
5.2. Server Procedures 5.2. Server Procedures
When receiving a STUN Binding Request the STUN controlled NAT will When receiving a STUN Binding Request the STUN controlled NAT will
respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS
attribute (which points at the NAT's public IP address and port -- 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 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 the public Internet) and an XOR-INTERNAL-ADDRESS attribute (which
points to the source IP address and UDP port the packet STUN Binding points to the source IP address and UDP port the packet STUN Binding
Request packet had prior to being NATted). Request packet had prior to being NATted). See Figure 14 which
depicts how this might be implemented in a NAT.
For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the For example, looking at Figure 2, the XOR-INTERNAL-ADDRESS is the
IP address and UDP port prior to the NAPT operation. If there is IP address and UDP port prior to the NAPT operation. If there is
only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would only one NAT, as shown in Figure 2, XOR-INTERNAL-ADDRESS would
contain the STUN client's own IP address and UDP port. If there contain the STUN client's own IP address and UDP port. If there
are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP
address of the next NAT (that is, the next NAT closer to the STUN address of the next NAT (that is, the next NAT closer to the STUN
client). client).
When receiving a STUN Binding Request the STUN controlled firewall When receiving a STUN Binding Request the STUN controlled firewall
will respond with a STUN Binding Response containing an XOR-MAPPED- will respond with a STUN Binding Response containing an XOR-MAPPED-
ADDRESS attribute (which points at the public IP address and port) ADDRESS attribute (which points at the public IP address and port)
and an XOR-INTERNAL-ADDRESS attribute (which points to the source IP and an XOR-INTERNAL-ADDRESS attribute (which points to the source IP
address of the interface and UDP port where the packet STUN Binding address of the interface and UDP port where the packet was received,
Request packet was received, i.e., the internal interface. i.e., the internal interface).
Server produces for handling the BOOTNONCE attribute can be found in Server procedures for handling the BOOTNONCE and REFRESH-INTERVAL
Section 6.5. attributes can be found in Section 6.5 and Section 6.1.
STUN Binding Requests, which arrived from its public interface(s), 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., 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. return an ICMP error). This specification does not need them.
6. New Attributes 6. New Attributes
6.1. REFRESH-INTERVAL Attribute 6.1. REFRESH-INTERVAL Attribute
In a STUN request per [I-D.ietf-behave-rfc3489bis], the REFRESH- In a STUN request, the REFRESH-INTERVAL attribute indicates the
INTERVAL attribute indicates the number of milliseconds that the number of milliseconds that the client wants the NAT binding (or
client wants the NAT binding (or firewall pinhole) to be opened. firewall pinhole) to be opened. This applies to all bindings that
When the NAT Keepalive usage is being used, the server may become exist in that NAT from that same source IP address and same source
overloaded with keepalive messages (Binding Requests or other UDP port (see also Appendix B.2). In a STUN response, the REFRESH-
application-level keepalive messages). The REFRESH-INTERVAL provies INTERVAL attribute indicates the number of milliseconds the STUN
a mechanism for the client to learn and adjust the NAT's binding server (embedded in the NAT or firewall) will keep the bindings open.
lifetime and thus reduce the frequency of client-initiated keepalive
messages.
In a STUN response, the same attribute indicates how long the STUN
controlled NAT (or a STUN controlled firewall) is willing to allocate
the binding (or to create the pinhole).
REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and
represents an interval measured in milliseconds (thus the maximum represents an interval measured in milliseconds (thus the maximum
value is approximately 50 days). This attribute can be present in value is approximately 50 days). This attribute can be present in
Binding Requests and in Binding Responses. Binding Requests and in Binding Responses.
6.2. XOR-INTERNAL-ADDRESS Attribute 6.2. XOR-INTERNAL-ADDRESS Attribute
This attribute MUST be present in a Binding Response and is necessary This attribute MUST be present in a Binding Response and is necessary
to allow a STUN client to perform the outside-in discovery technique, to allow a STUN client to perform the outside-in discovery technique,
skipping to change at page 13, line 15 skipping to change at page 16, line 29
The format of the XOR-INTERNAL-ADDRESS attribute is: The format of the XOR-INTERNAL-ADDRESS attribute is:
0 1 2 3 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 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 x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (32 bits or 128 bits) | | X-Address (32 bits or 128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: XOR-INTERNAL-ADDRESS Attribute Figure 7: XOR-INTERNAL-ADDRESS Attribute
The meaning of Family, X-Port, and X-Address are exactly as in The meaning of Family, X-Port, and X-Address are exactly as in
[I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the
address family (IPv4 or IPv6). address family (IPv4 or IPv6).
6.3. PLEASE-TAG Attribute 6.3. PLEASE-TAG Attribute
If a STUN client wants to discover on-path firewalls, it MUST include If a STUN client wants to discover on-path firewalls, it MUST include
this attribute in its Binding Response when performing the Binding this attribute in its Binding Response when performing the Binding
Discovery usage. Discovery usage.
skipping to change at page 13, line 39 skipping to change at page 17, line 13
operation described in this document. operation described in this document.
The format of the PLEASE-TAG attribute is: The format of the PLEASE-TAG attribute is:
0 1 2 3 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 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| |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PLEASE-TAG Attribute Figure 8: PLEASE-TAG Attribute
The 3-bit Mechanism field indicates the control mechanism desired. The 3-bit Mechanism field indicates the control mechanism desired.
Currently, the only defined mechanism is STUN Control, and is Currently, the only defined mechanism is STUN Control, and is
indicated with all zeros. The intent of this field is to allow indicated with all zeros. The intent of this field is to allow
additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM). additional control mechanisms (e.g., UPnP, NAT-PMP, MIDCOM).
6.4. TAG Attribute 6.4. TAG Attribute
The TAG attribute contains the XOR'd management transport address of The TAG attribute contains the XOR'd management transport address of
the middlebox. Typically, a firewall as well as a NAT may find this the middlebox. Typically, a firewall as well as a NAT may find this
technique useful as well. technique useful as well.
If the associated STUN Request contained the PLEASE-TAG attribute, a If the associated STUN Request contained the PLEASE-TAG attribute, a
middlebox MUST append this attribute as the last attribute of the middlebox MUST append this attribute as the last attribute of the
STUN Response (with that same transaction-id). After appending this STUN Response (with that same transaction-id). After appending this
skipping to change at page 14, line 20 skipping to change at page 17, line 41
The format of the TAG attribute is: The format of the TAG attribute is:
0 1 2 3 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 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 | |Mech.|M|x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (32 bits or 128 bit) | | X-Address (32 bits or 128 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: TAG Attribute Figure 9: TAG Attribute
Mech: The 3-bit Mechanism field indicates the control mechanism Mech: The 3-bit Mechanism field indicates the control mechanism
supported on the described port. Currently, the only defined supported on the described port. Currently, the only defined
mechanism is STUN Control, and is indicated with 0x0. The intent of mechanism is STUN Control, and is indicated with 0x0. The intent of
this field is to allow additional control mechanisms (e.g., UPnP, this field is to allow additional control mechanisms (e.g., UPnP,
Bonjour, MIDCOM). NAT-PMP, MIDCOM).
The one-bit M field indicates if this firewall permits Mobility The one-bit M field indicates if this firewall permits Mobility
Header packets to flow through it ([RFC3775]). Header packets to flow through it ([RFC3775]).
The meaning of Family, X-Port, and X-Address are exactly as in The meaning of Family, X-Port, and X-Address are exactly as in
[I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the
address family (IPv4 or IPv6). address family (IPv4 or IPv6).
6.5. BOOTNONCE Attribute 6.5. BOOTNONCE Attribute
The BOOTNONCE attribute protects against the attack described in The BOOTNONCE attribute protects against the attack described in
Section 9.4. Section 8.4.
Client procedures: The STUN client expects each NAT to return the Client procedures: The STUN client expects each NAT to return the
same BOOTNONCE value each time that NAT is contacted. If a NAT same BOOTNONCE value each time that NAT is contacted. If a NAT
returns a different value, the STUN client MUST NOT use any returns a different value, the STUN client MUST NOT use any
information returned in the Binding Response and MUST re-run the NAT information returned in the Binding Response and MUST re-run the STUN
Control procedures from the beginning (i.e., obtain its public IP Control procedures from the beginning (i.e., obtain its public IP
address from the STUN server on the Internet). This would only occur 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 if an attack is in progress or if the NAT rebooted. If the NAT
rebooted, it is good practice to re-run the NAT Control procedures rebooted, it is good practice to re-run the STUN Control procedures
anyway, as the network topology could be different as well. anyway, as the network topology could be different as well.
Server procedures: This attribute's value is a hash of the STUN 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 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 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 this hash to thwart an attacker attaching to the NAT's internal
network and learning the BOOTNONCE value. network and learning the BOOTNONCE value.
The format of the BOOTNONCE attribute is: The format of the BOOTNONCE attribute is:
0 1 2 3 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 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) | | Boot Nonce value (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: BOOTNONCE Attribute Figure 10: BOOTNONCE Attribute
7. Benefits
7.1. Simple Security Model
Unlike other middlebox control techniques which have relatively
complex security models because a separate control channel is used,
STUN Control's is simple. It's simple because only the flow being
used can be controlled (e.g., have its NAT timeout queried or
extended). Other flows cannot be created, queried, or controlled via
STUN Control.
7.2. Incremental Deployment
NAT Control can be incrementally deployed. If the outer-most NAT
does not support it, the STUN client behaves as normal. In this
case, the tagging procedure described in Section 4.2, will still
allow to gain some optimizations. Where the outer-most STUN NAT does
support it, the STUN client can gain some significant optimizations
as described in the following sections.
Likewise, there is no change required to applications if NATs are
deployed which support NAT 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.
7.3. Optimize SIP-Outbound
In SIP outbound [I-D.ietf-sip-outbound], the SIP proxy is also the
STUN server. STUN Control as described in this document enables two
optimizations of SIP-Outbound's keepalive mechanism:
1. 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, and;
2. all of the on-path NATs can explicitly indicate their timeouts,
reducing the frequency of keepalive messages.
7.4. Optimize ICE
The NAT Control usage provides several opportunities to optimize ICE
[I-D.ietf-mmusic-ice], as described in this section.
7.4.1. Candidate Gathering
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.
7.4.2. Keepalive
ICE uses STUN Indications as its primary media stream keepalive
mechanism. This document enables two optimizations of ICE's
keepalive technique:
1. STUN keepalive messages need only be sent to the outer-most NAT,
rather than across the access link to the remote peer, and;
2. all of the on-path NATs can explicitly indicate their timeouts,
which allows reducing the keepalive frequency.
7.4.3. Learning STUN Servers without Configuration
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.
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:
+-------+ +-------+ +-------------+
endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server |
+-------+ | +-------+ +-------------+
|
endpoint-2
8. Limitations
8.1. Overlapping IP Addresses with Nested NATs 7. Limitations of STUN Control
7.1. Overlapping IP Addresses with Nested NATs
If nested NATs have overlapping IP address space, there will be If nested NATs have overlapping IP address space, there will be
undetected NATs on the path. When this occurs, the STUN client will 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 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 UDP port. For example, in the following figure, NAT-A and NAT-B are
both using 10.1.1.x as their 'private' network. both using 10.1.1.x as their 'private' network.
+------+ +--------+ +--------+ +------+ +--------+ +--------+
| 10.1.1.2 | 10.1.1.2 | 192.0.2.1 | 10.1.1.2 | 10.1.1.2 | 192.0.2.1
| STUN +-------+ NAT-A +-----+ NAT-B +------<Internet> | STUN +-------+ NAT-A +-----+ NAT-B +------<Internet>
skipping to change at page 17, line 46 skipping to change at page 19, line 31
most address. This is not a problem -- the STUN client is still able 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 to communicate with the outer-most NAT and is still able to avoid
consuming access network bandwidth and avoid communicating with the consuming access network bandwidth and avoid communicating with the
public STUN server. All that is lost is the ability to optimize public STUN server. All that is lost is the ability to optimize
paths within the private network that has overlapped addresses. paths within the private network that has overlapped addresses.
Of course when such an overlap occurs the end host (STUN client) Of course when such an overlap occurs the end host (STUN client)
cannot successfully establish bi-directional communication with hosts cannot successfully establish bi-directional communication with hosts
in the overlapped network, anyway. in the overlapped network, anyway.
8.2. Address Dependent NAT on Path 7.2. Address Dependent NAT on Path
In order to utilize the mechanisms described in this document, a STUN 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 Request is sent from the same source IP address and source port as
the original STUN Binding Discovery message, but is sent to a the original STUN Binding Discovery message, but is sent to a
different destination IP address -- it is sent to the IP address of 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 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- and the STUN server, with 'address dependent' or 'address and port-
dependent' mapping behavior (as described in Section 4.1 of dependent' mapping behavior (as described in Section 4.1 of
[RFC4787]), that NAT will prevent a STUN client from taking advantage [RFC4787]), that NAT will prevent a STUN client from taking advantage
of the technique described in this document. When this occurs, the of the technique described in this document. When this occurs, the
skipping to change at page 18, line 30 skipping to change at page 20, line 23
In this figure, NAT-A is a NAT that has address dependent mapping. 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 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 on UDP/3478, NAT-A will choose a new public UDP port for that
communication. NAT-B will function normally, returning a different communication. NAT-B will function normally, returning a different
port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client
that a symmetric NAT exists between the STUN client and the STUN that a symmetric NAT exists between the STUN client and the STUN
server it just queried (NAT-B, in this example). server it just queried (NAT-B, in this example).
Figure 12: Address Dependant NAT on Path Figure 12: Address Dependant NAT on Path
8.3. Address Dependent Filtering 7.3. Address Dependent Filtering
If there is an NAT along the path that has address dependent If there is an NAT along the path that has address dependent
filtering (as described in section 5 of [RFC4787]), and the STUN filtering (as described in section 5 of [RFC4787]), and the STUN
client sends a STUN packet directly to any of the on-path NATs public client sends a STUN packet directly to any of the on-path NATs public
addresses, the address-dependent filtering NAT will filter packets addresses, the address-dependent filtering NAT will filter packets
from the remote peer. Thus, after communicating with all of the on- 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, path NATs the STUN client MUST send a UDP packet to the remote peer,
if the remote peer is known. if the remote peer is known.
8.4. Interacting with Legacy NATs 7.4. Interacting with Legacy NATs
There will be cases where the STUN client attempts to communicate There will be cases where the STUN client attempts to communicate
with an on-path NAT, which does not support the outside-in usage. with an on-path NAT, which does not support STUN Control. There are
There are two cases: two cases:
o the NAT does not run a STUN server on its public interface (this o the NAT does not run a STUN server on its public interface (this
will be the most common) will be the most common)
o the NAT does run a STUN server on its public interface, but does o the NAT does run a STUN server on its public interface, but does
not return the XOR-INTERNAL-ADDRESS attribute defined in this not return the XOR-INTERNAL-ADDRESS attribute defined in this
document document
In both cases the optimizations described in this section will not be In both cases the optimizations described in this section will not be
available to the STUN client. This is no worse than the condition available to the STUN client. This is no worse than the condition
today. This allows incremental upgrades of applications and NATs today. This allows incremental upgrades of applications and NATs
that implement the technique described in this document. that implement the technique described in this document.
9. Security Considerations 8. Security Considerations
This security considerations section will be expanded in a subsequent This security considerations section will be expanded in a subsequent
version of this document. So far, the authors have identified the version of this document. So far, the authors have identified the
following considerations: following considerations:
9.1. Authorization 8.1. Authorization
Only hosts that are 'inside' a NAT, which a NAT is already providing 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. services for, can query or adjust the timeout of a NAT mapping.
A discussion of additional authorization mechanisms that might be A discussion of additional authorization mechanisms that might be
needed for firewall traversal can be found at needed for firewall traversal can be found at
[I-D.wing-session-auth]. [I-D.wing-session-auth].
9.2. Resource Exhaustion 8.2. Resource Exhaustion
A malicious STUN client could ask for absurdly long NAT bindings A malicious STUN client could ask for absurdly long NAT bindings
(days) for many UDP sessions, which would exhaust the resources in (days) for many UDP sessions, which would exhaust the resources in
the NAT. The same attack is possible (without considering this the NAT. The same attack is possible (without considering this
document and without considering STUN or other UNSAF [RFC3424] NAT document and without considering STUN or other UNSAF [RFC3424] NAT
traversal techniques) -- a malicious TCP (or UDP) client can open traversal techniques) -- a malicious TCP (or UDP) client can open
many TCP (or UDP) connections, and keep them open, causing resource many TCP (or UDP) connections, and keep them open, causing resource
exhaustion in the NAT. exhaustion in the NAT.
9.3. Comparison to Other NAT Control Techniques 8.3. Comparison to Other NAT Control Techniques
Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage Like UPnP, NAT-PMP, and host-initiated MIDCOM, the STUN usage
described in this document allows a host to learn its public IP described in this document allows a host to learn its public IP
address and UDP port mapping, and to request a specific lifetime for address and UDP port mapping, and to request a specific lifetime for
that mapping. mappings from that same source IP address and same source UDP port.
However, unlike those technologies, the NAT Control usage described However, unlike other NAT traversal technologies, STUN Control
in this document only allows each UDP port on the host to create and described in this document only allows each UDP port on the host to
adjust the mapping timeout of its own NAT mappings. Specifically, an create and adjust the mapping timeout of its own NAT mappings.
application on a host can only adjust the duration of a NAT bindings Specifically, an application on a host can only adjust the duration
for itself, and not for another application on that same host, and of a NAT bindings for itself, and not for another application on that
not for other hosts. This provides security advantages over other same host, and not for other hosts. This provides security
NAT control mechanisms where malicious software on a host can advantages over other NAT control mechanisms where malicious software
surreptitiously create NAT mappings to another application or to on a host can surreptitiously create NAT mappings to another
another host. application or to another host.
9.4. Rogue STUN Server 8.4. BOOTNONCE Attribute
Using the mechanisms described in this document, a STUN client learns Using the mechanisms described in this document, a STUN client learns
the public IP addresses of its NATs which support the mechanisms the public IP addresses of its NAT which supports the mechanisms
described in this document. However, without the STUN client's described in this document. However, without the STUN client's
knowledge, those NATs may acquire a new IP address (e.g., DHCP lease knowledge, that NAT may acquire a new IP address (e.g., due to DHCP
expiration, a moving network). When any of those NAT acquire a new lease expiration or network renumbering). When this occurs, the STUN
IP address without the STUN client's knowledge, the STUN client will client will send a STUN Binding Request to the NAT's previous public
send a STUN Binding Request to the NAT's previous public IP address. IP address. If an attacker were to run a rogue STUN server on that
If an attacker were to run a rogue STUN server on that address, the address, the attacker will have effectively compromised the STUN
attacker will have effectively compromised the STUN server, as server, as described in Section 12.2.1 of [RFC3489]. The attacker,
described in Section 12.2.1 of [RFC3489]. The attacker, upon upon receiving STUN Binding Requests, will reply with STUN Binding
receiving STUN Binding Requests, will reply with STUN Binding
Responses indicating an IP address the attacker controls. The Responses indicating an IP address the attacker controls. The
attacker will thus ensure access to whatever media stream is being attacker will thus have access to the subsequent flow established by
established by the STUN client (e.g., RTP traffic). When such an the STUN client (e.g., RTP traffic). This attack is possible because
attack occurs, the STUN client is unable to distinguish the the STUN client is unable to distinguish the attacker's replies from
attacker's replies from legitimate replies from the STUN server replies from the legitimate NAT.
embedded in the STUN client's NAT.
To defend against this attack, the STUN server embedded in the NAT To defend against this attack, the STUN server embedded in the NAT
returns a BOOTNONCE value. The STUN client validates that it returns a BOOTNONCE value. The STUN client validates that it
receives the same BOOTNONCE value in each STUN Binding Response from receives the same BOOTNONCE value in each STUN Binding Response from
that NAT. 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.
A weakness of this approach is that an attacker can learn the 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 BOOTNONCE value if the attacker is able to connect to the NAT's
internal network prior to initiating the attack; this is plausible if internal network prior to initiating the attack. This is plausible
the internal network has no security (e.g., public WiFi network). if the internal network has no security (e.g., public WiFi network).
For this reason, it is RECOMMENDED that the BOOTNONCE value is hashed For this reason, it is RECOMMENDED that the BOOTNONCE value is hashed
with the STUN client's IP address. Doing so means the attacker must with the STUN client's IP address. Doing so means that a successful
acquire the same IP address as the victim from behind the NAT (to attacker must acquire both the same IP address as the victim from
learn the BOOTNONCE), and must also acquire the NAT's previous public behind the NAT (to learn the BOOTNONCE), and must also acquire the
IP address. 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.
10. Open Issues and Discussion Points 9. Open Issues and Discussion Points
o Discussion Point: After discovering NATs and firewalls, o Discussion Point: After discovering NATs and firewalls,
controlling those devices might also be done with a middlebox controlling those devices might also be done with a middlebox
control protocol (e.g., by using standard or slightly modified control protocol (e.g., by using standard or slightly modified
versions of SIMCO, UPnP, MIDCOM, or Bonjour). This is open for versions of SIMCO, UPnP, MIDCOM, or NAT-PMP). This is open for
discussion as this document is scoped within the IETF. discussion as this document is scoped within the IETF.
o Discussion Point: Tagging would also be useful for the o Discussion Point: Tagging would also be useful for the
Connectivity Check usage (which is used by ICE), especially Connectivity Check usage (which is used by ICE), especially
considering that a different firewall may be traversed for media considering that a different firewall may be traversed for media
than for the initial Binding Discovery usage. In such a than for the initial Binding Discovery usage. In such a
situation, the new on-path firewall's policy might not allow a situation, the new on-path firewall's policy might not allow a
binding request to leave the network or allow a binding response binding request to leave the network or allow a binding response
to return. In this case, the firewall would need to indicate its to return. In this case, the firewall would need to indicate its
presence to the STUN client in another way. An ICMP error message presence to the STUN client in another way. An ICMP error message
skipping to change at page 22, line 5 skipping to change at page 24, line 5
o The inside-out discovery technique was removed with version -03 of o The inside-out discovery technique was removed with version -03 of
this document. The procedure worked as follows: The STUN client this document. The procedure worked as follows: The STUN client
sends a STUN request to UDP/3478 of the IP address of its default 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 router. If there is a STUN server listening there, it will
respond, and will indicate its default route via the new DEFAULT- respond, and will indicate its default route via the new DEFAULT-
ROUTE attribute. With that information, the STUN client can ROUTE attribute. With that information, the STUN client can
discover the next-outermost NAT by repeating the procedure. More discover the next-outermost NAT by repeating the procedure. More
feedback is needed to determine whether the functionality is feedback is needed to determine whether the functionality is
needed. needed.
11. IANA Considerations 10. IANA Considerations
This section registers new STUN attributes per the procedures in This section registers new STUN attributes per the procedures in
[I-D.ietf-behave-rfc3489bis]: [I-D.ietf-behave-rfc3489bis]:
Mandatory range: Mandatory range:
0x0029 XOR-INTERNAL-ADDRESS 0x0029 XOR-INTERNAL-ADDRESS
0x00.. BOOTNONCE 0x00.. BOOTNONCE
Optional range: Optional range:
0x8024 REFRESH-INTERVAL 0x8024 REFRESH-INTERVAL
0x80.. PLEASE-TAG 0x80.. PLEASE-TAG
0x80.. TAG 0x80.. TAG
12. Acknowledgements 11. Acknowledgements
Thanks to Remi Denis-Courmont, Bajko Gabor, Markus Isomaki, Cullen Thanks to Remi Denis-Courmont, Christian Dickmann, Bajko Gabor,
Jennings, and Philip Matthews for their suggestions which have Markus Isomaki, Cullen Jennings, and Philip Matthews for their
improved this document. suggestions which have improved this document.
13. References Thanks to Christian Dickmann and Yan Sun for their initial
implementations of STUN Control.
13.1. Normative References 12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Session Traversal Utilities for (NAT) Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
(STUN)", draft-ietf-behave-rfc3489bis-06 (work in Wing, "Session Traversal Utilities for (NAT) (STUN)",
progress), March 2007. draft-ietf-behave-rfc3489bis-10 (work in progress),
September 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
13.2. Informational References 12.2. Informational References
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple Rosenberg, J., "Traversal Using Relays around NAT (TURN):
Traversal Underneath NAT (STUN)", Relay Extensions to Session Traversal Utilities for NAT
draft-ietf-behave-turn-03 (work in progress), March 2007. (STUN)", draft-ietf-behave-turn-04 (work in progress),
July 2007.
[UPnP] UPnP Forum, "Universal Plug and Play", 2000, [UPnP] UPnP Forum, "Universal Plug and Play", 2000,
<http://www.upnp.org>. <http://www.upnp.org>.
[Bonjour] Apple Computer, "Bonjour", 2005, [Vista-cert]
<http://www.apple.com/macosx/features/bonjour/>. Microsoft, "Windows Logo Program Device Requirements",
2006, <http://download.microsoft.com/download/d/e/1/
de1e0c8f-a222-47bc-b78b-1656d4cf3cf7/
WLP-DeviceReqs_309.pdf>.
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-02 (work in progress),
October 2006.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002. framework", RFC 3303, August 2002.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-18 (work in progress),
September 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-09 (work in progress), June 2007. draft-ietf-sip-outbound-10 (work in progress), July 2007.
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in
progress), March 2007. progress), July 2007.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007. April 2007.
[I-D.shore-tist-prot] [I-D.shore-tist-prot]
Shore, M., "The TIST (Topology-Insensitive Service Shore, M., "The TIST (Topology-Insensitive Service
Traversal) Protocol", draft-shore-tist-prot-00 (work in Traversal) Protocol", draft-shore-tist-prot-00 (work in
progress), May 2002. progress), May 2002.
[I-D.shore-nls-tl] [I-D.shore-nls-tl]
Shore, M., "Network-Layer Signaling: Transport Layer", Shore, M., "Network-Layer Signaling: Transport Layer",
draft-shore-nls-tl-05 (work in progress), June 2007. draft-shore-nls-tl-05 (work in progress), June 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[I-D.wing-session-auth] [I-D.wing-session-auth]
Wing, D., "Media Session Authorization", Wing, D., "Media Session Authorization",
draft-wing-session-auth-00 (work in progress), draft-wing-session-auth-00 (work in progress),
February 2006. February 2006.
Appendix A. Changes Appendix A. Changes
A.1. Changes between -03 and 02 A.1. Changes in -04
o Clarified that all existing bindings, for that source IP address
and UDP port, are controlled with STUN Control.
o Introduction now concentrates on the primary purpose of STUN
Control, namely reducing keepalive traffic for SIP-Outbound.
A.2. Changes in -03
o Removed TLS from normal STUN operation (as few use it, and ICE o Removed TLS from normal STUN operation (as few use it, and ICE
makes it unnecessary anyway) makes it unnecessary anyway)
o BOOTNONCE attribute replaces STUN Control's previous use of TLS. o BOOTNONCE attribute replaces STUN Control's previous use of TLS.
o Added "MIP-capable" bit to TAG attribute o Added "MIP-capable" bit to TAG attribute
o Removed "inside-out" discovery technique. o Removed "inside-out" discovery technique.
Appendix B. Block Diagram of Internal NAT Operation Appendix B. Implementation Details
B.1. Internal NAT Operation
Internally, the NAT can be diagrammed to function like this, where Internally, the NAT can be diagrammed to function like this, where
the NAT operation occurs before the STUN server: the NAT operation occurs before the STUN server:
| |
| outside interface | outside interface
| |
+---------+---------------+ +---------+---------------+
| | | | | |
| | +--------+ | | | +--------+ |
| |----+ STUN | | | |----+ STUN | |
| | | Server | | | | | Server | |
| | +--------+ | | | +---^----+ |
| | | | | | |
| +-------+-------------+ | | | API |
| | | |
| +-------+--------V----+ |
| | NAT Function | | | | NAT Function | |
| +-------+-------------+ | | +-------+-------------+ |
| | | | | |
+---------+---------------+ +---------+---------------+
| |
| inside interface | inside interface
| |
| |
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.
Figure 14: Block Diagram of Internal NAT Operation Figure 14: Block Diagram of Internal NAT Operation
B.2. Linux specifics
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.
For example, with the following message flow:
STUN Client NAT STUN Server
| | |
1. |-----Binding Request (UDP)--------------->|
2. |<----Binding Response (UDP)---------------|
| | |
3. |--Binding Request (UDP)------->| |
4. |<-Binding Response (UDP)-------| |
| | |
the following two connection table entries are created:
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
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.
s
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
 End of changes. 85 change blocks. 
311 lines changed or deleted 422 lines changed or added

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