Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 1 Feb 2008 01:47:09 -0800

> For the simplicity, I think we should only admit peers with public
addresses
> to be the TURN servers at the first step.

This simplicity may be far too expensive in real deployments.
The effort to develop the protocol for TURN servers behind p2p friendly
NAT is fully justified IMHO.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Song Yongchao
Sent: Friday, February 01, 2008 8:22 AM
To: 'Cullen Jennings'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer

See inline
> On Jan 28, 2008, at 8:01 AM, Bruce Lowekamp wrote:
> > But otherwise, the TURN
> > protocol seems to work as is.  For the purposes of a TURN server, a
> > NAT having endpoint independent mapping seems to be the only real
> > requirement on the NAT
> 
> Agree on that but ...
> I think the hard part we have not fully solved yet is how a peer that
> is thinking of being a TURN server is going to detect if this is the
> case or not.

In that case,each peer that is willing to be the TURN server must dialog
with several STUN servers with public address to detect its NAT mapping
type, only peers with public addresses or behind endpoint independent
NATs
could be TURN servers. However, STUN servers may be behind NAT either,
in
the worst case, it may be behind the same outermost NAT with the peer,
and
these STUN servers response different reflexive addresses with the
public
STUN servers. So, in that case STUN servers must be classified in to
public
addressed and non-public addressed, and the peer willing to be the TURN
server must dialog with public addressed STUN servers to detect its NAT
mapping type.

For the simplicity, I think we should only admit peers with public
addresses
to be the TURN servers at the first step.

> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/p2psip

---

From: Song Yongchao <[email-masked]>
Date: Fri, 01 Feb 2008 17:59:36 +0800

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, February 01, 2008 5:47 PM
> To: Song Yongchao; Cullen Jennings; Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
> 
> 

I'm very glad to hear that, what I just said is about how a peer that is
willing to be a TURN server to detect whether it is behind a P2P friendly
NAT. Could you please provide some information about the justified
detecting?

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 1 Feb 2008 03:06:13 -0800

> how a peer that is willing to be a TURN server to detect whether it is

> behind a P2P friendly NAT.
> Could you please provide some information 

Two excellent papers deal with NAT discovery:

< draft-ietf-behave-nat-behavior-discovery-02>
<draft-wing-behave-nat-control-stun-usage-05>

These are powerful tools not only to detect the NAT behavior but also to
determine the position in multi-level NAT-ed networks.

Deployment on the net may yet reveal some more work is required for fine
tuning, 
but the above are the best I know of today and seem to be the right
approach.

My apology if I have missed some other recent relevant work.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Song Yongchao
Sent: Friday, February 01, 2008 11:00 AM
To: Henry Sinnreich; 'Cullen Jennings'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] Choice of STUN peer or TURN peer

I'm very glad to hear that, what I just said is about how a peer that is
willing to be a TURN server to detect whether it is behind a P2P
friendly
NAT. Could you please provide some information about the justified
detecting?

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Feb 2008 08:56:11 -0800

> Sent: Friday, February 01, 2008 3:06 AM
> Cc: P2PSIP Mailing List; Dan Wing

The second paper, draft-wing-behave-nat-control-stun-usage, 
resulted in a BoF at the last IETF in Vancouver.  The consensus
at that BoF was that IETF would not be successful building
such a protocol.  Minutes of the BoF are at
http://www.ietf.org/proceedings/07dec/safe.html and audio is available at
http://videolab.uoregon.edu/events/ietf/.  A mailing list, SAFE, was created
to discuss it.  Archives are at
http://www.ietf.org/mail-archive/web/safe/current/index.html

If there is interest in pursuing SAFE or the NAT Control STUN Usage, please
email [email-masked] or email me off-list.

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Song Yongchao
> > > > protocol seems to work as is.  For the purposes of a 
> TURN server,
> a

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Feb 2008 09:24:55 -0800

> From: JiangXingFeng [mailto:[email-masked]] 
> Sent: Thursday, January 31, 2008 11:04 PM
> To: 'Bruce Lowekamp'
> Cc: 'Dan Wing'; 'P2PSIP Mailing List'
> Hi, Bruce:
> Sorry for late response. See inline. 
> 
> --
> Jiang XingFeng
> 
> > > >   TURN client         STUN server          NAT  TURN server
> > > >        |                   |                |      |
> > > >  1.    |------give me a TURN address------->|----->|
> > > >  2.    |                   |<--STUN Request--------|
> > > >  3.    |                   |-STUN Response->|----->|
> > > >  4.    |<-----here is your TURN address------------|
> > > >
> > 
> > If we allow a TURN server to be behind a NAT, then the only change I
> > would see necessary would that 1 and 4 would have to be routed over
> > the overlay (a reload tunnel, for example).  But otherwise, the TURN
> > requirement on the NAT as long as the two voice endpoints 
> support ICE;
> > the connectivity checks should take care of any form of 
> filtering the
> > NAT uses.
> 
> While TURN client in question gets its relayed address from 
> the TURN server,
> it will exchange them with its peer, say B. According to the 
> connectivity
> check in ICE, B and ICE will send message to try to find 
> direct connection. 
> 
> So if B send the message destined to the relayed address 
> first, it will be
> filtered by the TURN server. Then TURN client sends a message 
> destined to
> the B's candidate, it will send the message through the TURN 
> server. But in
> the message 1 reached the TURN server in a hop-by-hop way, if 
> the message is
> sent directly to the TURN server, it will be filtered. If the 
> message is
> sent in a hop-by-hop way through the overlay, the immediate 
> peer to the STUN
> server may change over time, so the message may also be filtered. Am I
> missing something? 
> 

