Subject: [BEHAVE] ICE performance

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jul 2007 07:33:02 -0700

(Changing subject line) 

> -----Original Message-----
> From: David Barrett [mailto:[email-masked]] 
> Sent: Tuesday, July 17, 2007 1:04 AM
> To: 'Dan Wing'; 'Henry Sinnreich'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [BEHAVE] Re: removing application milestone
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[email-masked]]
> > 
> > What's the latency if there are no NATs involved whatsoever?  Your
> > numbers indicate hundreds of milliseconds for every NAT scenario,
> > even for the kinds of NATs that allow connections from any IP
> > address.  NATs do not, on their own accord, add hundreds of
> > milliseconds of delay.  If they did, DNS queries would take too
> > long and people would complain that "the Internet" is slow (web
> > pages with lots of embedded objects on different servers).
> 
> I'm not sure I follow.  The times I gave were the elapsed ms 
> it took to establish the connection from start to finish.  So 
> it'd be roughly:
> 
> (The RTT time between A and the RZ server) +
> (The processing time inside the RZ) +
> (The RTT time between A and B) +
> (The three-way handshake and NAT penetration time)

Without any NATs, that last event (NAT penetration time) doesn't occur.  I'm
curious what times you have without any NATs.  This would allow learning the
NAT penetration time for the non-ICE NAT traversal technique you're using.

> Thus in general, it takes a second or less to establish the 
> connection. 

By 'the connection', I believe you're referring to that last step (3 way
handshake and NAT penetration time)?

Is the 3-way handshake TCP, or is that your NAT penetration code doing a
3-way handshake?  I ask because ICE does a 4-way handshake (of sorts), which
is its NAT penetration.

> However, once that connection has been established, 
> there is no additional latency introduced by the system: packets 
> flow between A and B directly at whatever latency is introduced 
> by the intermediate networks.

Right.

> Does this answer your question?  How long does it typically 
> take ICE to establish a connection, including the "triggered 
> check" optimization? 

I don't know.  I don't have direct experience with ICE on 
the Internet.  I haven't seen any published information with
those numbers.  You may have noticed Henry asking for such
information on MMUSIC and on SIP, 
http://www1.ietf.org/mail-archive/web/mmusic/current/msg05997.html

> Is it also subsecond on average between any two points on the globe?

Most of the time, yes.

ICE always establishes a direct, peer-to-peer connection when it can.  
In some cases [such as two endpoints behind 'symmetric' NATs (RFC3489
terminology) or non-Endpoint-Independent Mapping NATs (RFC4787 
terminology)] there is no reliable technique to get a direct peer-to-
peer connection.  The unreliable technique to establish a direct 
peer-to-peer connection in that situation is to guess the port number 
assigned by the remote NAT.

-d

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 17 Jul 2007 08:48:36 -0700

> I ask because ICE does a 4-way handshake (of sorts), which
> is its NAT penetration.

This is a welcome discussion and points to the fact that we have no
published facts on ICE. Faith is a poor replacement for measurements.

ICE differs from say SIP in that it is far more than a protocol
agreement. ICE is a technology that has to deal with countless NAT
implementations and scenarios, with physical reality on the net vs.
getting an agreement on some protocol header or data format.

Excellent role models in BEHAVE where an I-D is based on facing and
measuring reality on the net are:

1. "NAT Classification Test Results"
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-jennings-behave-
test-results-04.txt  

and 

2. "Application Design Guidelines for Traversal through Network Address
Translators" 
<
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ford-behave-app-
05.txt> which is based on test tools and real testing on the net, as
reported in 

"Peer-to-Peer Communication Across Network Address Translators" 
http://www.brynosaurus.com/pub/net/p2pnat/ 

This is BTW the reason why I have argued <draft-ford-behave-app-05.txt>
to be a WG item.

Dan: Is there a way to squeeze it in?

To conclude; this discussion would not have taken place if we would have
had deployment results for ICE.

Thanks, Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 7:33 AM
To: 'David Barrett'; Henry Sinnreich; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: ICE performance 

(Changing subject line) 

> (The three-way handshake and NAT penetration time)

Without any NATs, that last event (NAT penetration time) doesn't occur.
I'm
curious what times you have without any NATs.  This would allow learning
the
NAT penetration time for the non-ICE NAT traversal technique you're
using.

Is the 3-way handshake TCP, or is that your NAT penetration code doing a
3-way handshake?  I ask because ICE does a 4-way handshake (of sorts),
which
is its NAT penetration.

