Subject: [MMUSIC] much beefier tutorial in ICE - preview text

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jun 2006 15:31:27 -0400

So, its clear from the various comments on ICE-08 that ICE is still too 
hard to understand. One of the problems, it seems, is that it requires 
multiple passes to understand. One has to more or less get it in order 
to make any sense at all of the terminology section. The overview 
section is also really terse and doesn't explain enough of the core 
concepts.

So, I've taken a stab at substantially increasing the content in the 
overview section, which would then be moved prior to the terminology 
section as suggested. I'll be submitting ice-09 probably monday morning 
at 859am, so I figured I'd float the proposed text to get comments. I'm 
particularly looking for input on whether this tutorial is 
understandable starting only with a very high levle understanding of 
STUN and the problem to be solved (nat traversal for media).

Comments welcome:

<section title="Overview of ICE">

<t> A typical architecture for an ICE deployment is shown in <xref
target="fig:ice-ref-arch"/>. 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 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 <xref
target="RFC3264"/> 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.
</t>

<t>
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.
</t>

<figure anchor="fig:ice-ref-arch"><artwork>
<![CDATA[

                            +-------+
                            | SIP   |
         +-------+          | Srvr  |          +-------+
         | STUN  |          |       |          | STUN  |
         | Srvr  |          +-------+          | Srvr  |
         |       |                             |       |
         +-------+                             +-------+

             +--------+                   +--------+
             |  NAT   |                   |  NAT   |
             +--------+                   +--------+

         +-------+                             +-------+
         | Agent |                             | Agent |
         |   L   |                             |   R   |
         |       |                             |       |
         +-------+                             +-------+
]]></artwork></figure>

<t>
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.
</t>

<t>
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.
</t>

<t> 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.
</t>

<t>
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.
</t>

<t> 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 <xref
target="I-D.ietf-behave-rfc3489bis"/> or the Relay Usage <xref
target="I-D.ietf-behave-turn"/> 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 <xref target="fig:address-types"/>.
</t>

<figure anchor="fig:address-types"><artwork>
<![CDATA[
               To Internet

                   |
                   |
                   |  /------------  Relayed
                   | /               Address
               +--------+
               |        |
               |  STUN  |
               | Server |
               |        |
               +--------+
                   |
                   |
                   | /------------  Server
                   |/               Reflexive
             +------------+         Address
             |    NAT     |
             +------------+
                   |
                   | /------------  Local
                   |/               Address
               +--------+
               |        |
               | Agent  |
               |        |
               +--------+
]]></artwork></figure>

<t>
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 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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<figure anchor="fig:cand-relations"><artwork>
<![CDATA[

            Server                         Server
           Reflexive                      Reflexive
           Candidate                      Candidate
         ..............                 ..............
         .            .                 .            .
         .  +-+  +-+  .                 .  +-+  +-+  .
         .  | |  | |  .                 .  | |  | |  .
         .  +-+  +-+  .                 .  +-+  +-+  .
         .   ^    ^   .                 .   ^    ^   .
         ....|....|....                 ....|....|....
             |    |                         |    |
             |    |                         |    |
         ....|....|....                 ....|....|....
         .   |    |   .                 .   |    |   .
         .  +-+  +-+  .   Local         .  +-+  +-+  .   Local
         .  | |  | |  . Candidate       .  | |  | |  . Candidate
         .  +-+  +-+  .                 .  +-+  +-+  .
         .   |    |   .                 .   |    |   .
         ....|....|....                 ....|....|....
             |    |                         |    |
             |    |                         |    |
         ....|....|....                 ....|....|....
         .   V    V   .                 .   V    V   .
         .  +-+  +-+  .                 .  +-+  +-+  .
         .  | |  | |  .                 .  | |  | |  .
         .  +-+  +-+  .                 .  +-+  +-+  .
         .            .                 .            .
         ..............                 ..............
            Relayed                        Relayed
           Candidate                      Candidate

                                Legend
                                ------

                         +-+
                         | | Transport Address
                         +-+

                        ---> Derived From

                         ...
                         . . Candidate
                         ...

]]></artwork></figure>

<t>
The relationship between these various transport addresses and
candidates is shown pictorially in <xref
target="fig:cand-relations"/>. 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.
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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 active candidate, since it is
the one that is the active destination for receipt of media traffic.
</t>

<t>
Once the active 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 active candidate, just like the offered
did. It then sends the answer.
</t>

<t>
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 tids of its two transport addresses.
</t>

<t>
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.
</t>

