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."

Great article

[Nasarius]

I'm impressed, this is really good stuff. The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established. Is this technique being used or considered by any P2P apps? I've run into the situation several times where I'm firewalled, and the only seeder of a torrent is too.

Re:

[BarkLouder]

The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established.

There is no such thing as a "UDP connection". UDP is connection-less. TCP uses connections.

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.

TCP over UDP

[John Sokol]

Once you have a bi-directional UDP packet exchange going, (it's not a connection like TCP) but it is in some sense an unreliable connection.

You can then route TCP over it (grab packets from /dev/tap or /dev/tun) , or use a user space TCP stack connection or use something like my ECIP (http://www.ecip.com/ [ecip.com]) over it.

Re:

[Opie812]

+4 Insightful? How about "-1 RTFA, assface".

Re:Great article

[pilot1]

Back when eDonkey was still fairly popular, I remember the lMule devs (GNU/Linux port of eMule) were aware of this technique and planned on incorporating it in lMule. BitTorrent became popular, lMule forked many times, and we never got around to it. I'm not aware of any current P2P apps that do it. The problem is that the technique, as they describe it, requires a central trusted server that both sides can connect to. With Skype that's fine, but it's a problem when you're dealing with something that's supposed to be entirely P2P. I don't remember this limitation, so either I have a bad memory or there's some way around it.

Re:Great article

[d3ac0n]

I would imagine that using the tracker server for this purpose would work. Obviously for "trackerless" torrents it would break again, but for standard tracker torrents it would probably work quite well. Couple it with torrent encryption and you have a very nice way to get around your college/work firewall.

Re:

[izomiac]

BitComet (a Bittorrent client) uses "UDP NAT Bypassing" which I assume is this technique. Unfortunately, this feature has been broken/disabled for the last few versions though.

Re:

[w128jad]

I'm impressed, this is really good stuff. The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established. Is this technique being used or considered by any P2P apps? I've run into the situation several times where I'm firewalled, and the only seeder of a torrent is too.

I was impressed with this technique too. Perhaps the third party for a protocol such at bittorrent could use the seeders as UDP port mediators. It would b

Re:Great article

[_xeno_]

The core BitTorrent protocol uses TCP, so the UDP technique the article describes won't work. (As far as I know, there's no corresponding technique for doing something similar with TCP.)

There's been a bit of work on various UDP protocol replacements for BitTorrent, but nothing that's really gained any cohesion that I'm aware of. So, when it comes to BitTorrent, no, there really isn't much work on making such a technique work.

There might be other P2P platforms that do attempt to do something like the technique described in the article, but the official BitTorrent protocol uses TCP and therefore can't use the technique.

Re:

[Amouth]

once you have established a UDP connection (i know it is connection list but both of them talking) between the them you can fake your own TCP connection or switch it to one. once you know the forwarding port your good to go..

Re:

[_xeno_]

I'd really hope that doesn't work with any sane NAT implementation. Most NAT implementations view TCP and UDP as separate protocols, because - well, because they are separate protocols. So using this technique to punch a UDP hole would offer absolutely nothing when it comes to establishing a TCP connection. While the port numbers are similar, they apply only to their individual protocol. TCP port 80 has no relation to UDP port 80. The only thing similar about the two is that they both run over IP.

Re:

[jmauro]

This is the thing the body/header of a TCP packet happens to be a valid body/header of a UDP packet as well. The only thing that makes a packet "TCP" is that it's IP Protocol number is TCP instead of UDP. If you tag a packet as UDP and have the body of a TCP packet you can still run the same TCP algoritms on it and it'll work just fine. Granted you cannot use the OS implemeted ones, but it's possible.

Re:

[Score Whore]

TCP headers and UDP headers are quite different and a valid TCP header is not a valid UDP header. Bytes 5-8 of a TCP header are the sequence number. Bytes 5-6 of the UDP header are length, and 7-8 are the checksum. It seems unlikely that a UDP stack would be able to handle parsing part of a TCP sequence number as a length value.

Could you encapsulate a stream that acts like TCP inside of a stream of UDP packets? Sure. But it's not you can switch to a TCP stream as the predecessor post claimed.

Old news and incomplete as well

[Xenna]

I was impressed too when I read about it several years ago. Really, this is very old news. The P2P VPN tool Hamachi uses the same system.

AFAIK Skype uses a fallback system when the technique described doesn't work (where UDP traffic is blocked). In those cases it uses a well connected peer (yes, that could be your Skype client) to relay the voice data to the other party. Your PC becomes a Supernode without your knowledge and consent. Well, not really, coz this is in the Skype EULA:

4.1 Permission to utilise your computer. In order to receive the benefits provided by the Skype Software, you hereby grant permission for the Skype Software to utilise the processor and bandwidth of your computer for the limited purpose of facilitating the communication between Skype Software users.

http://computerworld.co.nz/news.nsf/news/7AB67323D 6305E49CC2570A1001698C0 [computerworld.co.nz]

What was it again? All your base belong to us?

X.

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:

[gad_zuki!]

Right, and if an admin gives full-control to the local firewall to the local user then his nightmares should be about his shoddy work, not apps requesting an open port. Something tells me heise security doesnt sell too many impressions or get on the front page of slashdot without all the alarmist language.

Nothing new here

[Fenis-Wolf]

There's really nothing new, or special about this technique. Definately nothing to 'keep firewall admins up at night'. Its the same thing that Kazaa did, and Napster as well. Establish connection to a central server, central server informs each client of the others client ip address, each client connects out, NAT router sees outgoing connections to that host, and allows data in. Nothing new, or exciting.

Re:Nothing new here

[Rycross]

The OpenTNL library (a game networking library pulled from the Torque engine) does this too. I remember thinking it was pretty clever at the time.

Re:

[throx]

Most (if not all) game engines do it, and have been doing it since the late '90s. If I recall correctly, the first I saw it was the original Battle.Net code but that doesn't mean B.Net didn't get it from someone before that.

Re:

[Rycross]

Thats interesting, but not surprising. I'm guessing that, like the OP said, the technique is very old and used pretty much everywhere UDP is.

Where did you see the Battle.Net code? Did you work for Blizzard or are you talking about bnetd?

Re:

[Tenareth]

You know it doesn't have to be new to be a security issue, right? There are mitigating controls, but at least 73% of companies don't actively control these protocols. (Granted, when you talk "companies" that includes small businesses, so the % may seem high to you)

But, as scary as it sounds... there are Fortune 1000 companies that don't actively control this attack vector.

Re:

[rbarreira]

What attack vector? The point of the story is, if you let the network make UDP connections, the network can make UDP connections to anyone. So what?

Re:

[Anonymous Coward]

Attack vector? If a program on the inside of your network is sending out out connections to other places on the internet at the request of another place that it is already has a connection with, you're 'attack' has already taken place if you didn't want that program running.

This is no more of an attack vector than any other program you allow to run on your internal network that you allow to connect to external sources.

the security issue.

[Erris]

You know it doesn't have to be new to be a security issue, right? There are mitigating controls, but at least 73% of companies don't actively control these protocols.

The problem is not the "firewall." The problem is needing one in the first place. The world will be a much better place when 73% of companies take the mitigating control of dumping Windoze.

Re:

[Chris Pimlott]

This is similar to the way FXP worked to let you transfer files directly between two FTP servers. You set passive mode and tell A to expect a file, and it says "okay, send it to a.a.a.a:aaa", then you turn around to server B and say "send me a file, I'm waiting at a.a.a.a:aaa".

Re:Nothing new here

[jfengel]

You're right that it's not new, but you're missing a crucial step. They need to exchange port numbers, not just IP addresses, via the central server (or at least one port number). Then they need to prime the firewall to pass connections through to that port by sending out a packet to the peer from that port, even though the final destination of that packet will be filtered out.

So it's not new, but it's still pretty clever.

Re:

[Amouth]

i was jsut thinking about it... and if they set the first out going packet's ttl to 1 or 2 they could make it even more effective aginst active fire walls as the udp packet would die before it makde it the other person so that they nat box wouldn't see an incoming attempt before a request from it's clients..

that and they would save 1 packet of info per call on the net.. think abouthow much bandwidth that is :)

