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

["Dan Wing" <[e-mail]>]

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


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



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


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