Right.

Most of the time, yes.

-d

---

From: Guilherme Balena Versiani <[email-masked]>
Date: Tue, 17 Jul 2007 13:46:10 -0300

Hello Dan,

I run a VoIP network on Internet that uses ICE-08 for establishing 
peer-to-peer sessions (we are now migrating to ICE-17). This network has 
about 80,000 registered clients. I will add below some practical values 
to this discussion. Comments in-line.

> NAT penetration time for the non-ICE NAT traversal technique you're using.
First, we use "Binding Discovery" (as defined in RFC 3489) to determine 
the minimal number of candidates to offer (the least the candidates, 
less time to complete). So, if the client is behind Open and Cone NATs, 
we do not allocate Relay candidates (we use a proprietary HTTPS Tunnel 
Relay, so its use is something expensive). The default "Binding 
Discovery" process takes so much time to complete, so we have made some 
optimization of the process, so now it concludes in 2.5s at most.

The "Checking" time for open x open NATs (ICE-17) is about an RTT 
between the two peers (plus half a SIP message delay between them) -- 
the practical values is about 100-300ms for our current operation (as 
expected, you get much less time if the two peers are in the same 
network connections -- about 20-50ms). For the cases where a Relay 
candidate is needed, the total time is the negotiation time between the 
local host and the Relay server plus an RTT between Relay server and 
remote peer -- as we run an HTTPS Relay, the time is much greater than a 
TURN/STUN Relay server, and that time is about 1000-1300ms.

There are worst cases in which the concluding time is about 1500-3500ms 
(it occurs occurs when the two peers are behind UDP blocked firewalls, 
so we need two Relays to complete the call, and in this case the audio 
latency is very worse than 700ms).

You could expect less time than 1000-1300ms for normal TCP connections, 
as we have SSL plus HTTP negotiation before sending packets (this long 
time is due a TCP 3-way-handshake, an SSL negotiation and an HTTP 
request/response). For an approximation, you could divide the total 
value by three, so the expected time would be 350-450ms for our 
conditions. But these values change between implementations and network 
conditions, so you must expect different values around the globe.

Regards,

Guilherme Balena Versiani.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jul 2007 10:19:31 -0700

> peer-to-peer sessions (we are now migrating to ICE-17). This 
> network has about 80,000 registered clients. I will add below 
> some practical values to this discussion. Comments in-line.
> 
> Dan Wing wrote:
> First, we use "Binding Discovery" (as defined in RFC 3489) to 
> determine the minimal number of candidates to offer (the least 
> the candidates, less time to complete). So, if the client is 
> behind Open and Cone NATs, we do not allocate Relay candidates 
> (we use a proprietary HTTPS Tunnel Relay, so its use is something 
> expensive). 

As an aside:

   (Analyzing the NAT's type is risky.  For example, I am familiar
   with the operation of one of Cisco's NATs which, depending on
   exactly how ports are allocated, can appear to be a 'cone' NAT but
   if ports are allocated differently will be 'symmetric' (and thus
   will need a media relay). This specific NAT is not the sole example
   of this behavior in the market.  But this sort of non-deterministic
   behavior is why we deprecated learning the style of NAT (symmetric,
   cone, etc.) in draft-ietf-behave-rfc3489bis.  Mind you, I'm not
   saying "the optimization you are doing doesn't work"; I am just
   saying that the optimization you are doing is risky because, for
   some kinds of NATs in some situations, this optimization will fail
   to establish a connection.)

> The default "Binding Discovery" process takes so much time to 
> complete, so we have made some optimization of the process, so 
> now it concludes in 2.5s at most.

I am interested in how those 2.5 seconds are being consumed --
when you say 2.5 seconds, are you considering the case where
you do a UDP STUN Binding Request and an HTTPS relay request?

A STUN binding discovery should take roughly the same amount 
of time as a DNS query; less, in fact, because the STUN server 
has far less processing to do than a DNS caching-only server.  

You should be seeing something closer to 100ms, worst case, for a 
DSL subscriber doing a STUN Binding Discovery.  If you send two 
STUN Binding Discovery requests (to two different servers, for
example a STUN server and a TURN server) and pace those requests
20ms apart (to avoid killing a low-end NAT), this should be 120ms 
of wall-clock time.

> network connections -- about 20-50ms).

If your network has 100-300ms of round trip delay, I guess it has
half that (50ms-150ms) of one-way delay, which is pretty high.

