Internet DRAFT - draft-draft-ietf-mmusic-ice
draft-draft-ietf-mmusic-ice
MMUSIC J. Rosenberg
Internet-Draft dynamicsoft
Expires: August 16, 2004 February 16, 2004
Interactive Connectivity Establishment (ICE): A Methodology for
Network Address Translator (NAT) Traversal for Multimedia Session
Establishment Protocols
draft-ietf-mmusic-ice-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a methodology for Network Address Translator
(NAT) traversal for multimedia session signaling protocols, such as
the Session Initiation Protocol (SIP). This methodology is called
Interactive Connectivity Establishment (ICE). ICE is not a new
protocol, but rather makes use of existing protocols, such as Simple
Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN)
and even Real Specific IP (RSIP). ICE works through the mutual
cooperation of both endpoints in a session.
Rosenberg Expires August 16, 2004 [Page 1]
Internet-Draft ICE February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multimedia Signaling Protocol Abstraction . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 8
5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . 10
5.1 Gathering Transport Addresses . . . . . . . . . . . . . . . 10
5.2 Enabling STUN on Each Transport Address . . . . . . . . . . 10
5.3 Prioritizing the Transport Addresses . . . . . . . . . . . . 12
5.4 Constructing the Initiate Message . . . . . . . . . . . . . 13
5.5 Responder Processing - Connectivity Checks and Gathering . . 13
5.6 Generating the Accept Message . . . . . . . . . . . . . . . 16
5.7 Initiator Processing of the Accept . . . . . . . . . . . . . 17
5.8 Additional ICE Cycles . . . . . . . . . . . . . . . . . . . 17
6. Running STUN on Derived Transport Addresses . . . . . . . . 19
6.1 STUN on a TURN Derived Transport Address . . . . . . . . . . 19
6.2 STUN on a STUN Derived Transport Address . . . . . . . . . . 20
7. XML Schema for ICE Messages . . . . . . . . . . . . . . . . 22
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Mapping ICE into SIP . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 29
12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . 29
12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . . 29
12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . . 30
12.4 Requirements for a Long Term Solution . . . . . . . . . . . 31
12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . . 31
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
Normative References . . . . . . . . . . . . . . . . . . . . 33
Informative References . . . . . . . . . . . . . . . . . . . 34
Author's Address . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . 36
Rosenberg Expires August 16, 2004 [Page 2]
Internet-Draft ICE February 2004
1. Introduction
A multimedia session signaling protocol is a protocol that exchanges
messages between a pair of agents for the purposes of establishing
the flow of media traffic between them. This media flow is distinct
from the flow of control messages, and may take a different path
through the network. Examples of such protocols are the Session
Initiation Protocol (SIP) [4], the Real Time Streaming Protocol
(RTSP) [5] and ITU H.323.
These protocols, by nature of their design, are difficult to operate
through Network Address Translation (NAT). Because their purpose in
life is to establish a flow of packets, they tend to carry IP
addresses within their messages, which is known to be problematic
through NAT [6]. The protocols also aim for peer to peer media flow,
in order to reduce latency, which is also difficult to accomplish
through NAT. Many other aspects of these protocols are fundamentally
incompatible with NAT. A full treatment of the reasons for this is
beyond the scope of this specification.
Numerous solutions have been proposed for allowing these protocols to
operate through NAT. These include Application Layer Gateways (ALGs),
the Middlebox Control Protocol [7], Simple Traversal of UDP through
NAT (STUN) [1], Traversal Using Relay NAT [14], Realm Specific IP
[8][9], symmetric RTP [10], along with session description extensions
needed to make them work, such as [2]. Unfortunately, these
techniques all have pros and cons which make each one optimal in some
network topologies, but a poor choice in others. The result is that
administrators and implementors are making assumptions about the
topologies of the networks in which their solutions will be deployed.
This introduces a lot of complexity and brittleness into the system.
What is needed is a single solution which is flexible enough to work
well in all situations.
This specification provides that solution. It is called Interactive
Connectivity Establishment, or ICE. ICE makes use of many of the
protocols above, but uses them in a specific methodology which avoids
many of the pitfalls of using any one alone. ICE is not a new
protocol, and does not require extensions from STUN, TURN or RSIP.
However, it does require additional signaling capabilities to be
introduced into the multimedia session signaling protocols. For those
protocols which make use of the Session Description Protocol (SDP),
this specification defines the necessary extensions to it. Other
protocols will need to define their own mechanisms.
Rosenberg Expires August 16, 2004 [Page 3]
Internet-Draft ICE February 2004
2. Multimedia Signaling Protocol Abstraction
This specification defines a general methodology that allows the
media streams of multimedia signaling protocols to successfully
traverse NAT. This methodology is independent of any particular
signaling protocol. In order to discuss the methodology, we need to
to define an abstraction of a multimedia signaling system, and define
terms that can be used throughout this specification. Figure 1 shows
the abstraction.
+-----------+
| |
| |
> | Signaling |\
/ | Relay | \
/ | | \
Initiate / | | \ Initiate
Message / / +-----------+ \ Message
/ / < \
/ / \ \
/ / \ \
/ / Accept Accept \ \
/ / Message Message \ >
/ / \
+-----------+ / \ +-----------+
| | < | |
| | Media Stream | |
| Session | ................................ | Session |
| Initiator | | Responder |
| | Media Stream | |
| | ................................ | |
+-----------+ +-----------+
Figure 1
Communications occur between two clients - the session initiator and
the session responder, also referred to as the initiator and
responder. The initiator is the one that decides to engage in
communications. To do so, it sends an initiate message. The initiate
message contains parameters that describe the capabilities and
configuration of media streams for the initiator. This message may
travel through signaling intermediaries, called a signaling relay,
before finally arriving at the session responder. Assuming the
session responder wishes to communication, it generates an accept
message, which is relayed back to the initiator. This message
contains capabilities and configuration of media streams for the
Rosenberg Expires August 16, 2004 [Page 4]
Internet-Draft ICE February 2004
responder. As a result, media streams are established between the
initiator and responder. The signaling protocol may also support an
operation that allows for modification of the media stream parameters
after establishment. We refer to this signaling messages as a modify
message. Its positive response is a modify acceptance message. The
signaling protocol may also support an operation that allows for
termination of the communications session. We refer to this signaling
message as a terminate message.
This abstraction is readily mapped to SIP, RTSP, and H.323, amongst
others. For SIP, the initiator is the User Agent Client (UAC), the
responder is the User Agent Server (UAS), the initiate message is an
INVITE containing an SDP offer, the accept message is a 200 OK
containing an SDP answer, the modify message is an INVITE with an
offer, the modify acceptance response is a 200 OK with an answer, and
the terminate message is a BYE. For RTSP, the initiator is the RTSP
client, the responder is the RTSP server, the initiate message is a
SETUP message, and the accept message is a SETUP response. The modify
message is a SETUP message, and the modify acceptance message is a
SETUP response.
This specification defines parameters that need to be included in
these various signaling messages in order to implement the
functionality described by ICE. Those parameters are represented in
XML for convenience. Any multimedia signaling protocol that uses ICE
will need to define how to map those parameters into its own protocol
messages. Section 9 provides such a mapping for SIP.
Rosenberg Expires August 16, 2004 [Page 5]
Internet-Draft ICE February 2004
3. Terminology
Several new terms are introduced in this specification:
Session Initiator: A software entity that, at the request of a user,
tries to establish communications with another entity, called the
session responder. A session initiator is also called an
initiator.
Initiator: Another term for a session initiator.
Session Responder: A software entity that receives a request for
establishment of communications from the session initiator, and
either accepts or declines the request. A session responder is
also called a responder.
Responder: Another term for a session responder.
Client: Either the initiator or responder.
Peer: From the perspective of one of the clients in a session, its
peer is the other client. Specifically, from the perspective of
the initiator, the peer is the responder. From the perspective of
the responder, the peer is the initiator.
Signaling Relay: An intermediary of signaling messages. Examples are
SIP proxies and H.323 Gatekeepers.
Initiate Message: The signaling message used by an initiator to
establish communications. It contains capabilities and other
information needed by the responder to send media to the
initiator.
Accept Message: The signaling message used by a responder to agree to
communications. It contains capabilities and other information
needed by the initiator to send media to the responder.
Modify Message: The signaling message used by either an initiator or
responder to change the capability and other information needed by
the peer for sending media.
Modify Acceptance Message The signaling message used by a client to
agree to the changes proposed in a modify message, and to present
the capability or other information needed by its peer for sending
media.
Rosenberg Expires August 16, 2004 [Page 6]
Internet-Draft ICE February 2004
Terminate Message The signaling message used by a client to terminate
the session and associated media streams.
Transport Address: The combination of an IP address and port.
Local Transport Address: A local transport address is transport
address that has been allocated from the operating system on the
host. This includes transport addresses obtained through VPNs, and
also transport addresses obtained through RSIP (which lives at the
operating system level). Transport addresses are typically
obtained by binding to an interface.
Derived Transport Address: A derived transport address is a transport
address which is associated with, but different from, a local
transport address. The derived transport address is associated
with the local transport address in that packets sent to the
derived transport address are received on the socket bound to that
local transport address. Derived addresses are obtained using
protocols like STUN and TURN, and more generally, any UNSAF
protocol [11].
Peer Derived Transport Address: A peer derived transport address is a
derived transport address learned from a STUN server advertised by
a peer in a media session.
TURN Derived Transport Address: A derived transport address obtained
from a TURN server.
STUN Derived Transport Address: A derived transport address obtained
from a STUN server whose address has been provisioned into the UA.
This, by definition, excludes Peer Derived Transport Addresses.
Unilateral Allocations: Queries made to a network server which
provides an UNSAF service.
Bilateral Allocations: Addresses obtained by using an UNSAF service
that actually runs on the peer of the communications session. Peer
derived transport addresses are synonymous with bilateral
allocations.
Rosenberg Expires August 16, 2004 [Page 7]
Internet-Draft ICE February 2004
4. Overview of ICE
ICE makes the fundamental assumption that clients exist in a network
of segmented connectivity. This segmentation is the result of a
number of addressing realms in which a client can simultaneously be
connected. We use "realms" here in the broadest sense. A realm is
defined purely by connectivity. Two clients are in the same realm if,
when they exchange the addresses each has in that realm, they are
able to send packets to each other. This includes IPv6 and IPv4
realms, which actually use different address spaces, in addition to
private networks connected to the public Internet through NAT.
The key assumption in ICE is that a client cannot know, apriori,
whether the peer it wishes to communicate with is connected to one or
all of the address realms it is in. Therefore, in order to
communicate, it has to try them all, and choose the best one that
works.
Before the initiator establishes a session, it obtains as many IP
address and port combinations in as many address realms as it can.
These adresses all represent potential points at which the initiator
will receive a specific media stream. Any protocol that provides a
client with an IP address and port on which it can receive traffic
can be used. These include STUN, TURN, RSIP, and even a VPN. The
client also uses any local interface addresses. A dual-stack v4/v6
client will obtain both a v6 and a v4 address/port. The only
requirement is that, across all of these addresses, the initiator can
be certain that at least one of them will work for any responder it
might communicate with. This is easily guaranteed by using TURN,
RSIP, MIDCOM or a VPN from a server on the public Internet to obtain
one of the addresses.
The initiator then makes a STUN server available on each of the
address/port combinations it has obtained. This STUN server is
running locally, on the initiator. All of these addresses are placed
into the initiate message, and they are ordered in terms of
preference. Local IPv6 addresses always have the highest preference,
followed by local IPv4 addresses, followed by STUN-allocated
addresses, followed last by addresses allocated through protocols
using relays, such as TURN and VPN. The initiate message also conveys
the STUN username and password which are required to gain access to
the STUN server on each address/port combination.
The initiate message is sent to the responder. This specification
does not address the issue of how the signaling messages themselves
traverse NAT. It is assumed that signaling protocol specific
mechanisms are used for that purpose. Once the responder receives the
initiate message, it sends STUN requests to each alternate address/
Rosenberg Expires August 16, 2004 [Page 8]
Internet-Draft ICE February 2004
port in the initiate message. These STUN requests include the
username and password obtained from the initiate message. None of the
STUN flags are used. The STUN requests serve two purposes. The first
is to check for connectivity. If a response is received, the
responder knows that it can reach the initiator at that address. The
second purpose is to obtain more addresses at which the responder can
be contacted. If there were NATs between the responder and initiator,
the responder may discover another address through the STUN
responses. In its accept message, the responder includes all
addresses that it can unilaterally determine (just as the initiator
did), in addition to any that were discovered using the STUN messages
to the initiator.
When the accept message arrives at the initiator, the initiator
performs a similar operation. Using STUN, it checks connectivity to
each of the addresses in the accept message. Through the STUN
responses, it may learn of additional addresses that it can use to
receive media. It can therefore generate a modify message to pass
this address to the responder. Generally, at the end of the first
exchange, both sides will have discovered one of more addresses which
they are capable of successfully sending media to. Each side uses the
most preferred address amongst the ones which worked.
In some cases, an additional exchange will be required.
Rosenberg Expires August 16, 2004 [Page 9]
Internet-Draft ICE February 2004
5. Detailed ICE Algorithm
This section describes the detailed processing needed for ICE.
5.1 Gathering Transport Addresses
The initiator begins the process by gathering transport addresses.
There are two types of addresses it can gather - local transport
addresses, and derived transport addresses. Local transport addresses
are obtained by binding to an ephemeral port on an interface
(physical or virtual) on the host. A multi-homed host SHOULD attempt
to bind on all interfaces for all media streams it wishes to receive.
For media streams carried using the Real Time Transport Protocol
(RTP) [12], the initiator will need to bind to an ephemeral port for
both RTP and RTCP.
The result will be a set of local transport addresses. The initiator
may also have access to servers that provide unilateral self-address
fixing (UNSAF) [11]. Examples of such protocols include STUN, TURN,
and TEREDO [13]. For each of these protocols, the initiator may have
access to a multiplicity of servers. For example, a user connected to
a natted cable access network might have access to a STUN server in
the private cable network and in the public Internet. For each local
transport address, the initiator SHOULD obtain an address from every
server for each protocol it supports. The result of this will be a
set of derived transport addresses, with each derived address
associated with the local transport address it is derived from.
ICE works better the more options exist for connectivity. However, in
order to communicate with the peer, at least one of the offered
addresses has to be guaranteed to work with any peer that might be
called. This generally requires that at least one of the derived
addresses be obtained from a relay service (such as TURN) that exist
within the public Internet. ICE requires that a client know, through
configuration, which of the derived transport addresses is coming
from a provider on the public Internet.
5.2 Enabling STUN on Each Transport Address
Once the initiator has obtained a set of transport addresses, it
starts a STUN server on each local transport address (including ones
used for RTCP). This, by definition, means that the STUN service will
be reached for requests sent to the derived addresses.
However, the client does not need to provide STUN service on any
other IP address or port, unlike the normal STUN usage as described
in [1]. The need to run the service on multiple ports is to support
the change flags. However, those flags are not needed with ICE, and
Rosenberg Expires August 16, 2004 [Page 10]
Internet-Draft ICE February 2004
the server SHOULD reject any requests with these flags set.
Furthermore, there is no need to support TLS or to be prepared to
receive SharedSecret request messages. Those messages are used to
obtain shared secrets to be used with BindingRequests. However, with
ICE, usernames and passwords are exchanged in the signaling protocol.
It is important to note that the client will receive both STUN
requests and media packets on each local transport address. This will
require the initiator to disambiguate STUN messages from messages for
the underlying media stream protocol. In the case of RTP/RTCP, this
disambiguation is easy. RTP and RTCP packets start with the bits 0b10
(v=2). The first two bits in STUN are always 0b00. Disambiguating
STUN with other media stream protocols may be more complicated.
However, it is guaranteed to always be possible by selecting an
appropriately random username (see below).
The need to run STUN on the same transport address as the media
stream represents the "ugliest" piece of ICE. However, it is an
essential part of the story. By sending STUN requests to the very
same place media is sent, any bindings learned through STUN will be
useful even when communicating through symmetric NATs. This results
in a substantial increase in the scope of applicability of STUN, in
terms of cases where it can provide connectivity. In that sense, the
usage of STUN here is radically different than the usage models
outlined in [1], where STUN is generally useless for dealing with
symmetric NAT.
For each local transport address where a STUN server is running, the
client MUST choose a username and password. The username MUST be
globally unique, so that no other host will select a username with
the same value. This username and password will be passed to the
responder in the initiate message. They are used by the responder to
authenticate the STUN requests to the server.
The global uniqueness requirement stems from the lack of uniquenes
afforded by IP addresses. Consider clients A, B, and C. A and B are
within private enterprise 1, which is using 10.0.0.0/8. C is within
private enterprise 2, which is also using 10.0.0.0/8. As it turns
out, B and C both have IP address 10.0.1.1. A initiates
communications to C. C, in its accept message, provides A with its
transport addresses. In this case, thats 10.0.1.1:8866 and 8877. As
it turns out, B is in a session at that same time, and is also using
10.0.1.1:8866 and 8877. This means that B has a STUN server running
on those ports, just as C does. A will send a STUN request to
10.0.1.1:8866 and 8877. However, these do not go to C as expected.
Instead, they go to B. If B just replied to them, A would believe it
has connectivity to C, when in fact it has connectivity to a
Rosenberg Expires August 16, 2004 [Page 11]
Internet-Draft ICE February 2004
completely different user, B. To fix this, the STUN username takes on
the role of a unique identifier. C provides A with a unique username.
A uses this username in its STUN query to 10.0.1.1:8866. This STUN
query arrives at B. However, the username is unknown to B, and so the
request is rejected. A treats the rejected STUN request as if there
were no connectivity to C (which is actually true). Therefore, the
error is avoided.
Once the STUN server is started, it MUST run until the first media
packet arrives on that address. Once that occurs, the agent MAY
terminate the server. It is still possible that a late or lost STUN
message will show up, but these will generally fail any media stream
validity checks and be discarded (STUN packets always fail the RTP
validity checks).
While the server is running, it MUST act as a normal STUN server, but
MUST only accept STUN requests from clients that authenticate using
the username and password handed out for the dialog.
5.3 Prioritizing the Transport Addresses
With the STUN servers starting, the next step is to prioritize the
transport addresses. This priority reflects the desire that the UA
has to receive media on that address, and is assigned as a value from
0 to 1 (1 being most preferred). Although any prioritization is
possible, it is RECOMMENDED that the prioritization be based on the
number of intermediaries that will be traversed. The fewer
intermediaries, the higher the priority. Furthermore, it is
RECOMMENDED that, given an equal number of intermediaries, an IPv6
address receive higher priority than an IPv4 address. As a result of
this, local IPv6 transport addresses obtained from physical
interfaces have highest priority. Next are local IPv4 transport
addresses obtained from physical interfaces. Next are STUN derived
transport addresses, followed by TURN, RSIP or TEREDO derived
transport addresses. Peer derived transport addresses obtained
through STUN requests sent through a TURN relay using the SEND
command have a priority equal to TURN derived transport addresses.
Last up are local transport addresses obtained from VPN interfaces.
Ordering of transport addresses within any one of the groups above
(i.e., addresses obtained from relay services, such as TURN or RSIP),
is more complicated. When a device is configured to use a
multiplicity of these relays, each from the same provider, it is
RECOMMENDED that the client be configured with the relative
preference for each. This is useful, for example, in enterprises with
multiple layers of NAT, each of which hosts a relay. In such a case,
the preference for each relay would normally decrease as the relays
move farther away from the client.
Rosenberg Expires August 16, 2004 [Page 12]
Internet-Draft ICE February 2004
5.4 Constructing the Initiate Message
The next step is to construct the initiate message. Section 7
provides the XML schema for the initiate message. The message
consists of a series of media streams. For each media stream, there
is a default address and a list of alternates. The default address is
the one that will be used by responders that don't understand ICE.
This is mapped to the address currently conveyed in the signaling
messages of SIP, H.323 and RTSP. The alternates provide additional
points of contact.
For each media stream, the client chooses the transport address which
has the highest probability of working with any arbitrary peer.
Generally, this will be a transport address learned from a relay
service on the public Internet, such as TURN. Frequently this is also
the lowest priority transport address. This transport address is
placed into default address in the initiate message. This is the
address that will be used by a peer that doesn't understand ICE.
Therefore, to maximize the ability to complete a call, the address
which is most likely to succeed is used.
The client then encodes all of its available transport addresses
(including the one that was set as the default) as a series of
alternate elements. Each alternate element conveys a transport
address for RTP, one for RTCP, the STUN username and STUN password.
The client MUST assign each alternate a unique identifier. These
identifiers MUST be unique across all alternates used within the
session. This identifier is encoded in the "id" attribute of the
alternate element. The priority for the transport address, as
computed above, is included as an attribute as well.
Once the initiate message is constructed, it is sent.
5.5 Responder Processing - Connectivity Checks and Gathering
Once the responder receives the initiate message, it does several
things in parallel. First, it performs the same processing described
in Section 5.1. Specifically, for each media stream in the initiate
message, the responder allocates a set of local transport addresses
and the full set of derived transport addresses.
Note that these addresses can be "pre-gathered" before the call is
even received, so that a set is always "on-deck". This will avoid any
increase in call setup times, at the expense of holding onto
addresses which may not get used. Retaining these addresses may also
require refresh traffic that consumes network bandwidth.
While the unilateral derived addresses are being obtained, the
Rosenberg Expires August 16, 2004 [Page 13]
Internet-Draft ICE February 2004
responder sends a STUN BindingRequest from each local transport
address to each STUN server identified in an alternate in the
initiate message. This BindingRequest MUST contain the USERNAME
attribute, and the value of the USERNAME MUST equal the username from
that alternate element. Similarly, the BindingRequest MUST contain a
PASSWORD attribute, and the value of the PASSWORD MUST equal the
password from the alternate element. The BindingRequest MUST contain
a MESSAGE-INTEGRITY attribute, computed using the username and
password from the alternate element in the initiate message. The
BindingRequest MUST NOT contain the CHANGE-REQUEST or
RESPONSE-ADDRESS attribute.
It is RECOMMENDED that these STUN requests be sent in parallel. The
responder MAY alert the user during this time. Generally, if the user
is a human (and not an automata), the STUN transactions will have
completed before the call is answered.
If the responder had obtained an address from TURN, it MAY use the
TURN SEND primitive to relay STUN BindingRequest messages, in
addition to sending them from the associated local transport address.
Generally, this would be done only by clients in networks that
prevent the client from sending outbound traffic directly to the
public Internet. These networks frequently require outbound traffic
to pass through some kind of intermediary. A TURN server can play the
role of such an intermediary. It is RECOMMENDED that, whether a
client should or should not also relay its STUN BindingRequests
through the TURN server, be configurable.
When STUN BindingRequest messages are being sent through a TURN
server, the ordering of alternates which are tried makes a
difference. When one of these BindingRequest messages elicits a
response, the response packet causes the TURN server to lock down
towards that alternate. Once locked down, the relay cannot be used
for receiving traffic from other addresses. If the lock down occurs
to an alternate with low preference, the result is sub-optimal. To
avoid this, instead of trying each alternate in parallel, it is
RECOMMENDED that the client try the addresses sequentially, starting
with the alternate with the highest preference value.
OPEN ISSUE: Trying this sequentially is ugly. Any alternatives I
was able to come up with required the client to control lock down.
Once this happens, it becomes possible to misuse TURN to run
public services behind a NAT, which is considered a non-starter.
Is there some other way?
In all cases, if the STUN BindingRequest elicits a BindingResponse
before the STUN transaction times out, the result is considered a
success. For successful transactions, the responder stores the
Rosenberg Expires August 16, 2004 [Page 14]
Internet-Draft ICE February 2004
transport address from the initiate message (which identifies both
the STUN server and the place where media is sent), the local
transport address from which the STUN request was sent, the id of
that alternate from the initiate message, and the preference from
that alternate. If the STUN transaction succeeds, the client knows
for certain that the media can reach the destination as well. That is
because the media traffic will be sent from the same transport
address, to the same trasport address, as the STUN packet was.
When a client receives an initiate message, it MAY begin sending
media immediately to the address and port specified in the default.
If that address and port was also listed as an alternate, the client
MUST send media from the same address and port used to send a STUN
request to the peer. As the STUN transactions begin to complete, the
client begins to learn which alternates it has connectivity to. If
one of those alternates has a higher priority than the one currently
in use, that transport address MUST be used instead (along with its
corresponding local address). Note that, between two transport
addresses with the same preference, a STUN derived address MUST be
used. Furthermore, once a client sends media to a transport address
with a specified priority, it MUST NOT, during the lifetime of the
session, send media to a connected transport address with a lower
priority.
This restriction allows a client to free derived transport addresses
once it knows that its peer has been able to connect to a transport
address with higher priority, or one of equal priority if it was peer
derived. A client can know that a peer was able to connect to a
transport address based on the receipt of a STUN BindingRequest
against that transport address. The username and password in the STUN
BindingRequest can be used to determine which transport address the
STUN request was generated against. Note that the transport address
that the STUN request was received on does not say anything about
which transport address the peer sent to, and so the username and
password are used. Such an address SHOULD be freed no earlier than 3
seconds after receipt of the STUN request. This provides a window of
time for the peer to cease using the address and switch to a better
one.
This connectivity check makes an important assumption. It assumes
that if a STUN request is able to get from A to B, the STUN
response will get from B to A (packet losses aside). To our
knowledge this is generally true, since it is one of the
definining characteristics of the client-server protocols that
NATs have been designed to pass. We need to make this assumption
in order to free up resources and also eliminate additional ICE
cycles.
Rosenberg Expires August 16, 2004 [Page 15]
Internet-Draft ICE February 2004
The drawback of this restriction is that if connectivity should be
lost during the session, the client cannot fall back to lower
priority address. We believe that it is more important to free
unneeded resources than to hold onto them in case of the unlikely
event of a problem.
For those successful STUN transactions, the responder compares the
MAPPED-ADDRESS attribute in the response to the local transport
address from which the STUN request was sent. If the two differ, the
responder considers the MAPPED-ADDRESS as another transport address
that has been gathered for usage in this session. This transport
address is referred to as a peer derived transport address. The
preference of this transport address is set to the value of the
preference of that alternate from the initiate message. For example,
if the initiator provides a transport address obtained from a local
interface, it might set the preference to 1.0. If the responder sends
a STUN request to the server and obtains a new transport address,
that transport address is assigned a preference of 1.0. That
preference will be used in comparison to other addresses gathered by
the responder.
If any STUN BindingRequest results in a BindingErrorResponse, the
ERROR-CODE is examined. If it is 401, 430, 432 or 500, the client
SHOULD retry the request, applying any appropriate fixes specified by
the error code. In the case of 400, 431 and 600, the client MUST NOT
retry. This case is treated identically to a timeout, so that it is
equal to no connectivity at all.
5.6 Generating the Accept Message
At some point, the responder will decide to accept or reject the
communications. A rejection terminates ICE processing, of course. In
the case of acceptance, the accept message is constructed as follows.
At the time when the accept message is to be sent, the responder will
have gathered some number of transport addresses. Some of these will
be local transport addresses, some will be unilaterally derived
addresses, and some will be stun derived from the peer in the dialog.
Each of these will have a preference, based on either the rules in
Section 5.1 or Section 5.5.
Constructing the accept proceeds identically to the way in which the
initiate message is constructed (Section 5.4). The transport address
with the highest probability of success is placed into the default
element. All of the alternatives (including the one placed into the
default) are placed into an alternate element. Each is assigned a
unique ID. For alternates that were peer-dervived STUN addresses, the
derived element is present, and it contains the id of the initiator's
Rosenberg Expires August 16, 2004 [Page 16]
Internet-Draft ICE February 2004
alternate it was derived from. Each alternate contains its preference
as computed above. Each alternate contains a username and password
that must be used to contact the STUN server listening on that
address. Each address SHOULD have a different username and password.
The accept is then sent.
5.7 Initiator Processing of the Accept
There are two possible cases for processing of the Accept message. If
the recipient of the Initiate message did not support ICE, the Accept
message will only contain the default address information. As a
result, the initiator knows that it cannot perform its connectivity
checks. In this case, it SHOULD just sent to the transport address
listed. However, if local configuration information tells the
initiator to try connectivity checks by sending them through the TURN
server, this means that packets sent directly to responder may be
dropped by a local firewall. To deal with this, the initiator SHOULD
allocate, using TURN, a new TURN derived transport address. It does
not advertise this address anywhere. Rather, it issues a SEND command
using this new transport address. The SEND command contains the media
packet to send to the responder. Once this command has been accepted,
the initiator SHOULD send all media packets to the TURN server, which
will then forward them towards the responder.
If the Accept message contains alternates, the processing of the
accept by the initiator is nearly identical to that of the responder
processing the initiate message. Specifically, the initiator will
send STUN requests to the STUN servers listed in the accept. This
results in the same connectivity processing, and will also result in
the gathering of new STUN derived addresses. The initiator can begin
sending media to the responder immediately using the address in the
default. Once STUN has verified connectivity of higher priority
addresses, media is sent to those addresses instead. When a client
sends media to an alternate with higher priority, if that alternate
contained the derived element, the client MUST send media from the
local transport address with the id contained in the derived element.
5.8 Additional ICE Cycles
After the completion of the initiate/accept exchange, both sides may
continue to obtain more derived transport addresses. This may occur
because a STUN transaction took too long to complete, and thus missed
the "window" of the previous initiate message/accept exchange. Or, it
may occur because the previous initiate/accept exchange provided
additional addresses which resulted in new STUN derived attributes.
At any point when either client has one or more new gathered
Rosenberg Expires August 16, 2004 [Page 17]
Internet-Draft ICE February 2004
addresses, it MAY initiate a modify message, and therefore a new
corresponding ICE cycle. This modify message is identical to the
initiate or accept message generated previously by that client.
However, it would include any additional alternates learned since the
last message was sent. However, if the preference of those new
gathered addresses is lower than the preference for an address that
the peer has established connectivity to, the client SHOULD NOT
initiate a modify exchange just to convey this address. If an modify
exchange is taking place anyway (because a higher priority address is
available), the lower qvalue addresses SHOULD be included. A client
can determine which addresses a peer has established connectivity to
by checking if a STUN request was sent by the peer to that address.
OPEN ISSUE: This optimization doesnt work in cases where the peer
establishes connectivity by sending media through its TURN relay,
since the resulting priority is less. The client doesnt have any
way to know whether or not the connectivity check was made by
sending through a relay.
Typically, there won't be more than one or two ICE cycles before
convergence. Assuming that there is no network packet loss (which can
extend the STUN transaction) and zero network latency, it appears
that a maximum of two ICE cycles are needed to reach convergence.
Rosenberg Expires August 16, 2004 [Page 18]
Internet-Draft ICE February 2004
6. Running STUN on Derived Transport Addresses
One of the seemingly bizarre operations done during the ICE
processing is the transmission of a STUN request to a transport
address which is obtained through TURN or STUN itself. This actually
does work, and in fact, has extremely useful properties. The
subsections below go through the detailed operations that would occur
at each point to demonstrate correctness and the properties derived
from it.
6.1 STUN on a TURN Derived Transport Address
Consider a client A that is behind a NAT. It connects to a TURN
server on the public side of the NAT. To do that, A binds to a local
transport address, say 10.0.1.1:8866, and then sends a TURN request
to the TURN server. The NAT translates the net-10 address to
192.0.2.88:5063. Assume that the TURN server is running on 192.0.2.1
and listening for TURN traffic on port 7764. The TURN server
allocates a derived transport address 192.0.2.1:26524 to the client,
and returns it in the TURN response. Remember that all traffic from
the TURN server to the client is sent from 192.0.2.1:7764 to
10.0.1.1:8866.
Now, the client runs a STUN server on 10.0.1.1:8866, and advertises
that its server actually runs on 192.0.2.1:26524. Another client, B,
sends a STUN request to this server. It sends it from a local
transport address, 192.0.2.77:1296. When it arrives at
192.0.2.1:26524, the TURN server "locks down" outgoing traffic, so
that data packets received from A are sent to 192.0.2.77:1296. The
STUN request is then forwarded to the client, sent with a source
address of 192.0.2.1:7764 and a destination address of
192.0.2.88:5063. This passes through the NAT, which rewrites the
source address to 10.0.1.1:8866. This arrives at A's STUN server. The
server observes the source address of 192.0.2.1:7764, and generates a
STUN response containing this value in the MAPPED-ADDRESS attribute.
The STUN response is sent with a source address fo 10.0.1.1:8866, and
a destination of 192.0.2.1:7764. This arrives at the TURN server,
which, because of the lock-down, sends the STUN response with a
source address of 192.0.2.1:26524 and destination of 192.0.2.77:1296,
which is B's STUN client.
Now, as far as B is concerned, it has obtained a new STUN derived
transport address of 192.0.2.1:7764. And indeed, it has! STUN derived
transport addresses are scoped to the session, so they can only be
used by the peer in the session. Furthermore, that peer has to send
requests from the socket on which the STUN server was running. In
this case, A is the peer, and its STUN server was on 10.0.1.1:8866.
If it sends to 192.0.2.1:7764, the packet goes to the TURN server,
Rosenberg Expires August 16, 2004 [Page 19]
Internet-Draft ICE February 2004
and due to lock-down, is forwarded to B, and specifically, is
forwarded to the transport address B sent the STUN request from.
Therefore, the address is indeed a valid STUN derived transport
address.
The benefit of this is that it allows two clients to share the same
TURN server for media traffic in both directions. With "normal" TURN
usage, both clients would obtain a derived address from their own
TURN servers. The result is that, for a single call, there are two
bindings allocated by each side from their respective servers, and
all four are used. With ICE, that drops to two bindings allocated
from a single server. Of course, all four bindings are allocated
initially. However, once one of the clients begins receiving media on
its STUN derived address, it can deallocate its TURN resources.
[[TODO: Include a diagram that shows this pictorially.]]
6.2 STUN on a STUN Derived Transport Address
Consider a client A that is behind a NAT. It connects to a STUN
server on the public side of the NAT. To do that, A binds to a local
transport address, say 10.0.1.1:8866, and then sends a STUN request
to the STUN server. The NAT translates the net-10 address to
192.0.2.88:5063. Assume that the STUN server is running on 192.0.2.1
and listening for STUN traffic on port 3478, the default STUN port.
The STUN server sees a source IP address of 192.0.2.88:5063, and
returns that to the client in the STUN response. The NAT forwards the
response to the client.
Now, the client runs a STUN server on 10.0.1.1:8866, and advertises
that its server actually runs on 192.0.2.88:5063. Another client, B,
sends a STUN request to this address. It sends it from a local
transport address, 192.0.2.77:1296. When it arrives at
192.0.2.88:5063 (on the NAT), the NAT rewrites the source address to
10.0.1.1:8866, assuming that it is of the full-cone variety [1], or
is restricted, and the permission for 192.0.2.77:1296 is open. This
arrives at A's STUN server. The server observes the source address of
192.0.2.77:1296, and generates a STUN response containing this value
in the MAPPED-ADDRESS attribute. The STUN response is sent with a
source address of 10.0.1.1:8866, and a destination of
192.0.2.77:1296. This arrives at B's STUN client.
Now, as far as B is concerned, it has obtained a new STUN derived
transport address of 192.0.2.77:1296. Of course, this is the same
address as the local transport address, and therefore this derived
address is not used. However, had there been additonal NATs between B
and A's NAT, B would end up seeing the binding allocated by that
outermost NAT. The net result is that STUN requests sent to a STUN
Rosenberg Expires August 16, 2004 [Page 20]
Internet-Draft ICE February 2004
derived address behave as normal STUN would. However, these STUN
requests have the side-effect of creating permissions in the NATs
which see those requests in the public to private direction. This
turns out to be very useful for traversing restricted NATs.
Rosenberg Expires August 16, 2004 [Page 21]
Internet-Draft ICE February 2004
7. XML Schema for ICE Messages
This section contains the XML schema used to define the initiate,
accept, and modify messages. Any protocol that uses ICE needs to map
the parameters defined here into its own messages.
Note that STUN allows both the username and password to contain the
space character. However, usernames and passwords used with ICE
cannot contain the space.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="media-streams">
<xs:annotation>
<xs:documentation>This is the root element, which holds a series
of media stream elements.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="media-stream" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>There are zero or more media stream
elements. Each defines attributes for a specific media
stream.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="default-address">
<xs:annotation>
<xs:documentation>The default address is used for
sending media before connectivity has been
verified.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="rtp-info"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:sequence>
<xs:element name="alternate" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Each alternate is a
possible point of contact.</xs:documentation>
</xs:annotation>
Rosenberg Expires August 16, 2004 [Page 22]
Internet-Draft ICE February 2004
<xs:complexType>
<xs:complexContent>
<xs:extension base="transport-data">
<xs:attribute name="preference"
type="xs:double" use="required"/>
<xs:attribute name="id" type="xs:string"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="transport-data">
<xs:sequence>
<xs:element name="stun-username" type="xs:string"/>
<xs:element name="stun-password" type="xs:string"/>
<xs:element name="derived-from" type="xs:string" minOccurs="0"/>
<xs:element name="rtp-address" type="transport-address"/>
<xs:element name="rtcp-address" type="transport-address"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="transport-address">
<xs:sequence>
<xs:element name="ip-address" type="xs:string"/>
<xs:element name="port">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rtp-info">
<xs:sequence>
<xs:element name="rtp-address" type="transport-address"/>
<xs:element name="rtcp-address" type="transport-address"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Rosenberg Expires August 16, 2004 [Page 23]
Internet-Draft ICE February 2004
8. Examples
TODO. Fill in with example XML message exchanges.
Rosenberg Expires August 16, 2004 [Page 24]
Internet-Draft ICE February 2004
9. Mapping ICE into SIP
In this section, we show how to map ICE into SIP. This requires
extensions to SDP.
A new SDP attribute is defined to support ICE. It is called "alt".
The alt attribute MUST be present within a media block of the SDP. It
contains an alternative IP address and port (or pair of IP addresses
and ports in the case of RTP) that the recipient of the SDP can use
instead of the ones indicated in the m and c lines. There MAY be
multiple alt attributes in a media block. In that case, each of them
MUST contain a different IP address and port (or a differing pair of
IP address and ports in the case of RTP).
The syntax of this attribute is:
alt-attribute = "alt" ":" id SP qvalue SP derived-from SP
username SP password SP
unicast-address SP port [unicast-address SP port]
;qvalue from RFC 3261
;unicast-address, port from RFC 2327
username = non-ws-string
password = non-ws-string
id = token
derived-from = ":" / id
With the addition of the alt attribute, the mapping of the ICE
messages to SIP/SDP is straightforward. The ICE initiate message
corresponds to a SIP message with an SDP offer. The ICE accept
message corresponds to a SIP message with a SDP answer. The ICE
modify message corresponds to a SIP INVITE or UPDATE with an offer,
and the ICE modify accept message corresponds to an INVITE or UPDATE
response with an answer.
Each media stream element in an ICE message maps to a media block in
the SDP. The default address maps to the m and c lines in the SDP. If
the ICE message indicates an RTCP address and port that are not one
higher than that of the RTP, the SDP RTCP attribute [2] MUST be used
to convey them.
Each alternate element in an ICE message maps either to an alt
attribute in the SDP, or a new media block, depending on the IP
version of the alternate. For the highest priority IPv6 alternate, it
is mapped into a separate media block, using the IPV grouping [3].
Any additional IPv6 addresses are placed as alternates within this
media block. For alternates that are IPv4 addresses, the alt
attribute is used. The rtp-address element maps to the first
Rosenberg Expires August 16, 2004 [Page 25]
Internet-Draft ICE February 2004
unicast-address and port components of the alt attribute. The
rtcp-address element maps to the second unicast-address and port
components of the alt attribute. Note that, if the RTCP address is
identical to the RTP address, and the port is one higher, the second
unicast-address and port MAY be omitted. The preference value from
the alternate element is mapped to the q-value component of the alt
attribute. The STUN username and password elements map to the
username and password components of the alt attribute. When the
derived element is present in the ICE message, it is represented in
the derived-from component of the alt attribute. If it is not present
in the ICE message, the derived-from component of the alt attribute
has a value of ":".
Rosenberg Expires August 16, 2004 [Page 26]
Internet-Draft ICE February 2004
10. Security Considerations
ICE conveys the STUN username and password within its messages. If an
eavesdropper should see the username and password, the worst they can
do is send STUN requests to the host. Since STUN is a stateless
protocol, the attacker can not alter the processing of the call or
otherwise disrupt it. They could flood the server with BindingRequest
packets. However, this would be no worse than if the attacker simply
floods the host with any kind of packet.
However, integrity protection of the username and password are more
important. If an attacker is capable of intercepting the message and
modifying the username or password, they could prevent connectivity
from being established between peers, and therefore disrupt the call.
Of course, if the attacker can intercept the message, there are many
other ways in which they could do that, such as simply discarding the
message. Injecting fake messages with incorect usernames and
passwords can also disrupt a call, and does not require the
compromise of an intermediate server. A similar attack is possible by
modifying most of the ICE message attributes. To prevent these kinds
of attacks, it is RECOMMENDED that the actual protocols the ICE maps
to make use of security mechanisms that provide message integrity
protection.
Rosenberg Expires August 16, 2004 [Page 27]
Internet-Draft ICE February 2004
11. IANA Considerations
This specification defines one new media attribute: alt. Its syntax
is defined in Section 9.
Rosenberg Expires August 16, 2004 [Page 28]
Internet-Draft ICE February 2004
12. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing",
which is the general process by which a client attempts to determine
its address in another realm on the other side of a NAT through a
collaborative protocol reflection mechanism [11]. ICE is an example
of a protocol that performs this type of function. Interestingly, the
process for ICE is not unilateral, but bilateral, and the difference
has a signficant impact on the issues raised by IAB. The IAB has
mandated that any protocols developed for this purpose document a
specific set of considerations. This section meets those
requirements.
12.1 Problem Definition
From RFC 3424 any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not
be generalized to solve other problems; this is why "short term
fixes usually aren't".
The specific problems being solved by ICE are:
Provide a means for two peers to determine the set of transport
addresses which can be used for communication.
Provide a means for resolving many of the limitations of other
UNSAF mechanisms by wrapping them in an additional layer of
processing (the ICE methodology).
Provide a means for a client to determine an address that is
reachable by another peer with which it wishes to communicate.
12.2 Exit Strategy
From RFC 3424, any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed.
ICE itself doesn't easily get phased out. However, it is useful even
in a globally connected Internet, to serve as a means for detecting
whether a router failure has temporarily disrupted connectivity, for
example. However, what ICE does is help phase out other UNSAF
mechanisms. ICE effectively selects amongst those mechanisms,
Rosenberg Expires August 16, 2004 [Page 29]
Internet-Draft ICE February 2004
prioritizing ones that are better, and deprioritizing ones that are
worse. Local IPv6 addresses are always the most preferred. As NATs
begin to dissipate as IPv6 is introduced, derived transport addresses
from other UNSAF mechanisms simply never get used, because higher
priority connectivity exists. Therefore, the servers get used less
and less, and can eventually be remove when their usage goes to zero.
Indeed, ICE can assist in the transition from IPv4 to IPv6. It can be
used to determine whether to use IPv6 or IPv4 when two dual-stack
hosts communicate with SIP (IPv6 gets used). It can also allow a
client in a v6 island to communicate with a v4 host on the other side
of a 6to4 NAT, by allowing the v6 host to address-fix against the v4
host, and in the process, obtain a v4 address which can be handed to
the v4 client.
12.3 Brittleness Introduced by ICE
From RFC3424, any UNSAF proposal must provide:
Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.
ICE actually removes brittleness from existing UNSAF mechanisms. In
particular, traditional STUN (the usage described in RFC 3489) has
several points of brittleness. One of them is the discovery process
which requires a client to try and classify the type of NAT it is
behind. This process is error-prone. With ICE, that discovery process
is simply not used. Rather than unilaterally assessing the validity
of the address, its validity is dynamically determined by measuring
connectivity to a peer. The process of determining connectivity is
very robust. The only potential problem is that bilaterally fixed
addresses through STUN can expire if traffic does not keep them
alive. However, that is substantially less brittleness than the STUN
discovery mechanisms.
Another point of brittleness in STUN, TURN, and any other unilateral
mechanism is its absolute reliance on an additional server. ICE makes
use of a server for allocating unilateral addresses, but allows
clients to directly connect if possible. Therefore, in some cases,
the failure of a STUN or TURN server would still allow for a call to
progress when ICE is used.
Another point of brittleness in traditional STUN is that it assumes
that the STUN server is on the public Internet. Interestingly, with
ICE, that is not necessary. There can be a multitude of STUN servers
in a variety of address realms. ICE will discover the one that has
Rosenberg Expires August 16, 2004 [Page 30]
Internet-Draft ICE February 2004
provided a usable address.
The most troubling point of brittleness in traditional STUN is that
it doesn't work in all network topologies. In cases where there is a
shared NAT between each client and the STUN server, traditional STUN
may not work. With ICE, that restriction can be lifted.
Traditional STUN also introduces some security considerations.
Unfortunately, since ICE still uses network resident STUN servers,
those security considerations still exist.
12.4 Requirements for a Long Term Solution
From RFC 3424, any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions
-- contribute to the process of finding the right longer term
solution.
Our conclusions from STUN remain unchanged. However, we feel ICE
actually helps because we believe it can be part of the long term
solution.
12.5 Issues with Existing NAPT Boxes
From RFC 3424, any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This will interfere with proper
operation of any UNSAF mechanism, including ICE.
Rosenberg Expires August 16, 2004 [Page 31]
Internet-Draft ICE February 2004
13. Acknowledgements
The authors would like to thank Douglas Otis and Francois Audet for
their comments and input.
Rosenberg Expires August 16, 2004 [Page 32]
Internet-Draft ICE February 2004
Normative References
[1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
[2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003.
[3] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for
the Session Description Protocol Grouping Framework",
draft-camarillo-mmusic-alt-02 (work in progress), October 2003.
Rosenberg Expires August 16, 2004 [Page 33]
Internet-Draft ICE February 2004
Informative References
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[6] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.
[8] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[9] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm
Specific IP: Protocol Specification", RFC 3103, October 2001.
[10] Yon, D., "Connection-Oriented Media Transport in SDP",
draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
2003.
[11] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[13] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-ietf-ngtrans-shipworm-08 (work in progress), September
2002.
[14] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-03 (work in progress), October
2003.
Rosenberg Expires August 16, 2004 [Page 34]
Internet-Draft ICE February 2004
Author's Address
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Rosenberg Expires August 16, 2004 [Page 35]
Internet-Draft ICE February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Rosenberg Expires August 16, 2004 [Page 36]
Internet-Draft ICE February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires August 16, 2004 [Page 37]
