MMUSIC J. Rosenberg Internet-Draft Cisco Systems Expires: December 28, 2006 June 26, 2006 Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols draft-ietf-mmusic-ice-09 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 December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a protocol for Network Address Translator (NAT) traversal for multimedia session signaling protocols based on the offer/answer model, such as the Session Initiation Protocol (SIP). This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Simple Traversal of UDP through NAT (STUN), applying its binding discovery, connectivity check and relay usages. Rosenberg Expires December 28, 2006 [Page 1] Internet-Draft ICE June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 18 5. Receipt of the Offer and Generation of the Answer . . . . . . 19 6. Processing the Answer . . . . . . . . . . . . . . . . . . . . 19 7. Common Procedures . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Gathering Candidates . . . . . . . . . . . . . . . . . . 20 7.2. Prioritizing the Candidates and Choosing an Operating One . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Encoding Candidates into SDP . . . . . . . . . . . . . . 27 7.4. Forming Candidate Pairs . . . . . . . . . . . . . . . . . 31 7.5. Ordering the Candidate Pairs . . . . . . . . . . . . . . 33 7.6. Performing the Connectivity Checks . . . . . . . . . . . 36 7.7. Sending a Binding Request for Connectivity Checks . . . . 42 7.8. Receiving a Binding Request for Connectivity Checks . . . 44 7.9. Promoting a Candidate to Operating . . . . . . . . . . . 46 7.10. Learning New Candidates from Connectivity Checks . . . . 47 7.10.1. On Receipt of a Binding Request . . . . . . . . . . 47 7.10.2. On Receipt of a Binding Response . . . . . . . . . . 51 7.11. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 53 7.11.1. Sending of a Subsequent Offer . . . . . . . . . . . 53 7.11.2. Receiving the Offer and Sending an Answer . . . . . 56 7.11.3. Receiving the Answer . . . . . . . . . . . . . . . . 59 7.12. Binding Keepalives . . . . . . . . . . . . . . . . . . . 59 7.13. Sending Media . . . . . . . . . . . . . . . . . . . . . . 61 7.14. Receiving Media . . . . . . . . . . . . . . . . . . . . . 63 8. Guidelines for Usage with SIP . . . . . . . . . . . . . . . . 64 9. Interactions with Forking . . . . . . . . . . . . . . . . . . 66 10. Interactions with Preconditions . . . . . . . . . . . . . . . 67 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 67 11.1. Basic Example . . . . . . . . . . . . . . . . . . . . . . 68 11.2. Advanced Example . . . . . . . . . . . . . . . . . . . . 72 12. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 13. Security Considerations . . . . . . . . . . . . . . . . . . . 95 13.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 95 13.2. Attacks on Address Gathering . . . . . . . . . . . . . . 98 13.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 99 13.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 99 13.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . 99 13.4.2. STUN Amplification Attack . . . . . . . . . . . . . 99 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 100 14.1. candidate Attribute . . . . . . . . . . . . . . . . . . . 100 14.2. remote-candidate Attribute . . . . . . . . . . . . . . . 100 14.3. ice-pwd Attribute . . . . . . . . . . . . . . . . . . . . 101 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 101 Rosenberg Expires December 28, 2006 [Page 2] Internet-Draft ICE June 2006 15.1. Problem Definition . . . . . . . . . . . . . . . . . . . 102 15.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 102 15.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 103 15.4. Requirements for a Long Term Solution . . . . . . . . . . 104 15.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 104 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 17.1. Normative References . . . . . . . . . . . . . . . . . . 105 17.2. Informative References . . . . . . . . . . . . . . . . . 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 108 Intellectual Property and Copyright Statements . . . . . . . . . 109 Rosenberg Expires December 28, 2006 [Page 3] Internet-Draft ICE June 2006 1. Introduction RFC 3264 [4] defines a two-phase exchange of Session Description Protocol (SDP) messages [5] for the purposes of establishment of multimedia sessions. This offer/answer mechanism is used by protocols such as the Session Initiation Protocol (SIP) [2]. Protocols using offer/answer are difficult to operate through Network Address Translators (NAT). Because their purpose is to establish a flow of media packets, they tend to carry IP addresses within their messages, which is known to be problematic through NAT [15]. The protocols also seek to create a media flow directly between participants, so that there is no application layer intermediary between them. This is done to reduce media latency, decrease packet loss, and reduce the operational costs of deploying the application. However, this is difficult to accomplish through 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 [17], Simple Traversal of UDP through NAT (STUN) [14] and its revision [12], the STUN Relay Usage [13], and Realm Specific IP [18] [19] along with session description extensions needed to make them work, such as the Session Description Protocol (SDP) [5] attribute for the Real Time Control Protocol (RTCP) [1]. 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 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 for media streams established by signaling protocols based on the offer-answer model. It is called Interactive Connectivity Establishment, or ICE. ICE makes use of STUN and its relay extension, commonly called TURN, but uses them in a specific methodology which avoids many of the pitfalls of using any one alone. 2. Overview of ICE A typical architecture for an ICE deployment is shown in Figure 1. The figure shows two endpoints (known as agents in RFC 3264 terminology) which we call L and R (for left and right, which helps visualize call flows). Both L and R are behind a NAT. The type of Rosenberg Expires December 28, 2006 [Page 4] Internet-Draft ICE June 2006 NAT and its properties are unknown. Indeed, it is not known whether the agent is behind a NAT at all, or whether there are multiple NATs between it and the network. Agents A and B are capable of engaging in an offer/answer exchange [4] by which they can exchange SDP messages, whose purpose is to set up a media session between A and B. Of course, the offer/answer exchange itself must be capable of traversing the NAT. Such traversal is facilitated through signaling elements such as SIP servers, and is outside the scope of this specification. Different solutions are applied for traversal of the signaling that carries the offer/answer exchange, and for the media set up by that offer/answer exchange. This is because of the vastly different requirements on latency, packet loss, and overall bandwidth between the signaling and media. For example, usage of a signaling intermediary, such as a SIP proxy, as a relay for all signaling at all times, is acceptable, whereas usage of relays at all times for media is highly undesirable. In addition to the agents, a SIP server and NATs, ICE is typically used in concert with STUN servers in the network. Each agent can have its own STUN server, or they can be the same. +-------+ | SIP | +-------+ | Srvr | +-------+ | STUN | | | | STUN | | Srvr | +-------+ | Srvr | | | | | +-------+ +-------+ +--------+ +--------+ | NAT | | NAT | +--------+ +--------+ +-------+ +-------+ | Agent | | Agent | | L | | R | | | | | +-------+ +-------+ Rosenberg Expires December 28, 2006 [Page 5] Internet-Draft ICE June 2006 Figure 1 Prior to initiating an offer, the offering agent (L in this example) starts by performing a process known as address gathering. This process allows the client to obtain one or more transport addresses, one more of which might be viable addresses at which the agent can receive incoming media packets from the other agent, which we call its peer. A transport address is just the combination of an IP address and port. With ICE, an agent will actually provide its peer with all of its possible transport addresses, and ICE will figure out which one to actually use. Naturally, one viable transport address is one obtained directly from a local interface the client has towards the network. Such a transport address is called a local transport address. The local interface could be one on a local layer 2 network technology, such as ethernet or WiFi, or it could be one that is obtained through a tunnel mechanism, such as a Virtual Private Network (VPN) or Mobile IP (MIP). In all cases, these appear to the agent as a local interface from which ports (and thus transport addresses) can be allocated. If an agent is multihomed, it can obtain a transport address from each interface. Depending on the location of the peer on the IP network, the agent may be reachable through one of those interfaces, or through another. Consider, for example, an agent which has a local interface to a private net 10 network, and also to the public Internet. A transport address from the net10 interface will be directly reachable when communicating with a peer on the same private net 10 network, while a transport address from the public interface will be directly reachable when communicating with a peer on the public Internet. Rather than trying to guess which interface will work prior to sending an offer, the offering agent includes both transport addresses in its offer. Indeed, when using a media technology like the Real Time Transport Protocol (RTP), an agent needs two transport addresses on each interface - one for the RTP, and one for the Real Time Control Protocol (RTCP). Other media technologies may require a multiplicity of transport addresses to be used and treated as a bundle. Each of these transport addresses is called a component. There are two components in an RTP stream - the RTP itself, and the RTCP. In ICE, the set of transport addresses that represent an atomic grouping on which communications is possible is called a candidate. In the example so far, the agent would obtain two candidates - one from the net 10 interface, and one from the interface on the public Internet. Each candidate would contain two transport addresses, corresponding to each of the two components. Rosenberg Expires December 28, 2006 [Page 6] Internet-Draft ICE June 2006 Once the agent has obtained local transport addresses, it uses STUN to obtain additional transport addresses. To do this, it would send a STUN Binding Request, using the Binding Discovery Usage [12] or the Relay Usage [13] from a local transport address, to its STUN server. It is assumed that the address of the STUN server is configured, or learned in some way. Indeed, an agent might even have multiple STUN servers. As a consequence of communicating with the STUN server, the agent can learn potentially two new types of transport addresses - server reflexive transport addresses and relayed transport addresses. The relationship of these addresses to the local transport address is shown in Figure 2. To Internet | | | /------------ Relayed | / Address +--------+ | | | STUN | | Server | | | +--------+ | | | /------------ Server |/ Reflexive +------------+ Address | NAT | +------------+ | | /------------ Local |/ Address +--------+ | | | Agent | | | +--------+ Figure 2 The local transport address is resident on the agent itself. Through either the Binding Discovery Usage or the Relay Usage, the agent can discover its server reflexive transport address. This is the address on the public side of the NAT, facing the STUN server. It is the transport address allocated to the agent on the public side of the Rosenberg Expires December 28, 2006 [Page 7] Internet-Draft ICE June 2006 NAT as a consequence of the transmission of the STUN request through the NAT, to the STUN server. The NAT will allocate a binding, mapping this server reflexive transport address to the local transport address. Packets received at the NAT, targeted towards the server reflexive transport address, will have their destination address rewritten to the local transport address by the NAT, and then be forwarded to the agent. When there are multiple NATs between the agent and the STUN server, the STUN request will create a binding on each NAT, but only the outermost server reflexive transport address will be discovered by the agent. In addition, through the Relay Usage, the agent can request that the STUN server itself allocate a transport address from one of its local interfaces, and establish a binding that maps that transport address (called a relayed transport address, naturally) towards the source transport address of the STUN request, which will actually be equal to the server reflexive transport address allocated by the outermost NAT. Consequently, packets sent to the relayed transport address will be routed by the IP network towards the STUN server. The STUN server will receive them, rewrite the destination address to be equal to the server reflexive transport address, and forward them. They will then arrive at the NAT, where the destination address is rewritten once again, and the packet forward finally to the agent at its local address. Since the server reflexive transport addresses and relayed transport addresses and obtained from a local transport address, they are said to be derived transport addresses, since they are derived from (and ultimately map to) their associated local transport address. During the process of address gathering, the agent will obtain as many transport addresses of a given type as are needed for the media session. For example, with RTP, two transport addresses are needed for a candidate. The agent will obtain two server reflexive transport addresses (each derived from a local transport address), and they would be used to constitute a server reflexive candidate. The local transport addresses make up a local candidate, and the relayed transport addresses make up a relayed candidate. Rosenberg Expires December 28, 2006 [Page 8] Internet-Draft ICE June 2006 Server Server Reflexive Reflexive Candidate Candidate .............. .............. . . . . . +-+ +-+ . . +-+ +-+ . . | | | | . . | | | | . . +-+ +-+ . . +-+ +-+ . . ^ ^ . . ^ ^ . ....|....|.... ....|....|.... | | | | | | | | ....|....|.... ....|....|.... . | | . . | | . . +-+ +-+ . Local . +-+ +-+ . Local . | | | | . Candidate . | | | | . Candidate . +-+ +-+ . . +-+ +-+ . . | | . . | | . ....|....|.... ....|....|.... | | | | | | | | ....|....|.... ....|....|.... . V V . . V V . . +-+ +-+ . . +-+ +-+ . . | | | | . . | | | | . . +-+ +-+ . . +-+ +-+ . . . . . .............. .............. Relayed Relayed Candidate Candidate Legend ------ +-+ | | Transport Address +-+ ---> Derived From ... . . Candidate ... Figure 3 Rosenberg Expires December 28, 2006 [Page 9] Internet-Draft ICE June 2006 The relationship between these various transport addresses and candidates is shown pictorially in Figure 3. The figure shows our example agent with two local interfaces, each of which provides two transport address pairs to make up two candidates. From those two local candidates, a server reflexive and relayed candidate are derived. Once the agent has completed gathering its candidates, it assigns each a candidate identifier, called the candidate ID. The candidate ID is a random number used to uniquely identify each candidate, and is used in the connectivity checks discussed below. The components of each candidate are ordered numerically, starting at one, such that each transport address has a component ID. For example, in an RTP candidate there are two components, component ID 1 and component ID 2. Each transport address pair is therefore uniquely identified by a combination of its candidate ID and its component ID. The combination of the two is called, unsurprisingly, a transport address ID, or tid for short. The agent will place all of its candidates in an offer, using a new SDP attribute called the candidate attribute. This attribute contains the actual transport address, the candidate ID and component ID, and a q-value. The q-value is used for the agent to prioritize its candidates. An agent will typically prefer to receive media at particular candidates over other candidates, based on local policy. For example, an agent would normally prefer to receive interactive voice RTP packets at its local candidate as opposed to its relayed candidate, due to the extra latency incurred by traveling through the relay. The candidate attribute will also include an indicator of the type of candidate (server reflexive, local, relayed), and its related transport address. For server reflexive transport addresses, the related transport address is the local transport address from which it was derived. For relayed transport addresses, the related transport address is the server reflexive address towards the relay. The related transport address for reflexive candidates is used by the ICE algorithm itself, as explained below. For relayed candidates, the related transport address is not used by ICE directly; it is useful for diagnostic purposes and for Quality of Service mechanisms that require knowledge of addresses closer to the agent. Finally, the agent chooses one of its candidates for inclusion in the m and c lines (called the m/c-line collectively). Assuming that candidate is verified as functional by the ICE connectivity checks described below, this is the actual IP address and port to which media will be sent. The candidate selected for inclusion in the m/c- line of an offer (or an answer) is called the operating candidate, Rosenberg Expires December 28, 2006 [Page 10] Internet-Draft ICE June 2006 since it is the one that is the in-use destination for receipt of media traffic. Once the operating candidate is chosen, the agent sends the offer. Through the wonders or SIP or other signaling protocols, this offer is delivered to the peer, which must now select its answer. To create the answer, the agent starts by gathering addresses, in exactly the same way the offered did. It includes those as candidates in its answer, and selects one as the operating candidate, just like the offered did. It then sends the answer. Each agent then pairs up each of its candidates with the candidates of its peer. From the perspective of the offerer, the set of candidates it sent in its offer are called its native candidates, and the ones received in the answer are the remote candidates. Similarly, from the perspective of the answerer, the set of candidates it sent in its answer are the native candidates, and the ones received in the offer are the remote candidates. Both agents pair up each of their native candidates with each of the remote candidates, producing a set of candidate pairs. If there were N native candidates and M remote candidates, there will be N*M candidate pairs. Within each candidate pair, the transport addresses themselves are paired up one for one, resulting in transport address pairs as well. The transport addresses are paired up such that they have identical component IDs. Each transport address pair has an ID, called the transport address pair ID, formed by concatenating the transport address IDs of its two transport addresses. Once the pairing is done, the transport address pairs are ordered in such a way that both the offerer and answerer will end up with the same order. This ordering is done by using the q-values each side provided, along with the candidate IDs to help break ties. Then, each side begins a process known as connectivity checks. Connectivity checks are STUN transactions, using the connectivity check usage of STUN, sent from the native transport address to the remote transport address of a particular transport address pair. If an agent sends a STUN request and gets a successful response, the transport address pair is said to be Receive Valid, or Recv Valid for short, since the agent knows that its peer was able to receive a packet. If an agent receives a request and sends a response, the transport address pair is said to be Send Valid, since the agent knows that its peer was able to send it a packet. When transactions in both directions complete, the transport address pair is said to be Valid. The idea behind ICE is that if a transport address pair is valid, it means that agents were able to succesfully exchange IP packets in both directions. Consequently, any media packets, which are sent to and from exactly the same IP addresses and ports, should also work, since they don't differ in their IP addresses or ports. Rosenberg Expires December 28, 2006 [Page 11] Internet-Draft ICE June 2006 It's important to point out that, when used with ICE, an agent will always send and receive media on the same transport address. That is, if an agent includes a transport address of 192.0.2.1:2444 (meaning an IP address of 192.0.2.1 and port of 2444) in its SDP for receiving RTP packets (and also STUN connectivity check), it will not only receive STUN requests and RTP packets on this transport address, it will also send STUN requests and RTP packets from this transport address. This property, known as symmetric RTP, is essential for proper operation of ICE. Peer reflexive transport addresses, discussed further below, will generally only work when symmetric RTP is used. Symmetric RTP is also key for keeping NAT bindings alive. Since there can be quite a few transport address pairs to check, performing all of the connectivity checks in parallel can cause substantial load on the network. Instead, each agent will start at the top of the ordered list they each created, and every 50ms, begin a new connectivity check. In order to succesfully process a STUN connectivity check, an agent must be able to correlate the STUN request or response with the transport address pair whose connectivity the STUN message is meant to validate. To perform this correlation, the STUN connectivity checks contain a USERNAME attribute formed in a special way. In particular, the USERNAME contains the actual transport address pair ID, which, as described above, is formed by concatenating the transport address IDs of each of the candidates. The USERNAME is used in conjunction with an authentication and message integrity operation on the STUN message that requires a password. This password is conveyed in the offer/answer exchange, and is a random number valid only for the duration of the media session. This ensures that, if the signaling channel carrying the offer/answer exchange is secure, the agent can be certain that its STUN connectivity checks are taking place with the agent which responded to the signaling. Because each agent is receiving STUN requests on the same IP address and port that media will later be sent to, each agent is effectively acting as its own mini STUN server, implementing the connectivity check usage described in [12]. Like all STUN servers, when the agent sends a STUN response to a request, the response includes the XOR- MAPPED-ADDRESS attribute that contains the source IP address and port that the request came from. In certain deployment scenarios, and in particular where one of the agents is behind a NAT whose address and port mapping properties are address and port dependent [32], this source IP address and port may differ from the server reflexive ones allocated by the peer during the address gathering phase. This source IP address and port, conveyed in the XOR-MAPPED-ADDRESS attribute of the STUN response, therefore constitutes a new transport Rosenberg Expires December 28, 2006 [Page 12] Internet-Draft ICE June 2006 address, called a peer reflexive transport address, which can be used for communications. +-------+ | STUN | | Srvr | | | +-------+ ^ | | | | +--------------------------+ | | NAT-2| |NAT-1 | +-----------+ | | APD NAT | | +-----------+ | | | | \ | VL1 \|R1 +-------+ +-------+ | Agent | | Agent | | L | | R | | | | | +-------+ +-------+ Figure 4 Consider the example of Figure 4. The agent on the left, agent L, has a single interface and is not behind a NAT. Consequently, it ends up with a single candidate with a single transport address (normally two for RTP, but we'll consider just one for ease of explanation), transport address L1. It sends an offer to agent R, which is behind one of these Address and Port Dependent (APD) mapping NATs. Agent R has a local transport address R1, and obtains a server reflexive transport address from its STUN server, transport address NAT-1. Now, when agent R sends a connectivity check from its local transport address (R1) to L's local transport address (L1), this check will traverse the NAT. The connectivity check itself will create a new mapping in the NAT and be allocated a new binding on the NAT - NAT-2. This STUN request arrives at L, which generates a STUN response containing transport address NAT-2. Agent R, noticing that this is not the same as its other two transport addresses, treats this as a new peer reflexive transport address. This new peer reflexive transport address is paired up with the Rosenberg Expires December 28, 2006 [Page 13] Internet-Draft ICE June 2006 remote transport address containing the STUN server from which that transport address was learned (transport address L1 in the example above). This becomes a new transport address pair, and connectivity checks are run on it as well. Once all of the transport address pairs in a candidate pair have been validated, that candidate pair is ready to be used. Media starts being sent on it immediately, and the offerer will send an updated offer, now containing the agents half of the validated candidate pair in the m/c-line. This is called "promoting a candidate to operating". The updated offer only contains a single candidate attribute - the one for the operating candidate. It also contains an attribute, called the remote-candidate attribute, which tells the answerer the remote candidate in the validated candidate pair. The answerer uses this attribute, along with its own view on the states of the candidate pairs, to place a candidate in the m/c-line and populate the candidate attributes in its answer. It is important to understand that, when ICE is in use, media is not sent to a candidate without validation, even if that candidate appears in the m/c-line. This is in order to avoid denial-of-service attacks. In particular, without ICE, an offerer can send an offer to another agent, and list the IP address and port of a target in the offer. If the agent is an automata that answers a call automatically, it will do so and then proceed to send media to the target. This provides substantial packet amplifications. ICE fixes this by requiring that an agent never send media packets unless it has sent a STUN message towards the target of the RTP packets, and received a reply from that target. See Section 7.13 for details. A summary of this overall behavior is shown in the basic call flow in Figure 5. Rosenberg Expires December 28, 2006 [Page 14] Internet-Draft ICE June 2006 Agent A STUN Servers Agent B |(1) Gather Addresses | | |-------------------->| | |(2) Offer | | |------------------------------------------>| | |(3) Gather Addresses | | |<--------------------| |(4) Answer | | |<------------------------------------------| |(5) STUN Check | | |<------------------------------------------| |(6) STUN Check | | |------------------------------------------>| |(7) Media | | |<------------------------------------------| |(8) Media | | |------------------------------------------>| |(9) Offer | | |------------------------------------------>| |(10) Answer | | |<------------------------------------------| Figure 5 3. Terminology Several new terms are introduced in this specification: Agent: As defined in RFC 3264, an agent is the protocol implementation involved in the offer/answer exchange. There are two agents involved in an offer/answer exchange. Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the offerer, the peer is the answerer. From the perspective of the answerer, the peer is the offerer. Transport Address: The combination of an IP address and port. Local Transport Address: A local transport address is a transport address that has been allocated from the operating system on the host. This includes transport addresses obtained through Virtual Private Networks (VPNs) and transport addresses obtained through Realm Specific IP (RSIP) [18] (which lives at the operating system level). Transport addresses are typically obtained by binding to an interface. Rosenberg Expires December 28, 2006 [Page 15] Internet-Draft ICE June 2006 m/c line: The media and connection lines in the SDP, which together hold the transport address used for the receipt of media. Derived Transport Address: A derived transport address is a transport address which is obtained from a local transport address. The derived transport address is related to the associated local transport address in that packets sent to the derived transport address are received on the socket bound to its associated local transport address. Derived addresses are obtained using protocols like STUN, and more generally, any UNSAF protocol [20]. Reflexive Transport Address: As defined in [12], a derived transport address learned by a client which identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the binding allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the XOR-MAPPED-ADDRESS attribute in STUN Binding Responses and Allocate Responses [13]. Server Reflexive Transport Address: A server reflexive transport address is a reflexive address that is reflected off of a server, distinct from the peer, whose address is configured or learned by the client prior to an offer/answer exchange. Peer Reflexive Transport Address: A peer reflexive transport address is a reflexive address that is reflected off of the peer. Peer reflexive transport addresses are learned by connectivity checks. Relayed Transport Address: A derived transport address that terminates on a server, and is forwarded towards the client. The STUN Allocate Request, defined as part of the STUN relay usage [13] can be used to obtain a relayed transport address, for example. Associated Local Transport Address: When a peer sends a packet to a transport address, the associated local transport address is the local transport address at which those packets will actually arrive. For a local transport address, its associated local transport address is the same as the local transport address itself. For reflexive and relayed transport addresses, however, they are not the same. The associated local transport address is the one from which the reflexive or relayed transport was derived. Candidate: A sequence of transport addresses that form an atomic set for usage with a particular media session. Here, atomic means that all of transport addresses in the candidate need to work before the candidate will be used for actual media transport. In Rosenberg Expires December 28, 2006 [Page 16] Internet-Draft ICE June 2006 the case of RTP, there can be one or more transport addresses per candidate. In the most common case, there are two - one for RTP, and another for RTCP. If the agent doesn't use RTCP, there would be just one. If Generic Forward Error Correction (FEC) [16] is in use, there may be more than two. The transport addresses that compose a candidate are all of the same type - local, server reflexive, peer reflexive or relayed. Local Candidate: A candidate whose transport addresses are local transport addresses. Server Reflexive Candidate: A candidate whose transport addresses are server reflexive transport addresses. Peer Reflexive Candidate: A candidate whose transport addresses are peer reflexive transport addresses. Relayed Candidate: A candidate whose transport addresses are relayed transport addresses. Generating Candidate: The candidate from which a peer reflexive candidate is derived. Operating Candidate: The candidate that is in use for exchange of media. This is the one that an agent places in the m/c line of an offer or answer. Candidate ID: An identifier for a candidate. Component: When a media stream, and as a consequence, its candidate, require several IP addresses and ports to work atomically, each of the constituent IP addresses and ports represents a component of that media stream. For example, RTP-based media streams typically have two components - one for RTP, and one for RTCP. Component ID: An integer, starting with one within each candidate and incrementing by one for each component, which identifies the component. Transport Address ID (tid): An identifier for a transport address, formed by concatenating the candidate ID with the component ID, separated by a "colon". Candidate Pair: The combination of a candidate from one agent along with a candidate from its peer. Rosenberg Expires December 28, 2006 [Page 17] Internet-Draft ICE June 2006 Native Candidate: From the perspective of each agent, the candidate in a candidate pair which represents a set of addresses obtained by that agent. Remote Candidate: From the perspective of each agent, the candidate in a candidate pair which represents the set of addresses obtained by that agents peer. Transport Address Pair: The combination of the transport address for one component of a candidate with the transport address of the same component for the matching candidate in a candidate pair. Transport Address Pair ID: An identifier for a transport address pair. Formed by concatenating the native transport address ID with the remote transport address ID, separated by a "colon". Matching Transport Address Pair: When a STUN Binding Request is received on a local transport address, the matching transport address pair is the transport address pair whose connectivity is being checked by that Binding Request. Candidate Pair Priority Ordering: An ordering of candidate pairs based on a combination of the qvalues of each candidate and the candidate IDs of each candidate. Candidate Pair Check Ordering: An ordering of candidate pairs that is similar to the candidate pair priority ordering, except that the operating candidate appears at the top of the list, regardless of its priority. Transport Address Pair Check Ordering: An ordering of transport address pairs that determines the sequence of connectivity checks performed for the pairs. Transport Address Pair Count: The number of transport address pairs in a candidate pair. This is equal to the minimum of the number of transport addresses in the native candidate and the number of transport addresses in the remote candidate. 4. Sending the Initial Offer When an agent wishes to begin a session by sending an initial offer, it starts by gathering transport addresses, as described in Section 7.1. This will produce a set of candidates, including local ones, server reflexive ones, and relayed ones. This process of gathering candidates can actually happen at any time Rosenberg Expires December 28, 2006 [Page 18] Internet-Draft ICE June 2006 before sending the initial offer. A agent can pre-gather transport addresses, using a user interface cue (such as picking up the phone, or entry into an address book) as a hint that communications is imminent. Doing so eliminates any additional perceivable call setup delays due to address gathering. When it comes time to offer communications, the agent determines a priority for each candidate and identifies the operating candidate that will be used for receipt of media, as described in Section 7.2. The next step is to construct the offer message. For each media stream, it places its candidates into a=candidate attributes in the offer and puts its operating candidate into the m/c line. The process for doing this is described in Section 7.3. The offer is then sent. 5. Receipt of the Offer and Generation of the Answer Upon receipt of the offer message, the agent checks if the offer contains any a=candidate attributes. If the offer does, the offerer supports ICE. In that case, it starts gathering candidates, as described in Section 7.1, and prioritizes them as described in Section 7.2. This processing is done immediately on receipt of the offer, to prepare for the case where the user should accept the call, or early media needs to be generated. By gathering candidates (and performing connectivity checks) while the user is being alerted to the request for communications, session establishment delays are reduced. The agent then constructs its answer, encoding its candidates into a=candidate attributes and including the operating one in the m/c- line, as described in Section 7.3. The agent then forms candidate pairs as described in Section 7.4. These are ordered as described in Section 7.5. The agent then begins connectivity checks, as described in Section 7.6. It follows the logic in Section 7.10 on receipt of Binding Requests and responses to learn new candidates from the checks themselves. Transmission of media is performed according to the procedures in Section 7.13. 6. Processing the Answer There are two possible cases for processing of the answer. If the answerer did not support ICE, the answer will not contain any a=candidate attributes. As a result, the offerer knows that it Rosenberg Expires December 28, 2006 [Page 19] Internet-Draft ICE June 2006 cannot perform its connectivity checks. In this case, it proceeds with normal media processing as if ICE was not in use. However, it SHOULD send media with the symmetric property described in Section 7.13, and follow the keepalive procedures in Section 7.12. If the answer contains candidates, it implies that the answerer supports ICE. The offerer then forms candidate pairs as described in Section 7.4. These are ordered as described in Section 7.5. The agent then begins connectivity checks, as described in Section 7.6. It follows the logic in Section 7.10 on receipt of Binding Requests and responses to learn new candidates from the checks themselves. Transmission of media is performed according to the procedures in Section 7.13. 7. Common Procedures This section discusses procedures that are common between offerer and answerer. 7.1. Gathering Candidates An agent gathers candidates when it believes that communications is imminent. For offerers, this occurs before sending an offer (Section 4). For answerers, it occurs before sending an answer (Section 5). Each candidate has one or more components, each of which is associated with a sequence number, starting at 1 for the first component of each candidate, and incrementing by 1 for each additional component within that candidate. These components represent a set of transport addresses for which connectivity must be validated. For a particular media stream, all of the candidates SHOULD have the same number of components. The number of components that are needed are a function of the type of media stream. All of the components in a candidate MUST be of the same type - server reflexive, relayed, or local, and obtained from the same server in the case of server reflexive or relayed candidates. For local candidates, each component MUST be obtained from the same interface. For server reflexive and relayed candidates, each component MUST be derived from a component with the same component ID, all of which come from a single local candidate. For traditional RTP-based media streams, it is RECOMMENDED that there be two components per candidate - one for RTP and one for RTCP. The component with the component ID of 1 MUST be RTP, and the one with component ID of 2 MUST be RTCP. If an agent doesn't implement RTCP, Rosenberg Expires December 28, 2006 [Page 20] Internet-Draft ICE June 2006 it SHOULD have a single component for the RTP stream (which will have a component ID of 1 by definition). Each component of a candidate has a single transport address. The first step is to gather local candidates. Local candidates are obtained by binding to ports (typically ephemeral) on an interface (physical or virtual, including VPN interfaces) on the host. The process for gathering local candidates depends on the transport protocol. Procedures are specified here for UDP. Extensions to ICE that define procedures for other transport protocols MUST specify how local transport addresses are gathered. For each UDP media stream the agent wishes to use, the agent SHOULD obtain a set of candidates (one for each interface) by binding to N UDP ports on each interface, where N is the number of components needed for the candidate. For RTP, N is typically two. If a host has K local interfaces, this will result in K candidates for each UDP stream, requiring K*N local transport addresses. Once the agent has obtained local candidates, it obtains candidates with derived transport addresses. The process for gathering derived candidates depends on the transport protocol. Procedures are specified here for UDP. Extensions to ICE that define procedures for other transport protocols MUST specify how derived transport addresses are gathered. Agents which serve end users directly, such as softphones, hardphones, terminal adapters and so on, MUST implement the STUN Binding Discovery usage and SHOULD use it to obtain server reflexive candidates. These devices SHOULD implement the STUN Relay usage, and SHOULD use its Allocate request to obtain both server reflexive and relayed candidates. They MAY implement and MAY use other protocols that provide derived transport addresses, such as TEREDO [29]. The requirement to use the relay Usage is at SHOULD strength to allow for provider variation. If it is not to be used, it is RECOMMENDED that it be implemented and just disabled through configuration, so that it can re-enabled through configuration if conditions change in the future. Agents which represent network servers under the control of a service provider, such as gateways to the telephone network, media servers, or conferencing servers that are targeted at deployment only in networks with public IP addresses MAY use the STUN Binding Discovery usage and relay usage, or other similar protocols to obtain candidates. Rosenberg Expires December 28, 2006 [Page 21] Internet-Draft ICE June 2006 Why would these types of endpoints even bother to implement ICE? The answer is that such an implementation greatly facilitates NAT traversal for clients that connect to it. Consider a PC softphone behind a NAT whose mapping policy is address and port dependent. The softphone initiates a call through a gateway that implements ICE. The gateway doesn't obtain any server reflexive or relayed transport addresses, but it implements ICE, and consequently, is prepared to receive STUN connectivity checks on its local transport addresses. The softphone will send a STUN connectivity to check to that local transport address, causing the NAT to allocate a new binding for the softphone. The connectivity check will inform the softphone of this address, allowing it to be used by the gateway as a peer reflexive remote candidate. This allows direct media transmission between the gateway and softphone, without the need for relays. Furthermore, implementation of the STUN connectivity checks allows for NAT bindings along the way to be kept open. ICE also provides numerous security properties that are independent of NAT traversal, and would benefit any multimedia endpoint. See Section 13 for a discussion on these benefits. Obtaining derived candidates requires transmission of packets which have the effect of creating bindings on NAT devices between the client and the STUN servers. Experience has shown that many NAT devices have upper limits on the rate at which they will create new bindings. Furthermore, transmission of these packets on the network makes use of bandwidth and needs to be rate limited by the agent. As a consequence, a client SHOULD pace its STUN transactions, such that the start of each new transaction occurs at least Ta seconds after the start of the previous transaction. The value of Ta SHOULD be configurable, and SHOULD have a default of 50ms. Note that this pacing applies only to the start of a new transaction; pacing of retransmissions within a STUN transaction is governed by the retransmission rules defined by STUN. Derived candidates can be obtained from the STUN Binding Discovery usage or the STUN Relay usage. The latter is preferred since it will provide the client with both a server reflexive and a relayed transport address with a single transaction. It is possible that some STUN servers will only support the Relay usage or only the Binding Discovery usage, in which case a client might be configured with different servers depending on the usage. To obtain both server reflexive and relayed candidates using the STUN Relay Usage, the client takes a local UDP candidate, and for each configured STUN server, produces both candidates. It is anticipated that clients may have a multiplicity of STUN servers configured or discovered in network environments where there are multiple layers of NAT, and where that layering is known to the provider of the client. Rosenberg Expires December 28, 2006 [Page 22] Internet-Draft ICE June 2006 To obtain these candidates, for each configured STUN server, the client initiates an Allocate Request transaction using the procedures of Section 8.1.2 of [13] from each transport address of a particular local candidate. The Allocate Response will provide the client with its server reflexive transport address (obtained from the XOR-MAPPED- ADDRESS attribute) and its relayed transport address in the RELAY- ADDRESS attribute. Indeed, these two transport addresses are related to each other. The relay will forward packets received on the relayed transport address towards that server reflexive transport address. As such, the server reflexive transport address is said to be the associated server reflexive transport address for that relayed address. Once the Allocate requests have given a client a relayed transport address for all transport addresses in a relayed candidate, there is no reason for a client to obtain further relayed candidates through the same STUN server. Thus, if there are other local candidates from which the client has not yet obtained relayed transport address, the client SHOULD NOT bother to obtain them. Instead, it SHOULD use the STUN Binding Discovery usage and obtain just server reflexive addresses from that STUN server. The order in which local candidates are tried against the STUN server to obtain relayed candidates is a matter of local policy. To obtain server reflexive candidates using the STUN Binding Discovery usage, the client takes a local UDP candidate, and for each configured STUN server, produces a server reflexive candidate. To produce the server reflexive candidate from the local candidate, it follows the procedures of Section 12.2 of [12] for each local transport address in the local candidate. The Binding Response will provide the client with its server reflexive transport address. If the client had K local candidates, this will produce S*K server reflexive candidates, where S is the number of STUN servers. Since a client will pace its STUN transactions (both Binding and Allocate requests) at a total rate of one new transaction every Ta seconds, it will take a certain amount of time to complete the address gathering phase. It is RECOMMENDED that implementations have a configurable upper bound on the total amount of time allotted to address gathering. Any transactions not completed at that point SHOULD be abandoned, but MAY continue and be used in an updated offer once they complete. A default value of 5s is RECOMMENDED. Since the total number of allocations that could be done (based on the number of STUN servers and local interfaces) might exceed this value, clients SHOULD prioritize their local candidates and STUN servers, performing transactions from the highest priority local candidates to the highest priority STUN servers first. A STUN server would typically be higher priority if it supports the STUN Relay Usage, since such a server provides two transport addresses with one transaction. Rosenberg Expires December 28, 2006 [Page 23] Internet-Draft ICE June 2006 Once the allocations are complete, any redundant candidates are discarded. Candidate A is redundant with candidate B if the transport addresses of each component match, and each component of their associated local candidates match. For example, consider a set of candidates with a single component. One candidate is a local candidate, and its one component has a transport address of 10.0.1.1: 4458. A reflexive transport address is derived from this local transport address, producing a 10.0.1.1:4458. These two candidates are identical, and also have identical associated local transport addresses, so they are redundant. +----------+ | STUN Srvr| +----------+ | | ----- // \\ | | | B:net10 | | | \\ // ----- | | +----------+ | NAT | +----------+ | | ----- // \\ | A | |192.168/16 | | | \\ // ----- | | |192.168.1.1 ----- +----------+ // \\ +----------+ | | | | | | | Offerer |---------| C:net10 |---------| Answerer | | |10.0.1.1 | | 10.0.1.2 | | +----------+ \\ // +----------+ ----- Rosenberg Expires December 28, 2006 [Page 24] Internet-Draft ICE June 2006 Figure 6 Consider the more complicated case of Figure 6. In this case, the offerer is multi-homed. It has one interface, 10.0.1.1, on network C, which is a net 10 private network. The Answerer is on this same network. The offerer is also connected to network A, which is 192.168/16. The offerer has an interface of 192.168.1.1 on this network. There is a NAT on this network, natting into network B, which is another net10 private network, but not connected to network C. There is a STUN server on network B. The offerer obtains local transport address on its interface on network C (10.0.1.1:2498) and a local transport address on its interface on network A (192.168.1.1:3344). It performs a STUN query to its configured STUN server from 192.168.1.1:3344. This query passes through the NAT, which happens to assign the binding 10.0.1.1: 2498. The STUN server reflects this in the STUN Binding Response. Now, the offerer has obtained a candidate with a transport address it already has (10.0.1.1:2498), but from a new interface. It therefore keeps it. When it performs its connectivity checks, the offerer will end up sending packets from both interfaces, and those sent from its interface on network C will succeed. 7.2. Prioritizing the Candidates and Choosing an Operating One The prioritization process takes the set of candidates for a particular media stream and associates each with a priority. This priority reflects the desire that the agent has to receive media at that candidate, and is assigned as a value from 0 to 1 (1 being most preferred). Priorities are a property of a candidate, and thus shared across all components of a candidate. Priorities are ordinal, so that their significance is only meaningful relative to other candidates from that agent for a particular media stream. Candidates MAY have the same priority. However, it is RECOMMENDED that each candidate have a distinct priority. Doing so improves the efficiency of ICE. This specification makes no normative statements on how the prioritization is done. However, some useful guidelines are suggested on how such a prioritization can be determined. One criteria for choosing one candidate over another is whether or not that candidate involves the use of an intermediary. That is, if media is sent to that candidate, will the media first transit an intermediate server before being received. Relayed candidates are clearly one type of candidates that involve an intermediary. Another are local candidates associated with a VPN server. When media is transited through an intermediary, it can increase the latency Rosenberg Expires December 28, 2006 [Page 25] Internet-Draft ICE June 2006 between transmission and reception. It can increase the packet losses, because of the additional router hops that may be taken. It may increase the cost of providing service, since media will be routed in and right back out of an intermediary run by the provider. If these concerns are important, candidates with this property can be listed with lower priority. Another criteria for choosing one candidate over another is IP address family. ICE works with both IPv4 and IPv6. It therefore provides a transition mechanism that allows dual-stack hosts to prefer connectivity over IPv6, but to fall back to IPv4 in case the v6 networks are disconnected (due, for example, to a failure in a 6to4 relay) [23]. It can also help with hosts that have both a native IPv6 address and a 6to4 address. In such a case, higher priority could be afforded to the native v6 address, followed by the 6to4 address, followed by a native v4 address. This allows a site to obtain and begin using native v6 addresses immediately, yet still fallback to 6to4 addresses when communicating with agents in other sites that do not yet have native v6 connectivity. Another criteria for choosing one candidate over another is security. If a user is a telecommuter, and therefore connected to their corporate network and a local home network, they may prefer their voice traffic to be routed over the VPN in order to keep it on the corporate network when communicating within the enterprise, but use the local network when communicating with users outside of the enterprise. Another criteria for choosing one address over another is topological awareness. This is most useful for candidates that make use of relays. In those cases, if an agent has preconfigured or dynamically discovered knowledge of the topological proximity of the relays to itself, it can use that to select closer relays with higher priority. There may be transport-specific reasons for preferring one candidate over another. In such a case, specifications defining usage of ICE with other transport protocols SHOULD document such considerations. Once the candidates have been prioritized, one may be selected as the operating one. This is the candidate that will be used for actual exchange of media if and when its validated, until a higher priority candidate is validated. The operating candidate will also be used to receive media from ICE-unaware peers. As such, it is RECOMMENDED that one be chosen based on the likelihood of that candidate to work with the peer that is being contacted. Unfortunately, it is difficult to ascertain which candidate that might be. As an example, consider a user within an enterprise. To reach non-ICE capable agents within the enterprise, a local candidate has to be used, since Rosenberg Expires December 28, 2006 [Page 26] Internet-Draft ICE June 2006 the enterprise policies may prevent communication between elements using a relay on the public network. However, when communicating to peers outside of the enterprise, a relayed candidate from a publically accessible STUN server is needed. Indeed, the difficulty in picking just one address that will work is the whole problem that motivated the development of this specification in the first place. As such, it is RECOMMENDED that the operating candidate be a relayed candidate from a STUN server providing public IP addresses in response to an Allocate request. Furthermore, ICE is only truly effective when it is supported on both sides of the session. It is therefore most prudent to deploy it to close-knit communities as a whole, rather than piecemeal. In the example above, this would mean that ICE would ideally be deployed completely within the enterprise, rather than just to parts of it. An additional consideration for selection of the operating candidate is the switching of media stream destinations between the initial offer and the subsequent offer. The operating candidate pair in the initial offer is validated first, and if that validation succeeds, media will immediately begin to flow between the pair. When the ICE checks complete and yield a higher priority candidate pair, media will begin to flow to it (there will also be an updated offer/answer exchange that changes the operating candidate). This will result in a change in the destination of the media packets. This may also cause a different path for the media packets. That path might have different delay and jitter characteristics. As a consequence, the jitter buffers may see a glitch, causing possible media artifacts. If these issues are a concern, the initial offer MAY omit an operating candidate. This is done by including an m/c-line with an a=inactive attribute. In such a case, an updated offer will need to be sent immediately when communicating with an ICE-unaware agent, setting an operating candidate. There may be transport-specific reasons for selection of an operating candidate. In such a case, specifications defining usage of ICE with other transport protocols SHOULD document such considerations. 7.3. Encoding Candidates into SDP For each candidate for a media stream, the agent includes a series of a=candidate attributes as media-level attributes, one for each component in the candidate. Each candidate has a unique identifier, called the candidate ID. The candidate ID MUST be chosen randomly and contain at least 24 bits of randomness. This means that a candidate ID must be at least 4 characters long, since each character in the base64 alphabet used for candidate IDs contains at most 6 bits of randomness. A candidate ID MAY be longer than 4 characters, and Rosenberg Expires December 28, 2006 [Page 27] Internet-Draft ICE June 2006 different candidate IDs MAY have different lengths. It is chosen only when the candidate is placed into the SDP for the first time; subsequent offers or answers within the same session containing that same candidate MUST use the same candidate ID used previously. 24 bits is sufficient because the candidate ID is not providing security (the much more random password is). Its sole purpose is to make it highly unlikely that both the offerer and answerer select the same value for a candidate for the same media stream. Different values for the candidate ID are required to break ties in the procedure that is used to order the candidate pairs. Each component of the candidate has an identifier, called the component ID. The component ID is a sequence number. For each candidate, it starts at one, and increments by one for each component. As discussed below, ICE will perform connectivity checks such that, between a pair of candidates, checks only occur between transport addresses with the same component ID. As a consequence, if one candidate has three components, and it is paired with a candidate that has two, there will only be two transport address pairs and two connectivity checks. ICE will work without a standardized mapping between the components of a media stream and the numerical value of the component ID. This allows ICE to be used with media streams with multiple components without development of standards around such a mapping. However, a specific mapping has been defined in this specification for RTP - component ID 1 corresponds to RTP, and component ID of 2 corresponds to RTCP. Like the candidate ID, the component ID is assigned at the time the candidate is first placed into the SDP; subsequent offers or answers within the same session containing that same candidate MUST use the same component ID used previously. The transport, addr and port of the a=candidate attribute (all defined in Section 12) are set to the transport protocol, unicast address and port of the tranport address. A Fully Qualified Domain Name (FQDN) for a host MAY be used in place of a unicast address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS using an A or AAAA record, and the resulting IP address is used for the remainder of ICE processing. The qvalue is set to the priority of the candidate, and MUST be the same for all components of the candidate. The agent MUST include a type for the transport address by populating the candidate-types production with the appropriate value - "local" for local transport addresses, "srflx" for server reflexive candidates, and "relay" for relayed candidates. If the transport address is server reflexive, the agent MUST include the rel-addr and rel-port productions containing the associated local transport Rosenberg Expires December 28, 2006 [Page 28] Internet-Draft ICE June 2006 address for that server reflexive transport address. There are environments in which the policy of an agent is such that it never provides local transport addresses in its offers or answers, for fear of revealing internal topology to external hosts. In such cases, an agent MAY include a random transport address instead, as long as it is the same transport address for all server reflexive candidates derived from the same actual local transport address. This is because the transport address in the rel-addr and rel-port production are used by the ICE algorithm itself for correlation purposes. If the tranport address is relayed, the agent SHOULD include the rel- addr and rel-port productions, containing the associated server reflexive transport address. When a relayed address is obtained from a STUN relay, the associated server reflexive transport address is the value from the XOR-MAPPED-ADDRESS that was returned in the same STUN response which provided the relayed address to the agent. Though not used directly with ICE, the rel-addr and rel-port attributes are essential for proper functioning of QoS mechanisms, such as those defined by 3gpp and Packetcable. The rel-addr and rel-port production MUST NOT be present for a local transport address. All of the candidates for a media stream share a password that is used for securing the STUN connectivity checks. The password will be used to process the MESSAGE-INTEGRITY attribute for STUN requests received by the agent. The password for candidates for different media streams MAY be the same, or MAY be different. This password MUST be chosen randomly with 128 bits of randomness (though it can be longer than 128 bits). This password is contained in the a=ice-pwd attribute, present as a session or media level attribute. Since each character of the ice-pwd attribute can represent six bits of randomness, the ice-pwd attribute will always be at least 22 characters long. New passwords MUST be selected for each new session, even if the transport address from a previous session is being recycled. The combination of candidate ID and component ID uniquely identify each transport address. As a consequence, each transport address has a unique identifier, called the transport address ID. The transport address ID is formed by concatenating the candidate ID with the component ID, separated by the colon (":"). The transport address ID is not explicitly encoded in the SDP; it is derived from the candidate ID and component ID, which are present in the SDP. The usage of the colon as a separator allows the candidate ID and component ID to be extracted from the transport address ID, since the colon is not a valid character for the candidate ID. Rosenberg Expires December 28, 2006 [Page 29] Internet-Draft ICE June 2006 The transport address ID gets combined, through further concatenation, with the transport address ID of a transport address from the remote candidate (separated again by another colon) to form the username that is placed in the STUN checks between the peers. This allows the STUN message to uniquely identify the pairing whose connectivity it is checking. The transport address ID is needed as a unique identifier because the IP address within the candidate fails to provide that uniqueness as a consequence of NAT. Consider agents 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 sends an offer to C. C, in its answer, provides A with its transport addresses. In this case, that is 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, B is in a session at that same time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877. This means that B is prepared to accept STUN messages on those ports, just as C is. A will send a STUN request to 10.0.1.1:8866 and and another to 10.0.1.1: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 completely different user, B. To fix this, the transport address ID takes on the role of a unique identifier. C provides A with an identifier for its transport address, and A provides one to C. A concatenates these two identifiers (with a colon between) and uses the result as the 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. An unfortunate consequence of the non-uniqueness of IP addresses is that, in the above example, B might not even be an ICE agent. It could be any host, and the port to which the STUN packet is directed could be any ephemeral port on that host. If there is an application listening on this socket for packets, and it is not prepared to handle malformed packets for whatever protocol is in use, the operation of that application could be affected. Fortunately, since the ports exchanged in SDP are ephemeral and usually drawn from the dynamic or registered range, the odds are good that the port is not used to run a server on host B, but rather is the agent side of some protocol. This decreases the probability of hitting a port in-use, due to the transient nature of port usage in this range. However, the possibility of a problem does exist, and network deployers should be prepared for it. Note that this is not a problem specific to ICE; stray packets can arrive at a port at any time for any type of protocol, especially ones on the public Internet. As such, this requirement is just restating a general design guideline for Internet Rosenberg Expires December 28, 2006 [Page 30] Internet-Draft ICE June 2006 applications - be prepared for unknown packets on any port. The operating candidate, if there is one, is placed into the m/c lines of the SDP. For RTP streams, this is done by placing the RTP address and port into the c and m lines in the SDP respectively. If the agent is utilizing RTCP, it MUST encode its address and port using the a=rtcp attribute as defined in RFC 3605 [1]. If RTCP is not in use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in RFC 3556 [6]. If there is no operating candidate, the agent MUST include an a=inactive attribute. The media address and port in the m/c-line is inconsequential, since it won't be used. Encoding of candidates may involve transport protocol specific considerations. There are none for UDP. However, extensions that define usage of ICE with other transport protocols SHOULD specify any special encoding considerations. Once an offer or answer are sent, an agent MUST be prepared to receive both STUN and media packets on each candidate. As discussed in Section 7.13, media packets can be sent to a candidate prior to its promotion to operating. 7.4. Forming Candidate Pairs Once the offer/answer exchange has completed, both agents will have a set of candidates for each media stream. Each agent forms a set of candidate pairs for each media stream by combining each of its candidates with each of the candidates of its peer. Candidates can be paired up only if their transport protocols are identical. Each candidate has a number of components, each of which has a transport address. Within a candidate pair, the components themselves are paired up such that transport addresses with the same component ID are combined to form a transport address pair. If one candidate has more components than the other, those extra components will not be part of a transport address pair, won't be validated, and will effectively be treated as if they weren't included in the candidate pair in the first place. For example, if an offer/answer exchange took place for a session comprised of an audio and a video stream, and each agent had two candidates per media stream, there would be 8 candidate pairs, 4 for audio and 4 for video. For each of the 8 candidate pairs, there would be two transport address pairs - one for RTP, and one for RTCP. The relationship between a candidate, candidate pair, transport address, transport address pair and component are shown in Figure 7. Rosenberg Expires December 28, 2006 [Page 31] Internet-Draft ICE June 2006 This figure shows the relationships as seen by the agent that owns the candidate with candidate ID "L". This candidate has two components with transport addresses A and B respectively. This candidate is called the native candidate, since it is the one owned by the agent in question. The candidate owned by its peer is called the remote candidate. As the figure shows, there is a single candidate pair, and two components in each candidate. The native candidate has a candidate ID of "L", and the remote candidate has a candidate ID of "R". Since the two component IDs are 1 and 2, candidate "L" has two transport addresses with transport address IDs of "L:1" and "L:2" respectively. Similarly, candidate "R" has two transport addresses with transport address IDs of "R:1" and "R:2" respectively. Note that these candidate IDs are not actually legal since they are not sufficiently random. However, we use "L" and "R" to keep the figures readable. Furthermore, each transport address pair is associated with an ID, the transport address pair ID. This ID is equal to the concatenation of the transport address ID of the native transport address with the transport address ID of the remote transport address, separated by a colon. This means that the identifiers are seen differenly for each agent. For the agent that owns candidate "L", there are two transport address pairs. One contains transport address "L:1" and "R:1", with a transport address pair ID of "L:1:R:1". The other contains transport address "L:2" and "R:2", with a transport address pair ID of "L:2:R:2". For the agent that owns candidate "R", the identifiers for these two transport address pairs are reversed; it would be "R:1:L:1" for the first one and "R:2:L:2" for the second. Rosenberg Expires December 28, 2006 [Page 32] Internet-Draft ICE June 2006 ............................................... . . . . . ............. ............. . . . tid=L:1 . . tid=R:1 . . . . -- . . -- . . component component. . | A|------------------------| C| . . id=1 id=1 . . -- . Transport . -- . . . . . Address . . . . . . Pair . . . . . . id=L:1:R:1 . . . . . . . . . . . . . . . . . tid=L:2 . . tid=R:2 . . component . . -- . . -- . . id=2 . . | B|------------------------| D| component . . -- . Transport . -- . . id=2 . . . Address . . . . . . Pair . . . . . . id=L:2:R:2 . . . . . . . . . . ............. ............. . . Native Remote . . Candidate Candidate . . id=L id=R . . . . . ............................................... Candidate Pair Figure 7 If a candidate pair was created as a consequence of an offer generated by an agent, then that agent is said to be the offerer of that candidate pair and all of its transport address pairs. Similarly, the other agent is said to be the answerer of that candidate pair and all of its transport address pairs. As a consequence, each agent has a particular role, either offerer or answerer, for each transport address pair. This role is important; when a candidate pair is to be promoted to operating, the offerer is the one which performs the updated offer. 7.5. Ordering the Candidate Pairs Recall that when each candidate is encoded into SDP, it contains a qvalue between 1 and 0, with 1 being the highest priority. Peer Rosenberg Expires December 28, 2006 [Page 33] Internet-Draft ICE June 2006 reflexive candidates, learned through the procedures described in Section 7.10 also have a priority between 0 and 1. For each media stream, the native candidates are ordered based on their qvalues, with higher q-values coming first. Amongst candidates with the same qvalue, they are ordered based on candidate ID, using reverse ASCII sort order. For example, the candidate with candidate ID "lagDx" sorts before the candidate with ID "bad79", and both of those follow the candidate with ID "m8zz". The usage of a reverse ASCII sort order is important; as discussed in Section 13, it allows peer-derived candidates to be preferred over native ones. The result of these ordering rules will be an ordered list of candidates. The first candidate in this list is given a sequence number of 1, the next is given a sequence number of 2, and so on. This same procedure is done for the remote candidates. The result is that each candidate pair has two sequence numbers, one for the native candidate, and one for the remote candidate. First, all of the candidate pairs for whom the smaller of the two sequence numbers equals 1 are taken first. Then, all of those for whom the smaller of the two sequence numbers equals 2 are taken next, and so on. Amongst those pairs that share the same value for their smaller sequence number, they are ordered by the larger of their two sequence numbers (smallest first). Amongst those pairs that share the same value for their smaller sequence number and the same value for their larger sequence number, the larger of the two candidate IDs in each pair are selected, and the pairs are ordered in reverse ASCII order of the candidate ID, largest first. The resulting ordering of candidate pairs is called the candidate pair priority ordered list. As an example, consider two agents, A and B. One offers two candidates for a media stream with candidate IDs of "g9g9" and "8888", with q-values of 1.0 and 0.8 respectively. The other answers with three candidates with candidate IDs of "h8h8", "6565" and "klkl", with q-values of 0.3, 0.2 and 0.1 respectively. The following table shows the rank ordering of the six candidate pairs. The column labeled "Max SN" is the larger of the two sequence numbers in the candidate pair, and "Min SN" is the minimum. The column labeled "Max Cand. ID" is the value of the larger of the two candidate IDs in the candidate pair. Rosenberg Expires December 28, 2006 [Page 34] Internet-Draft ICE June 2006 Order A A A B B B Max Cand. Cand. Cand. Cand. Cand. Cand. Max Min Cand. ID q-value SN ID q-value SN SN SN ID --------------------------------------------------------------------- 1 g9g9 1.0 1 h8h8 0.3 1 1 1 h8h8 2 8888 0.8 2 h8h8 0.3 1 2 1 h8h8 3 g9g9 1.0 1 6565 0.2 2 2 1 g9g9 4 g9g9 1.0 1 klkl 0.1 3 3 1 klkl 5 8888 0.8 2 6565 0.2 2 2 2 8888 6 8888 0.8 2 klkl 0.1 3 3 2 klkl The candidate pair priority ordered list is then used to obtain an ordered list of transport address pairs, on which the agent will, in order, attempt to send STUN connectivity checks. This list, called the transport address pair check ordered list, is very similar to the candidate pair priority ordered list, but differs in two important respects. Firstly, the candidate pairs matching the operating candidate pair (there can actually be more than one) get promoted to the top of the list. This allows the operating candidate pair to be validated first. Secondly, many of the checks would be redundant, and a filtering algorithm is used to eliminate these redundant checks. Ordering of candidates may involve transport protocol specific considerations. There are none for UDP. However, extensions that define usage of ICE with other transport protocols SHOULD specify any special ordering considerations. To form the transport address pair check ordered list, the candidate list is first modified by taking the candidate pairs corresponding to the operating candidate pair, and promoting them to the top of the list. A candidate pair matches the operating candidate pair when its native and remote transport address match the native and remote transport addresses in the m/c-line, respectively. In unusual circumstances, there may be more than one such candidate pair. In such a case, they should be promoted such that the higher priority candidate pairs appear first. In addition, it is possible that none of the candidate pairs match the operating candidate pair. In that case, no candidate pairs are promoted. Within each candidate pair there will be a set of transport address pairs, one for each component ID. Those pairs are ordered by component ID. The result is an absolute ordering of all transport address pairs for a media stream, sorted first by the order of their candidate pairs (with the exception of the operating candidate), followed by the order of their component IDs. This ordering is used as the start of the transport address pair check ordering. Rosenberg Expires December 28, 2006 [Page 35] Internet-Draft ICE June 2006 The next step is to remove redundant transport addresses. Starting at the top of the list, the agent moves down from one transport address pair to the next. If a transport address pair under consideration has the same remote transport address as a previous pair, based on transport address pair ID comparisons, and the native transport address from that previous pair has the same origination transport address as the one under consideration (based on IP address and port comparison), the one under consideration is removed from the list. The origination transport address is the address that the agent would send from in order to emit a packet with that native transport address as a source transport address. For a local transport address, the origination transport address is equal to that local transport address. For a server reflexive transport address, the origination transport address is equal to the local transport address from which it was derived. For relayed addresses, packets are emitted by explicitly sending them through the relay. Consequently, the origination transport address is equal to the relayed address. After the agent has gone through the entire list, the result is the transport address pair check ordered list. The pairs that get removed are redundant since the agent would send a STUN connectivity check using the same source and destination addresses as a previous check. Consequently, the connectivity check will provide no information to the remote agent except for the transport address pair ID its associated with. These turn out to be unnecesary due to the STUN processing rules outlined below. 7.6. Performing the Connectivity Checks Connectivity checks are a STUN usage defined in [12]. They are performed by sending peer-to-peer STUN Binding Requests. These checks result in a transport address pair progressing through a state machine that captures the progress of the connectivity checks. The specific state machine and the procedures for the connectivity checks are specific to the transport protocol. This specification defines rules for UDP. The state machine processing described in this section MUST be followed by agents. Extensions to ICE that describe other transport protocols SHOULD describe the state machine and the procedures for connectivity checks. The set of states for a transport address pair visited by the offerer and answerer are depicted graphically in Figure 9. Note that this state machine exists for all transport address pairs, including ones pruned from the transport address pair check ordered list. Rosenberg Expires December 28, 2006 [Page 36] Internet-Draft ICE June 2006 | |Start | | V +------------+ +-----------------| | | | | | +----| Waiting |----------------+ | | | | | | | | | | | Miss | +------------+ | | ---- | | | Match Res| - | | Selected | Match Req ---------| | | --------. | ------- - | | | Send Req Match Req | Send Req | | V --------- | | Match Res | +------------+ Re-Xmit | | --------- | | | Req | | - | | | | | +------c----| Testing |-----------+ | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | | Error or | | | | | | Miss | | Timer Tr | | | | ----- | | -------- V V | V - V V Send Req +------------+ | +------------+ +------------+ +-----| | +--->| | | | | | Recv- | | | | Send- | | | Valid |------->| Invalid |<-------| Valid | | | | | | | | +---->| | Error, | | Error, | | +------------+ Miss +------------+ Miss +------------+ | ----- ^ ----- | | - | Error, - | | | Miss | | | ----- | | | - | | +------------+ | | | | | | | | | +-------------->| Valid |<-------------+ Match Req | | Match Res --------- | | --------- - +------------+ - Rosenberg Expires December 28, 2006 [Page 37] Internet-Draft ICE June 2006 | ^ | | | | +-------+ Timer Tr -------- Send Req Figure 9 The state machine has six states - Waiting, Testing, Recv-Valid, Send-Valid, Valid and Invalid. In the Waiting state, the agent is waiting to send or receive a connectivity check for the pair. In the Testing state, the agent has sent a connectivity check and is awaiting a response. In the Recv-Valid state, the agent knows that its peer can receive packets from it on this transport address pair. In the Send-Valid state, the agent knows that its peer can send packets to it. In the Valid state, the agent knows that its peer can both send and receive packets from it. Initially, all transport address pairs start in the Waiting state. In this state, the agent waits for one of three events - a chance to send a Binding Request, receipt of a Binding Request, or receipt of a Binding Response. Since there is an instance of the state machine for each transport address pair, Binding Requests and responses need to be matched to the specific state machine for which they were meant to apply. As described below, the Binding Request may not be a match for the transport address pair it was meant to validate. To find the transport address pair it was meant to validate, called the target transport address pair, the agent examinines the USERNAME of the incoming Binding Request. The USERNAME directly contains the transport address pair ID for the pair it was meant to validate. Binding Responses are matched to their requests using the STUN transaction ID, and then mapped to the transport address pair from that. For each media stream, the agent starts a new connectivity check for a transport address pair every Tb*RND seconds. Tb SHOULD scale linearly with the number of media streams, so that the pace of connectivity checks overall is invariant to the number of media streams. Consequently, it is RECOMMENDED that Tb have a default value of N*50ms, where N is the number of media streams. RND is a random number chosen uniformly between 0.7 and 1.3, and it helps to avoid synchronization between the transmission of connectivity checks for different media streams. On average, if there are N media streams, the checks across all media streams will be paced out at a Rosenberg Expires December 28, 2006 [Page 38] Internet-Draft ICE June 2006 total of N/Tb checks per second. The check is started for the first transport address pair in the transport address pair check ordered list that is in the Waiting state. The "Selected" event is passed to the state machine for this transport address pair, causing it to be moved to the Testing state. The agent then sends a connectivity check using a STUN Binding Request, as outlined in Section 7.7. Once a STUN connectivity check begins, the processing of the check follows the rules for STUN. Specifically, retransmits of STUN requests are done as specified in [12], and furthermore, if a transaction fails and needs to be retried, that retry can happen rapidly, as described below. It doesn't "count" against the average rate limit of 1/Tb checks per second per media stream. In addition, the keepalives that are generated for a valid pair do not count against the rate limit either. The rate limit applies strictly to the start of connectivity checks for a transport address pair that has been newly signaled through an offer/answer exchange. When an agent receives a Binding Request, which per the processing rules of Section 7.8 produces a succesful response, the agent examines the source transport address of the request. If the native transport address was relayed, this would be the source as seen by the relay. For the STUN relay usage, that source transport address will be present in the REMOTE-ADDRESS attribute of a STUN Data Indication message, if the Binding Request was delivered through a Data Indication. If the Binding Request was not encapsulated in a Data Indication, that source transport address is equal to the current active destination for the STUN relay session. If the source transport address matches the remote transport address of the target transport address pair, the Binding Request is considered to be a match for the target transport address pair. Consequently, a Match Req event is passed to the state machine for the target transport address pair. If the state machine was in the Waiting or Testing state, the state machine moves into the Send-Valid state. If it was previously in the Waiting state, the agent sends a connectivity check of its own for the target transport address pair, as outlined in Section 7.7. If it was in the Testing state, it retransmits a Binding Request for the transaction in progress. This retransmission is one that would not normally occur based on the procedures in [12]. ICE "prods" the STUN transaction state machine to send an extra retransmit, in addition to the one which is scheduled to be sent next. This helps speed up bidirectional connectivity verification when one agent is behind a NAT with an address and port dependent filtering behavior [32]. If the source transport addresses in the Binding Request was not a match for the remote transport address, the Binding Request is Rosenberg Expires December 28, 2006 [Page 39] Internet-Draft ICE June 2006 considered to be a miss for the target transport address pair. Consequently, a Miss event is passed to the state machine of the target transport address pair, and it immediately moves into the Invalid state. Typically, the source transport address won't match when there was a NAT between the sender and receiver with an address and port dependent mapping property, though there are other cases in which this can happen. Though it was a miss for the target transport address pair, the connectivity check may have been a match for a different transport address pair. To determine this, the agent checks the source transport address of the Binding Request against all of the other remote transport addresses of transport address pairs for the same media stream that use the same transport protocol and share the same native transport address (based on transport address ID comparison) of the target. Of those that match (assuming at least one matches), it refines the set further by selecting only those for whom the origination transport address of the remote transport address matches the origination transport address of the remote transport address in the target transport address pair. The origination transport address for a remote transport address is obtained from information signaled in the SDP, and depends on the type. For a local transport address, the origination address equals that local transport address. For a server reflexive transport address, the origination address is obtained from the related address information provided in the SDP. For a relayed transport address, the origination transport address quals that relayed transport address. For these three types, the type is signaled in the SDP. For a peer derived transport address, the origination address is the same as the origination address of the generating transport address. If there was a match (there can only be either one or zero matches), this match is called the alternate. In many cases, the alternate transport address pair will not be in the transport address pair check ordered list; it will have been one of the ones pruned. Indeed, this is why it was pruned - a check on the remaining transport address pairs can serve to validate it. The state machine for the alternate is passed the Match Req event. If it was in the Waiting state, this causes it to move into the Send-Valid state, and a connectivity check is generated for the alternate transport address pair. It may have been in the Testing state, in which case it moves move into the Send-Valid state, and the agent restransmits the Binding Request for the transaction in progress. If it was the in the Recv-Valid state, this causes it to move into the Valid state. If no alternate could be found, it means that a new remote transport address and corresponding origination transport address have been discovered. In this case, the agent follows the procedures of Rosenberg Expires December 28, 2006 [Page 40] Internet-Draft ICE June 2006 Section 7.10.1 to create a new transport address pair and state machine for it. If the Binding Request didn't generate a success response, an Error event is passed to the state machine of the target, causing it to move into the Invalid state. If the agent receives a successful response to its STUN request, it agent examines the transport address in the XOR-MAPPED-ADDRESS attribute of the response. This will be a peer reflexive transport address. If the peer reflexive transport address matches (based on IP address and port comparison) the native transport address of the target transport address pair, a Match Res event is passed to the state machine of the target. If the state machine was in the Testing state, the state machine moves into the Recv-Valid state. If it was in the Send-Valid state, it moves into the Valid state. If, however, the transport addresses didn't match, a Miss event is passed to the state machine of the target, and it immediately moves into the Invalid state. The agent checks the peer reflexive transport address against all of the other native transport addresses for transport address pairs for the same media stream with the same transport protocol and the same remote transport address (based on comparison of transport address ID) as the target. Of those that match (assuming at least one matches), it refines the set further by selecting only those for whom the origination transport address of the native transport address matches the origination address of the native transport address in the target transport address pair. The resulting transport address pair (there can be only zero or one) is called the alternate. In many cases, the alternate transport address pair will not be in the transport address pair check ordered list; it will have been one of the ones pruned. The state machine for the alternate is passed the Match Res event. If it was in the Waiting state, this causes it to move into the Recv-Valid state. It may have been in the Testing state, in which case it moves move into the Recv- Valid state. If it was the in the Send-Valid state, this causes it to move into the Valid state. If no alternate could be found, the Binding Response will create a new peer reflexive transport address, and the procedures of Section 7.10.2 are followed to create a new transport address pair and state machine for it. In any state, if the STUN transaction results in an error, the state machine moves into the Invalid state. A STUN transaction produces an "error" based on the processing in Section 7.7, which indicates which STUN response codes constitute an error as far as ICE processing is concerned. Rosenberg Expires December 28, 2006 [Page 41] Internet-Draft ICE June 2006 If a transport address pair is in the Recv-Valid or Valid state, an agent MUST generate a new STUN Binding Request transaction every Tr seconds. This transaction ensures that NAT bindings for the transport address pair remain open while the candidate is under consideration. The transaction is performed as outlined in Section 7.7. These transactions can also be used to keep the NAT bindings alive when the candidate is promoted to operating, as described in Section 7.12. Tr SHOULD be configurable, and SHOULD default to 15 seconds. These STUN transactions are processed in the same way as any other, and can result in new peer derived transport addresses, or can fail and cause the transport address pair to be invalidated. The candidate pair itself has a state, which is derived from the states of its transport address pairs. If at least one of the transport address pairs in a candidate pair is in the invalid state, the state of the candidate pair is considered to be invalid. If the candidate pair enters this state, an agent moves the state machines for all of the other transport address pairs in this candidate pair into the invalid state as well. This will ensure that connectivity checks never start for those transport address pairs. Furthermore, if checks are already in progress for one of those transport address pairs, the agent ceases them. If all of the transport address pairs making up the candidate pair are Valid, the candidate pair is considered valid. If all of the transport address pairs making up the candidate pair are either Valid or Recv-Valid, and at least one is Recv-Valid, the candidate pair is considered to be Recv-Valid. If all of the transport address pairs making up the candidate pair are either Valid or Send-Valid, and at least one is Send-Valid, the candidate pair is considered to be Send- Valid. If all of the transport address pairs in a candidate pair are in the Waiting state, the candidate pair is in the waiting state. If all of the transport address pairs in the candidate pair are either in the Waiting or Testing states, and at least one is in the Testing state, the state of the candidate pair is Testing. Otherwise, the state of the candidate pair is considered Indeterminate. A candidate itself also has a state. If a candidate is present in at least one valid candidate pair, that candidate is said to be valid. If all of the candidate pairs containing that candidate are invalid, the candidate itself is invalid. Otherwise, the candidate's state is Indeterminate. 7.7. Sending a Binding Request for Connectivity Checks An agent performs a connectivity check on a transport address pair by sending a STUN Binding Request from its native transport address, and Rosenberg Expires December 28, 2006 [Page 42] Internet-Draft ICE June 2006 sending it to the remote transport address. Sending from its native transport address is done by sending it from its origination transport address. As mentioned above, the origination transport address depends on the type of transport protocol and the type of transport address (local, reflexive, or relayed). This specification defines the meaning for UDP. Specifications defining other transport protocols must define what this means for them. For UDP-based local transport addresses, sending from the local transport address has the meaning one would expect - the request is sent such that the source IP address and port equal that of the local transport address. For reflexive transport addresses, it is sent by sending from the associated local transport address used to derive that reflexive address. For relayed transport addresses, it is sent by using STUN mechanisms to send the request through the STUN relay (using the Send request). Sending the request through the STUN relay server necesarily requires that the request be sent from the client, using the local transport address used to derive the relayed transport address. The Binding Request sent by the agent MUST contain the USERNAME attribute. This attribute MUST be set to the transport address pair ID of the corresponding transport address pair as seen by its peer. Thus, for the first transport address pair in Figure 7, if the agent on the left sends the STUN Binding Request, the USERNAME will have the value R:1:L:1. If the agent on the right sends the STUN Binding Request, the USERNAME will have the value L:1:R:1. To be clear, the USERNAME that is used is NOT the one seen locally, but rather the one as seen by its peer. The request SHOULD contain the MESSAGE- INTEGRITY attribute, computed according to [12]. The key used as input to the HMAC is the password provided by the peer for this remote transport address. This password will be identical for all remote transport addresses for the same media stream. Note that all ICE implementations are required to be compliant to [12], as opposed to the older [14]. Consequently, all connectivity checks will contain the magic cookie in the STUN header, and cause the STUN server embedded in each ICE implementation to include XOR- MAPPED-ADDRESS attributes in the response, rather than MAPPED- ADDRESS. Once created, the STUN transaction is linked to the transport address pair so that, when the response is received, the state machine on the linked transport address pair can be updated. The STUN transaction will generate either a timeout, or a response. If the response is a 420, 500, or 401, the agent should try again as described in [12] (as mentioned above, it need not wait the roughly Rosenberg Expires December 28, 2006 [Page 43] Internet-Draft ICE June 2006 Tb seconds to try again). Either initially, or after such a retry, the STUN transaction might produce a non-recoverable failure response or a failure result inapplicable to this usage of STUN and thus unrecoverable. If this happens, an error event is generated into the state machine, and the transport address pair enters the invalid state. If the STUN transaction times out, the client SHOULD NOT retry. The only reason a retry might succeed is if there was severe packet loss during the duration of the check, or the answer was significantly delayed, also due to packet loss. However, STUN Binding Request transactions run for 9.5 seconds, which is well beyond the typical tolerance for a session establishment. The retries come with a penalty of additional traffic, which can be used to launch DoS attacks (see Section 13.4.2). The only reason to not follow the SHOULD NOT is if the agent has adjusted the STUN transaction timers to be more aggressive. If the Binding Response is a 200, the agent SHOULD check for the MESSAGE-INTEGRITY attribute and verify it, as discussed in [12]. Indeed, this check SHOULD be done for all responses. This will result in the response being discarded (eventually leading to a timeout), if the integrity check fails. 7.8. Receiving a Binding Request for Connectivity Checks As a result of providing a list of candidates in its offer or answer, an agent will receive STUN Binding Request messages. An agent MUST be prepared to receive STUN Binding Requests on each local transport address from the moment it sends an offer or answer that contains a candidate with that local transport address. Similarly, it MUST be prepared to receive STUN Binding Requests on a local transport address the moment it sends an offer or answer that contains a derived candidate derived from that local transport address. It can cease listening for STUN messages on that local transport address after sending an updated offer or answer which does not include any candidates with transport addresses that are equal to or derived from that local transport address. As discussed in [12], since the username and password for STUN requests are exchanged through another mechanism - here, ICE - the Shared Secret Request mechanism is not needed and need not be implemented by agents that provide the connectivity check usage. One of the candidates may be in use as the operating candidate, or may become promoted to the operating candidate in the next offer/ answer exchange as a consequence of a successful validation. In either case, both media and STUN packets will be sent to the Rosenberg Expires December 28, 2006 [Page 44] Internet-Draft ICE June 2006 transport addresses comprising that candidate, causing both to receive on their associated local transport addresses. The agent MUST be able to disambiguate them. This is done trivially by looking for the STUN magic cookie as the value of the second 32-bit word in the packet. If present, it identifies a STUN packet. Processing of the Binding Request proceeds in two steps. The first is generation of the response, and the second is ICE-specific processing. Generation of the response follows the general procedures of [12], and is independent of the state machinery described in Section 7.6. The USERNAME is considered valid if one of the candidate IDs sent in an offer or answer is a prefix of the USERNAME (this will always be the case, even for peer reflexive candidates), and for the component indicated in the USERNAME, the associated local transport address matches the local transport address on which the request was received. The password associated with that candidate ID, which was provided by the agent to its peer, is used to verify the MESSAGE-INTEGRITY attribute, if one was present in the request. If the USERNAME is not valid, the agent generates a 430. Otherwise, the success response will include the XOR-MAPPED- ADDRESS attribute, which is used for learning new candidates, as described in Section 7.10. The XOR-MAPPED-ADDRESS attribute is constructed using the source IP address and port of the Binding Request. For Binding Requests received over relayed transport addresses, this MUST be the source IP address and port of the Binding Request when it arrived at the relay, prior to forwarding towards the agent. That source transport address will be present in the REMOTE- ADDRESS attribute of a STUN Data Indication message, if the Binding Request was delivered through a Data Indication. If the Binding Request was not encapsulated in a Data Indication, that source address is equal to the current active destination for the STUN relay session. The ICE processing involves changes to the state machine for a transport address pair. This processing cannot be done until the initial offer/answer exchange has completed. As a consequence, if the offerer received a Binding Request that generated a success response, but had not yet received the answer to its offer, it waits for the answer, and when it arrives, then performs the ICE processing. The agent takes the entire contents of the USERNAME, and compares them against the transport address pair identifiers as seen by that agent for each transport address pair. If there is no match, nothing is done - this should never happen for compliant implementations. If there is a match, the resulting transport address pair is called the matching transport address pair. The state machine for the matching transport address pair is then updated based on the receipt of a STUN Rosenberg Expires December 28, 2006 [Page 45] Internet-Draft ICE June 2006 Binding Request, and the resulting actions described in Section 7.6 are undertaken. An agent will continue to receive periodic STUN connectivity checks on a local transport address as long as it had listed that transport address, or one derived from it, in an a=candidate attribute in its most recent offer or answer and the transport address is for UDP. Whether STUN keepalives are used for other transport protocols is defined by the specifications for that transport protocol. The agent processes any such transactions according to this section. It is possible that a transport address pair that was previously valid may become invalidated as a result of a subsequent failed STUN transaction. 7.9. Promoting a Candidate to Operating As a consequence of the connectivity checks, each agent will change the states for each transport address pair, and consequently, for the candidate pairs. When a candidate pair enters the valid state, and the agent is in the role of offerer for that candidate pair, the agent follows the logic in this section. The rules only apply to the offerer of a candidate pair in order to eliminate the possibility of both agents simultaneously offering an update to promote a candidate to operating. The agent locates the candidate pair in the candidate pair priority ordered list. If it is the highest priority candidate pair, the agent SHOULD send an updated offer immediately as described in Section 7.11.1. If it is not the highest priority candidate pair, and the states of all lower priority candidate pairs are Invalid, the agent SHOULD send an updated offer immediately. If it is not the highest priority candidate pair, and the state of at least one of the lower priority candidate pairs is Indeterminate, the agent does nothing. Tests have yet to begin for higher priority candidate pairs. If it is not the highest priority candidate pair, and none of the lower priority candidate pairs have a state of Indeterminate, the agents starts a timer, called the wait-state timer, but only if this timer is not already running. The timer is set to fire in Tws seconds. Tws SHOULD be configurable, and SHOULD have a default of Tws = max(0, 200ms - N*Tb), where N is the number of components for the candidates for this media stream. The 200ms allows for a single STUN retransmission (which takes 100ms) and an RTT of 100ms. This timer allows for a higher priority connectivity check to complete, in the event its STUN Binding Request was lost or delayed in the network. Note that the timer goes to zero as the number of components increases. If, prior to the wait-state timer firing, another connectivity check completes and a candidate pair is validated, there is no need to reset or cancel the timer. Once the Rosenberg Expires December 28, 2006 [Page 46] Internet-Draft ICE June 2006 timer fires, the agent SHOULD issue an updated offer as described in Section 7.11.1. This updated offer will use the highest priority candidate pair in Valid state when the timer fires. 7.10. Learning New Candidates from Connectivity Checks ICE makes use of reflexive addresses, which are addresses that inform an agent of its transport address as seen by another host. An initial offer or answer generated by an agent includes server reflexive addresses, which are learned from a configured or discovered STUN server in the network. However, the connectivity checks themselves can inform an agent of reflexive addresses, and in particular, ones that are reflexive towards its peer. These are called peer reflexive candidates. A new peer reflexive candidate is typically observed when two agents are separated by a NAT with the address-dependent or address and port dependent mapping properties [32]. However, in unusual topologies, peer reflexive candidates can be observed even when there are only NATs with the endpoint independent mapping property. Because STUN and the media packets are sent on the same port, regardless of the filtering properties of the NAT (whether endpoint independent, address dependent, or address and port dependent), this reflexive address can be used by the peer for sending STUN and media packets back towards the agent. To obtain and use these peer reflexive transport addresses, ICE agents MUST perform the additional processing on the receipt of STUN Binding Requests and responses described in the following two subsections. These procedures are not just applied in the (hopefully increasingly rare) case of address and port dependent mapping NATs. They are also needed for behave-compliant NATs [32]. 7.10.1. On Receipt of a Binding Request The procedures in this section are followed when an agent receives a STUN Binding Request matched to a target transport address pair whose source transport address (where the source is the one seen by the relay for requests received on a relayed transport address) doesn't match any of the existing remote transport addresses, or where the source matches, but the origination transport address does not. This source address and its associated origination transport address become a new remote transport address. To use it, that source transport address needs to be associated with a candidate (called a peer-derived candidate). In this case, however, the candidate isn't signaled through an offer/answer exchange; it is constructed dynamically from information in the STUN request. Like all other candidates, the peer-derived candidate has a candidate ID. The candidate ID is derived from the candidate IDs of Rosenberg Expires December 28, 2006 [Page 47] Internet-Draft ICE June 2006 the target candidate pair. In particular, the candidate ID is constructed by concatenating the remote candidate ID with the native candidate ID (without the colon). The password for the new candidate equals that of the remote candidate ID in the target candidate pair (note that, this password would be the same for all remote candidates for the same media line). When the STUN Binding Request is received, the agent constructs the candidate ID for the peer reflexive candidate, and checks to see if that candidate exists. It may already exist if it had been constructed as a consequence of a previous application of this logic on receipt of a Binding Request from a different remote transport address of the same new peer reflexive candidate. If there is not yet a peer reflexive candidate with that candidate ID, the agent creates it, and assigns it the newly computed candidate ID. The priority of the peer-derived candidate is set to the priority of its generating candidate. The genera