TURN returning multiple MAPPED-ADDRESSes

Jon Ringle <[email protected]> Sat, 18 Sep 2004 23:17:46 -0400
Newsgroups gmane.ietf.midcom
Message-ID <[email protected]>
Hello,

I have been studying ICE, STUN, and TURN. I believe that I have come up with a 
theoretical scenario where TURN in it's current incarnation would have a 
problem. Perhaps there is another way to solve the problem I describe below?

Consider the following topology:

                     +--------+       +----------+
                     |        |       |   /  \   |
                     |  PC    |          /SIP \
                     |        |         /Phone \
                     |        |        /  102   \
                     +--------+       ------------

                         +--------+-------+
                         |      NAT A     |
                         |    Symmetric   |
                         +----------------+
                                  | DSL, Cable
                         --+-------------+--
                  ///////                   \\\\\\\
               ///                                 \\\
             ||                                       ||
            |                Internet                   |
           |                                             |
            |                                           |
             ||                                       ||
               \\\                                 ///
                  \\\\\\\                   ///////
                         ---------+---------
                                  |
                              192.0.2.1
                            +------------+
                            |   NAT B    |
       ---------------------| Symmetric  |--------------------------
                            | No hairpin |
        10.0.0.0/16         +------------+                  DMZ



                 +---------+              +---------+
                 |         |              | TURN/   |
                 | Proxy   |              | STUN    |
                 |         |              |  Server |
                 +---------+              +---------+
                                           10.0.1.1

      ...........................................................


                              +----------+
                              |   /  \   |
                                 /SIP \
                                /Phone \
                               /  101   \
                              ------------

The following properties apply to the devices:
SIP Phone 102:
	Initiator
	Configured to use TURN/STUN server at 192.0.2.1

NAT A:
	symmetric

NAT B:
	symmetric, no hairpin.
	Forwards 5060 to Proxy.
	Forwards 3478, 5556, and range of UDP ports for RTP to TURN/STUN Server.

SIP Phone 101:
	Responder
	Configured to use TURN/STUN server at 10.0.1.1

Both 102 and 101 will collect a set of local, STUN and TURN derived addresses. 
However, when 101 does it's connectivity checks on the derived addresses 
supplied by 102, none of them will succeed. The local address will obviously 
not work. 101's attempt on STUN on 102's STUN derived address will not 
succeed because the Home NAT is symmetric. 101's attempt on STUN on 102's 
TURN derived address (192.0.2.1:xyz) will also not work because Firewall NAT 
does not support hairpinning.

The scenario could work if the TURN server had a way of returning multiple 
MAPPED-ADDRESSes for a single Allocate request. Then the following could 
happen:

1) SIP Phone 102 requests TURN Allocate.
2) TURN server Responds with 2 MAPPED-ADDRESSes: 192.0.2.1:xyz and 
10.0.1.1:xyz
3) SIP Phone 102 now has 2 TURN derived addresses to offer SIP Phone 101.
4) SIP Phone 101 could attempt STUN on TURN derived address 10.0.1.1:xyz first 
based on the fact that it is itself a part of a net-10 network (although this 
does not guarantee connectivity, but would result in a shorter path than the 
other TURN derived address in the case where NAT B did support hairpinning).
5) SIP Phone 102 successfully contacts SIP Phone 101's STUN server.

Thanks for taking the time to review this idea. If there is a way to 
accomplish this already with the current proposed drafts, kindly point me in 
the right direction.

Jon