Can you draw a diagram of that (in PowerPoint/JPEG/GIF or ASCII)?

-d

> Regards!
> JiangXingFeng

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 1 Feb 2008 18:13:52 -0600

I'm sure this is an incredibly dumb question: but why does a peer need to
think of being a TURN server (by presumably "testing" if it is behind a NAT)?

Wouldn't it work if all peer always try to be TURN/STUN servers?
A peer would advertize a TURN server for the any public IP addresses
it has. That includes both local public IP addresses as well as
self-discovered IP addresses (gathered through STUN using other peers).

If it happens that the peer is behind a NAT that does not have an 
endpoint independent mapping, then it just won't receive any TURN/STUN packets.

The algorithm could work something like this, upon connecting to the network:

- If local IP address is public then advertize it (both STUN and TURN)
- Then, when another peer STUN server is discovered, discover if you have another public IP address
  binding (that would occur for example if you have NATing of public IP addresses)
- Then advertize new IP address (both for STUN and TURN server) on discovered IP address and port
- And so on

You just won't get any incoming STUN/TURN destined to your local IP:port if you are NATed (public to
public). Similarly, you won't get any incoming STUN/TURN destined to your discovered IP:port if the
NAT is not endpoint-independent.

> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Thursday, January 31, 2008 20:44
> To: Bruce Lowekamp
> Cc: P2PSIP Mailing List
> I think the hard part we have not fully solved yet is how a 
> peer that is thinking of being a TURN server is going to 
> detect if this is the case or not.

---

From: Song Yongchao <[email-masked]>
Date: Sat, 02 Feb 2008 09:28:16 +0800

> http://www.ietf.org/mail-archive/web/safe/current/index.html
Thanks for your information. Dan.

Song Yongchao

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 02 Feb 2008 11:22:32 +0800

TURN client      Peer X    STUN server        NAT      TURN server
  |               |           |                   |             |
1. |-------------------->|---Give me a Turn Address
--------->|----------------->|
2.                           |<-----------------STUN Request----------|
3.                           |-------------------STUN Response------>|
4. |<--------------------|<---------here is your TURN
address-------------------|
             Figure 1: message flow to get a TURN address
As Bruce suggested that message 1 and 4 will be routed through the overlay.
So here, we assume the Peer X is the neighbor peer to the TURN server.
Message 4 will return to TURN client by traversing Peer X or not. Here, we
assume the NAT has an address-dependent filtering behavior which most NATs
have. 

When TURN servers receives message 1 through the overlay, it will set the
Internal Remote transport address as Peer X's transport address. Then send
message back to the Internal Remote transport address in its Internal
5-tuple. Then NAT will open a port for Peer X. 

TURN client      Peer Y     Peer B        NAT      TURN server
|                  |           |             |             |
5.|--------------------- ->|-------Send
Indication---------------------------->| 
6.                            |----Binding Request-------     | (filtered by
the NAT)
7.
8.
			Figure 2 message flow for connectivity check in ICE

When TURN client wants to communicate with Peer B which is also behind the
NAT (the NAT in front of the Peer B is ignored in the Figure 2), it should
use overlay routing to exchange their candidates.
We assume the candidate pair from TURN client is {relayed candidate, server
reflexive candidate of Peer B}
So In message 5, TURN client will send a binding message which will be
encapsulate in the Send Indication and the message will be sent to TURN
server. 
There are two ways which could be used to send the message:
1. directly, due to NAT has a address-dependent filtering behavior, NAT will
filter the message;
2. through the overlay. yes, the message could arrive at the TURN server.
But you know, overlay topology is changing and the immediate peer to TURN
server in message 5 may not be Peer X any more, may be other peer, such as
Peer Y. For TURN server, it will check its association, and find no matched
internal 5-tuple, because Internal Remoter Transport address has been
changed. It will be discarded by the TURN server. 

On the other hand, Peer B will send a Binding request to TURN client's
relayed address, whose destination is TURN server. But it will also be
filtered by the NAT due to its filtering behavior. 