Re:

[Blakey Rat]

AOL Instant Messenger used this technique for file transfers and "Direct IM" since like 1998. It really isn't even close to new.

Re:

[E++99]

There's really nothing new, or special about this technique. Definately nothing to 'keep firewall admins up at night'. Its the same thing that Kazaa did, and Napster as well. Establish connection to a central server, central server informs each client of the others client ip address, each client connects out, NAT router sees outgoing connections to that host, and allows data in. Nothing new, or exciting.

RTFA. They're talking about punching a hole based upon the source port used by the other computer to sen

DS

[an7ron]

I wish my nintendo DS did this, so I could play metroid at work.

Re:DS

[MyLongNickName]

I wish my nintendo DS did this, so I could play metroid at work.

And if you could disguise it to look like a cash register, your customers would have no idea you weren't ringing up their Happy Meal.

Re:DS

[GweeDo]

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

Oh come on.

[SatanicPuppy]

This isn't an exploit. If the admin's didn't want the firewall to forward ESTABLISHED/RESPONSE packets, they can take that capability out...One of the things I've always had issues with, with regards to commercial firewall software (e.g Zone Alarm/Windows Firewall) is that that capability usually ISN'T enabled, so I'm forever getting "APPLICATION IS TRYING TO CONNECT TO THE INTERNET" pop-ups.

