< draft-wing-behave-nat-control-stun-usage-01.txt   draft-wing-behave-nat-control-stun-usage-02.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: August 17, 2007 February 13, 2007 Expires: December 2, 2007 May 31, 2007
Controlling NAT Bindings using STUN Discovering, Querying, and Controlling Firewalls and NATs using STUN
draft-wing-behave-nat-control-stun-usage-01 draft-wing-behave-nat-control-stun-usage-02
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 34 skipping to change at page 1, line 34
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 August 17, 2007. This Internet-Draft will expire on December 2, 2007.
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 NAT binding. These drawbacks to query a public STUN server for every new NAT binding (e.g., every
require frequent messages which present a load on servers (like SIP phone call). These drawbacks require frequent messages which present
servers and STUN servers) and are bad for low speed access networks, a load on servers (like SIP servers and STUN servers) and are bad for
such as cellular. This document proposes that the STUN server be low speed access networks, such as cellular access.
embedded in the NAT itself, and describes how these STUN servers can
be readily discovered and utilized to reduce queries to public STUN This document describes several mechanisms to discover NATs and
servers and to reduce NAT keepalive traffic. firewalls and a method to query and control them. With these
changes, binding discovery and keepalive traffic can be reduced to
involve only the necessary NATs or firewalls. At the same time,
backwards compatibility with NATs and firewalls that do not support
this document is retrained.
This document is discussed on the BEHAVE mailing list,
<https://www1.ietf.org/mailman/listinfo/behave>, in anticipation of a
BoF at IETF69 in Chicago.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in this Document . . . . . . . . . . . . . . 4 3. Conventions Used in this Document . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . . . 7 5. Discovery of Middleboxes . . . . . . . . . . . . . . . . . . . 6
4.2. Interacting with Legacy NATs . . . . . . . . . . . . . . . 9 5.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 7
5. NAT Control Usage . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 11
5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 10 5.1.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . 12
5.2. Client Discovery of Server . . . . . . . . . . . . . . . . 10 5.1.3. Interacting with Legacy NATs . . . . . . . . . . . . . 13
5.3. Server Determination of Usage . . . . . . . . . . . . . . 10 5.2. Inside-Out . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. New Requests or Indications . . . . . . . . . . . . . . . 10 5.2.1. DEFAULT-ROUTE Attribute . . . . . . . . . . . . . . . 14
5.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5.1. XOR-INTERNAL-ADDRESS . . . . . . . . . . . . . . . . . 11 5.3.1. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . 15
5.5.2. REFRESH-INTERVAL . . . . . . . . . . . . . . . . . . . 11 5.3.2. TAG Attribute . . . . . . . . . . . . . . . . . . . . 16
5.6. Client Procedures . . . . . . . . . . . . . . . . . . . . 11 6. Query and Control . . . . . . . . . . . . . . . . . . . . . . 17
5.7. Server Procedures . . . . . . . . . . . . . . . . . . . . 12 6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 17
6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Client Procedures . . . . . . . . . . . . . . . . . . . . 17
6.1. Incremental Deployment . . . . . . . . . . . . . . . . . . 13 6.3. Server Procedures . . . . . . . . . . . . . . . . . . . . 18
6.2. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 14 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Simple Security Model . . . . . . . . . . . . . . . . . . 19
6.3.1. Candidate Gathering . . . . . . . . . . . . . . . . . 14 7.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 19
6.3.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 19
6.3.3. Learning STUN Servers without Configuration . . . . . 15 7.4. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 19
7. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.4.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20
7.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 15 7.4.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 16 7.4.3. Learning STUN Servers without Configuration . . . . . 20
7.3. Address Dependent Filtering . . . . . . . . . . . . . . . 16 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 21
8.1. Authorization and Resource Exhaustion . . . . . . . . . . 17 8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 21
8.2. Comparison to Other NAT Control Techniques . . . . . . . . 17 8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 22
8.3. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. Authorization and Resource Exhaustion . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Comparison to Other NAT Control Techniques . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.3. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 23
10.2. Informational References . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informational References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
Two common usages of STUN [I-D.ietf-behave-rfc3489bis] are Binding Two common usages of STUN ([I-D.ietf-behave-rfc3489bis],[RFC3489])
Discovery and NAT Keepalive. The Binding Discovery usage allows a are Binding Discovery and NAT Keepalive. The Binding Discovery usage
STUN client to learn its public IP address (from the perspective of allows a STUN client to learn its public IP address (from the
the STUN server it contacted) and the NAT keepalive usage allows a perspective of the STUN server it contacted) and the NAT keepalive
STUN client to keep an active NAT binding alive. Unlike some other usage allows a STUN client to keep an active NAT binding alive.
techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour [Bonjour]), Unlike some other techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303],
STUN does not interact directly with the NAT. Because STUN doesn't Bonjour [Bonjour]), STUN does not interact directly with the NAT.
interact directly with the NAT, STUN cannot request additional Because STUN doesn't interact directly with the NAT, STUN cannot
services from the NAT such as longer lifetimes (which would reduce request additional services from the NAT such as longer lifetimes
keepalive messages). (which would reduce keepalive messages), and each new NAT binding
(e.g., each phone call) requires communicating with the STUN server
on the Internet.
This paper describes a mechanism for the STUN client to interact This paper describes three mechanisms for the STUN client to discover
directly with the NAT and request additional services, by using the NATs and firewalls that are on path with its STUN server. After
STUN protocol itself. Thereafter, the STUN client need only ask that discovering the NATs and firewalls, the STUN client can query and
NAT's embedded STUN server for public IP addresses and UDP ports -- control those devices using STUN. The STUN client needs to only ask
as it will return the same information as the public STUN server. those STUN servers (embedded in the NATs and firewalls) for public IP
Additionally, the STUN client can ask the NAT's embedded STUN server addresses and UDP ports, thereby offloading that traffic from the
to extend the NAT binding for the flow, and the STUN client can learn STUN server on the Internet. Additionally, the STUN client can ask
the IP address of the next-outermost NAT. By repeating this the NAT's embedded STUN server to extend the NAT binding for the
procedure with the next-outermost NAT, all of the NATs along that flow, and the STUN client can learn the IP address of the next-
path can have their bindings extended. By learning all of the STUN outermost NAT. By repeating this procedure with the next-outermost
servers on the path between the public Internet and itself, an NAT, all of the NATs along that path can have their bindings
endpoint can optimize the path of peer-to-peer communications. 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.
2. Motivation 2. Motivation
There are a number of problems with existing NAT traversal techniques There are a number of problems with existing NAT traversal techniques
such as STUN [RFC3489], [UPnP], and [Bonjour]): such as STUN [RFC3489], [UPnP], and [Bonjour]):
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, often with only one physical Ethernet port. These
subscribers then install NATs behind those devices to provide subscribers then install NATs behind those devices to provide
additional features, such as wireless access. additional features, such as wireless access. Another example is
a NAT in the basement of an apartment building or a campus
dormitory, which combined with a NAT within the home or dormitory
room also result in nested NATs. In both of these situations,
UPnP and Bonjour no longer function at all, 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).
Nested NATs are, unfortunately, becoming quite common and often One technique to avoid nested NATs is to disable one of the NATs
occur without the knowledge of users. For example, some ISPs if it obtains an RFC1918 address on its WAN interface. This
provide their subscribers with modems that include integrated NAT merely sidesteps the problem. This technique is also ineffective
functionality. When the subscriber installs another NAT, perhaps if the ISP is NATting its subscribers and the ISP restricts each
to provide himself with wireless network access, the endpoints are subscriber to one IP address.
now behind nested NATs. Another example is a NAT in the basement
of an apartment building or a campus dormitory, which combined The technique described in this paper allows optimization of the
with a NAT within the home or dormitory room also result in nested
NATs. In both of these situations, UPnP and Bonjour no longer
function at all, as those protocols can only control the first
NAT. 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). The
technique described in this paper allows optimization of the
traffic behind those NATs so that the traffic can traverse 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 perform its binding discovery, a STUN client communicates to a
server on the Internet. This consumes bandwidth across the user's server on the Internet. This consumes bandwidth across the user's
access network which in some cases is bandwidth constrained (e.g., access network which in some cases is bandwidth constrained (e.g.,
wireless, satellite). wireless, satellite). STUN's chattiness is often cited as a
reason to use other NAT traversal techniques such as UPnP or
Bonjour.
STUN's chattiness is often cited as a reason to use other NAT The technique described in this paper provides a significant
traversal techniques such as UPnP or Bonjour. However, those NAT reduction in STUN's chattiness, to the point that the only time a
traversal techniques bring restrictions (they both require a UPnP- STUN client needs to communicate with the STUN server on the
aware or Bonjour-aware NAT, they do not work with nested NATs, and public Internet is when the STUN client is initialized.
they only work within one broadcast domain). The technique
described in this paper provides a significant reduction in STUN's
chattiness, to the point that the only time a STUN client needs to
communicate with the STUN server on the public Internet is when
the STUN client is initialized.
incremental deployment incremental deployment:
Many NAT traversal techniques require the endpoint and the NAT to Many other NAT traversal techniques require the endpoint and its
both support the new feature or else NAT traversal isn't possible NAT to both support the new feature or else NAT traversal isn't
at all. possible at all.
However, the technique described in this paper allows incremental The technique described in this paper allows incremental
deployment of local endpoints, local NATs, and remote endpoints deployment of local endpoints and their NATs that support STUN
and their remote NATs which support the features described in this Control. If the local endpoint, or its NATs, don't support the
paper. Only the local endpoints and the NATs on the path to their STUN Control functionality, normal STUN and ICE
STUN server need to implement the technique in this paper to [I-D.ietf-mmusic-ice] procedures are used to traverse the NATs
optimize their functionality. without the optimizations described in this paper.
3. Conventions Used in this Document 3. Conventions Used in this Document
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].
4. Overview of Operation 4. Overview of Operation
This document describes three functions, which are all implemented
using the STUN protocol:
Discovery of Middleboxes (NATs and Firewalls):
This document describes three techniques to find NATs or
firewalls. The first technique uses STUN to find the outer-most
NAT and works itself towards the host. The second technique
requests on-path firewalls or NATs to append their IP address to a
STUN packet. The third technique sends a STUN packet to the
default router (which, in a small network, is often your NAT).
This is described in Section 5.
Querying Discovered Middleboxes:
After discovering a NAT or a firewall, it's 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 Section 6.
Discussion Point: After discovering NATs and firewalls,
querying those devices might also be done with a middlebox
control protocol (e.g., by using standard or slightly modified
versions of SIMCO [RFC4540], UPnP, MIDCOM, or Bonjour). This
is open for discussion as this document is scoped within the
IETF.
Controlling Discovered Middleboxes
A NAT or 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[I-D.ietf-behave-turn]). This is described in Section 6.
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, MIDCOM, or Bonjour). This is open for
discussion as this document is scoped within the IETF.
5. Discovery of Middleboxes
There are three techniques to discover a middlebox (a NAT or a
firewall): outside-in, inside-out (useful when the outer-most NAT
device doesn't support STUN Control), or by tagging (useful for
firewalls).
These techniques can be combined in useful ways. 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 don't 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.
5.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 which indicates the IP address and UDP port seen by a STUN Response which 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 of that NAT. For example, server, and knows the 'public' IP address of that NAT. For example,
in the following diagram, the STUN client learns the public IP in the following diagram, the STUN client learns the public IP
address of its NAT is 192.0.2.1: address of its NAT is 192.0.2.1:
+--------+ +---------------+ +--------+ +---------------+
skipping to change at page 5, line 22 skipping to change at page 8, line 5
| 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 1: One NAT with embedded STUN server
Internally, the NAT can be diagrammed to function like this, where
the NAT operation occurs before the STUN server:
|
| outside interface
|
+---------+---------------+
| | |
| | +--------+ |
| |----+ STUN | |
| | | Server | |
| | +--------+ |
| | |
| +-------+-------------+ |
| | NAT Function | |
| +-------+-------------+ |
| | |
+---------+---------------+
|
| inside interface
|
|
Figure 2: Block Diagram of Internal NAT Operation
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 first obtaining a outer-most NAT. The STUN client does this by first obtaining a
shared secret, over a TLS connection, to the NAT's public IP address shared secret, over a TLS connection, to the NAT's public IP address
(192.0.2.1 in the figure above). After obtaining a shared secret, it (192.0.2.1 in the figure above). After obtaining a shared secret, it
sends a STUN Binding Request to the NAT's public IP address. The NAT sends a STUN Binding Request to the NAT's public IP address. The NAT
will return a STUN Binding Response message including the XOR- will return a STUN Binding Response message including the XOR-
INTERNAL-ADDRESS attribute, which will indicate the IP address and INTERNAL-ADDRESS attribute, which will indicate the IP address and
UDP port seen on the *internal* side of the NAT for that translation. UDP port seen on the *internal* side of the NAT for that translation.
In the example above, the IP address and UDP port indicated in XOR- In the example above, the IP address and UDP port indicated in XOR-
skipping to change at page 6, line 22 skipping to change at page 9, line 22
6. |<----Binding Response (UDP)---------------| } 6. |<----Binding Response (UDP)---------------| }
| | | | | |
7. |-----TLS/TCP------------------>| | } 7. |-----TLS/TCP------------------>| | }
8. |--Shared Secret Request (TLS)->| | } 8. |--Shared Secret Request (TLS)->| | }
9. |<-Shared Secret Response (TLS)-| | } NAT Control 9. |<-Shared Secret Response (TLS)-| | } NAT Control
10. |--TCP connection closed------->| | } STUN Usage 10. |--TCP connection closed------->| | } STUN Usage
11. |--Binding Request (UDP)------->| | } 11. |--Binding Request (UDP)------->| | }
12. |<-Binding Response (UDP)-------| | } 12. |<-Binding Response (UDP)-------| | }
| | | | | |
Figure 2: Communication Flow Figure 3: Communication Flow
In the call flow above, steps 1-6 are normal STUN behavior In the call flow above, steps 1-6 are normal STUN behavior
[I-D.ietf-behave-rfc3489bis]: [I-D.ietf-behave-rfc3489bis]:
1: STUN client initiates a TLS-over-TCP connection to its STUN 1: STUN client initiates a TLS-over-TCP connection to its STUN
server on the Internet. server on the Internet.
2: Using that connection, the STUN client sends Shared Secret 2: Using that connection, the STUN client sends Shared Secret
Request to that STUN server. Request to that STUN server.
skipping to change at page 7, line 21 skipping to change at page 10, line 21
9: Using that connection, the STUN server sends Shared Secret 9: Using that connection, the STUN server sends Shared Secret
Response. This contains the STUN username the client should use Response. This contains the STUN username the client should use
for subsequent queries to this STUN server, and the STUN for subsequent queries to this STUN server, and the STUN
password that will be used to integrity-protect subsequent STUN password that will be used to integrity-protect subsequent STUN
messages with this STUN server. messages with this STUN server.
10: TCP connection is closed. 10: TCP connection is closed.
11: STUN client sends UDP Binding Request to the STUN server 11: STUN client sends UDP Binding Request to the STUN server
embedded in its outer-most NAT, using the STUN username obtained embedded in its outer-most NAT, using the STUN username obtained
from from that STUN server (from step 10). from that STUN server (from step 10).
12: STUN server responds with UDP Binding Response, integrity 12: STUN server responds with UDP Binding Response, integrity
protected with the STUN password (from step 10). protected with the STUN password (from step 10).
The response obtained in the message 12 contains the XOR-MAPPED- The response obtained in the message 12 contains the XOR-MAPPED-
ADDRESS attribute which will have the same value as when the STUN ADDRESS attribute which will have the same value as when the STUN
server on the Internet responded (in step 6). The STUN client can server on the Internet responded (in step 6). The STUN client can
perform steps 11-12 for any new UDP communication (e.g., for every perform steps 11-12 for any new UDP communication (e.g., for every
new phone call), without needing to repeat steps 1-10. This meets new phone call), without needing to repeat steps 1-10. This meets
the desire to reduce chattiness. the desire to reduce chattiness.
The response obtained in message 12 will also contain the XOR- The response obtained in message 12 will also contain the XOR-
INTERNAL-ADDRESS, which allows the STUN client to repeat steps 7-12 INTERNAL-ADDRESS, which allows the STUN client to repeat steps 7-12
in order to communicate with all the on-path NATs between itself and 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 its STUN server on the Internet. This is described in detail in
section Section 4.1. This meets the desire to optimize traffic section Section 5.1.1. This functionality meets the need to optimize
between nested NATs. traffic between nested NATs, without requiring configuration 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, as described in Section 5.5. The STUN client receives lifetime, as described in Section 6.1. The STUN client receives
positive confirmation that the binding lifetime has been extended, positive confirmation that the binding lifetime has been extended,
allowing the STUN client to significantly reduces its NAT keepalive allowing the STUN client to significantly reduces its NAT keepalive
traffic. Additionally, as long as the NAT complies with [RFC4787], traffic. Additionally, as long as the NAT complies with [RFC4787],
the STUN client's keepalive traffic need only be sent to the outer- the STUN client's keepalive traffic need only be sent to the outer-
most NAT's IP address. This further meets the desire to reduce most NAT's IP address. This functionality meets the need to reduce
chattiness. STUN's chattiness.
4.1. Nested NATs 5.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 following diagram shows how a STUN client iterates over the NATs The following diagram shows how a STUN client iterates over the NATs
to communicate with all of the NATs in the path. First, the STUN to communicate with all of the NATs in the path. First, the STUN
client would learn the outer-most NAT's IP address by performing the client would learn the outer-most NAT's IP address by performing the
steps above. In the case below, however, the IP address and UDP port steps above. In the case below, however, the IP address and UDP port
indicated by the XOR-INTERNAL-ADDRESS will not be the STUN client's indicated by the XOR-INTERNAL-ADDRESS will not be the STUN client's
own IP address and UDP port -- rather, it's the IP address and UDP own IP address and UDP port -- rather, it's the IP address and UDP
port on the *outer* side of the NAT-B -- 10.1.1.2. port on the *outer* side of the NAT-B -- 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
knows there are no other NATs between itself and NAT-B, and finishes. knows there are no other NATs between itself and NAT-B, and finishes.
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 NATs with embedded STUN servers Figure 4: Two nested NATs with embedded STUN servers
Internally, the NAT can be diagrammed to function like this, where The message flow with two nested NATs is shown below:
the NAT operation occurs before the STUN server.
| STUN Client NAT-B NAT-A STUN Server
| outside interface | | | |
| 1. |-----TLS/TCP----------------------------->| }
+---------+---------------+ 2. |-----Shared Secret Request (TLS)--------->| }
| | | 3. |<----Shared Secret Response (TLS)---------| } normal STUN
| | +--------+ | 4. |-----TCP connection closed--------------->| } behavior
| |----+ STUN | | 5. |-----Binding Request (UDP)--------------->| }
| | | Server | | 6. |<----Binding Response (UDP)---------------| }
| | +--------+ | | | | |
| | | 7. |-----TLS/TCP------------------>| | }
| +-------+-------------+ | 8. |--Shared Secret Request (TLS)->| | }
| | NAT Function | | 9. |<-Shared Secret Response (TLS)-| | }
| +-------+-------------+ | 10. |--TCP connection closed------->| | }
| | | 11. |--Binding Request (UDP)------->| | }
+---------+---------------+ 12. |<-Binding Response (UDP)-------| | } NAT Control
| | | | | } STUN Usage
| inside interface 13. |-----TLS/TCP--------->| | | }
| 14. |--Sh. Sec. Req (TLS)->| | | }
| 15. |<-Sh. Sec. Resp (TLS)-| | | }
16. |-TCP conn. closed---->| | | }
17. |--Binding Req (UDP)-->| | | }
18. |<-Binding Resp (UDP)--| | | }
| | | |
Figure 4: Block Diagram of Internal NAT Operation Figure 5: Message Flow for Outside-In with Two NATs
4.2. Interacting with Legacy 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
subsequent bindings for individual UDP streams (that is, for each
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
NAT-B, the STUN client has the opportunity to optimize the packet
flow if their UDP peer is also behind the same NAT.
5.1.2. XOR-INTERNAL-ADDRESS Attribute
This attribute MUST be present in a Binding Response and may be used
in other responses as well. This attribute is necessary to allow a
STUN client to 'walk backwards' and communicate directly with all of
the STUN-aware NATs along the path.
The format of the XOR-INTERNAL-ADDRESS attribute is:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: XOR-INTERNAL-ADDRESS Attribute
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
address family (IPv4 or IPv6).
5.1.3. 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 usage described in with an on-path NAT which does not support the outside-in usage
this document. There are two cases: described in Section 5.1. There are 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 o the NAT does run a STUN server on its public interface, but
doesn't return the XOR-INTERNAL-ADDRESS attribute defined in this doesn't return the XOR-INTERNAL-ADDRESS attribute defined in this
document document
In both cases the optimizations described in this document won't be In both cases the optimizations described in this section won't be
available to the STUN client and the STUN client. This is no worse available to the STUN client. This is no worse than the condition
than the condition today. This allows incremental upgrades of today. This allows incremental upgrades of applications and NATs
applications and NATs that implement the technique described in this that implement the technique described in this document. In such a
document. situation, the STUN client might implement the inside-out technique,
described in Section 5.2.
5. NAT Control Usage 5.2. Inside-Out
This section describes a new STUN usage, following the recommendation [[Discussion Point: This is being included as a discussion item.
for defining a new usage in [I-D.ietf-behave-rfc3489bis]. 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.]]
5.1. Applicability 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.
This STUN usage MAY be used by a STUN client that discovers there is 5.2.1. DEFAULT-ROUTE Attribute
a NAT between itself and its STUN server. Such discovery would most
likely occur with a STUN Binding Request / Binding Response exchange
to a STUN server on the Internet, and by noticing the IP address and
UDP port indicated by the XOR-MAPPED-ADDRESS attribute of the STUN
Binding Response differs from the local socket's IP address and UDP
port. Such a difference indicates a NAT is present between the STUN
client and its STUN server.
5.2. Client Discovery of Server The DEFAULT-ROUTE attribute contains the XOR'd default route, which
is useful for finding the next-outer device.
As this usage involves communicating with on-path NATs directly, the The format of the DEFAULT-ROUTE attribute is:
client needs to find those NATs. The outer-most NAT is found by the
normal XOR-MAPPED-ADDRESS attribute in a STUN Response. To iterate
through the inner NATs, each NAT needs to support the usage described
in this document, and the STUN client discovers each of those NATs by
iterating through the XOR-INTERNAL-ADDRESS attribute returned by
those NATs. This is described in diagrams and examples in Section 4.
5.3. Server Determination of Usage 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-Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a STUN Binding Request is received from a NAT's private interface Figure 7: DEFAULT-ROUTE Attribute
and sent to the IP address of its public interface, the STUN server
can assume the NAT Control Usage.
5.4. New Requests or Indications The meaning of X-Address is exactly as in
[I-D.ietf-behave-rfc3489bis].
This usage does not define any new message types. 5.3. Tagging
5.5. New Attributes The Outside-In discovery technique (Section 5.1) uses the public IP
address of the NAT to find the outer-most NAT that supports STUN
Control. Firewalls do not normally put their IP address into
packets, so a different technique is needed to identify firewalls.
The following figure indicates which attributes are present in which To discover an on-path firewall, the PLEASE-TAG attribute is used
messages for this usage. An M indicates that inclusion of the with a normal STUN Binding Request usage. A firewall sees the normal
attribute in the message is mandatory, O means its optional, C means Binding Request usage (a STUN packet sent to UDP/3478) with the
it's conditional based on some other aspect of the message, and - PLEASE-TAG attribute. When the firewall sees the associated Binding
means that the attribute is not applicable to that message type. 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 pointer to each of the on-path firewalls between the
client and that STUN server.
Error Note: Tagging is similar to how NSIS [I-D.ietf-nsis-nslp-natfw],
Attribute Request Response Response Indication TIST [I-D.shore-tist-prot], and NLS [I-D.shore-nls-tl] function.
_________________________________________________________________
XOR-INTERNAL-ADDRESS - M - -
REFRESH-INTERVAL O C - -
5.5.1. XOR-INTERNAL-ADDRESS 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 ICMP extension [RFC4884] could indicate
the firewall is controllable.
This attribute MUST be present in a Binding Response and may be used This figure shows how tagging functions.
in other responses as well. This attribute is necessary to allow a
STUN client to 'walk backwards' and communicate directly with all of
the STUN-aware NATs along the path.
The format of the XOR-INTERNAL-ADDRESS attribute is: STUN Client firewall STUN Server
| | |
1. |--Binding Request->|------------------>|
2. | |<-Binding Response-|
3. | [inserts tag] |
4. |<-Binding Response-| |
5. [firewall discovered] | |
Figure 8: Tagging Message Flow
1. Binding Request, containing PLEASE-TAG attribute, is sent to the
IP address of the STUN server. This is seen by the firewall, and
the firewall remembers the STUN transaction id, and permits the
STUN Binding Request packet.
2. The STUN Binding Response packet is seen by the firewall.
3. The firewall inserts the TAG attribute, which contains the
firewall's management address.
4. The firewall sends the (modified) STUN Binding Response towards
the STUN client.
5. The STUN client has now discovered the firewall, and can query it
or control it.
5.3.1. PLEASE-TAG Attribute
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.
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port | |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable) |
Figure 9: PLEASE-TAG Attribute
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, Bonjour, MIDCOM).
5.3.2. TAG Attribute
The TAG attribute contains the XOR'd management transport address of
the middlebox (typically a firewall, although a NAT may find this
technique useful as well).
A middlebox MUST append this attribute as the last attribute of a
STUN response, and only if the associated STUN request (with the same
transaction-id) contained the PLEASE-TAG attribute.
The format of the TAG attribute is:
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| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (32 bits or 128 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: XOR-INTERNAL-ADDRESS Attribute Figure 10: TAG Attribute
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, Bonjour, MIDCOM).
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).
5.5.2. REFRESH-INTERVAL 6. Query and Control
The REFRESH-INTERVAL attribute is defined in This section describes how to use STUN to query and control a NAT
[I-D.ietf-behave-rfc3489bis] where it can only appear in a response. that was discovered using the technique described in Section 5.
In the NAT Control usage defined in this document, the REFRESH-
INTERVAL may also appear in a request.
In a Binding Request, the REFRESH-INTERVAL indicates the desired 6.1. REFRESH-INTERVAL Attribute
mapping timeout. In a Binding Response, the REFRESH-INTERVAL
indicates the NAT's mapping timeout.
5.6. Client Procedures 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. In a STUN response, the same
attribute indicates the length of time of that NAT binding (or
firewall pinhole).
The STUN client sends a STUN Binding Request to its STUN server on REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and
the Internet and receives a STUN Binding Response, as normal. The represents an interval measured in milliseconds (thus the maximum
STUN Binding Response contains the XOR-MAPPED-ADDRESS attribute which value is approximately 50 days). This attribute can be present in
indicates the IP address and UDP port of the STUN Binding Request, as Binding Requests and in Binding Responses. In a request, the value
seen by the STUN server. If this IP address differs from the STUN 0xFFFF means it's a query and the refresh interval isn't actually
client's IP address, the STUN client knows there is at least one NAT changed.
between itself and the STUN server, and it continues with the
procedure; otherwise, it stops.
The STUN client now knows the public IP address of its outer-most NAT 6.2. Client Procedures
-- it was returned in the XOR-MAPPED-ADDRESS attribute. The STUN
client performs the Shared Secret Usage (as described in
[I-D.ietf-behave-rfc3489bis]) with the public IP address of its After discovering on-path NATs and firewalls, the STUN client begins
outer-most NAT. After performing that usage, the STUN client now has querying and controlling those devices. The STUN client first
a STUN USERNAME and PASSWORD which authenticate subsequent messages performs the Shared Secret Usage (as described in
between the STUN client and this NAT's STUN server. [I-D.ietf-behave-rfc3489bis]) 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.
If subsequent messages from the STUN server fail authentication, the If subsequent messages from that STUN server fail authentication, the
STUN client MUST re-obtain its IP address from a public STUN server, STUN client MUST re-obtain its IP address from a public STUN server,
not from its outer-most NAT (see section Section 8.3). not from its outer-most NAT (see section Section 9.3).
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 in its outer-most NAT's Binding Request to the IP address of address in its outer-most NAT's
STUN UDP port (3478). The NAT's STUN server will respond with a STUN STUN UDP port (3478). The NAT's STUN server will respond with a STUN
Binding Response containing an XOR-MAPPED-ADDRESS attribute (which Binding Response containing an XOR-MAPPED-ADDRESS attribute (which
points at the NAT's public IP address and port -- just as if the STUN 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 Binding Request had been sent to a STUN server on the public
Internet) and an XOR-INTERNAL-ADDRESS attribute (which points to the Internet) and an XOR-INTERNAL-ADDRESS attribute (which points to the
source IP address and UDP port the packet STUN Binding Request packet source IP address and UDP port the packet STUN Binding Request packet
had prior to being NATted). had prior to being NATted).
If the XOR-INTERNAL-ADDRESS attribute indicates an IP address and UDP 6.3. Server Procedures
port different from the STUN client's own IP address and port, the
STUN client knows there is at least one NAT between itself and the
STUN server it last contacted. If the STUN client wants to use
multiple STUN servers, or wants to control the properties of the NAT
bindings in each of those NATs, the STUN client can iteratively
perform the Short-Term Password Usage followed by the Binding
Discovery Usage with each NAT learned via the XOR-INTERNAL-ADDRESS
attribute from the previous NAT.
In each case where the STUN client is sending STUN Binding Requests
to the NATs, the STUN client can also include other STUN attributes
to request certain properties for the flow. Requesting certain
properties may require the STUN client to obtain short-term
credentials. Defined in this document is a requested lifetime for
the NAT binding in order to reduce keepalive traffic (REFRESH-
INTERVAL).
5.7. Server Procedures
The server should listen for STUN Shared Secret Requests and STUN The server should listen for STUN Shared Secret Requests and STUN
Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478) Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478)
on its public IP address, from hosts connected to its private on its public IP address(es) and its private IP address(es), and
interface(s). The NAT SHOULD only respond to such message which accept such STUN packets from hosts connected to its private
arrive from its 'internal' interface. STUN Binding Requests sent to interface(s). STUN Binding Requests which arrived from its public
the NAT's public IP address which arrived from its public interface interface(s) MAY be handled as if the server isn't listening on that
SHOULD be handled as if the NAT isn't listening on that port (e.g., port (e.g., return an ICMP error) -- this specification does not need
return an ICMP error). them.
After receiving a STUN Shared Secret Request, the NAT follows the After receiving a STUN Shared Secret Request, the NAT follows the
procedures described in the Short-Term Usage section of procedures described in the Short-Term Usage section of
[I-D.ietf-behave-rfc3489bis]. The embedded STUN server MUST store [I-D.ietf-behave-rfc3489bis]. The embedded STUN server MUST store
that username and password so long as any NAT bindings, created or that username and password so long as any NAT bindings, created or
adjusted with that same STUN username, have active mappings on the adjusted with that same STUN username, have active mappings on the
NAT. NAT, and for 60 seconds thereafter (to allow the STUN client to
obtain a new binding).
After receiving a STUN Binding Request containing the REFRESH- After receiving a STUN Binding Request containing the REFRESH-
INTERVAL attribute, the server SHOULD authenticate the request using INTERVAL attribute, the server SHOULD authenticate the request using
the USERNAME attribute and the previously-shared STUN password (this the USERNAME attribute and the previously-shared STUN password (this
is to defend against resource starvation attacks, see Section 8.1). is to defend against resource starvation attacks, see Section 9.1).
If authenticated, the new binding's lifetime can be maximized against If authenticated, the new binding's lifetime can be maximized against
the NAT's configured sanity check and the lifetime indicated in the the NAT's configured sanity check and the lifetime indicated in the
REFRESH-INTERVAL attribute of the STUN Binding Response. REFRESH-INTERVAL attribute of the STUN Binding Response.
In addition to its other attributes, the Binding Response always In addition to its other attributes, the Binding Response MUST
contains the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes. contain the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes.
The XOR-MAPPED-ADDRESS contains the public IP address and UDP port The XOR-MAPPED-ADDRESS contains the public IP address and UDP port
for this binding. The XOR-INTERNAL-ADDRESS contains the IP address for this binding, which is shared with the intended peer. The XOR-
and UDP port of the STUN Binding Request prior to the NAT INTERNAL-ADDRESS contains the IP address and UDP port of the STUN
translation. The XOR-INTERNAL-ADDRESS is used by the STUN client to Binding Request prior to the NAT translation, which is used by the
walk backwards through nested NATs. STUN client to walk backwards through nested NATs (Section 5.1)
For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the
IP address and UDP port _prior to_ the NAPT operation. If there IP address and UDP port prior to the NAPT operation. If there is
is only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would only one NAT, as shown in Figure 1, 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). Iterating over this procedure allows the STUN client to client). Iterating over this procedure allows the STUN client to
find all of the NATs along the path. find all of the NATs along the path.
6. Benefits 7. Benefits
6.1. Incremental Deployment 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 NAT Control can be incrementally deployed. If the outer-most NAT
does not support it, the STUN client behaves as normal. Where the does not support it, the STUN client behaves as normal. In this
outer-most STUN NAT does support it, the STUN client can gain some case, the STUN client might benefit from attempting inside-out
significant optimizations as described in the following sections. procedure described in Section 5.2, and still 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 to applications if NATs are deployed Likewise, there is no change required to applications if NATs are
which support NAT Control. 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.
6.2. Optimize SIP-Outbound 7.3. Optimize SIP-Outbound
In sip-outbound [I-D.ietf-sip-outbound], the SIP proxy is also the In sip-outbound [I-D.ietf-sip-outbound], the SIP proxy is also the
STUN server. This document enables two optimizations of SIP- STUN server. STUN Control as described in this document enables two
Outbound's keepalive mechanism: optimizations of SIP-Outbound's keepalive mechanism:
1. STUN keepalive messages need only be sent to the outer-most NAT, 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 rather than across the access link to the SIP proxy, which vastly
reduces the traffic to the SIP proxy, and; reduces the traffic to the SIP proxy, and;
2. all of the on-path NATs can explicitly indicate their timeouts, 2. all of the on-path NATs can explicitly indicate their timeouts,
reducing the frequency of keepalive messages. reducing the frequency of keepalive messages.
6.3. Optimize ICE 7.4. Optimize ICE
The NAT Control usage provides several opportunities to optimize ICE The NAT Control usage provides several opportunities to optimize ICE
[I-D.ietf-mmusic-ice]. [I-D.ietf-mmusic-ice], as described in this section.
6.3.1. Candidate Gathering 7.4.1. Candidate Gathering
During its candidate gathering phase, an ICE endpoint normally During its candidate gathering phase, an ICE endpoint normally
contacts a STUN server on the Internet. If an ICE endpoint discovers 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 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 outer-most NAT's STUN server rather than using the STUN server on
the Internet. This saves access bandwidth and reduces the reliance the Internet. This saves access bandwidth and reduces the reliance
on the STUN server on the Internet -- the STUN server on the Internet on the STUN server on the Internet -- the STUN server on the Internet
need only be contacted once. need only be contacted once -- when the ICE endpoint first
initializes.
6.3.2. Keepalive
[Note: In ICE-13, the keepalives were changed to STUN 7.4.2. Keepalive
Indications. If this change to ICE becomes working group
consensus for ICE keepalives, this section in this document should
be deleted.]
ICE uses STUN as its primary media stream keepalive mechanism. This ICE uses STUN Indications as its primary media stream keepalive
document enables two optimizations of ICE's keepalive techniques: mechanism. This document enables two optimizations of ICE's
keepalive technique:
1. STUN keepalive messages need only be sent to the outer-most NAT, 1. STUN keepalive messages need only be sent to the outer-most NAT,
rather than across the access link to the remote peer, and; rather than across the access link to the remote peer, and;
2. all of the on-path NATs can explicitly indicate their timeouts, 2. all of the on-path NATs can explicitly indicate their timeouts,
reducing the frequency of keepalive messages. which allows reducing the keepalive frequency.
6.3.3. Learning STUN Servers without Configuration 7.4.3. Learning STUN Servers without Configuration
ICE allows endpoints to have multiple STUN servers, but it is ICE allows endpoints to have multiple STUN servers, but it is
difficult to configure all of the STUN servers in the ICE endpoint -- difficult to configure all of the STUN servers in the ICE endpoint --
it requires some awareness of network topology. By using the 'walk it requires some awareness of network topology. By using the 'walk
backward' technique described in this document, all the on-path NATs backward' technique described in this document, all the on-path NATs
and their embedded STUN servers can be learned without additional and their embedded STUN servers can be learned without additional
configuration. By knowing the STUN servers at each address domain, configuration. By knowing the STUN servers at each address domain,
ICE endpoints can optimize the network path between two peers. ICE endpoints can optimize the network path between two peers.
For example, if endpoint-1 is only configured with the IP address of For example, if endpoint-1 is only configured with the IP address of
skipping to change at page 15, line 27 skipping to change at page 21, line 5
NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 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 can optimize their media path so they make the optimal path from
endpoint-1 to NAT-A to endpoint-2: endpoint-1 to NAT-A to endpoint-2:
+-------+ +-------+ +-------------+ +-------+ +-------+ +-------------+
endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server | endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server |
+-------+ | +-------+ +-------------+ +-------+ | +-------+ +-------------+
| |
endpoint-2 endpoint-2
7. Limitations 8. Limitations
7.1. Overlapping IP Addresses with Nested NATs 8.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>
|client| 10.1.1.1 | 10.1.1.1 | |client| 10.1.1.1 | 10.1.1.1 |
+------+ +--------+ +--------+ +------+ +--------+ +--------+
Figure 8: Overlapping Addresses with Nested NATs Figure 12: Overlapping Addresses with Nested NATs
When this situation occurs, the STUN client can only learn the outer- When this situation occurs, the STUN client can only learn the outer-
most address. This isn't a problem -- the STUN client is still able most address. This isn't 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.
7.2. Address Dependent NAT on Path 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.
8.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 16, line 35 skipping to change at page 22, line 21
+------+ +--------+ +--------+ +------+ +--------+ +--------+
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 9: Address Dependant NAT on Path Figure 13: Address Dependant NAT on Path
Open issue: We could resolve this problem by introducing a new Open issue: We could resolve this problem by introducing a new
STUN attribute which indicates the UDP port the STUN client wants STUN attribute which indicates the UDP port the STUN client wants
to control. However, this changes the security properties of NAT to control. However, this changes the security properties of NAT
Control, so this seems undesirable. Control, so this seems undesirable.
Open issue: When the STUN client detects this situation, should Open issue: When the STUN client detects this situation, should
we recommend it abandon the NAT Control usage, and revert to we recommend it abandon the NAT Control usage, and revert to
operation as if it doesn't support the NAT Control usage? operation as if it doesn't support the NAT Control usage?
7.3. Address Dependent Filtering 8.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.
Discussion: How many filter entries are in address dependent Discussion: How many filter entries are in address dependent
filtering NATs? If only one, this does become a real limitation 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 if NATs are nested; if they're not nested, the outer-most NAT can
avoid overwriting its own address in its address dependent filter. avoid overwriting its own address in its address dependent filter.
8. Security Considerations 9. 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:
8.1. Authorization and Resource Exhaustion 9.1. Authorization and Resource Exhaustion
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 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. To ensure the STUN client is not spoofing its IP address the NAT. The same attack is possible (without considering this
when launching such an attack, the STUN server can challenge requests document and without considering STUN or other UNSAF [RFC3424] NAT
to extend the timeout by sending a NONCE to the STUN client. The traversal techniques) -- a malicious TCP client can open many TCP
STUN server can authorize an extension to the refresh timeout if a connections, and keep them open, causing resource exhaustion in the
new request is sent with that same NONCE value. NAT. One way to thwart such an attack is to challenge the STUN
client with a nonce, which is already part of the STUN specification.
Without considering this document and without considering STUN or By doing this, a NAT can provide DoS protection similar to what it
other UNSAF NAT traversal techniques, a malicious TCP client can open could do for TCP today.
many TCP connections, and keep them open, causing resource exhaustion
in the NAT. A NAT which provide protection against such a TCP attack
can provide a similar level of protection, via the NONCE challange/
response, as they can for TCP sessions.
8.2. Comparison to Other NAT Control Techniques 9.2. Comparison to Other NAT Control Techniques
Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage Like UPnP, Bonjour, 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. that mapping.
However, unlike those technologies, the NAT Control usage described However, unlike those technologies, the NAT Control usage described
in this document only allows each UDP port on the host to create and 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 adjust the mapping timeout of its own NAT mappings. Specifically, an
application on a host can only adjust the duration of a NAT bindings 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 for itself, and not for another application on that same host, and
not for other hosts. This provides security advantages over other not for other hosts. This provides security advantages over other
NAT control mechanisms where malicious software on a host can NAT control mechanisms where malicious software on a host can
surreptitiously create NAT mappings to another application or to surreptitiously create NAT mappings to another application or to
another host. another host.
8.3. Rogue STUN Server 9.3. Rogue STUN Server
As described in Section 6, a STUN client can learn its outer-most NAT As described in Section 7, a STUN client can learn its outer-most NAT
runs an embedded STUN server. However, without the STUN client's runs an embedded STUN server. However, without the STUN client's
knowledge, the outer-most NAT may acquire a new IP address. This knowledge, the outer-most NAT may acquire a new IP address. This
could occur when the NAT moves to a new mobile network or its DHCP could occur when the NAT moves to a new mobile network or its DHCP
lease expires. When the NAT acquires a new IP address, the STUN lease expires. When the NAT acquires a new IP address, the STUN
client will send a STUN Binding Request to the NAT's prior public IP client will send a STUN Binding Request to the NAT's prior public IP
address, which will be routed to the NAT's previous address. address, which will be routed to the NAT's previous address.
If an attacker runs a rogue STUN server on that address, the attacker If an attacker runs a rogue STUN server on that address, the attacker
has effectively compromised the STUN server (the attacked described has effectively compromised the STUN server (the attacked described
in section 12.2.1 of [RFC3489]). The attacker will send STUN Binding in section 12.2.1 of [RFC3489]). The attacker will send STUN Binding
Responses indicating his IP address, which will be indistinguishable, Responses indicating his IP address, which will be indistinguishable,
to the STUN client, from the behavior of the legitimate STUN server. to the STUN client, from the behavior of the legitimate STUN server.
To defend against this attack, the STUN client and STUN server obtain To defend against this attack, the STUN client and STUN server obtain
a short-term password as described in section Section 5.6. a short-term password as described in section Section 6.2.
9. IANA Considerations 10. IANA Considerations
This section registers one new STUN attribute per the procedures in This section registers one new STUN attribute per the procedures in
[I-D.ietf-behave-rfc3489bis]: [I-D.ietf-behave-rfc3489bis]:
0x0026 XOR-INTERNAL-ADDRESS Mandatory range:
0x0028 XOR-INTERNAL-ADDRESS
10. References Optional range:
0x80.. PLEASE-TAG
0x80.. TAG
10.1. Normative References 11. Acknowledgements
Thanks to Remi Denis-Courmont, Markus Isomaki, Cullen Jennings, and
Philip Matthews for their suggestions which have improved this
document.
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., "Simple Traversal Underneath Network Rosenberg, J., "Session Traversal Utilities for (NAT)
Address Translators (NAT) (STUN)", (STUN)", draft-ietf-behave-rfc3489bis-06 (work in
draft-ietf-behave-rfc3489bis-05 (work in progress), progress), March 2007.
October 2006.
[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.
10.2. Informational References 12.2. Informational References
[I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-03 (work in progress), March 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, [Bonjour] Apple Computer, "Bonjour", 2005,
<http://www.apple.com/macosx/features/bonjour/>. <http://www.apple.com/macosx/features/bonjour/>.
[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 Methodology for Network Address Translator (NAT) (ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-13 (work in progress), January 2007. draft-ietf-mmusic-ice-15 (work in progress), March 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-07 (work in progress), draft-ietf-sip-outbound-08 (work in progress), March 2007.
January 2007.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in
progress), March 2007.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
[I-D.shore-tist-prot]
Shore, M., "The TIST (Topology-Insensitive Service
Traversal) Protocol", draft-shore-tist-prot-00 (work in
progress), May 2002.
[I-D.shore-nls-tl]
Shore, M., "Network-Layer Signaling: Transport Layer",
draft-shore-nls-tl-04 (work in progress), May 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple
Middlebox Configuration (SIMCO) Protocol Version 3.0",
RFC 4540, May 2006.
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems Cisco Systems
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. 102 change blocks. 
314 lines changed or deleted 566 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/