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 PROTECTED] 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 > > 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 [email protected] https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