If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they'r

you have no clue

[RelliK]

If you're using a NAT with IPTables, it's trivial to tell it to drop packets on any port regardless of whether they're established or UDP.

And how are you going to receive replies if you tell it to drop the response packets?

The trick that this article points out is that UDP is connectionless, so even a stateful firewall will not know whether a packet is a valid reply or not. The only way to prevent this is to block UDP entirely.

Re:

[grasshoppa]

Generally, it's wise not to open your mouth unless you know what you are talking about;

The kernel firewall knows how to MASQ udp packets; There's a timeout associated with them. So if you get a random UDP packet that it doesn't have a matching connection for, it'll drop it.

The real problem is being an administrator for a network which doesn't block outgoing traffic.

Re:

[whoever57]

The kernel firewall knows how to MASQ udp packets; There's a timeout associated with them. So if you get a random UDP packet that it doesn't have a matching connection for, it'll drop it.

Which brings up an interesting question: the article talks about destination port numbers, but does not discuss source port numbers.

Surely, iptables/netfilter also requires source ports to match? This is important, since the MASQ/NAT firewall can rewrite source port numbers, and hence the central server cannot reliably pa

Re:

[TwistedSpring]

Surely that doesn't matter. Whether the source port is rewritten or not external services will still try to respond to that port and the firewall will have to deal with that for things like DNS to work. The firewall can rewrite the source port so long as it remembers it did so when a response comes to that port. Now, if the firewall randomly rewrites source ports depending on destination IP the system won't work, because a datagram has to be sent to the mediation server first to establish which port the dat

Re:

[whoever57]

Surely that doesn't matter. Whether the source port is rewritten or not external services will still try to respond to that port and the firewall will have to deal with that for things like DNS to work.

The key word here is respond. Yes, if a DNS query is sent out with the source port re-writeen, the DNS server replies with the source and destiantion reversed (what was the source is now the destination). The MASQ firewall, when receiving this packet will match the destination port in the reply with its ta

Re:

[SatanicPuppy]

UDP is not connectionless. It is "stateless" which is not the same thing. Incoming UDP packets still have to open a connection with a NEW packet, so simply dropping all NEW UDP packets will keep you secure from any non-established connection.

The IPTables code would be:

iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT

This still wouldn't protect you from the "attack" described in the article, so to be truly secure, you should on

Re:

[mindstrm]

Now we're into semantics... stateless and connectionless are the same thing.

The nat or filter tables use the concept of a connection to allow/deny udp packets, but that is only a convention; UDP in and of itself is completely connectionless and stateless. There is absolutley nothing saying that 2 packets with the same source & destination ports are part of the same conversation at all.

It's not even an attack anyway... if you allow outgoing connections, why do you care if the person is connecting to som

Re:you have no clue

[SatanicPuppy]

Well, no, I suppose if you sent every packet from a UDP session to a different port, there would be no way of telling that they're all part of the same session, because you're right, UDP doesn't contain any tracking info.