> For the cases where a Relay candidate is needed, the total time is
> the negotiation time between the local host and the Relay server
> plus an RTT between Relay server and remote peer -- as we run an
> HTTPS Relay, the time is much greater than a  TURN/STUN Relay
> server, and that time is about 1000-1300ms.
>
> There are worst cases in which the concluding time is about
> 1500-3500ms (it occurs occurs when the two peers are behind UDP
> blocked firewalls, so we need two Relays to complete the call, and
> in this case the audio latency is very worse than 700ms).
>
> You could expect less time than 1000-1300ms for normal TCP
> connections, as we have SSL plus HTTP negotiation before sending
> packets (this long time is due a TCP 3-way-handshake, an SSL
> negotiation and an HTTP request/response). For an approximation, you
> could divide the total value by three, so the expected time would be
> 350-450ms for our conditions. But these values change between
> implementations and network conditions, so you must expect different
> values around the globe.

Thanks,
-d

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Jul 2007 10:30:15 -0700

This is really, really fantastic.  Do you have any capability to measure
direct peer connectivity success rates on an individual or pairwise NAT
basis (I'm assuming that at worst it'll always "work" through a relay, but
I'm more interested in the direct case)?  Is it above 90%?

Also, I see excellent estimates and such made for the timing -- do you have
any solid measurements?

Basically, I've laid out the data as I've found it most valuable to obtain
for my own testing purposes, and I'd *love* to see ICE's capabilities laid
out in a similar fashion for direct comparison.  (Or, if you have ICE
connectivity/establishment-time data organized in a different way, I'd be
happy to reorganize my data to match.)

-david 

> From: Guilherme Balena Versiani [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2007 9:46 AM
> To: Dan Wing
> Cc: 'David Barrett'; 'Henry Sinnreich'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] ICE performance
> 
> Hello Dan,
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Jul 2007 10:39:45 -0700

(I adjusted the subject, because this thread is about BEHAVE's application
milestone).

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Tuesday, July 17, 2007 8:49 AM
> To: Dan Wing; David Barrett; [email-masked]
> Subject: [BEHAVE] RE: ICE performance 
> 

I don't believe draft-ford-behave-app-05.txt contains the
same information as http://www.brynosaurus.com/pub/net/p2pnat.  
Rather, draft-ietf-behave-p2p-state-03.txt seems to contain the same
information as http://www.brynosaurus.com/pub/net/p2pnat.  
draft-ietf-behave-p2p-state-03.txt is a working group item, and I
expect to be issuing a WGLC in the next day or two.

In Prague's BEHAVE meeting, there was consensus to not adopt
draft-ford-behave-app, and there was consensus to remove our
application milestone altogether, per my post on April 11:
http://www1.ietf.org/mail-archive/web/behave/current/msg02128.html
which had no replies on the list until Suresh's reply on July 7,
http://www1.ietf.org/mail-archive/web/behave/current/msg02459.html

> To conclude; this discussion would not have taken place if we 
> would have had deployment results for ICE.

(I responded to that last point in your MMUSIC/SIP thread.)

-d

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Jul 2007 10:56:30 -0700

> NAT penetration time for the non-ICE NAT traversal technique you're using.

Well, the three-way handshake needs to occur either way.  So the only real
difference would be the "NAT penetration time", which in practice just means
"the time it takes for all the retries and voodoo to find a working route"
-- the exact same algorithm is used in all configurations**, it just happens
to work better/faster between some NAT pairs than others.  

Regardless, the specific answer to your question is "770ms" is how long it
takes on average between "fullstatic" and "fullstatic" clients (ie,
non-NAT'd, endpoint-independent filtering), which is about ~200ms faster
than the total average of "961ms".

** I've prototyped additional optimizations for symmetric/symmetric and
symmetric/rstrcone, but I don't have data on how effective those are.

> 3-way handshake?  I ask because ICE does a 4-way handshake (of sorts),

Correct, the connection is the last step.  My protocol is UDP based, but
does a 3-way handshake using strongly modeled off of TCP (though I find DCCP
to be a great model as well).

> > Is it also subsecond on average between any two points on the globe?

Er, I don't mean to be contrarian, but without data or direct experience,
how can you claim this?  I think you'll find as you get real-world data and
experience that all this works much slower and less reliably than you'd
expect.  At least, that has been my experience.  Thus I'd respectfully ask
that we stick to the data, and avoid (or at least label) guesswork.

> ICE always establishes a direct, peer-to-peer connection when it can.

Heh, this is a safe statement!

> assigned by the remote NAT.

Correct.  Does ICE support this?  I haven't had great luck with it myself,
but I haven't put a lot of energy into it yet.

-david

---

From: Guilherme Balena Versiani <[email-masked]>
Date: Tue, 17 Jul 2007 17:48:03 -0300

Comments in-line.

>    to establish a connection.)
OK, I know I am running against the current way of BEHAVE and MMUSIC. I 
know there are known issues in "Binding Discovery" usage, but I just let 
the market respond. Until now, for the current user profiles, I don't 
have a substantial problem. I just can't let the clients open an HTTPS 
Relay connection for all calls. It is overkill.
> you do a UDP STUN Binding Request and an HTTPS relay request?
This time is consumed during the "Binding Discovery" usage, as defined 
in RFC 3489 Section 10.1, and that I meant to be the "default" discovery 
process. If you follow the flow described there, for example, you could 
get 4 * T, where T is the STUN transaction time, for Restricted/Port 
Restricted Cones.

I think this could be of some interest of the current work: I developed 
a new flow to discover the NAT type, so I get the result in less time, 
based on the old draft-takeda-symmetric-nat-traversal-00.txt. The new 
flow is as follow:

Test I   ----\   /---- Try A
Test II  ----+---+---- Try B
Test III ----/   \---- Try C

After sending these requests I check the results and then I can 
determine the NAT type. The Test I, Test II and Test III have 
CHANGE-REQUEST "0b00" (no change), "0b10" (change IP), "0b11" (change IP 
and change port) respectivelly. The Try A, Try B and Try C have 
CHANGE-REQUEST "0b00" (no change). Then, the worst case is 2 * T instead 
of 4 * T. I check the results using the following flow:

+----------------+  N
| Test I worked? |-----> Blocked
+-------+--------+
        | Y                    +---> Open
        V                    Y |
+-------------+   Y    +-------+---------+  N
|  IP same?   |------->| Test II worked? |----> Sym Firewall
+-----+-------+        +-----------------+
      | N
      V
+-----------------+  N  +------------------+
| Test II worked? |---->| Test III worked? |----> Port Sensitive
+-----+-----------+     +--------+---------+         Filter
      | Y                        |
      V                          V
  No Filter              Address Sensitive
                              Filter

For the last three types (No filter, Address Sensitive, Port Sensitive), 
I get the four allocated ports and name them as p0, p1, p2 and p3 for 
the MAPPED-ADDRESS (or XOR-MAPPED-ADDRESS as defined in 'bis') of Test 
I, Try A, Try B, and Try C respectively. Then a follow this flow:

+-----------------------------------+  Y
| p0 == p1 && p1 == p2 && p2 == p3? |----> Cone
+-----------+-----------------------+
            | N
            V
+----------------------------------+  Y
| p0 == p2 && p1 == p3 && p0 != p1 |-----> Exceptional
+-----------+----------------------+        Behavior
            | N
            V
+----------------------------------+  Y
| p0 == p1 && p1 == p2 && p2 != p3 |-----> Address Sensitive
+-----------+----------------------+         Allocation
            | N
            V
       Port Sensitive
         Allocation

Them I use the Table 6.3.1 in 
draft-takeda-symmetric-nat-traversal-00.txt to determine the NAT type:

      +----------------------+-----------------------------------+
      |                      |      Incoming Packet Filter       |
      |                      |-----------------------------------|
      |                      | No Filter | AS Filter | PS Filter |
      +----------+-----------+-----------+-----------+-----------+
      |          | Cone      | Full-cone |Restricted-|Port restr-|
      | Port     |           |           |cone       |icted-cone |
      |Allocation|-----------+-----------+-----------+-----------|
      | Rule     | AS        | Symmetric | Symmetric | Symmetric |
      |          | Symmetric |    (a)    |    (b)    |    (c)    |
      |          |-----------+-----------+-----------+-----------|
      |          | PS        | Symmetric | Symmetric | Symmetric |
      |          | Symmetric |    (d)    |    (e)    |    (f)    |
      +----------------------+-----------------------------------+
      AS: Address Sensitive, PS: Port Sensitive

The way described above is a more robust solution than described in RFC 
3489, and is capable to detect a known issue in Linux NAT boxes (this 
was written by Remi Denis-Courmont/Nokia):

"FYI, my personal experience with Linux/NetFilter was that it also showed
this symmetric behavior on an almost systematic basis when the firewall
part of NetFilter was configured to "accept" unexpected UDP traffic from
the outside, and that traffic happened to have the allocated port as a
destination. Linux would then reject the packet with ICMP Port
Unreachable and record a conflicting association of this port with
itself (ie. the NAT box) as a destination, instead of the user behind
the NAT."

BTW, *the normal use of RFC 3489 detects this type of NAT as Port 
Restricted*!

> has far less processing to do than a DNS caching-only server.  
I didn't compute the DNS resolution time.
> 20ms apart (to avoid killing a low-end NAT), this should be 120ms 
Yes, but the clients are distributed around many providers, so the STUN 
servers aren't so close to clients. The 150-300ms is a mean time for 
"outside clients" (if you are in the same provider as the STUN server, 
you would get less times).
> half that (50ms-150ms) of one-way delay, which is pretty high.
Yes, as I said, this value represents the "outside providers" around the 
globe. And the values varies for different networks and locations, so 
there are no "standard values".

Regards,

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 18 Jul 2007 10:39:45 +0300

> itself (ie. the NAT box) as a destination, instead of the user behind

I did write this. Note though that this is collected from running the Teredo 
qualification procedure (RFC4380), rather than classic STUN (RFC3489).

The major practical problem with NAT type checks that I've had is that it 
incorrectly return "cone" if the procedure is re-run too quickly, such as if 
the application is restarted.

> BTW, *the normal use of RFC 3489 detects this type of NAT as Port

If you used ICE, you would not care. However, if you used ICE, it might or 
might not work depending on the timing of each side's connectivity checks. 
The problem here is, when sending connectivity checks, you punch a hole in 
your NAT, but you may confuse the other side's NAT (particularly if it is an 
ICMP-sending NAT).

