One document matched: draft-rosenberg-mmusic-ice-nonsip-00.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc symrefs='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc ipr="full3978" category="std">
<front>
<title abbrev="NICE: ICE for non-SIP Protocols">
NICE: Non Session Initiation Protocol (SIP) usage of Interactive
Connectivity Establishment (ICE)</title>
<author initials="J.R." surname="Rosenberg"
fullname="Jonathan Rosenberg">
<organization>Cisco</organization>
<address>
<postal>
<city>Edison</city> <region>NJ</region>
<country>US</country>
</postal>
<phone>+1 973 952-5000</phone>
<email>jdrosen@cisco.com</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<date month="February" year="2008" />
<keyword>NAT</keyword>
<keyword>SIP</keyword>
<keyword>ICE</keyword>
<keyword>STUN</keyword>
<abstract>
<t>Interative Connectivity Establishment (ICE) has been
specified as a NAT traversal mechanism for protocols
based on the offer/answer exchange model. In practice,
only the Session Initiation Protocol (SIP) has been based
on the offer/answer model. This document defines a SIP
independent subset of ICE, called NICE, which can be used
with any protocol wishing to establish a direct
host-to-host relationship through NAT. Protocol
specifications need only reference this document, and
include the object defined here in their messages,
in order to achieve NAT traversal. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Interactive Connectivity Establishment (ICE)
<xref target="I-D.ietf-mmusic-ice"/> has been specified by the
IETF as a mechanism for NAT traversal for protocols based on the
offer/answer model <xref target="RFC3264"/>, which exchanges Session
Description Protocol (SDP) <xref target="RFC4566"/> objects to
negotiate media sessions.
</t>
<t>
ICE has many benefits. It is automated, relying on very little
configuration. It works through an extremely broad range of network
and NAT topologies. It is robust, establishing connections in many
challenging environments. It is efficient, utilizing relays and
intermediaries only when other options will not work. At the time of
writing, ICE has seen widespread usage on the Internet for traversal
of Voice over IP, primarily based on the Session Initiation Protocol
(SIP) <xref target="RFC3261"/>
</t>
<t>
However, SIP is not the only protocol that requires the establishment
of host-to-host relationships for communications. Consequently, ICE
has recently been considered as the NAT traversal technique for other
protocols. These include Peer-to-Peer SIP (P2PSIP)
<xref target="I-D.bryan-p2psip-reload"/>, Host Identity Protocol (HIP)
<xref target="I-D.manyfolks-hip-sturn"/> and Mobile IP v6
<xref target="I-D.tschofenig-mip6-ice"/>. In each case, the
protocol in question provides a mechanism for two hosts to rendezvous
through some intermediary, and then needs a host-to-host connection
established. This fits the NAT traversal capability provided by ICE.
</t>
<t>
Unfortunately, the ICE specification itself is intertwined with SDP
and the offer/answer model, and is not immediately usable by protocols
that do not utilize offer/answer. For this reason, each of these
protocols has needed to define its own usage of ICE. This results in
duplicate work and inconsistent solutions for NAT traversal.
</t>
<t>
To remedy this, this document defines a generic NAT traversal solution
based on ICE, called NICE. It does so by referencing the specific
parts of the ICE specification that are needed. It also defines a
simply object that can be exchanged in
other protocols. Consequently, protocols that fit the design pattern
for NICE need only reference this document, and provide a way to
include the defined object in their messages. With that, they have a
solution for NAT traversal.
</t>
</section>
<section title="Can My Protocol Use NICE?">
<t>
Not all protocols can make use of NICE. NICE works only with protocols
that fit the pattern of a session protocol. A session protocol is one
in which there exists some kind of rendezvous service, typically
through a server on the Internet, by which hosts can contact each
other. Through the rendezvous service, hosts can exchange information
for the purposes of negotiating a direct host to host connection. Each
host is assumed to have an identifier by which it is known to the
rendezvous service, and by which other hosts can identify it. There is
typically some kind of registration operation, by which a host
connects to the rendezvous service and identifies itself. This
protocol design pattern is shown in <xref target="fig-session"/>.
</t>
<figure title="Session Protocols" anchor="fig-session"><artwork>
<![CDATA[
+--------------+
| |
| |
> | Rendezvous | \
/ | Service | \
/ | | \
/ | | \
/ | | \
/ +--------------+ \
/ \
/ Connect \
/ To Y \
/ \
+--------+ +--------+
| | | |
| | | |
| Host | ......................... | Host |
| ID:X | | ID:Y |
| | | |
+--------+ +--------+
]]></artwork></figure>
<t>
If hosts can reach each other through the rendezvous service, why
create direct connections? Typically, the rendezvous service provides
an indirect connection, and may be very suboptimal in terms of latency
and other path metrics. The rendezvous service may also have limited
bandwidth, and not be capable of supporting the volume of data
required to flow between the hosts.
</t>
<t>
As an example, in SIP, the rendezvous service is the SIP server. The
identifier is the SIP URI. The registration process is supported using
the REGISTER method. Connections are established using the INVITE
method.
</t>
<t>
For a protocol to use NICE, it must exhibit the properties of
a session protocol as described above. Furthermore, it must provide a
mechanism for exchanging MIME objects between the hosts for purposes
of establishing the connection. It must provide for, at least, one
message from the initiator to the other host, and one message back. If
all of these criteria are met, NICE can be used.
</t>
</section>
<section title="Terminology">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>. </t>
<t>
In addition, this document introduces the following terms:
</t>
<list style="hanging">
<t hangText="Session Initiator:">A software or hardware entity on a
host that wishes to establish establish communications with another
host, called the session responder. A session initiator is also
called an initiator.</t>
<t hangText="Initiator:">Another term for a session initiator.</t>
<t hangText="Session Responder:">A software or hardware entity on a host
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.</t>
<t hangText="Responder:">Another term for a session responder.</t>
<t hangText="Client:">Either the initiator or responder.</t>
<t hangText="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. </t>
<t hangText="Rendezvous Service:">A protocol service provided to the
clients that allows them to identify each other using a well known
identifier, and then send messages back and forth. </t>
<t hangText="Initiate Message:">The message in the rendezvous protocol
used by an
initiator to establish communications. It contains the ICE parameters
needed to establish communications. </t>
<t hangText="Accept Message:">The message in the rendezvous protocol used by a
responder to establish communications. It contains the ICE parameters
needed to establish communications. </t>
</list>
</section>
<section title="Overview of Operation">
<t>
To utilize NICE, one host, the INITIATOR, sends a message using the
rendezvous protocol. This message is addressed towards another host,
the RESPONDER. This message is called the Initiate message. That
message contains a MIME object, specified in
<xref target="sec-iceobj"/>, which includes the information needed by
NICE. In particular, it contains a set of candidates for the purposes
of establishing a single "stream". This stream is a
host-to-host UDP association or TCP connection. The rendezvous
service delivers the Initiate message to the RESPONDER. It sends a
message back to the initiator, called the Accept message. This
message also carries the same object, containing information
from the Responder for the purposes of establishing the stream.
</t>
<t>
NICE uses server reflexive and relayed candidates learned from Session
Traversal Utilities for NAT (STUN) STUN
<xref target="I-D.ietf-behave-rfc3489bis"/> and Traversal Using Relay
through NAT (TURN) <xref target="I-D.ietf-behave-turn"/>
servers. These functions can be provided by the rendezvous service, or
by traditional STUN and TURN servers in the network. The candidates
learned from these servers are what is included in the objects
exchanged through the rendezvous protocol.
</t>
<t>
Once exchanged, the clients perform connectivity checks. These checks
probe for connectivity between the pairs of candidates signaled
through the rendezvous protocol. Once a match is found, the Initiator
sends an updated connectivity check, indicating that a pair has been
selected. At that point, packets can flow between initiator and
responder.
</t>
</section>
<section title="Differences between ICE and NICE">
<t>
NICE differs from ICE in two fundamental ways. Firstly, it is
abstracted from SDP and RTP specifics. Secondly, it is subsetted. This
subsetting operation removes many of the features in ICE that are
there for reasons having to do with the nuances of SIP, or the need for
real-time operation. In particular, the following ICE features are not
used in NICE:
</t>
<list style="symbols">
<t>ICE has the notion of a default candidate. This default candidate
is used for backwards compatibility with pre-ICE SIP
implementations. That mechanism is very specific to SDP backwards
compatibility techniques, and is not used here. Instead, if the
protocol using NICE requires backwards compatibility, it needs to
define its own mechanisms for such.
</t>
<t>ICE supports the notion of updated offers and answers that can
modify information. Indeed, it requires such an update when the pair
selected by ICE does not match the default. The notion of default
has been removed in NICE, as has the ability to update the ICE
information. This update allowed for mid-call changes in
connectivity, a frequent occurrence in events like call transfer. If
a protocol using NICE requires a connection to a different host, it
has to start a totally new and unrelated ICE session. This can
result in discontinuous connectivity while the checks
re-run. Continuous operation is needed for real-time usage, but not
more generally.
</t>
<t>
Simllarly, ICE restarts are not supported in NICE. Restarts are an
artifact of sending updated offers and answers.
</t>
<t>
ICE provides some guidance for handling SIP forking. This is a case
where a single offer elicits multiple answers. Forking is specific
to SIP, and so this capability is removed from NICE. NICE allows
connectivity to be set up only between a pair of hosts.
</t>
<t>
ICE defines a lite mode of operation for supporting ease of
implementation. Since NICE is already simpler by the removal of
several large ICE features (most notably updated offers and
answers), this simplified mode seems unneeded. It seems better to
simplify NICE overall rather than define complexity in the normal
mode in order to introduce a simplified lite mode.
</t>
<t>
ICE supports the notion of multiple streams and multiple components
per stream. This was done specifically to address the needs of
multimedia. NICE provides the ability to establish a single
connection between a pair of hosts. Consequently, that capability is
not present in NICE.
</t>
<t>
ICE defines an algorithm called the Frozen algorithm. This algorithm
exists to speed up completion of ICE in cases where multiple
candidates share similar properties. For example, when an audio and
video candidate are on the same host IP address. Since NICE only
supports a single candidate and a single component, the use cases
for the Frozen algorithm diminish significantly. Furthermore, the
Frozen algorithm is entirely about speed and is not as much an issue
for more general non-real tiem protocols . Thus, this algorithm is
not used by NICE. It falls out by using the algorithm defined in
ICE, but by setting each foundation to a unique value.
</t>
<t>
ICE defines SDP attributes for "remote-candidates". These are used
to resolve a race condition between a subsequent offer/answer and
the ICE checks. Since NICE does not use any subsequent rendezvous
signaling, this attribute and its procedures are not used in NICE.
</t>
<t>
ICE defines an SDP attribute called "ice-mismatch". This detects an
ICE failure case due to the presence of signaling intermediaries
that don't support ICE. This problem is specific to SIP and thus
this attribute and associated procedures are not used in NICE.
</t>
</list>
</section>
<section anchor="sec-gather" title="Gathering Candidates">
<t>
When a client wishes to establish a connection, it follows the process
of gathering candidates as described
in Section 4.1 of ICE <xref target="I-D.ietf-mmusic-ice"/>. However,
the client MUST follow those rules under the assumption of a single
media stream and a single component for that stream. This
simplification means that component ID for an ICE candidate is always
one. In addition, the rules in Section 4.1.1.3 MUST be ignored;
instead, each candidate MUST have a unique foundation, assigned
arbitrarily by the client.
</t>
<t>
If the client wishes to establish a TCP connection and not a UDP
stream, or wishes to try both, the client MUST implement ICE-tcp
<xref target="I-D.ietf-mmusic-ice"/>, and MUST follow the procedures
defined there for gathering of TCP candidates, again assuming a single
component.
</t>
<t>
The default candidate selection described in Section 4.1.3 of ICE MUST be
ignored; defaults are not signaled or utilized here.
</t>
<t>
The ICE specification assumes that an ICE agent is configured with, or
somehow knows of, TURN and STUN servers. Protocols using ICE need to
describe how such information is learned by clients.
</t>
</section>
<section title="Sending an Initiate Message">
<t>
Section 4.3 of ICE describes procedures for encoding the SDP. Instead
of actually encoding an SDP, the candidate information (IP address and
port and transport protocol, priority, foundation, component ID, type
and related address) is carried within the object defined in
<xref target="sec-iceobj"/>. Similarly, the username fragment and password
are carried in
this object. This object does not contain any default
candidates or the ice-lite attribute, as these features of ICE are not
used in NICE. The object does contain a Next-Protocol
field. This field is a string that contains the protocol name that is
to be run over the TCP or UDP association created by ICE. These names
are drawn from the list of protocols defined by IANA at
http://www.iana.org/assignments/port-numbers. Note that, since NICE
will cause STUN and this protocol to be multiplexed on the same port,
NICE can only be used to negotiate protocols that can be differentiated
from STUN by inspection. If the desired protocol cannot be
differentiated, it MUST be shimmed with a field that allows such
differentiation, and the resulting protocol MUST be given a new name.
</t>
</section>
<section title="Receiving an Initiate Message">
<t>
A responder MUST take the role of
controlled. The role determination mechanism in Section 5.2 of ICE is
not used with NICE. The ICE verification step in Section 5.1 is not used
either. Instead, protocols using this specification will need to
describe how to handle interoperability between clients which are
using it, and ones which are not.
</t>
<t>
The responder follows the procedures in <xref target="sec-gather"/> to
gather candidates. It then forms an Accept message and includes the
object defined in <xref target="sec-iceobj"/>.
</t>
<t>
The responder MUST follow the procedures in Section 5.7 and 5.8 of ICE,
following the full implementation requirements and behaving as if
there was a single media stream with a single component. Because there
is only a single media stream and single component in NICE, the states
described in Section 5.7.4 will become simplified. There will only be
a single check list, and none of the candidate pairs will ever have
the state of Frozen; all pairs will start in the Waiting state.
</t>
</section>
<section title="Receiving an Accept Message">
<t>
When the initiator receives a response message, it extracts and NICE object
from the message. The initiator MUST take the role of controlled, and
then MUST follow the procedures of Section 5.7 and 5.8 of ICE,
following the full implementation requirements and behaving as if
there was a single media stream with a single component.
</t>
</section>
<section title="Connectivity Checks">
<t>
The process of performing connectivity checks, as described in Section
7 of ICE, is used here without change. This means that STUN
connectivity checks will contain the ICE-CONTROLLED and
ICE-CONTROLLING attributes. Strictly speaking, these are not
needed. However, they are retained here to allow for the possibility
of gatewaying between NICE and ICE (for example, in the event that
H.323 decided to utilize NICE).
</t>
</section>
<section title="Concluding ICE">
<t>
The controlling client MUST utilize regular nomination. This is to
ensure consistent state on the final selected pairs without the need
for additional signaling.
</t>
<t>
The procedures in Section 8 of ICE are followed to conclude ICE, with
the following exceptions:
<list style="symbols">
<t>The controlling agent MUST NOT attempt to send an
updated offer once the state of its single media stream reaches
Completed.
</t>
<t>
Once the state of ICE reaches Completed, the agent can immediately
free all unused candidates. This is because the concept of forking is
not used here, and thus the three second delay in Section 8.3 of ICE
does not apply.
</t>
</list>
</t>
</section>
<section title="Subsequent Messaging">
<t>
A client MUST NOT send additional Initiate or Accept messages. Thus,
the procedures in Section 9 of ICE MUST be ignored. A client that
needs to modify its connection parameters in some way MUST establish a
completely new connection by starting a totally new Initiate/Accept
exchange and ICE connectivity checks.
</t>
</section>
<section title="Keepalives">
<t>
A NICE client MUST utilize STUN for the keepalives described in
Section 10 of ICE.
</t>
</section>
<section title="Sending and Receiving Data">
<t>
A client follows the procedures of Section 11.1.1 of ICE to determine
when it can proceed to send data. However, in this case, the "media"
takes the form of application layer protocols. The concept of a
previous selected pair for a component does not apply to NICE, since
ICE restarts are not used. A client MUST be prepared to receive data
at any time.
</t>
</section>
<section anchor="sec-iceobj" title="The NICE Object">
<t>
NICE operates by exchaning a MIME object, called the NICE object, in
an initiate and response message. The syntax of that object is
described here using the BNF defined in <xref target="RFC5234"/>.
</t>
<figure><artwork>
<![CDATA[
NICE-obj = nice-ufrag CRLF
nice-pwd CRLF
nice-proto CRLF
1*(nice-cand CRLF)
*(nice-opts CRLF)
*(nice-ext CRLF)
nice-ufrag = ice-pwd-att
nice-pwd = ice-ufrag-att
nice-cand = candidate-attribute
nice-opts = ice-options
nice-proto = "nextproto:" token
nice-ext = ext-name ":" ext-value
ext-name = token
ext-value = byte-string
]]></artwork></figure>
<t>
The BNF productions for ice-pwd-att, ice-ufrag-att,
candidate-attribute and ice-options are defined in
<xref target="I-D.ietf-mmusic-ice"/>. The NICE object also contains an
extensibility mechanism, allowing new parameters to be defined which
follow the form of name:value. The grammar for the name and its value
follow those for SDP attributes. This allows for a direct copying of
any future ICE-related SDP extensions into NICE without translations
or specifications; the attribute is simply placed into the bottom of
the NICE object using the grammar defined for it in the ICE extension.
</t>
<t>
The nextproto field contains an indication of the protocol that is to
be multiplexed with STUN over the established connection. In some
cases there is only one choice, based on the rendezvous protocol.
</t>
<t>
STUN connectivity checks between agents are authenticated using the
short term credential mechanism defined for STUN
<xref target="I-D.ietf-behave-rfc3489bis"/>. This mechanism relies on
a username and password that are exchanged through protocol machinery
between the client and server. With NICE, the Initiate and Accept exchange is
used to exchange them. The username
part of this credential is formed by concatenating a username fragment
from each agent, separated by a colon. Each agent also provides a
password, used to compute the message integrity for requests it
receives. The username fragment and password are exchanged in the
nice-ufrag and nice-pwd attributes, respectively. In addition to
providing security, the username provides disambiguation and
correlation of checks to media streams.
</t>
</section>
<section anchor="sec-security" title="Security Considerations">
<t>
ICE provides an extensive discussion on security considerations. That
discussion applies here as well.
</t>
<t>
In particular, ICE security depends in part on message integrity and
confidentiality of the offer/answer exchange. In the case of NICE, the
rendezvous protocol carrying the ICE object needs to provide
confidentiality and message integrity. Rendezvous protocols utilizing
ICE MUST implement and SHOULD use some kind of mechanism to achieve
that.
</t>
</section>
<section title="IANA Considerations">
<t>
This specification registers a new MIME type, "message/nice",
according to the procedures of <xref target="RFC2048">RFC
2048</xref>. This allows NICE to readily be used with protocols that
provide MIME transport, though MIME transport is not required to use NICE.
</t>
<list style="hanging">
<t hangText="MIME media type name:">message</t>
<t hangText="MIME subtype name:">nice</t>
<t hangText="Mandatory parameters:">None</t>
<t hangText="Optional parameters:">None.</t>
<t hangText="Encoding considerations:">None</t>
<t hangText="Security considerations:">See
<xref target="sec-security"/> of RFC XXXX [[RFC EDITOR: Replace with
RFC number of this specification]].</t>
<t hangText="Interoperability considerations:">none.</t>
<t hangText="Published specification:"> RFC XXXX [[NOTE TO RFC EDITOR:
Please replace XXXX with the published RFC number of this
specification.]].</t>
<t hangText="Applications which use this media type:"> This media type is
used in the NICE protocol defined in in RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC
number of this specification.]].</t>
<t hangText="Additional Information:">
<list style="hanging">
<t hangText="Magic Number:">None</t>
<t hangText="File Extension:">.nic</t>
<t hangText="Macintosh file type code:">"TEXT"</t>
<t hangText="Personal and email address for further information:">Jonathan
Rosenberg, jdrosen@jdrosen.net</t>
<t hangText="Intended usage:">COMMON</t>
<t hangText="Author/Change controller:">The IETF.</t>
</list>
</t>
</list>
</section>
<section title="Tongue Twister">
<t>
Say this five times fast: "ICE is nice, but NICE is nicer ICE".
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-mmusic-ice"?>
<?rfc include="reference.I-D.ietf-behave-rfc3489bis"?>
<?rfc include="reference.I-D.ietf-behave-turn"?>
<?rfc include="reference.RFC.5234"?>
<?rfc include="reference.RFC.2048"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.I-D.bryan-p2psip-reload"?>
<?rfc include="reference.I-D.manyfolks-hip-sturn"?>
<?rfc include="reference.I-D.tschofenig-mip6-ice"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:48:43 |