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

From: JiangXingFeng <[email-masked]>
Date: Tue, 22 Jan 2008 17:37:18 +0800

Hi, all:

In order to make the peers serve each other, some peers with special
capabilities could be exploited to play the STUN/TURN server role for other
peers who are behind NAT. Guys in P2PSIP community has agreed with that peer
behind NAT should seek help from other peers, not centralized STUN/TURN
server.

But which kinds of peers are qualified for playing STUN/TURN server? Of
course, Peers on the public internet could take this responsibility. I also
learned from the list that peers behind p2p-friendly NAT (with end-point
independent mapping and filtering behavior) also could do the same work. But
from my point of view, ICE negotiation procedure may fail if choosing this
kind of peer as STUN/TURN server.

Let's show an example: 

Peer A and peer B want to communicate directly. NAT2 is a p2p-friendly NAT.
So peer C would be considered as a candidate STUN server. If peer A choose
the Peer C as its STUN server, peer A will get a mapping on the NAT1 which
is in the address realm of private network. And Peer A will tell peer B this
server reflexive address. But peer B could not reach it because it is in
different address realm.  

Am I missing something? Comments are appreciated!

Regards!

--

Jiang XingFeng

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Jan 2008 18:07:50 -0800

ICE allows you to have multiple STUN servers.  In the diagram you provided,
Peer A could contact Peer C, Peer D, and Peer B, and would notice different
answers from some (or all) of them.  All of those different answers can be
provided as different candidates (a=candidate) in the call setup message.

-d

> -----Original Message-----
> From: JiangXingFeng [mailto:[email-masked]] 
> Sent: Tuesday, January 22, 2008 1:37 AM
> To: 'P2PSIP Mailing List'
> Subject: [P2PSIP] Choice of STUN peer or TURN peer
> 
> Hi, all:
> 
>  
> 
> In order to make the peers serve each other, some peers with 
> special capabilities could be exploited to play the STUN/TURN 
> server role for other peers who are behind NAT. Guys in 
> P2PSIP community has agreed with that peer behind NAT should 
> seek help from other peers, not centralized STUN/TURN server.
> 
>  
> 
> But which kinds of peers are qualified for playing STUN/TURN 
> server? Of course, Peers on the public internet could take 
> this responsibility. I also learned from the list that peers 
> behind p2p-friendly NAT (with end-point independent mapping 
> and filtering behavior) also could do the same work. But from 
> my point of view, ICE negotiation procedure may fail if 
> choosing this kind of peer as STUN/TURN server.
> 
>  
> 
> Let's show an example: 
> 
> 
> 
> Peer A and peer B want to communicate directly. NAT2 is a 
> p2p-friendly NAT. So peer C would be considered as a 
> candidate STUN server. If peer A choose the Peer C as its 
> STUN server, peer A will get a mapping on the NAT1 which is 
> in the address realm of private network. And Peer A will tell 
> peer B this server reflexive address. But peer B could not 
> reach it because it is in different address realm.  
> 
>  
>

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 23 Jan 2008 12:39:31 +0800

Hi, Dan:

Thanks for your comments.

ICE does support multiple servers. But I guess ICE has not considered
whether STUN server or TURN server is behind NAT. (Is my understanding
right?) So if STUN server or TURN server behind NAT are involved, the ICE
connectivity procedure will take more time to complete. I am not sure how
longer it is. 

--
JiangXingFeng

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2008 10:08 AM
> To: 'JiangXingFeng'; 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Jan 2008 00:12:45 -0800

> Sent: Tuesday, January 22, 2008 8:40 PM
> To: 'Dan Wing'; 'P2PSIP Mailing List'
> connectivity procedure will take more time to complete.
> I am not sure how longer it is. 

There are two variables:

  1. how many candidates you could gather
  2. how quickly your peer can send connectivity checks
     to those candidates

To the first point, in the diagram you provided in your earlier email, there
are only three candidate addresses:  one from the local interface, one from
the STUN server that is behind the same NAT you're behind, and another from a
STUN server on the Internet.  Are there network topologies where more
candidate addresses would be learned?

