Network Working Group J. Rosenberg
Internet-Draft Cisco
Intended status: Standards Track July 14, 2008
Expires: January 15, 2009
Guidelines for Usage of Interactive Connectivity Establishment (ICE) by
non Session Initiation Protocol (SIP) Protocols
draft-rosenberg-mmusic-ice-nonsip-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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 used ICE. This document provides guidance on how other
protocols can make use of ICE.
Rosenberg Expires January 15, 2009 [Page 1]
Internet-Draft ICE for non-SIP Protocols July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Can My Protocol Use ICE? . . . . . . . . . . . . . . . . . . . 3
3. Target Architecture . . . . . . . . . . . . . . . . . . . . . 5
4. General Considerations . . . . . . . . . . . . . . . . . . . . 7
4.1. Lite Implementation . . . . . . . . . . . . . . . . . . . 7
4.2. Multiple Components . . . . . . . . . . . . . . . . . . . 7
4.3. Multiple Media Streams . . . . . . . . . . . . . . . . . . 7
5. ICE Functions . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Gathering of Candidates . . . . . . . . . . . . . . . . . 8
5.1.1. Candidate types . . . . . . . . . . . . . . . . . . . 8
5.1.2. Pacing . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3. Number and Discovery of Servers . . . . . . . . . . . 9
5.1.4. Other Protocols . . . . . . . . . . . . . . . . . . . 10
5.1.5. Prioritization . . . . . . . . . . . . . . . . . . . . 10
5.1.6. Default Candidates . . . . . . . . . . . . . . . . . . 10
5.2. Initial Exchange of Candidates . . . . . . . . . . . . . . 11
5.2.1. ICE Mismatch . . . . . . . . . . . . . . . . . . . . . 12
5.2.2. Parameter Encoding . . . . . . . . . . . . . . . . . . 12
5.2.3. Role Determination . . . . . . . . . . . . . . . . . . 13
5.3. Connectivity Checks . . . . . . . . . . . . . . . . . . . 13
5.3.1. Scheduling Checks . . . . . . . . . . . . . . . . . . 14
5.4. Conclusion of ICE . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Regular vs. Aggressive Nomination . . . . . . . . . . 14
5.4.2. Updated Signaling and Remote Candidates . . . . . . . 14
5.5. Subsequent Signaling . . . . . . . . . . . . . . . . . . . 15
5.6. Media and Keepalives . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Rosenberg Expires January 15, 2009 [Page 2]
Internet-Draft ICE for non-SIP Protocols July 2008
1. Introduction
Interactive Connectivity Establishment (ICE) [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 [RFC3264], which exchanges
Session Description Protocol (SDP) [RFC4566] objects to negotiate
media sessions.
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) [RFC3261]
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)
[I-D.bryan-p2psip-reload], Host Identity Protocol (HIP)
[I-D.manyfolks-hip-sturn] and Mobile IP v6 [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.
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 need to define how to utilize ICE for their specific
needs. This document provides guidelines for authors of such
specifications. It includes guidance on when ICE can be used by a
protocol, describes each of ICE's major functions and how they can be
applied.
This document assumes the reader is familiar with ICE and its
operation.
2. Can My Protocol Use ICE?
Not all protocols can make use of ICE. ICE 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
Rosenberg Expires January 15, 2009 [Page 3]
Internet-Draft ICE for non-SIP Protocols July 2008
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 Figure 1.
+--------------+
| |
| |
> | Rendezvous | \
/ | Service | \
/ | | \
/ | | \
/ | | \
/ +--------------+ \
/ \
/ Connect \
/ To Y \
/ \
+--------+ +--------+
| | | |
| | | |
| Host | ......................... | Host |
| ID:X | | ID:Y |
| | | |
+--------+ +--------+
Figure 1: Session Protocols
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.
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 SIP REGISTER method. Connections are established using the
INVITE method.
For a protocol to use ICE, it must exhibit the properties of a
session protocol as described above. Furthermore, it must provide a
mechanism for exchanging information between the hosts for purposes
of establishing the connection. It must provide for, at least, one
Rosenberg Expires January 15, 2009 [Page 4]
Internet-Draft ICE for non-SIP Protocols July 2008
message from the initiator to the other host, and one message back.
If all of these criteria are met, ICE can be used.
3. Target Architecture
The goal of the recommendations in this document is to enable an
architecture for firewall and NAT traversal across many protocols
that has two properties:
1. STUN and TURN servers can be used to support multiple
applications
2. Gateways can easily be built between ICE-using protocols that are
compatible
The second of these requires further discussion. In some cases, two
different protocols are ones that provide similar functions, so that
it is reasonable to build gateways between them. For example,
gateways between SIP and H.323, or between SIP and RTSP, are
reasonable things to do. A gateway function between two session
protocols needs to concern itself with converting the signaling and
converting the media protocol - whether it be RTP or something else.
It is highly desirable to avoid actual conversion operations along
the direct media path. These greatly increase the cost and
complexity of gateway functions. Consequently, the ideal
architecture looks like this:
Rosenberg Expires January 15, 2009 [Page 5]
Internet-Draft ICE for non-SIP Protocols July 2008
+---------+
| STUN/ |
STUN/TURN | TURN | STUN/TURN
**************************| Servers |****************************
* | | *
* +---------+ *
* *
* *
* *
* *
* *
* +------------+ +------------+ *
* | Signaling | +-------+ | Signaling | *
* | Server | A | | B | Server | *
* | |<------->| GW |<-------->| | *
* | Protocol A | | | | Protocol B | *
* | | +-------+ | | *
* +------------+ +------------+ *
* | | *
* | | *
* | | *
* | | *
* | | *
* | | *
* | | *
* | media + | *
* checks *
* ///----\\\ ///----\\\ *
**** || Client 1 || .......................... || Client 1 ||****
\\\----/// \\\----///
Figure 2: Ideal Multi Protocol ICE Architecture
In this architecture, clients of two different protocols (A and B)
make use of signaling servers for their respective protocols. There
is a gateway function between them, but this function ONLY concerns
itself with the signaling. The content of the established sessions -
which includes the media and the path-based connectivity checks that
ICE uses - do not require any protocol conversion.
Of course, implementations can choose to gateway the media and checks
if they want, but it is a strong objective of the recommendations
here that they don't HAVE TO.
The architecture also shows that the goal is to have a common set of
TURN and STUN functions that serve all applications using ICE.
Rosenberg Expires January 15, 2009 [Page 6]
Internet-Draft ICE for non-SIP Protocols July 2008
4. General Considerations
There are some general considerations for the using protocol.
4.1. Lite Implementation
The lite mode of operation for ICE allows for usage by agents which
are always reachable by any other agent, both now and in the future.
The using protocol needs to decide whether this mode of operation is
supported or not. If not, all agents will be full implementations.
If the mode is supported, agents can either be lite or full.
The principal consideration is the likelihood of agents being always
publicly reachable, vs. the cost of an ICE implementation. ICE
itself provides strong caution against the lite mode of
implementation. It is very easy for protocol designers to envision
specific scenarios for deployment of their protocol, and then for the
reality to be different. Furthermore, the full mode provides
important security benefits. It ensures that an ICE implementation
cannot be used to launch DoS attacks. Consequently, that same
guidance is given here: using protocols should only use ICE's lite
mode if there is a belief that implementors absolutely will not
implement the full mode, and that those implementations will always
be publicly reachable by every other agent for the lifetime of
deployment of that implementation, and that the security benefits of
full mode are not worth the implementation complexity.
4.2. Multiple Components
ICE introduces the concept of multiple components for a single media
stream. ICE attempts to provide atomic processing across components,
such that a set of candidates (one for each component) are only used
if all of them succeeded. This grouping is useful when it is
desirable for path characteristics to be identical across multiple IP
addresses and ports that make up a connection of some sort.
Using protocols should indicate whether this functionality is needed
or not. If not, the procedures defined for ICE are used as is, but
the implementation for the using protocol just assumes there is
always a single component per stream.
4.3. Multiple Media Streams
ICE allows for multiple media streams. ICE largely runs
independently for each stream, with a few important exceptions.
First, ICE will perform pacing across all of the streams, thus
providing aggregate congestion control. Secondly, ICE will utilize
results from one stream to speed up the results of candidate
Rosenberg Expires January 15, 2009 [Page 7]
Internet-Draft ICE for non-SIP Protocols July 2008
gathering for another stream.
Using protocols should decide whether the concept of multiple streams
applies or not. If it does, the using protocol can elect to run ICE
on each stream completely independently (in which case its
effectively a separate offer/answer exchange and ICE state machine
for each stream), or together. The primary consideration, as noted
above, is whether aggregate congestion control and rapid convergence
are desired. This document recommends that, if a using protocol has
multiple streams, it runs ICE jointly across them, as defined by the
ICE specification (in other words, there is one instance of the ICE
state machine, not one for each media stream).
5. ICE Functions
ICE processing can be broken six distinct steps:
1. Gathering of candidates
2. Initial exchange of candidates
3. Connectivity checks
4. Conclusion of ICE
5. Subsequent signaling
6. Media and Keepalives
Each of these steps requires consideration by the designer of the
protocol that intends to use ICE (called the using protocol).
5.1. Gathering of Candidates
This phase of operation involves the gathering of candidates by the
agent. Any using protocol will need to perform this step. The
specification for the using protocol should point to Section 4.1 of
ICE, and dictate that the procedures there be followed. However,
there are several aspects of the gathering operation which are
subject to considerations by the using protocol, and the using
protocol should provide additional guidance on whether any of these
behaviors change or not.
5.1.1. Candidate types
ICE allows an agent, as a matter of policy, to gather candidates of a
particular type - host, server reflexive, and relayed. Consequently,
Rosenberg Expires January 15, 2009 [Page 8]
Internet-Draft ICE for non-SIP Protocols July 2008
a using protocol needs to define whether its agents will support all
three, or just a subset. ICE recommends strongly that all three
types be gathered and supported. This is because reliability of
connection establishment cannot be provided unless all three
mechanisms are implemented. Using protocols should only utilize a
subset if their deployment topologies are limited to cases where one
of the agents will always be behind NATs with endpoint independent
mapping properties.
5.1.2. Pacing
ICE defines a pacing algorithm for rate limiting the traffic it
generates during the gathering phase. When used in conjunction with
the parameter computations in Section 16.2, those algorithms are
applicable to any protocol. However, they may be overly conservative
for certain applications. Consequently, using protocols can define
alternative mechanisms for pacing ICE.
However, using protocols should be aware that there are two issues
that drove the design of the pacing. One of them is network
congestion control. The using protocol has to ensure that its pacing
remains TCP friendly whenever possible. The second issue is NAT
overload. Testing of NAT devices at the time of writing showed that
some of them went into an 'overload' mode when too many mappings were
created within a short interval of time. Keeping the creation of new
mappings to a rate less than one every 50ms seemed to address this
problem. Using protocols should follow a similar design goal.
5.1.3. Number and Discovery of Servers
ICE only defines operations for a single STUN server
[I-D.ietf-behave-rfc3489bis], or for a single TURN server
[I-D.ietf-behave-turn]. It does not consider cases where there are
multiple STUN and/or multiple TURN servers used by the agent.
However, this is an omission for the sake of simplicity. If a using
protocol has a need to highly optimize the connection paths in multi-
layer natting environments, multiple STUN servers - ideally one
behind each NAT - can provide an optimal path. A using protocol can
elect to specify that multiple STUN servers be used in these cases.
Of course, the using protocol will need to specify how a client
discovers or is configured with those additional STUN servers. The
usage of multiple STUN servers affects pacing; the overall rate of
candidate gathering across all servers needs to be congestion
controlled and stay below the rate of a new allocation every 50ms.
Rosenberg Expires January 15, 2009 [Page 9]
Internet-Draft ICE for non-SIP Protocols July 2008
5.1.4. Other Protocols
It is possible that the using protocol can define or utilize other
mechanisms for gathering candidates. For example, a mechanism may be
built into the rendezvous protocol itself. Indeed, this is the
primary reason for using something besides STUN and TURN. If a using
protocol is not building such functionality into the rendezvous
server itself, it is highly recommended that it reuse the STUN and
TURN protocols.
The primary reason for this is that it allows a domain to deploy STUN
and TURN servers just once, and then reuse them for multiple
protocols that require NAT traversal functionality. This reuse is
highly desirable, and would likely outweigh any minor protocol
improvements that could come from 'rolling your own' mechanism for
gathering candidates. This is why an exception is called out for
building the gathering protocol into the rendezvous server itself;
that server needs to be deployed anyway.
However, there are pitfalls to building a candidate gathering
mechanism into the rendezvous protocol and server. In particular,
obtaining relayed candidates from a rendezvous protocol can be
problematic. TURN servers are ideally deployed throughout the
network, in points that are topologically close to clients. Since
the whole purpose of ICE is to allow two clients to connect directly
to each other without sending data through the rendezvous server,
building TURN-like functionality into the rendezvous server defeats
much of the purpose of ICE itself. Such a move only makes sense if
it is believed that, for the using protocol, the likelihood of usage
of relayed candidates is particularly low.
5.1.5. Prioritization
ICE allows the prioritization of candidates to be a matter of local
policy. Using protocols may define their own policy for how
candidates are prioritized. However, protocols absolutely must
utilize the same range of priority values (0 to 2^32 - 1), and must
use the concepts of foundations and bases, along with the procedures
for eliminating redundant candidates. Utilizing those ensures that
ICE can be interoperated easily between different using protocols
with only a gateway function on the signaling, not the media.
5.1.6. Default Candidates
The concept of default candidates is primarily to support backwards
compatibility, and may not be required for a using protocol.
Firstly, if a using protocol is being defined for the first time, and
ICE is being used as a mandatory-to-implement part of the protocol,
Rosenberg Expires January 15, 2009 [Page 10]
Internet-Draft ICE for non-SIP Protocols July 2008
then clearly there are no backwards compatibility issues, and the
default candidate mechanism is not needed.
Even in cases where there are older, non-ICE implementations, there
are several basic mechanisms that can be used to deal with it:
Capability Query: An ICE-compliant agent can query the target agent,
prior to an ICE exchange, to determine if they support ICE. If
they do, the agent proceeds with the ICE exchange, otherwise, they
do not. If a using protocol utilizes this basic technique, the
default candidate mechanism is not needed.
Fail-and-Retry: An ICE-compliant agent sends an initial message with
ICE parameters, along with some kind of flag which tells the
recipient to reject the message if it doesn't support ICE. If
such a rejection is received, the agent retries without ICE. If a
using protocol utilizes this technique, the default candidate
mechanism is not needed.
Fallback: An ICE-compliant agent sends an initial message with ICE
parameters, but they are encoded in such a way that they will be
ignored by a non-ICE implementation. If a non-ICE implementation
receives them, it sends back an answer without ICE, and the
offerer notices this and proceeds without ICE. This technique
requires the default candidate mechanism defined by ICE.
Of these three approaches, the first two require potentially two
round trips to setup a session, whereas the third can do it in a
single round trip regardless of the capabilities of the other agent.
When latency for establishment is an important concern, the fallback
approach is preferable.
5.2. Initial Exchange of Candidates
ICE specifies the usage of the offer/answer protocol and the Session
Description Protocol for exchanging ICE parameters. This mechanism
is clearly ICE specific, and the using protocol should define
something appropriate. However, in all cases, the protocol exchange
has to allow for a two-phase exchange where one side offers ICE
information to the other, and the other offers ICE information back
in response. Though it is possible for protocols to utilize
mechanism other than a two-phase exchange, this is not recommended,
since it significantly complicates the construction of gateways
between protocols that utilize ICE.
Rosenberg Expires January 15, 2009 [Page 11]
Internet-Draft ICE for non-SIP Protocols July 2008
5.2.1. ICE Mismatch
The ICE mismatch feature is very specific to SIP. It is a
consequence of the existence of intermediaries which routinely modify
the media destination in the SDP, but are not ICE aware and will just
ignore (and pass on) any ICE attributes that are present. The ICE
mismatch mechanism detects these cases and falls back to non-ICE
operation.
A using protocol should only utilize this mechanism if it happens to
have similar deployment constraints.
5.2.2. Parameter Encoding
The syntax for the messages is entirely a matter of convenience for
the using protocol. However, the following parameters and their data
types needs to be conveyed in the initial exchange:
Candidate attribute There will be one or more of these for each
"media stream". Each candidate is composed of:
Foundation: A sequence of up to 32 characters.
Component-ID: This would be present only if the using protocol
were utilizing the concept of components. If it is, it would
be a positive integer that indicates the component ID for which
this is a candidate.
Transport: An indicator of the transport protocol for this
candidate. This need not be present if the using protocol will
only ever run over a single transport protocol. If it runs
over more than one, or if others are anticipated to be used in
the future, this should be present.
Priority: An encoding of the 32 bit priority value.
Candidate Type: The candidate type, as defined in ICE.
Related Address and Port: The related IP address and port for
this candidate, as defined by ICE.
Extensibility Parameters: The using protocol should define some
means for adding new per-candidate ICE parameters in the
future.
Rosenberg Expires January 15, 2009 [Page 12]
Internet-Draft ICE for non-SIP Protocols July 2008
Lite Flag: If ICE lite is used by the using protocol, it needs to
convey a boolean parameter which indicates whether the
implementation is lite or not.
Ufrag and Password: The using protocol has to convey a username
fragment and password. It must allow up to 256 characters for the
ufrag and 256 for the password.
ICE extensions: In addition to the per-candidate extensions above,
the using protocol should allow for new media-stream or session-
level attributes.
If the using protocol is using the ICE mismatch feature, a way is
needed to convey this parameter in answers. If is a boolean flag.
The exchange of parameters is symmetric; both agents need to send the
same set of attributes as defined above.
The using protocol may (or may not) need to deal with backwards
compatibility with older implementations that do not support ICE. If
the fallback mechanism is being used, then presumably the using
protocol already provides a way of conveying the default candidate
(its IP address and port) in addition to the ICE parameters.
5.2.3. Role Determination
The role determination mechanism must be used by the using protocol.
However, the conflict resolution algorithm in Section 5.2 of ICE is
almost entirely an artifact of the fact that SIP separates its
signaling exchange from the offer/answer exchange. In using
protocols that lack this separation, the conflict resolution
algorithm itself will never get used.
5.3. Connectivity Checks
The core of the ICE algorithm is the connectivity checks. After both
sides have gathered candidates and have exchanged them with each
other, the check process begins. Here, it is very important that the
using protocol simply follow the mechanisms already defined by ICE.
Implementations should directly utilize the functionality defined in
Section 5.7 to compute pairs and priorities, prune, form the check
lists, and compute states. If a using protocol has elected not to
use the concepts of multiple components or multiple streams, these
algorithms simplify. However, the using protocol must not specify a
different algorithm; it can only reuse what is there and constrain
its behavior by mandating constrained inputs (only one component, or
only one media stream).
Rosenberg Expires January 15, 2009 [Page 13]
Internet-Draft ICE for non-SIP Protocols July 2008
The actual connectivity checks themselves must also be performed
exactly as defined in Section 7 of ICE. The using protocol should
just reference that section directly. Note that, even if a using
protocol does not need to use the role conflict detection mechanism,
it must include the ICE-CONTOLLED and ICE-CONTROLLING attributes in
its connectivity checks as described in Section 7 of ICE. This
ensures that it is possible to easily build gateways between
different protocols using ICE.
5.3.1. Scheduling Checks
The primary area where using protocols can alter the behavior defined
in ICE is in the area of pacing. The using protocol can define
different mechanisms for computing Ta and RTO, and may even define a
different mechanism entirely for interleaving scheduled and triggered
checks.
As with the pacing of candidate gathering, the pacing of connectivity
checks needs to take congestion control and NAT overload into
consideration.
5.4. Conclusion of ICE
The procedures for concluding ICE as defined in Section 8 should be
used as defined for the using protocol, with only a few areas of
flexibility.
5.4.1. Regular vs. Aggressive Nomination
The primary area of flexibility is around regular vs. aggressive
nomination. A using protocol can mandate that all implementations
use one or the other or allow for both. The considerations for this
choice are identical for the using protocol as they are for ICE in
general. Aggressive nomination is faster but can introduce glitches;
regular nomination is slower but is more stable. Regular nomination
is recommended if at all possible.
5.4.2. Updated Signaling and Remote Candidates
ICE defines conditions on which an updated offer is required to be
sent after ICE concludes - namely, if the candidates selected by ICE
are not a match for the default candidates, an updated exchange is
sent.
This function of ICE is primarily an artifact of the realities of SIP
deployments. It is not at all needed for correctness of ICE
operation. In the case of SIP, signaling intermediaries that are
inspecting the offer/answer exchanges, but are not ICE aware, will be
Rosenberg Expires January 15, 2009 [Page 14]
Internet-Draft ICE for non-SIP Protocols July 2008
confused unless there is an updated exchange. This same
consideration applies to using protocols. If the using protocol has
deployments with intermediaries that inspect messages, and will be
confused if the actual connections/media are established to something
different than any defaults that were signaled, the updated exchange
should be used. If not, it can be avoided.
If it is used, the remote-candidates attribute has to be conveyed in
the updated offer, and the agents need to implement the algorithms
described in Section 9 of ICE for setting the answer based on this
attribute. Furthermore, the signaling protocols require a way to
encode it.
5.5. Subsequent Signaling
ICE defines procedures for performing subequent offer/answer
exchanges that have an affect of updating the state of ICE. Support
for subsequent exchanges is needed if the using protocol requires any
of the following capabilities:
o The ability to add a new candidate to a set while ICE is already
in progress, without abandoning the progress so far.
o The ability to add a new media stream, or remove a new media
stream, without redoing ICE processing for all of the media
streams.
o The ability to change the IP address or port for a media stream,
but to do so with a "make before break" property - so that the new
destination begins to be used only once checks for the new
destination have completed.
If any of these properties are important, ICE's capabilites for
subsequent signaling should be utilized.
One use case where these functions are not needed is when the using
protocol fundamentally doesn't allow any kind of updating of
connection addresses. If it requires the previous connection to be
closed, and a new one to be opened starting from scratch, ICE's
subsequent signaling feature is not needed.
If subsequent signaling is used, ICE restarts must be supported.
5.6. Media and Keepalives
The keepalive procedures in Section 10 must be used as defined. The
media handling rules in Section 11 apply as well, with the exception
of the RTP-specific guidelines.
Rosenberg Expires January 15, 2009 [Page 15]
Internet-Draft ICE for non-SIP Protocols July 2008
6. Security Considerations
Several ICE features exist to provide security, including the message
integrity mechanism. Using protocols must use these in the same way
ICE does.
The guidelines defined here do allow a using protocol to support the
ICE lite mode of operation. The lite mode is less secure than full
mode, as it allows an implementation to be used as a source of DoS
traffic. For this reason, using protocols must address, in their
security considerations, why they have elected to allow the lite
implementation in cases where it is being supported.
7. IANA Considerations
There are no IANA considerations associated with this specification.
8. Informative References
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3261] 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.
[I-D.bryan-p2psip-reload]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery
(RELOAD)", draft-bryan-p2psip-reload-04 (work in
progress), June 2008.
[I-D.manyfolks-hip-sturn]
Nikander, P., Melen, J., Komu, M., and M. Bagnulo,
"Mapping STUN and TURN messages on HIP",
Rosenberg Expires January 15, 2009 [Page 16]
Internet-Draft ICE for non-SIP Protocols July 2008
draft-manyfolks-hip-sturn-01 (work in progress),
November 2007.
[I-D.tschofenig-mip6-ice]
Tschofenig, H., "Mobile IP Interactive Connectivity
Establishment (M-ICE)", draft-tschofenig-mip6-ice-02 (work
in progress), February 2008.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-16 (work in progress),
July 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-08 (work in progress), June 2008.
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires January 15, 2009 [Page 17]
Internet-Draft ICE for non-SIP Protocols July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Expires January 15, 2009 [Page 18]