To have it (almost) always work with these annoying ICMP-sending NATs, you'd 
have to punch holes into your own NAT in a way that does not interfere with 
the peer's NAT, first. Once both sides have taken care of their own NAT, they 
would then actually start the real connectivity checks.

That looks nice on the paper. Unfortunately, it is not that easy. One way 
would consist of sending connectivity checks with synchronically increasing 
TTL values, but that would be terribly slow, unless you know exactly how many 
hops away your outermost NAT/firewall is. There are ways to determine this. 
For instance, you could send packets increasing TTL to a STUN or Teredo 
server's other address, then a  Binding Request with the change-address flag 
to the main address, until you receive a response.

I have never tested this, and I would expect this may either be impractical 
and/or break other types of NATs. Misconfigured Linux NATs are probably not 
the most common case.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Jul 2007 10:02:27 -0400

> your NAT, but you may confuse the other side's NAT (particularly if  

Can you describe, perhaps by providing a message sequence diagram,  
how ICE
might fail in this case? I don't understand the problem you are  
referring to.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Jul 2007 10:16:47 -0400

I think this is referring to the behavior of some NATs, which return 
ICMP port unreachable errors when receiving a packet on the outside from 
an unknown source.

In earlier versions of ICE the ICMP unreachable would instruct ICE to 
consider the check to have failed. That was actually fixed in a recent 
ICE revision, so that if you receive a connectivity check but a check in 
the previous direction had previously failed, you retry. This allows ICE 
to get a direct path in this case.

