Implementing Interactive Connectivity Establishment (ICE) in Lite Mode

Network Address Translation (NAT) devices are a major obstacle to protocols in which a pair of network elements need to form a direct connection. In many cases, such elements are able to talk to each other directly using a signalling protocol such as SIP but for efficiency reasons want to send data (e.g., media over RTP ) directly. A number of techniques are available for traversing NATs, but entities need a mechanism for discovering which technique will work in its specific environment (and its peer's environment). Interactive Connectivity Establishment (ICE) is such a technique. The basic principle behind ICE is that each entity collects all the addresses on which it might potentially be able to send and receive data. These may include its local address, addresses discovered via STUN or addresses provided by media relays . The peers then exchange these candidate addresses and try each potential pairing in priority order until they find one that is satisfactory. During the design of ICE, many implementors expressed concern about the complexity of the protocol and the difficulty of implementing it. This draft specifies a compatible simplified subset of ICE called "ICE Lite" which is suitable for implementations which will always be operated with public IP addresses. One particular environment where ICE Lite is intended to be useful is in SIP-PSTN gateways which are generally directly connected to the Internet.

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 .

A Lite Ice Implementation (LII) behaves much like a normal ICE implementation, with three major differences: It only gathers candidate addresses from its own interfaces. It cannot be a controlling endpoint. It does not generate checks but only responds to periodic checks from other endpoints. A LII can interoperate with a Full ICE Implementation (FII). there is a subtle point here; ICE is intended to establish bi-directional connectivity and the LII must have a way to know that its messages are getting through to the other endpoint. Ordinarily this would be done by having both sides perform checks but in order to optimize for simplicity of the LII, the LII does not do so. Rather, we use the fact that the FII receives the LII's STUN response as an implicit check. This requires that the LII receive some message from the peer that its message was received. This is accomplished by having the FII issue two checks. The first check omits the USE-CANDIDATE flag and so the LII will not attempt to use the candidate pair. The second check includes the USE-CANDIDATE flag and so tells the LII that the pair is safe to use. The interaction of an LII and an FII is shown below.

\ <- SDP Answer > First offer/answer + lite flag / STUN request -> \ Periodic <- STUN response / Check STUN request -> \ Candidate + USE-CANDIDATE flag > Selection <- STUN response / ]]> As with any ICE implementation, the first thing that happens is that the peers exchange SDP offer and answer. The LII attaches the a=ice-lite attribute to indicate that it does ICE Lite. This has two implications for the peer: It must be the controlling endpoint. It must not send the USE-CANDIDATE flag the first time it performs any check. As indicated above, the LII does not perform any checks. Thus, they must all be driven by the FII. The FII follows its usual behavior of creating the check list and starts performing checks. It sends all of its checks without the USE-CANDIDATE flag and only once it has a successful check on a candidate that it was willing to use does it send a second check on that candidate pair with the USE-CANDIDATE flag. Two LIIs will interoperate but will not do ICE.

This document is intended to mostly relieve the implementor of a Lite ICE implementation from the burden of having to read and understand all of RFC XXXX [[Insert ICE RFC # here] . However, it is not intended to be a standalone document. Rather it is intended to be read in conjunction with RFC XXXX. We assume that the reader is roughly familiar with how ICE works and has read at least Sections 1-3 of RFC XXXX. Section , contains a description of the responsibilities of a Lite Ice Implementation (LII). Each section follows the same pattern: expository text followed by a pointer to the relevant section of RFC XXXX.

A LII performs the following tasks: Gathering candidates. Sending an SDP offer/answer Processing the peer's offer/answer Responding to checks from peer endpoints. Determining that candidate pairs are valid and/or favored

Like any ICE implementation, a LII gathers candidates. However, unlike full ICE implementations, a LII gathers them only from its locally attached interfaces (host candidates). Other kinds of candidates are not necessary because a LII by definition has a public IP address. A LII may offer only one candidate per component. Note that this process is the same as what a non-ICE implementation does, namely allocating ports from the local interface. See: Sections 2.1 (paragraphs 1,2), 4.1 (paragraphs 1-4), 4.2 /

As with full-mode ICE, the candidates must be prioritized, using the algorithm defined in RFC XXX S 4.1.2. However, a LII will only have one candidate type: host. The type preference SHOULD be set to 126. The endpoint SHOULD set the local preference to 65535. The component IDs are set as in RFC XXXX. For RTP this means component ID 1 and RTCP component ID 2. Using these settings, an endpoint which wished to do RTP only would have a single candidate with priority 2130706431 (0x7effffff). An endpoint which to do both RTP and RTCP would have priotities 2130706431 (0x7effffff) for RTP and 2130706430 (0x7efffffe) for RTCP. See: Section 4.1.2

Once the candidates are gathered, a LII must encode them in an SDP offer or answer. Each candidate contains the IP address and port of the candidate and the priority computed in the previous sectoin. There will be one candidate for each component. All candidates MUST be marked as host candidates. In addition, a LII must set the "a=ice-lite" session-level attribute in order to indicate that it is not a full ICE implementation. See: Sections 4.3

When an LII receives an SDP offer or answer from a peer, it MUST first verify that the peer did not offer the "a=ice-lite" attribute. If it did, ICE processing MUST be terminated. Although an LII does not maintain a check list, when it receives an offer or answer it needs to extract all the ufrag/upass values from the SDP in order to use them to verify the STUN integrity checks. It also must identify the set of all media streams and components for which ICE must be established. See: Section 5.1.

During ICE discovery, a LII will receive Binding Requests on the bases of some or all of the candidates it included in its most recent offer or answer. When such a Binding Request is received, the LII MUST: Generate a STUN binding response. If the request contains the USE-CANDIDATE flag, create a new candidate pair corresponding to the addresses in the STUN request, add it to the Valid list and mark it "favored". As with ordinary ICE, the LII must combine its ufrag with the peers ufrag and use the correct password (from the SDP) to integrity check the STUN request. Once the request has been integrity checked, the LII generates a STUN response containing the transport-level source address in the XOR-MAPPED-ADDRESS field. Media may be sent on a candidate pair as soon as it is added to the Valid list. Once there is at least one entry on the Valid list for each component of each media stream, ICE processing is finished. See: Sections 7.2, 7.2.2, Section 8.

Like all ICE implementations, all LIIs must send keepalives on active candidate pairs and be prepared to receive keepalives. See: Section 11.

The security considerations for this document are the same as those for full ICE.

This document has no actions for IANA.