To the second point, the additional delay depends on how quickly you can send
the connectivity checks to the additional candidates.  This rate depends on
the RTP sending rate.  So, for example, if the endpoint is going to send an
~200 byte RTP packet every 20ms, the endpoint is permitted to send a ~200 byte
connectivity check (to a new candidate) every 20ms.  With 3 different
candidates, that is 3*20ms=60ms of additional time.  60ms does not seem
significant to me.

-d

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 23 Jan 2008 17:58:49 +0800

> Sent: Wednesday, January 23, 2008 4:13 PM

Even if there are enough candidates who could be learned by using enough
servers, how could ICE sort the candidate pairs in the order so that the
workable pairs could be considered as soon as possible? 

Regards!
JiangXingFeng

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 23 Jan 2008 09:31:13 -0500

> > > I am not sure how longer it is.

A STUN server being behind a NAT is irrelevant from the view of the
STUN client (assuming it knows how to contact the STUN server).  The
NAT in front of the STUN server doesn't change the address of an
incoming request from another client.

Similarly, a TURN server being behind a NAT is irrelevant as long as
both peers can contact it.  A peer that wishes to be a TURN server but
is behind a bad NAT is probably better off not being a TURN server,
but that is about it.

What matters is the kind of NATs the client (A and B in your example) is behind.

> workable pairs could be considered as soon as possible?

The reload-02 section I pointed you to describes this very briefly,
but let me try to provide more details. In almost all cases, A and B
will be behind friendly NATs.  In your particular example, no matter
how many STUN servers B uses, it will know two candidate addresses.
In A's case, it will know two or maybe three if it has C in its list
of STUN servers.

Two points to note here.  First, for peer protocol connections, there
is no need to gather candidate addresses when you wish to establish a
new connection because you can do that over time.  Second, reload-02
suggests that you maintain sets of peers grouped according to the
reflexive address they return, then make one query to each when you
gather candidates for media connections (or refresh your peer protocol
addresses).

Now the less common, but important case, is when A or B is behind a
p2p unfriendly NAT.  Any of your NAT1, NAT2, NAT3 could be unfriendly.
 In this case, what will happen is that A or B will discover that as
they make connections with new peers, the number of different
reflexive addresses that they see grows.  In B's case, it will
probably grow infinitely large.  In A's case, assuming there is more
than Peer C behind NAT 2 with it, if NAT 2 is the unfriendly NAT A may
observe several peers reporting the same reflexive address because
they are also behind NAT2.  In these cases, A and B should provide
addresses they see repeated as ICE candidates, but there's unlikely to
be any point in providing a list of every reflexive address ever seen.

In any event, when ordering the candidates for an ice offer, start
with the local address and list the learned addresses in the order of
their frequency.  That will very rarely be more than two.

Bruce

---

From: JiangXingFeng <[email-masked]>
Date: Thu, 24 Jan 2008 15:22:31 +0800

> is behind a bad NAT is probably better off not being a TURN server,

The following is another story. For peer to be a TURN server, how could TURN
clients get their allocated transport address belonging to the TURN server
if the TURN server is behind NAT? Because in TURN, the allocated address is
encapsulated in the message and then communicated with the clients, but due
to NAT, the allocated address could not be contacted by the clients in the
future. 

Am I missing soothing?  