The state table entry for a UDP packet, however, contains the source IP:port and the destination IP:port, and uses that information to "track" the exchange. So unless you just allow all UDP through the firewall, the state table keeps track of how often the destination ip responds, and if it doesn't respond within the timeout set in ip_conntrack_proto_udp.c at compile time, the system will terminate that connection, and require a "new" connection to be set up between those addresses. It also won't allow the destination port to be changed without a second "NEW" packet originating from the new destination port.

I agree it's not an "attack" as such. My original point was that it wasn't an exploit at all, in the sense that you are not able to break any existing rule using this method. If you allow UDP out, and UDP:Established in, then how can you complain that you end up accepting a bunch of UDP packets?

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.)

Re:

[SatanicPuppy]

The system maintains a "State Table" which stores information about all incoming/outgoing connections. For TCP it stores stuff out of the packet headers, including sequence, and state, and all that other junk, but it also stores origin and destination, to help spot packet spoofing.

For UDP the state table depends entirely on the origin port/address and the destination port/address. When the connection is made out, this is recorded in the table, and when the packets start coming back in, this is compared with

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.

Re:

[SatanicPuppy]

The protocol is connectionless, but the connection can be tracked easily enough. Bah, you're right. I just deal with the NAT end of it so often, I see connections everywhere.

Re:

[julesh]

And how are you going to receive replies if you tell it to drop the response packets?

By whitelisting the protocols you want to use UDP with, and preferably only for the hosts that you expect to receive responses from, and maybe even the machines on your own network you expect them to go to.

A corporate network should be locked down tight, and frankly most employees have no business messing around with anything that uses UDP. DNS requests should be sent to a trusted DNS resolving server, which should be the

Re:

[jimicus]

Of course it's not. But a lot of it depends on how you run your firewall.

If it's "every packet trying to cross the firewall in either direction is blocked unless it comes from the web proxy or the mail server" then Skype will also be blocked anyhow.

If it's "any packet trying to come in is blocked, but if the connection was originally set up from inside the network, anything goes" (which seems to be the most common configuration), then Skype will work quite happily.

Re:

[SatanicPuppy]

Absolutely. It be fair, it's easiest to set up a firewall that blocks all incoming non-ESTABLISHED traffic, and allows all outbound traffic. That's two lines of code.

Every other port or packet type you have a special case for is two more lines, so you see your work doubling in front of you with every little bit of added complexity.

Still, if you do it right, stuff like this won't sneak up on you.

Re:

[jimicus]

There is also the small issue of spyware and the like, and whether or not it should be blocked in that fashion. Though if you believe nobody has thought of tunnelling spyware traffic over HTTP you're fantastically naive - I've not actually looked into it, but I'd be astonished if they haven't, and if you don't have a half-decent AV solution which also looks out for spyware, you deserve all you get.

Re:

[SatanicPuppy]

It depends. At work, I deny everything, and then open specific ports for specific traffic from specific subnets, and then every address gets monitored for usage. Catches most things, and in a work environment, blocking 99% of all ports is acceptable.

At home, I allow all outgoing, and a tiny amount of incoming. I monitor usage with snort, to check for spyware traffic. I've been doing it for 5 or 6 years and I've never had any problems. Probably helps that I don't do any web surfing/email from Windows machine

Confusing title

[neonux]

From my understanding they're not talking about "hole-punching" firewalls but only about plain boring NAT traversal, which is anything but a new topic...

Re:

[Aadain2001]

No, it is "punching" a hole in the firewall. While NAT transversal is similar to this technique, is works even if you are not using NAT (say, at an office). While it's nothing "ground braking" or really that new, it is (at least to me) interesting and probably is to anyone who isn't a network guru.

Re:

[SatanicPuppy]

It's not even "punching a hole", so don't think about it that way.

Many firewalls are set up to trust the computers on the inside, so if they make a connection out, the firewall allows that connection to persist by allowing packets that are a part of the internally originating conversation to come back through.

So basically, far from having "a hole punched through your firewall", you've basically invited an untrustworthy element through your security, and it's opening a window so it can pass information back

Re:

[Aadain2001]

So basically, far from having "a hole punched through your firewall", you've basically invited an untrustworthy element through your security, and it's opening a window so it can pass information back out to it's friends.

