inline ...
On Sep 9, 2007, at 8:05 PM, David Barrett wrote: > So we’ve talked a lot about how dynamic DNS / mDNS could be used in > a P2P system as the backbone of a global naming system (after all, > that’s precisely what it’s designed for). However, it falls down > in the presence of NATs, especially restricted or symmetric NATs. > But I’m wondering if there are a couple minor extensions we could > make to get around that restriction. > > > > First, as background, the basic plan is this: > > > > - I install some P2P client (eg, a VoIP client) > > - I buy a DNS name (eg, “quinthar.com’) from any dynamic- > DNS provider (eg, DynDNS) > > - I enter my desired user name into the client (eg, > “dbarrett.quinthar.com”) > > - My client uses STUN and figures out my LAN and NAT IP > addresses > > - My client registers my current IPs with my dynamic-DNS > provider > > - My client listens for mDNS resolutions on > “dbarrett.quinthar.com” > > - You run some P2P client > > - You type my name (dbarrett.quinthar.com) in > > - Your client does a 100% standard DNS resolution on my name > > o If we’re on the internet, my dynamic DNS provider responds > to you > > o If we’re on an ad-hoc LAN, my client responds to you via mDNS > > - Either way, your client gets my latest LAN/NAT IP > addresses and tries to connect in parallel > > - Now, it’ll work some of the time: > > o If I’m not behind a NAT or firewall, then you can connect > to me directly > > o Likewise, if we’re on the same LAN (even if it’s ad hoc), > my client will hear your mDNS broadcast for “dbarrett.quinthar.com” > and will respond accordingly > > - But if we’re separated by a NAT you can’t connect to me > because: > > o You don’t know what port I’m listening on > > o Even if you did, I probably have a restricted-cone NAT > that blocks you > > One of the issues you need to consider is what wold be the expiry time on your DNS lookups. I understand some of your later proposal would imply basically zero but talking to the dyndns folks, if we had 50 million clients all doing a few calls a day - they sounded pretty concerned about the load that would cause with a really low TTL. I'm not arguing one way or the other here other than this is part of the design that would need consideration. > So first, before proposing my solution, let me rant on why this > would be so awesome: > > > > - Doesn’t require inventing new protocols from scratch > > - Works both on and off the internet > > - Seamlessly supports static and dynamic IP addresses > (fixed and mobile VoIP) > > - Leverages an existing, proven backbone (the global DNS > network) > > - Is decentralized in the way that matters most: between > separate legal entities (dynamic DNS providers) across separate > international jurisdictions > > > > But, currently, the above system has the following problems, to > each of which I propose a solution: > > > > 1) Problem: When you resolve my domain name > (dbarrett.quinthar.com) you get back my IPs, but not which port I’m > listening on. Thus it only works if we agree a priori on which > port to use (much like HTTP has reserved port 80 from the IANA, > we’d need to do the same for our VoIP protocol). This isn’t so bad, > but completely screws up any sort of port-hopping approach, as well > as any port-mapping applied by a NAT. > Solution: When my client uploads its latest IP addresses to the > dynamic DNS provider, it also provides the port being used on each > IP address. Then the dynamic-DNS provider creates a TXT record for > each IP listing which port to use. So, clients attempt to listen > on a well-known port, and clients who aren’t looking for these TXT > records won’t need them. But if you can’t listen on a well-known > port (or are behind a NAT, clients can use the TXT records to > figure out which port you’re on. And clients that aren’t expecting > the TXT records will simply ignore them. > It might be easier to just use SRV records and your client could upload the IP and port - no change need to SIP clients reading the record. > 2) Problem: If behind a restricted-cone NAT, even knowing my > IP and port is insufficient to connect to me – I also need to be > connecting to you at the same time. > Solution: This solution is broken into three sub-parts: > > a. When my client uploads its IP/ports to the dynamic DNS > provider, it maintains a persistent TCP connection such that the > server can communicate back to the client at any time. I've got no good idea on how to deal with this but if you keep a persistent TCP connection back to the DNS server - you have made the DNS server have many of the scalability problems of just running a SIP proxy. I think it will be hard to make this approach work in a way that is a few orders of magnitude more scaleable that just having a SIP proxy. Not saying this idea is not worth investigating - just that my gut feeling is that keeping all these connection and dealing with the messaging will turn out to be the achilles heal of this solution. > b. Rather than resolving my domain (dbarrett.quinthar.com), > you actually resolve a subdomain that encodes your own IP addresses > and ports. This communicates to my dynamic DNS provider your IP > address and port without requiring any changes to the DNS protocol, > or any DNS stack implementations > > xxx.yyy.zzz.www.port.dbarrett.quinthar.com > > c. Bringing these together: when you resolve my domain using > an encoded IP:port “backchannel”, my dynamic DNS provider notifies > me via the persistent TCP connection, basically saying “hey, > somebody at xxx.yyy.zzz.www:port just resolved your name; you might > want to try to connect to it so he can get through your NAT”. > > > > So this requires two changes to the dynamic-DNS server: > > > > 1) Record a port mapping for each IP address and respond to > DNS resolutions with a TXT record for each > > 2) Maintain a persistent TCP connection with the dynamic-DNS > client in order to notify it when people try to resolve its address. > > > > Both of these changes are fully backwards compatible. Existing DNS > clients that don’t expect the extra TXT fields will simply ignore > them. Existing dynamic DNS clients that don’t provide port > information just won’t get the TXT fields. Likewise, if they close > the resulting TCP connection, no problem. > > > > However, with these changes, you can use the regular DNS/mDNS > infrastructure as a massive, legally-decentralized, technically- > distributed rendezvous service that seamlessly works both on and > off the internet, and seamlessly supports both fixed and dynamic > DNS names and IP addresses. The mDNS is a good idea - the problem I see with it is that if I am on the same subnet as someone trying to call you, I might be able to high jack your calls depending on how the rest of your security works. This may or may not be a big deal depending on the use case. > > > Where are the holes? > > > > -david > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