I'll note that, I'm sure we'll find other random NAT behaviors over 
time. THis is why ICE does a 'try lots of things' model, so that in the 
worst case it ends up with a relay but at least it works. THis way ICE 
correctness is not dependent on us guessing and handling all variations 
on NAT behavior.

-Jonathan R.

Philip Matthews wrote:
> Can you describe, perhaps by providing a message sequence diagram, how ICE

-- 
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

---

From: Guilherme Balena Versiani <[email-masked]>
Date: Thu, 19 Jul 2007 13:59:04 -0300

Comments in-line.

Jonathan Rosenberg wrote:
> (...) In earlier versions of ICE the ICMP unreachable would instruct 
> ICE to consider the check to have failed. That was actually fixed in a 
> recent ICE revision, so that if you receive a connectivity check but a 
> check in the previous direction had previously failed, you retry. This 
> allows ICE to get a direct path in this case.

I personally decided not to consider ICMP port unreachable as an error, 
as some "Port Restricted" NATs could respond ICMP error until a packet 
is directed to the peer. The "NAT ICMP issue", when it occurs, it 
persists very likely during the process of a ICE agent.

> might fail in this case? I don't understand the problem you are 

Describing Linux BUG ('X:x' is an IP address / port):

A               STUN Server            NAT               B
|                   |                   |<---------------|
|                   |<-----src:X:x------|                |
|                   |                   |                |
|                   |                   |                |
|-----dst:X:x-------------------------->|                |
|<--ICMP port unreach-------------------|                |
|                   |                   |                |
|                   |                   |<---------------|
|<----src:X:y---------------------------|                |
|                   |                   |                |
|                   |                   |                |

