Preventing ip resolvers in a skype-like program

Question

I'm currently in the process of creating a Skype-like program, that uses a hybrid peer to peer system to communicate between users (i.e. server contains all users IPs, a client that wants to connect to a friend will tell the server, that will then send each client the other's IP so they could start hole punching to establish a connection between them).

I know that with Skype, there are many websites that allow you to enter a username and easily get his IP address. My question is, what is the best way of preventing such an exploit?

Here are a few solutions I could think of:

• save each and every users' friends lists on the server (so the server can just drop IP requests from users that aren't in the requested client's friends list)
• whenever the server is asked for a client's IP, ask that client if the asker is on their friends list (if not, don't reply)
• have each client use some secret key to communicate with the server (so only registered clients will be able to send IP requests)

Feel free to add a different solution, again, these are just solutions I could think of off the top of my head while writing this question.

In addition, a related question that I wanted to ask - what would be the best practice in such a program:

Have each client store his friends' IPs and make the server notify him whenever they are changed

-VS-

Have the client ask the server for a friend's IP whenever he wants to start a direct connection with him (keep in mind that the client anyway has to tell the server whenever he's trying to connect to someone, in order for the hole punching to work).

P.S. I've never created such a program and I'm not following any tutorial or such. If there's any better way of doing something I wrote, or if I got anything wrong, I'd be very glad if you could mention it.

Answer 1

I'm not sure how far you've got with your design. Your description of "hole-punching" does not ring exactly true.

AS I understand it, the server has no need for client IPs except when they are on-line and available for connection. Each client connects to the server, thereby providing a current IP location and NAT channel. A user wanting to call another user amounts to a search of connected users. Your server always needs to set up the connection (because both clients use outgoing NAT channels) but if the firewalls cooperate the server can stand aside and let them talk directly to each other. Magic happens, and during that magic each client learns the other's IP.

Your concern is that a rogue client could pillage connection info from your server by rapidly trying lots of connections. If this is a rogue client you cannot necessarily control it. So here are some suggestions.

1. Encrypt and protect the communications, so only your client can talk to your server. Certificates are good for that.
2. Restrict the rate of trying connections.
3. Monitor the rate and number of connections, and blacklist clients that exceed limits.
4. Only allow 'friends' to call 'friends', and exchange no IP info until the connection is accepted by the recipient.

If that's wide of the mark feel free to update your question and I'll try again.

Answer 2

Peer-to-peer connections don't play well with firewalls. Connections though an external server or proxy, play much better with firewalls. As long as you are providing IP addresses for the connection, I believe you will risk leaking client IP address(es).

Allowing the clients to switch to a peer-to-peer connection after establishing a connection may help reduce the exposure. I see exposures on all three options you list. Any option that allows use of a proxy, will have an exposure. Not allowing proxies will likely prevent usage in some cases.

End-to-end encryption using individual public-private key pairs, would help reduce the exposure. However, it leads to issues on how to distribute public key pairs.

EDIT: You may want at existing standards. There are people who have spent much more time than me looking at these things. Study them to see what works and doesn't work. For instance, RTSP has known problems working with firewalls.

• For chat and additional functions, there is XMPP previously known as Jabber.
• For voice and video there is SIP, RTSP, and Jingle.