To be honest, I am not very familiar with ICE. If there is something wrong,
please point it out. Thanks. 

JiangXingFeng

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Feb 2008 19:27:56 -0800

> Sent: Friday, February 01, 2008 7:23 PM
> To: 'Dan Wing'; 'Bruce Lowekamp'

I don't believe that will work; part of what causes TURN to
be an effective NAT relay is that the TURN client sends
a packet directly to the TURN server's publicly-routable
transport address.  The side effect of the TURN client
doing that is that the TURN client's (evil, nasty) NAT
opens pinholes to communicate bi-directionally with the 
TURN server's transport address.

("evil, nasty" meaning symmetric or port-restricted, using
RFC3489 definitions.)

-d

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 02 Feb 2008 11:35:15 +0800

> TURN server's transport address.

I agree with you. So I think we should also consider NAT's filtering
behavior while we choose a peer to be a TURN server. 

JiangXingFeng

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Feb 2008 19:39:24 -0800

> behavior while we choose a peer to be a TURN server. 

The TURN client's NAT filtering behavior??

-d

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 02 Feb 2008 11:44:10 +0800

> The TURN client's NAT filtering behavior??
No, the NAT which the TURN server is behind.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Feb 2008 20:20:02 -0800

> No, the NAT which the TURN server is behind.

Yes, I agree that needs to be tested.  Some sort of
qualification procedure is needed before a TURN server
advertises its transport address to the overlay.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 2 Feb 2008 00:32:03 -0800

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: Friday, February 01, 2008 4:14 PM
> To: Cullen Jennings; Bruce Lowekamp
> Cc: P2PSIP Mailing List
> - Then advertize new IP address (both for STUN and TURN 
> server) on discovered IP address and port
> - And so on
> 
> You just won't get any incoming STUN/TURN destined to your 
> local IP:port if you are NATed (public to
> public). Similarly, you won't get any incoming STUN/TURN 
> destined to your discovered IP:port if the

Reports indicate that roughly 25% of NATs would block such incoming packets. 

This means that a TURN client, trying to use a random TURN server's transport
address that is published into the p2p overlay, would get a 75% success rate.
If the TURN client tried two TURN servers it would get a success rate of
87.5%, and so on, up to trying 11 TURN servers to get a success rate of 99.9%.

Those success rates include no calculations about TURN servers that have
crashed, had their p2p-TURN application terminated, had their NATs crash or
otherwise lose state, etc.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 2 Feb 2008 16:58:32 -0800

> Reports indicate that roughly 25% of NATs would block such incoming  

Which reports are you thinking of here ?

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 2 Feb 2008 21:36:36 -0800

> Which reports are you thinking of here ?

Google uses a pre-standard version of ICE for their user-to-user connections,
and according to
http://code.google.com/apis/talk/libjingle/important_concepts.html, 8% of
those user-to-connections connections require a relay.  

For this to be a problem 8% of the time that two peers cannot establish a
direct connection, about 28% (28%*28%=7.84%) of NATs have a property
(port-specific filtering or port assignment) that would also break a TURN
server trying to run behind that NAT.

This brings me back to thinking about Bruce's idea that a TURN server be
triggered via a message sent through the overlay.  In
<http://www.ietf.org/mail-archive/web/p2psip/current/msg03814.html>, I said I
didn't think it would work.  However, on further reflection, there is an
advantage to communicating to the TURN server using the overlay and also
sending it TURN messages directly (i.e., not through the overlay).  This
combination with the TURN client communicating to the TURN server using the
overlay and using a normal TURN request means that a TURN server that is
behind an address-filtering NAT could still be a viable and usable TURN
server.  This would increase the number of TURN servers available to p2p-sip.