At a first glance, this behavior would not impact the ICE communication 
between a host without NAT (open) versus another host behind this type 
of NAT (this scenario will issue a peer derived candidate). But if the 
host 'A' is behind a "Port Restricted NAT", the connection has high 
probability to not establish on peer-to-peer basis: the host 'B' needs 
to pass a packet through NAT before a packet from host 'A' comes in 
(this way, the NAT works as a normal "Port Restricted NAT"). The Binding 
Discovery process is described before can detect this type of NAT as 
Symmetric, and not Port Restricted (as described in RFC 3489 and 
draft-ietf-behave-nat-behavior-discovery).

Regards,

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2007 10:23:30 -0700

> At a first glance, this behavior would not impact the ICE 
> communication between a host without NAT (open) versus 
> another host behind this type of NAT (this scenario will 
> issue a peer derived candidate).  But if the host 'A' is 
> behind a "Port Restricted NAT", the connection has high 
> probability to not establish on peer-to-peer basis: the host 
> 'B' needs to pass a packet through NAT before a packet from 
> host 'A' comes in (this way, the NAT works as a normal 
> "Port Restricted NAT"). 

Thanks for the write-up.  B's NAT is behaving as a symmetric NAT
because a host on the Internet (A) sent a UDP packet to that
port on B's NAT.  (Any well-timed UDP packet, sent maliciously 
or accidentally to that port on B's NAT would also cause B's 
NAT to become symmetric for that flow.  Perhaps too obscure 
of an attack to worry about?)

As you point out, ICE will not establish a peer-to-peer session
in this case (the case where one peer is behind a symmetric NAT 
and the other peer is behind a port-restricted NAT).  Instead, 
ICE will only be able to establish connectivity via a media 
relay.

> The Binding 

Yesterday I forwarded your previous email to the authors of
-ietf-behave-nat-behavior-discovery, and I think I CC'd you on that email.
I expect they'll integrate that test into a subsequent revision of their
document.

(As has been pointed out, but I want to restate for others reading this
thread:  ICE does not perform any tests to determine what kind of NAT
(symmetric, port-restricted, etc.) is in use.)

-d

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Jul 2007 14:05:08 -0400

> ICE will only be able to establish connectivity via a media

In ICE-17, the receipt of the ICMP port unreach will cause the
connectivity check from A to fail. [From section 7.1.2.1:
    Agents MAY support receipt of ICMP errors for connectivity checks.
    If the STUN transaction generates an ICMP error, the agent sets the
    state of the pair to Failed.  If the STUN transaction generates a
    STUN error response that is unrecoverable (as defined in
    [I-D.ietf-behave-rfc3489bis]), or times out, the agent sets the  
state
    of the pair to Failed.

However, the receipt of the subsequent Binding Request from B will  
cause the connectivity
check to go back to the Waiting state and B will retry the check.
[From section 7.2.1.4:

       *  If the state of the pair is Failed, it is changed to Waiting
          and the agent MUST create a new connectivity check for that
          pair (representing a new STUN Binding Request transaction), by
          enqueueing the pair in the triggered check queue.

So ICE will succeed (or should, I haven't done walked through the  
logic yet)
in this case.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2007 13:58:56 -0700

> logic yet) in this case.

Look carefully at Guilherme's diagram.  That subsequent message 
from B comes from a different source UDP port (because when B's 
NAT received the ICMP, B's NAT effectively switched into 
'symmetric' NAT behavior).  Up to this point, I agree that ICE
would set up peer-to-peer because of that subsequent message
from B.

However, in Guilherme's email, he indicated that A's NAT is a 
port-restrictive NAT.  Because of that, B's subsequent Binding 
Request (which is from a different port than A had been told
via the SDP offer/answer exchange) would be dropped by A's NAT.
ICE, on this peer-to-peer path, would be unable to complete.

-d