How Skype Punches Holes in Firewalls

An anonymous reader writes "Ever wondered, how P2P software like Skype directly exchanges data — despite the fact, that both machines are sitting behind a firewall that only permits outgoing traffic? Read about the hole punching techniques, that make a firewall admin's nightmares come true."

Comments

A Good Paper

[Al Mutasim]

Here is another good discussion (PDF): http://www.rootsecure.net/content/downloads/pdf/sk ype_protocol.pdf.

Re:DS

[GweeDo]

Um, if they worked at McDonalds they would already have free WiFi for DS gameplay.
See here

The answer...

[chill]

...is deep packet inspection. Instead of just letting packets thru based on "I'm just returning so-and-so's request", look to see what their payload contains and what type of stream it is. Yes, encryption can hide the payload. But, you can still prohibit non-SSH/HTTPS/SFTP streams from originating. If it isn't an approved protocol, make it go away.

Want to REALLY torque off the Skype guys? Let it thru, just add random packet delays to each UDP packet that goes out and comes in. A few ms each should do it. Their call quality will go to hell. Things like mail, web surfing, and other non-realtime protocols won't even notice the difference.

  Charles

Re:Great article

[autocracy]

It is true that UDP is connectionless, but stateful firewalls do track UDP conversations as "connections." This is why, for example, DNS requests going out can be answered without unrequested inbound UDP traffic sent anywhere.

Re: Punching Holes in BT

[Crazy Man on Fire]

I know you can punch holes for bit torrent, at least if you are using Azureus, as long as you setup your router to port forward/trigger to a particular UDP/TCP port.

If you're setting up port forwarding in your router, the application isn't "punching holes" you're just opening up your firewall at the router...

Re:you have no clue

[E 99]

All these people maintaining that UDP is a "connectionless" protocol are baffling to me...How do you think NAT works? Do you think that it just forwards UDP packets everywhere, hoping that someone wants them? All connection information has to be maintained with NAT, or there is no point.

UDP is connectionless. NAT routers invent imaginary connections based upon the outgoing packets they see, and then close the imaginary connections after inactivity. It's not part of the protocol. It's a model that the router uses to block all packets except the ones that were presumably requested.

UDP *is* Connectionless; Apps might not be

[billstewart]

UDP is a Layer 4 protocol for transmitting packets between (Layer 5,6,or 7) applications - it doesn't have any concept of connection, state, or acknowledgements, either in the packet headers or in the protocol for what to do with those packets. By contrast, TCP creates a connection between the two endpoints, using the 3-way-handshake mechanism, window size management, acknowledgements, retransmit mechanisms, etc., and the connection has state (SYN sent, SYN-ACK received, N bytes still waiting to go into a window, FIN received, etc.)

The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things

• Do a simple one-packet response to a one-packet query - DNS usually works this way, and all the protocols like Echo and Daytime that got turned off due to packet-amplification attacks like smurfing work that way. The application doesn't maintain any state - it just answers your question and waits for the next one.
• Send a stream of packets, unacknowledged, which you hope will mostly be delivered. Voice and videoconferencing applications work that way - it's better to have an occasional static or screen glitch than to slow the whole thing down waiting a few hundred milliseconds for lost packets to retransmit, watching everybody's mouth move out of sync like a bad Godzilla movie.
• Provide a full-scale connection, emulating TCP badly at Layer 7. Applications that do this are usually designed for LANs, where they usually work, and they can get higher throughput with less CPU demand on the computer because the connections usually work and are have much lower latency and loss and higher bandwidth than the environments TCP was designed for.

  Some applications that look like this are really hybrids - they've gone to a lot of work to make sure they work fine in a stateless UDP environment, where packets might get lost or duplicated, and remote partners might go on and off line, such as remote file-system apps where the Layer 7 acknowledgement that Block 12345 has been written to disk is what the application needed to know anyway. Being stateless lets the app not have to keep track of which remote sites are currently reachable, and lets a server scale to handle lots of sporadic accesses. And sometimes the client app maintains state even if the server doesn't - the client knows it has 242344 more bytes to send to the server, but the server responds to each packet idempotently when it comes in and doesn't worry about the past or future.

• Genuine one-shot unacked messages - telemetry apps are often like this, and sometimes logging apps are as well. If you lose the message "It's 43.123 degrees at 12:24:14", there'll be another one soon saying "It's 43.122 degrees at 12:24:15" that's probably just as useful as doing an ack and retransmit.

Firewalls used to be manually configured for some protocols - you'd allow a UDP connection from 1.1.1.1:1414 to 2.2.2.2:2828 - and also support protocols statelessly - you'd allow ping responses, or TCP SYN/ACKs, but didn't explicitly track which responses were really from which connections. This was usually good enough for TCP, but fairly crude for UDP, since the Layer 4 protocol doesn't tell you state. Stateful inspection techniques let the firewall keep track of each exchange between two sites - you'll accept ping responses from 2.2.2.2 to 1.1.1.1 because you know 1.1.1.1 just sent a ping to 2.2.2.2, and you'll accept TCP packets from 2.2.2.2:443 to 1.1.1.1:12345 because you know 1.1.1.1:12345 did a TCP SYN to that 2.2.2.2:443 and haven't seen a TCP FIN or timed out the connection. They're simulating state, even for protocols that don't have connections or state at Layer 4, because applications usually have one or a series of packet exchanges even if they don't have state at Layer 7 (or only have state at one end.)