This works because the TURN client would have already learned its public IP
address via STUN (although its port would be wrong, or its port would be
filtered), and the TURN client can communicate that IP address and UDP port
through the overlay to the TURN server.  When the TURN server receives that
communication (containing the TURN client's public IP address and UDP port)
through the overlay, the TURN server can send packets towards it; due to
p2p-unfriendlyness of the NAT in front of the TURN client, though, those
packets would be dropped by the TURN client's NAT.  However, those messages
cause the TURN server's NAT to open a permission towards the TURN client's IP
address.  The next retranmission by the TURN client will then make it through
the TURN server's NAT, to the TURN server, and the response will make it back
to the TURN client.  Here is a diagram, with "-" showing peer-to-peer
messages, and "=" showing messages sent through the p2p-sip overlay:

  TURN client   NAT  STUN Server   NAT      TURN server
       |         |        |         |           |
  1.   |--STUN request--->|         |           |
  2.   |--a.b.c.d/12345---|         |           |
       |         |        |         |           |
  3.   |--TURN request (1st xmit)-->X(dropped)  |
  4.   |====my address=a.b.c.d/12345===========>|
  5.   |         X<---TURN indication-----------|
  6.   |--TURN request (2nd xmit)-->|---------->|
  7.   |<--------|<---TURN response-------------|
       |         |        |         |           |

* Message 3 is dropped because the TURN Server's NAT filters incoming packets
based on their source address -- the TURN server has never sent a packet to
a.b.c.d, so the NAT drops the incoming packet.

* Message 4 is the p2psip overlay message.  

* Message 5 is mostly to mollify the TURN server's NAT.  Once the TURN
server's NAT sees message 5, it adds a permission for traffic from a.b.c.d/*.
(remember: the TURN server's NAT has address filtering behavior, which is what
we're trying to get a TURN Server working with by adding this p2psip overlay
message (4)). Message 5 is dropped by the TURN client's NAT.

* Message 6 is a normal retransmission of the TURN client's message.

With the functionality to trigger to the TURN server through the overlay, we
can run a TURN server even behind an address-filtering NAT (but not a
port-restricting NAT or a symmetric NAT).  Without the functionality to
trigger the TURN server, we cannot run behind an address-filtering NAT.

I don't know what (pre-standard) version of ICE that Google implemented, nor
do I recall which version of ICE added the ability to communicate directly
even with address-restricted NATs.  The standard version of ICE does something
vaguely like the above:  it sends a message through the overlay (the
Offer/Answer exchange, using SIP), and that message causes both peers to try
to communicate with each other, which allows two peers with address-filtering
NATs to communicate directly with each other (without a relay).  The ability
to communicate through the p2p-sip overlay to the TURN server provides a
similar capability so that a TURN server can be behind an address-filtering
NAT.

-d

---

From: JiangXingFeng <[email-masked]>
Date: Sun, 03 Feb 2008 17:16:16 +0800

Great! The overlay could be thought of as a rendezvous point and could be
used to exchange candidates. Further, the TURN client and the TURN server
could use ICE with the help of the rendezvous point to get a direct
connection. (It will exist if the NAT in front of the STUN server has
end-point independent mapping behavior.) And then TURN client could use the
TURN server to communicate with other peers.

--
Jiang XingFeng

> From: Dan Wing [mailto:[email-masked]]
> Sent: Sunday, February 03, 2008 1:37 PM
> To: 'Cullen Jennings'
> Cc: 'Francois Audet'; 'Bruce Lowekamp'; 'P2PSIP Mailing List';
'JiangXingFeng'

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 4 Feb 2008 11:13:50 -0500

> trigger the TURN server, we cannot run behind an address-filtering  

I think this is one of the complicated questions about this type of  
service for an overlay.  It allows functionality that is helpful in  
many cases, but is not as helpful as a fully open TURN server.  Is it  
worth the effort to spec, implement, and provide such a service?  My  
suspicion is that it depends on the type of deployment: a commercial  
service provider wouldn't care, a public unhosted overlay might  
consider the service worthwhile.

> similar capability so that a TURN server can be behind an address- 

This was one of the big reasons we put the TUNNEL method into  
reload-01.  It's very useful to use the overlay as a rendezvous  
service for a variety of applications (SIP and ICE being the most  
obvious for sip applications).   For some applications, by itself it  
may be enough to exchange the application-layer messages, although I  
think media is best not relayed through an overlay.

Bruce

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Feb 2008 11:56:06 -0600

> Sent: Saturday, February 02, 2008 00:32
> To: Audet, Francois (SC100:3055); 'Cullen Jennings'; 'Bruce Lowekamp'
> This means that a TURN client, trying to use a random TURN 
> server's transport address that is published into the p2p 
> overlay, would get a 75% success rate.
> If the TURN client tried two TURN servers it would get a 
> success rate of 87.5%, and so on, up to trying 11 TURN 
> servers to get a success rate of 99.9%.
> 
> 
> Those success rates include no calculations about TURN 
> servers that have crashed, had their p2p-TURN application 
> terminated, had their NATs crash or otherwise lose state, etc.

And?

That doesn't seem so bad to me. When a peers goes live (attempts to connect), it
would then try to find a working STUN/TURN server. After a few attempts, it is
likely to find a working one. A success of 87.5% after 2 tries seems very good to me.

Also, the alternative is that the servers themselves do a lot of self-assestment which
takes some time.

I'm also thinking that if somehow we could make the process of being a STUN/TURN server
and discovering others/joining the overlap mandatory, then we wouldn't have the problem
that everybody would opt out of being used as a STUN or TURN server.

(By mandatory, I don't mean "the spec says it's mandatory: I mean the procedures would be
intertwined enough that it would not be possible, or at least very difficult, to
disable the STUN and TURN server).

Just thinking out loud...
_______________________________________________
P2PSIP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/p2psip