Window... hole... basically a port is opened (from the inside) that allows data to into the 'secured' side of the network. You may not like the term 'hole', which conjures images of hackers and exploits, but you are, in effect, opening a 'hole' in your firewall that someone on the outsid

Re:

[AK Marc]

Well, I'm behind a firewall. When I request a page from Slashdot, and it comes up, it's obvious that it works because I punched a hole through the firewall through which the data returned. It might have been an exploit. It might have been what I requested. Either way, it was a hole I punched through my firewall. Or, it was data I requested being deliverd to me after I requested it. Either way, the effect if the Skype hole puncher is no different than what firewalls let happen with all sorts of other t

Re:

[Aadain2001]

Exactly. A fire"wall" is a "wall" for data going in and out. Most firewalls have rules that let you punch an outgoing hole to send data and get a response. Most are also configured to not open a hole when someone on the other side of the wall (the untrusted side) requests to get in (unless they are part of the previously mentioned communication). So yes, you are making a hole in the firewall. If it wasn't a hole, the it really isn't a fire"wall" and would be more of a fire"chain-link-fence".

Re:

[julesh]

No, it is "punching" a hole in the firewall.

There is no firewall here. If there was, there'd likely be a firewall rule that says "drop UDP packets originating or terminating on this list of addresses/ports that has been cleared for use" and nothing would happen. Most firewalls deny packets access unless there is some rule to allow them.

Why is this so bad?

[Salvance]

I don't exactly think this is Skype being tricky, it's just having users establish connections and keeping them open for incoming calls. This is the same way that Instant Messaging services such as AIM work too. If the admins don't want those services enabled, they should inform their users and then block Skype IP ranges.

Re:

[hey!]

Well, it's not being tricky so much as efficient in the case of Skype. What's interesting is the technique being used.

What the technique here describes is method of creating a two way connection between any two points A and B, provided that point B has a connection to point C, and that A and B can send UDP requests and receive responses. It so happens that A in Skype has a connection to C, but that's not stricly necessary.

Now there's nothing evil about Skype doing this. They're avoiding unnecessary traff

Slashdot, always bringing you the hottest news

[rbarreira]

While this is a cool technique, I had heard about NAT2NAT years ago... This is not a new technique, by any means.

Ever wondered

[spun]

Ever wondered, how to use, commas properly?

Re:Ever wondered

[CODiNE]

Don't tease, those, who have graduated, from the Shatner, School of Grammar.

Re:

[Peyna]

Not to mention how to properly use an em dash.

Waiting for God

[HTH NE1]

"After intensive investigation, comma, of the markings on the alien pod, comma, it has become clear, comma, to me, comma, that we are dealing, comma, with a species of awesome intellect, colon."

"Good. Perhaps they might be able to give you a hand with your punctuation."

"Shut up."

udp huh?

[minus_273]

didnt know skype was UDP based. Most do wonders to the quality of the network. Esp if there are bugs in the protocol being used. I remember the standard project where you need to implement sliding window and AIMD on UDP to mimic behavior of the dominant TCP variety. I also remember what happened when some kids messed up and started flooding the network with packets.

Re:

[minus_273]

I know why you wouldnt really need reliable transport on voice data due to the hard real time constraints. Im more concerned with the flow control. UDP has nothing it is just data blasted on the network. a buggy protocol on top of UDP and enough people using it will bring us back to the internet crash of the late 80s. Seems like not every one remember the internet becoming unusable. There is a reason why TCP was revised to behave the way it does today. The older TCP didnt really scale up well.

Re:

[dotgain]

It's voice, not file transfer.

We can only send packets as fast as they come out of the codec. After you've just transmitted a packet, there's maybe a 100mS wait until the next packet even exists. As long as Skype (or any VOIP stack) is working properly, the senders do all the 'flow control' necessary, simply by having a constant, regular stream to transmit. You don't want TCP flow control at all, you've either got enough bandwidth or you haven't.

punching holes...

[joeldg]

Skype is starting to charge now, so that means everyone will be migrating to the next thing that is free.
I sort of miss the dialpad.com days.

Re:

[AndrewNeo]

They're not 'starting to charge', their free period is ending at the end of the year just like they said when they started it.