<t>
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.
</t>

<t>
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 tids 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.
</t>

<t>
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 <xref
target="I-D.ietf-behave-rfc3489bis"/>. Like all STUN servers, when the
agent sends a STUN response to a request, the response includes the
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, 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 MAPPED-ADDRESS attribute of the STUN
response, therefore constitutes a new transport address, called a peer
reflexive transport address, which can be used for communications.
</t>

<figure anchor="fig:peer-example"><artwork>
<![CDATA[
                                    +-------+
                                    | STUN  |
                                    | Srvr  |
                                    |       |
                                    +-------+
                                         ^
                                         |
                                         |
                                         |
                                         |
           +--------------------------+  |
           |                     NAT-2|  |NAT-1
           |                      +-----------+
           |                      |  APD NAT  |
           |                      +-----------+
           |                          |  |
           |                           \ |
           VL1                          \|R1
       +-------+                    +-------+
       | Agent |                    | Agent |
       |   L   |                    |   R   |
       |       |                    |       |
       +-------+                    +-------+
]]></artwork></figure>

<t>
Consider the example of <xref target="fig:peer-example"/>. 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.
</t>

<t>
This new peer reflexive transport address is paired up with the 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.
</t>

<t>
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 active". The
updated offer only contains a single candidate attribute - the one for
the active 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.
</t>

<t> 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 <xref target="sec:send-media"/>. </t>

<t>
A summary of this overall behavior is shown in the basic call flow in
<xref target="fig:ice-model"/>.
</t>

<figure anchor="fig:ice-model"><artwork>
<![CDATA[
        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          |                     |
           |<------------------------------------------|

]]></artwork></figure>

</section>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 20 Jun 2006 16:11:54 -0500

I believe this text does help. Thanks for doing this.

Minor comments:
---------------

Your reference [37] should be draft-ietf-behave-nat-udp-07
instead of draft-ietf-behave-nat-udp-00.... (But really, it
is in final stages of being RFC so it should be updated
before publication). Might be worthwile to go through all the
refernces.

I find the use of "variable" for IP addresses and domain names
and others in SDP quite difficult to read. Also, I'm just having
visions of implementations in the wild putting $L1, $STUN-PUB-1.IP
and so forth in SDP... I'd much rather have examples with actual 
IP addresses and real domain names.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 12:31
> To: IETF MMUSIC WG
> Subject: [MMUSIC] much beefier tutorial in ICE - preview text
> 
> 
> <t> A typical architecture for an ICE deployment is shown in 
> <xref target="fig:ice-ref-arch"/>. 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 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 <xref 
> target="RFC3264"/> 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. </t>
> 
> <t>
> 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. </t>
> 
> 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. </t>
> 
> <t>
> 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. </t>
> 
> <t> 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. </t>
> 
> <t>
> 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. </t>
> 
> <t> 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 <xref target="I-D.ietf-behave-rfc3489bis"/> 
> or the Relay Usage <xref target="I-D.ietf-behave-turn"/> 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 <xref 
> target="fig:address-types"/>. </t>
> 
> 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 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. </t>
> 
> <t>
> 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. </t>
> 
> <t>
> 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. </t>
> 
> The relationship between these various transport addresses 
> and candidates is shown pictorially in <xref 
> target="fig:cand-relations"/>. 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. </t>
> 
> <t>
> 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. </t>
> 
> <t>
> 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. </t>
> 
> <t>
> 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 active candidate, since 
> it is the one that is the active destination for receipt of 
> media traffic. </t>
> 
> <t>
> 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 active candidate, just like the offered 
> did. It then sends the answer. </t>
> 
> <t>
> 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 tids of its two transport addresses. </t>
> 
> <t>
> 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. </t>
> 
> <t>
> 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. </t>
> 
> <t>
> 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 tids 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 
> connectivity checks are taking place with the agent which 
> responded to the signaling. </t>
> 
> <t>
> 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 <xref 
> target="I-D.ietf-behave-rfc3489bis"/>. Like all STUN servers, 
> when the agent sends a STUN response to a request, the 
> response includes the 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, 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 
> MAPPED-ADDRESS attribute of the STUN response, therefore 
> constitutes a new transport address, called a peer reflexive 
> transport address, which can be used for communications. </t>
> 
> Consider the example of <xref target="fig:peer-example"/>. 
> 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. </t>
> 
> <t>
> This new peer reflexive transport address is paired up with 
> the 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. </t>
> 
> <t>
> 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 active". The updated offer only 
> contains a single candidate attribute - the one for the 
> active 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. </t>
> 
> <t> 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 <xref 
> target="sec:send-media"/>. </t>
> 
> 
> <t>
> A summary of this overall behavior is shown in the basic call 
> flow in <xref target="fig:ice-model"/>. </t>
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 15:05:46 -0400

