Subject: [MMUSIC] Problem with Pairing Peer-Reflexive Candidates in ICE

From: Philip Matthews <[email-masked]>
Date: Thu, 29 Jun 2006 11:03:24 -0400

Currently, the ICE specification states that a peer-reflexive candidate
is ONLY paired with the remote candidate that was involved in
discovering it. However, Eric and I have discovered an example where
this results in an optimal communication path NOT being discovered
(and where the optimal path WOULD be discovered if peer-reflexive
candidates were paired with other candidates).

We briefly summarize the example below. Full details can be found at
   www.magma.ca/~philip_matthews/Peer-Reflexive-Pairing-Problem.pdf

Consider the following network. Here the candidates are indicated with
stars (*) and labeled L1, L2, etc.

         +-------------+                  +------------+
         | STUN Server |                  | STUN/TURN  |
         |      S      |              R5  * Server ST  |
         +-------------+                  +------------+

              L2                               R4
           +----*-----------------------------*------+
           |               NAT  N                    |
           +-----------------------------------------+

                                             +------------+
                                             | STUN/TURN  |
                                         R3  * Server STR |
                                             +------------+

          L1R3                            R1L1R3     R2
+------*-+                                   +*----*--+
| NAT NL |                                   | NAT NR |
+--------+                                   +--------+

    /\                                            /\
   /  * L1                                       /  * R1
  /  L \                                        /  R \
+------+                                      +------+

Both L and R get internet access from a provider that NATs its
entire network using NAT N. NAT N is almost BEHAVE-compliant,
but does not support hairpinning.
L is a home phone whose owner has purchased a simple NAT which
happens to be BEHAVE-compliant. L came pre-configured to use
STUN server S.
R is a corporate phone. R is behind a symmetric NAT NR
(= address-and-port-dependent mapping, address-and-port-dependent
filtering). R is configured to use two STUN/TURN servers:
server ST has a public IP address, while server STR is located
inside the ISP's network.

During the initial gathering of candidates phase, L learns only
L1 and L2. It does NOT learn a server-reflexive candidate on NL
because L is not configured to use a STUN server that could give it
that information.

But, as the connectivity checks proceed, L and R learn a peer-reflexive
candidate for L on NL. This peer-reflexive candidate is learned while
checking candidate pair (L1, R3), and thus the rules
of [ICE-08] say that the peer-reflexive candidate is named L1R3 and
it is paired only with R3, which is the candidate that helped find it.

HOWEVER, if the rules of ICE were changed to pair this new candidate
with R1 as well, then the connectivity checks for (L1R3, R1) would find
a second peer-reflexive candidate, which would be named R1L1R3.
This would then give rise to the pair (L1R3, R1L1R3), which is the
optimal path.

The obvious fix for this problem is to pair native peer-reflexive  
candidates
with *ALL* remote candidates, not just the one that was involved in
discovering it. However, this fix has the side effect of almost doubling
the number of candidate pairs (from 10 to 18) -- a huge increase with
corresponding increase in messaging. It may be that it is sufficient
to pair the peer-reflexive candidate with just certain other candidates.
This needs more investigation.

- Philip

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