Punching Holes

by Peter Saint-Andre

2007-07-18

Some IETF discussion lists (BEHAVE, MMUSIC, SIP) have erupted in controversy over the last few days with regard to ICE. As a result I've been introduced to the concept of UDP hole punching. I think this is the kind of thing that Matt Tucker and Thiago Camargo were talking about months ago on the standards@xmpp.org list. Consider:

1. You ask your XMPP server what it thinks your outward-facing IP address and port are, i.e., your "public endpoint". (We'd need a protocol for this, and it wouldn't work in all situations, but we might as well leverage the stable TCP connection we've already got in XMPP.)
2. Your potential Jingle conversation partner does the same. (Probably you both do this on login.)
3. When negotiating with your potential conversation party, you both exchange your public and private endpoints. (This would probably be an improved version of the Raw UDP Transport Method.)
4. You both try to connect over the public and private endpoints. If one of the endpoints succeeds, use it. (You need to figure out if it works, but there are no acks in UDP. Maybe checking via the Echo Protocol but on a high port would do it?)

We'd need a fallback, which would probably be none other than the Jingle ICE Transport Method. But this basic hole-punching technique would be more effective than our current raw UDP method, which right now is the NAT traversal equivalent of the "I'm Feeling Lucky" button in Google search.

Something to think about...

UPDATE: Well, ICE simply is a hole-punching technology, and the right fallback is probably a relay à la TURN. Plus you can't have your XMPP server tell you what your outfacing IP+port is since XMPP runs over TCP, not UDP. So call this post an intriguing idea that won't pan out. BTW, when it comes to open-source ICE libraries, check out libnice.

Peter Saint-Andre > Journal