inline.

> I believe this text does help. Thanks for doing this.

I did. Thanks. This never went beyond -00 because I had hardcoded the 
reference when an earlier ICE draft came out, and the behave-nat draft 
hadn't quite appeared yet and so wasn't in my bibliography.

> IP addresses and real domain names.

Yeah, Philip made this request too. I will do that.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Fri, 23 Jun 2006 15:29:18 -0400

> Yeah, Philip made this request too. I will do that.

Just to be clear, I just asked for ONE example with real candidate IDs.
The other examples can use  fake candidate IDs.

I fully understand why Jonathan uses fake IDs in his example,
and I do find fake IDs easy to read and work with.
My own preference is for IDs of the form L1, L2, L3, ...
and R1, R2, R3, ...  rather than $STUN-PUB-1, etc
because I find it easier to match things  up.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 16:37:02 -0400

inline.

Philip Matthews wrote:

>>> and so forth in SDP... I'd much rather have examples with actual  IP 
>>> addresses and real domain names.
>>
>>

Yes, I understand. My plan is to take one of the SDP in the examples 
section and show it with the variables filled in. Trust me, I have 
neither the time nor the energy nor the interest to do more than one ;)

-Jonathan R.

---

From: "Rohan Mahy" <[email-masked]>
Date: Sat, 24 Jun 2006 13:43:50 -0700

Hi Jonathan,

I think this is a big improvement.  Its much easier for a first time
reader to get oriented.  I have several minor suggestions inline.

On 6/20/06, Jonathan Rosenberg <[email-masked]> wrote:
> as agents in RFC 3264 terminology)

the reader doesn't care yet that we are using RFC3264 terminology.
Since "agent" is so fundamental, I propose:

The figure shows two endpoint known as "agents", which we call...

>which we call L and R (for left and

Is there a reason to use both A/B and L/R?  I would stick with just one.

> one

one or more of which...

> more of which might be viable addresses at which the agent can
> port.

and IP address family?

>With ICE, an agent will actually provide its peer with all of

I don't think this diagram or the paragraph immediately after it add
to the explanation before them.  I would remove them.

> a candidate identifier, called the candidate ID.

"it assigns each a candidate ID".

The candidate ID is a
> candidates, there will be N*M candidate pairs.

suggest a paragraph break here:

>Within each candidate

At this point, I think an example would be very useful.  How about
something like this:

</t>
For example, assume Agent A has three candidates: abcd, hijk, and
lmno, each with 2 components (one for RTP and one for RTCP), and Agent
B has two candidates: stuv and wxyz, each with 2 components (one for
RTP and one for RTCP). This yields a total of 6 candidate pairs, and
12 transport address pairs:
</t>
<figure><artwork>
  RTP pairs     RTCP pairs
abcd1:stuv1   abcd2:stuv2
abcd1:wxyz1   abcd2:wxyz2
hijk1:stuv1   hijk2:stuv2
hijk1:wxyz1   hijk2:wxyz2
lmno1:stuv1   lmno2:stuv2
lmno1:wxyz1   lmno2:wxyz2
</artwork></figure>

> transport address of a particular transport address pair.

new paragraph

> If an agent

I recommend moving the peer reflexive transport address discussion to
fall after the rest of the normal cases are described.

> m/c-line.

propose replacing this with:
Once all of the transport address pairs in a candidate pair have been
validated, that candidate pair is ready to be used. The Agent can
start sending media over the highest priority, valid candidate pair.
If the candidate pair being used is different than the active pair,
the offerer sends an updated offer with the newly selected candidate
pair in the m/c-line.

This is called "promoting a candidate to active". The
> the active candidate.

I would move the peer reflexive discussion here, possibly as a subsection

This next paragraph is a pretty advanced detail.  I'm not sure this
needs to be mentioned in the Overview at all.
>It also contains an attribute, called the

The diagram also illustrates my concern with using the term Answer in
(4).  After an unreliable 18x, you can do STUN checks and send media,
but you can't send a new Offer (9) until the real answer  sent in the
200 is acknowledged with an ACK.  If we are sloppy on this point, we
will have non-interoperable ICE implementations.

thanks,
-rohan