A Good Paper

[Al Mutasim]

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

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:The answer...

[Zone-MR]

A few ms each should do it.

I'm pretty sure a few ms would be absorbed by the jitter buffer. Heck, 20ms jitter is often a normal occurance on long-distance WAN links.

Doh - STUN

[Tetard]

"Nightmare come true". What sensationalism. This is just STUN, which SIP communication devices can also use:

http://en.wikipedia.org/wiki/STUN [wikipedia.org]

Alternatives Anyone?

[bogaboga]

What are the available Skype alternatives and how do they compare to the real Skype itself? Now that they are gonna end the `free ride' to US and Canada destinations, it ripe to begin looking at alternatives.

STUN?

[Darkforge]

Is this just the same thing as STUN [wikipedia.org] (Simple Traversal of UDP through NATs)? The technique described in the article sounds simpler than STUN, but similar in concept. (SIP uses STUN, right?)

I've also heard that what Skype does is somehow better than STUN, though it's hard to see how. Can anybody confirm/deny/explain that?

Re:STUN?

[tjansen]

* It's the same as STUN, the article even mentions STUN at the end.
* STUN also supports "symetric" firewalls/NATs, I think that's not mentioned in the article. But no one uses them at home anyway, and I doubt that they are widespread elsewhere.
* SIP can use STUN (it's not required, but pretty common now).
* What the article does not mention: Skype can also mis-use HTTP proxys with HTTPS support to get through the firewall. That's the configuration that most companies have, and I hoped to get a bit more information about that in the article. But basically it will work similar to the common HTTPS tunnels (google for them if you don't know them), just Skype-specific instead of allowing arbitrary TCP connections.

Not exactly new

[Wannabe Code Monkey]

Oh man, this shit is a pain in the ass. I had to look into the over the summer. This is the same technique that Apple's iChat uses for audio and video calls. Many many p2p applications use this technique to get through firewalls and NAT routers. The problem is that it doesn't always work when both computers are behind their own NAT router.

Let's say Bob (as in the example in the article) is behind a NAT, his local ip he got from his router via DHCP is 192.168.1.2, and the public IP of his router is 2.2.2.2. He wants to use UDP port 2828 on his computer to transmit his voice data to Alice. So he sends out the first packed to 1.1.1.1:1414, as in the example. Now because of his NAT it looks like the data is coming from 2.2.2.2 and some arbitrary port (the router can't always use the same source port as the NATed computer because some other computer on the local network might already be using that port to connect to the outside world) lets say his router uses 3939.

Now Bobs router says, "Okay, I'll let through any UDP packets sent from 1.1.1.1:1414 to 2.2.2.2:3939 and I'll pass them on to 192.168.1.2:2828". As in the example, Alice's router will just drop this packet because there is no pre-existing connection from Alice's computer using this info. Then when Alice tries to send a packet to 2.2.2.2:2828 Bob's router drops it because his router isn't expecting traffic to this port. His router is expecting packets to go to port 3939. And Bob has no way of telling Alice which port she should actually be sending packets to since he doesn't even know which port his router decided to use on the public side to send out his packets.

You can get around this if only one computer is behind a NAT, or if you open up a persistent connection through your router to your computer. Anyway, I believe UPnP is supposed to help with this somehow, but I got so sick of it that I switched jobs.

Re:

[larien]

Read page 2 of the article - it explains how Skype can bypass this, at least in some cases.

Re:Not exactly new

[dgatwood]

Let's say Bob (as in the example in the article) is behind a NAT, his local ip he got from his router via DHCP is 192.168.1.2, and the public IP of his router is 2.2.2.2. He wants to use UDP port 2828 on his computer to transmit his voice data to Alice. So he sends out the first packed to 1.1.1.1:1414, as in the example. Now because of his NAT it looks like the data is coming from 2.2.2.2 and some arbitrary port (the router can't always use the same source port as the NATed computer because some other computer on the local network might already be using that port to connect to the outside world) lets say his router uses 3939.

Now Bobs router says, "Okay, I'll let through any UDP packets sent from 1.1.1.1:1414 to 2.2.2.2:3939 and I'll pass them on to 192.168.1.2:2828". As in the example, Alice's router will just drop this packet because there is no pre-existing connection from Alice's computer using this info. Then when Alice tries to send a packet to 2.2.2.2:2828 Bob's router drops it because his router isn't expecting traffic to this port. His router is expecting packets to go to port 3939. And Bob has no way of telling Alice which port she should actually be sending packets to since he doesn't even know which port his router decided to use on the public side to send out his packets.

Alice's computer should not be sending to 2828. It should be sending to the source port seen in the packets sent to the centralized server used for the rendezvous operation. Bob doesn't tell Alice anything. Bob sends a message to the central computer, which in turn, tells Alice something. The central computer DOES know what port Bob's router used because it can look at the source port on the UDP packet.

When a breakdown occurs (rare, but possible), it is not because of the difference between 2828 and 3939. It occurs because the router picked a -different- source port to use when sending packets to Alice than it did when sending packets to the central server. If the router does not consistently map port 2828 to 3939, but instead adds a secondary mapping from 2828 to 5050 when communicating with Alice's machine, the connection may fail. However, in order for a complete failure to occur (as opposed to simply requiring two or more packets to be sent and a little extra negotiation), one of the following must be true:

A. Both routers must be broken in this way. If this is the case, neither side can get a packet through to the other side.
B. One router must be broken in this way and the other router must alter the source port (reverse port masquerading) of inbound traffic.

If neither of these is true and Alice's machine is the one with the broken router, her router will use a different source port when communicating with Bob's machine that corresponds with the different destination port to which Bob's response must be sent. As long as Bob's router does not munge this, Bob's computer now knows how to send a message back to Alice, and a bidirectional communications channel should exist at that point.

I'm not saying that any of these services/protocols handle that extra bit of negotiation, of course, just that the problem isn't unsolvable unless both routers have a critical defect in their behavior.

Otherwise known as STUN

[chhamilton]

As other have already pointed out, this a very common technique. It is slowly being adopted as a standard in the VoIP and P2P world (Google Voice uses it, for one). RFC 3489 [ietf.org] discusses this very technique, and defines a protocol to be spoken to the central server that is brokering the connection. For a good overview, you could check out the Wikipedia article [wikipedia.org]. There is also a simple, cross-platform and open-source library [sourceforge.net] available that implements the server and client side techniques, making it very easy

How Skype & Co. get round firewalls

[jctull]

I always thought of firewalls as being some variation of a rectangle myself, so getting round firewalls would seem to make them easier to circumvent. But if the holes they are punching are round, wouldn't the round firewalls just plug the holes?

How long does NAt allow a reply to UDP packet?

[Viol8]

UDP is connectionless so you can send a packet and get a valid reply in a microsecond or a year depending purely on how long the app is willing to wait. So how long with the NAT router wait before is prevents a UDP reply packet crossing the barrier back to the sending app?

Not hole punching.

[mindstrm]

This is not hole punching, and not a security risk.

It is a way to get two computers that are already allowed to talk to whoever they want on the internet to talk to each other despite both having firewalls that don't allow incoming connections. It does not cause violation of firewall policy or break firewall rules in any way, it just gets over an unfortunate incompatability in this world of NAT.

The issue only arises because both parties are firewalled.

The short version: Using a 3rd server that both partie

Re:

[julesh]

It is a way to get two computers that are already allowed to talk to whoever they want on the internet to talk to each other despite both having firewalls that don't allow incoming connections. It does not cause violation of firewall policy or break firewall rules in any way, it just gets over an unfortunate incompatability in this world of NAT.

The issue only arises because both parties are firewalled.

Exactly. As far as anyone else is concerned, they might as well be communicating via a third party relay.

You can do this with TCP too...

[sparr0w]

... but its a little more tricky. We figured this out during our senior design project (a video communications system) - all we had to do was have the server start a TCP connection to the client over static source and destination ports, trash the connection before reset/fin packets could be sent and then turn a server on the source port. The NAT we were using would then let an incoming connection come on through to the server. With UDP its a whole lot easier, but it still can be done with TCP as well.

Perl code

[sheriff_p]

Samy, the guy involved with the MySpace worm, wrote some Perl to do this a while ago:

http://samy.pl/chownat/ [samy.pl]

Misleading explanation of a easily solved non-prob

[Ancient_Hacker]

Hmmm.

• This isnt "hole punching".
• Whatever that is.
• Each client is initiating a connection to a broker.
• The broker tells anybody that wants to know where Bob is.
• The "firewalls" are stupidly allowing packets to come back in from any source.

Should take about five lines of code to fix, in any firewall that really want to.

Re:Misleading explanation of a easily solved non-p

[julesh]

The "firewalls" are stupidly allowing packets to come back in from any source.

No, they're letting packets back in from any source to which a packet has been previously sent. One of the first two packets sent by the clients will be dropped, but the others will all go through fine.

Not that this makes it anything other than a stupid way of setting up a firewall if you're trying to regulate what protocols can be used. And if you aren't, what's the big deal?

am I missing something here?

[advocate_one]

surely the answer is to block the clients from making the initial connection to the skype server? surely someone must have a blocklist available of the skype servers.

NAT Traversal, not firewalls

[phliar]

As others point out, the technique has been used for many years.

It's not even a real solution. The article says:

From the incoming query it sees that Alice is currently registered at the IP address 1.1.1.1 and a quick test reveals that her audio data *always comes from* UDP port 1414 [emphasis mine].

Really, always? Why do you know this? Because you tested it with your one client and the particular version of the one OS you use?

That's the problem with this technique: it might work for some or even mo

Not at all new

[strags]

This is really ancient stuff. I worked extensively on NAT traversal in 2000, and even that it wasn't a terribly original notion. The article also glosses over many of the numerous subtle differences between off-the-shelf routers/NAT devices - there are far more accurate and informative articles available.

I already published this technique in 6/3/2002

[John Sokol]

http://www.ecip.com/fwdoc.htm [ecip.com]

We had it in our one of our livecam video streaming product in 1997

Re:

[account_deleted]

Comment removed based on user account deletion

NAT behavior is not consistent

[__aadkms7016]

See: http://www.ietf.org/internet-drafts/draft-ietf-beh ave-nat-udp-08.txt [ietf.org] for a taxonomy of the ways NATs behave. The method described in the article won't work for all kinds of NATs.

News?

[Jahz]

Use of the procedure described above is not limited to Skype and is known as "UDP hole punching".

This sentence, which occurs in the last paragraph of TFA, should be further noted. The technique described here has been around for as long as NAT routers have been around (a very long time). Its fairly common knowledge/practice in network security circles. In fact, this was taught in my network security course last year. I think it was on the final as well... except we had to defeat a NAT router using TCP packets which is a slightly more tricky task.

On a tangent:
NAT routers are not really proper firewalls, though they have the side effect of keeping most attackers out. This is beacuse NAT was designed and implemented primarily for allowing multiple computers to utilize a single global address. They technically break the OSI stack by reaching past the link layer... and provide a bit less security than using vanilla iptables without modules. A more interesting exercise would be to describe the steps to defeat a firewall with stateful packet inspection.

Re:

[brunascle]

both alice and bob are doing the same thing: sending a UDP packet to the other. for both, once they send out a UDP packet, that allows a UDP packet from the other side to come in.

so whoever sends the first packet wont make it to the other side, but the other side's packet will make it across, because both holes would then be open.

Re:

[David Gould]

No, that's exactly it: as I read it, Bob's first attempt to connect to Alice is discarded by Alice's firewall, but it was never intended to be received; its only purpose was to put Bob's firewall into the "waiting for response" state, so that when Alice subsequently attempts to connect to Bob, Bob's firewall interprets the incoming data as the response that Bob was waiting for. And that's exactly what it is, in the sense that Alice and Bob are both intentionally following the Skype protocol; it's just not t

Re:

[Simon80]

Uh, no, Bob contacts Alice first in the diagram - that VoIP call arrow in the first picture isn't data being sent, it's just an indicator of what's going on. If you don't agree, look at it this way, the arrow is black, not red or green, and it doesn't pass through any of the firewalls, therefore, it's not data being sent.

Re:

[julesh]

Other option: don't allow incoming UDP packets, even if there has been an outgoing one, except from trusted IP addresses. I mean, you're only using UDP for DNS, right, and you know the IP address of your resolving DNS server...?