> gather candidates for media connections (or refresh your peer protocol

Thanks for your explanations. You mean that reload-2 uses the reflexive
address from its peers as its peer reflexive address candidate?

What my concern is how the peer learns the reflexive address when it just
joins the overlay? It should find a bootstrap peer? Must the bootstrap peer
have a public address? If not, how could the peer contact directly with the
bootstrap peer? 

Another concern is: although a peer could gather candidates over time, the
first reflexive address SHOULD be on the public Internet (If bootstrap peer
has to have a public address). The peer must actively find the STUN servers
and only passively relying on the packets from its peers to get reflexive
candidate is not enough because its peers could not contact him directly due
to NAT. 

One more question here is: how do you define p2p-friendly NAT in terms of
filtering behavior? Do you refer to end-point independent filtering or
others? If it is the case, the security property would be sacrificed.  

> their frequency.  That will very rarely be more than two.

Whatever method being used to sort the candidate, if two candidates in the
candidate pair is not within the same realm, the connectivity check must
fail, hence the connectivity check time will be prolonged.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 Jan 2008 10:03:28 -0800

> to NAT, the allocated address could not be contacted by the 
> clients in the future. 
>
> Am I missing soothing?  

The TURN server is responsible for obtaining a publicly-routable
address, and giving that address to the TURN client.  The TURN
specification, as currently written, expects the TURN server
itself to be on a publicly-routable network ("on the Internet").

If, however, the TURN server is behind a NAT, and we want the 
TURN server to still be responsible for obtaining a 
publicly-routable IP address, you could do that.  Here is a 
new technique that could be used:  the TURN server could use 
STUN (or NAT-PMP or UPnP, if there is only one NAT between 
the TURN server and the Internet), and obtain a publicly-
routable mapping:

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

Messages 2-3 are normal STUN request/response messages, and
tell the TURN server a publicly-routable IP address and UDP
port.  The IP address and UDP port returned in in the STUN 
Response (message 3) is the TURN server's publicly-routable
transport address, and is given to the TURN client in message 
4.

For the above message flow to work, the NAT has to be
p2p-friendly, of course -- that is a requirement for a
successful TURN server behind a NAT.

-d

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 24 Jan 2008 10:13:31 -0800

This is a very creative contribution to solving NAT traversal for peers
behind NAT to act as TURN servers.

Good job Dan!

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Thursday, January 24, 2008 10:03 AM
To: 'JiangXingFeng'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] Choice of STUN peer or TURN peer

-d

---

From: "Jerry Yin" <[email-masked]>
Date: Thu, 24 Jan 2008 13:53:36 -0500

> transport address, and is given to the TURN client in message

Does the "p2p-friendly" mean the NAT allows the STUN messages pass through?
How does the message 1 (STUN) go through the NAT?

I guess the TURN server has to send STUN keep alive messages to keep the NAT
hole open before the TURN request expire?

thanks,
Jerry

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 Jan 2008 14:33:21 -0800

> From: Jerry Yin [mailto:[email-masked]] 
> Sent: Thursday, January 24, 2008 10:54 AM
> To: Dan Wing

The p2p-sip TURN server, prior to those messages above, 
determined its publicly-routable IP address and publicly-
routable UDP port.  It may have determined that via STUN 
(or, if there is only one level of NAT, it might have 
determined that via UPnP or NAT-PMP).

The p2p-sip TURN server also determines that it can receive 
STUN requests from arbitrary STUN clients via that port; Bruce 
I believe has written up how a TURN server makes that 
determination.  Once the TURN server has made that determination, 
it would register itself as a TURN server in the p2p overlay 
network.

> hole open before the TURN request expire?

Yes, the p2p-sip TURN server would be responsible for keeping 
open all of the pinholes necessary for the p2p-sip TURN server 
to operate.

-d

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 25 Jan 2008 10:08:21 +0800

> successful TURN server behind a NAT.

If the NAT is nested, the location of the STUN server may fail the above the
method. For example, if the STUN server is also behind the NAT and reflects
the inner NAT mapping, not outer most NAT mapping, to the TURN server, the
relayed address will not be used for the TURN client to contact with TURN
server. In order to avoid this kind of failure, stun server's location
should be learned by its clients. In china, due to the lack of the IPv4
address, nested NAT is not a rare situation. 
Comments?

Regards!
JiangXingFeng

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 25 Jan 2008 10:12:24 +0800

> it would register itself as a TURN server in the p2p overlay

How do you assume the filtering behavior of the NAT which is in the front of
the TURN server? If it is not end-point independent filtering, how could the
TURN client's request reach the TURN peer behind the NAT?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 Jan 2008 19:53:16 -0800

> Sent: Thursday, January 24, 2008 6:08 PM
> To: 'Dan Wing'; 'Bruce Lowekamp'
> should be learned by its clients.

Yep.  That is part of the qualification a p2p-sip TURN server 
would have to do before it declares itself a TURN server.

-d

> In china, due to the lack 
> of the IPv4

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 Jan 2008 19:55:50 -0800

> Sent: Thursday, January 24, 2008 6:12 PM
> To: 'Dan Wing'; 'Jerry Yin'
> How do you assume the filtering behavior of the NAT which is 
> in the front of the TURN server?

You can test it, and hope your test accurately reflects the
NAT's filtering behavior when real traffic is attempting to
traverse the NAT.  

I am not aware of a better technique, unless you know you
are behind only one NAT (in which case you can use UPnP or
NAT-PMP, both of which require no filtering on the NAT).

> If it is not end-point independent 
> filtering, how could the

It wouldn't.  The p2p-sip TURN server needs to determine if 
it's behind that kind of NAT prior to declaring, to the 
p2p-sip network, that it is a TURN server.  That is part
of the qualification procedure the p2p-sip TURN server
needs to do.

-d

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 25 Jan 2008 17:16:31 +0800

Hi, 

I'd like to see your proposed method works, because it could make full use
of decentralized resource in the overlay to serve each other. 

Regards!

JiangXingFeng

> would have to do before it declares itself a TURN server.
I'm just worried about that rare end-point independent filtering NAT exists
according the data in the paper http://saikat.guha.cc/pub/imc05-tcpnat.pdf.
It said the proportion of the end-point independent filtering NAT is about
5.8%

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 Jan 2008 09:31:33 -0800

> Sent: Friday, January 25, 2008 1:17 AM

It seems useful to phase this for p2p-sip:  initially, just have
p2p-sip nodes advertise their TURN servers if the p2p-sip node
is not behind a NAT.

Once we know how to have p2p-sip TURN servers qualify their 
NAT's p2p-friendlyness, then can have p2p-sip nodes advertise 
those TURN servers, too.  If we make fast progress on a document
that describes the qualification procedure, and running code
that shows it works, we should be good to go.  No?

> according the data in the paper 
> http://saikat.guha.cc/pub/imc05-tcpnat.pdf.
> It said the proportion of the end-point independent filtering 
> NAT is about 5.8%

That paper is for TCP.  I thought the primary concern here, for
TURN, was UDP?

-d

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 28 Jan 2008 10:32:24 +0800

> that shows it works, we should be good to go.  No?

Yes. It is same to what I have in mind. First of all, we should determine
the p2psip node is not behind a NAT. 

Regard

JiangXingFeng

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 28 Jan 2008 11:01:05 -0500

Sorry for dropping off the thread for so long...

> > p2p-sip nodes advertise their TURN servers if the p2p-sip node

This seems like the best first step.  It also seems likely that
different overlays will have different policies for what defines a
good TURN relay.  Some provider-based overlays might actually have the
provider provision TURN servers, whereas at the other end of the
spectrum are overlays that may deploy nothing and rely entirely on
individuals who have eligible peers.

> > that shows it works, we should be good to go.  No?

This seems like a fairly straightforward application of
nat-behavior-discovery.

> >  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
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 as long as the two voice endpoints support ICE;
the connectivity checks should take care of any form of filtering the
NAT uses.

Bruce

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 31 Jan 2008 20:44:07 -0800

On Jan 28, 2008, at 8:01 AM, Bruce Lowekamp wrote:

> But otherwise, the TURN
> 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.
_______________________________________________
P2PSIP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/p2psip

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 01 Feb 2008 15:03:33 +0800

Hi, Bruce:

Sorry for late response. See inline. 

--
Jiang XingFeng

> the connectivity checks should take care of any form of filtering the

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? 

Regards!

JiangXingFeng

---

From: Song Yongchao <[email-masked]>
Date: Fri, 01 Feb 2008 15:21:49 +0800

See inline
> is thinking of being a TURN server is going to detect if this is the

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.