VPN lessons, from Skype attacks: dodging firewalls entirely.

Posted 25 Feb 2007 at 11:12 UTC (updated 25 Feb 2007 at 23:49 UTC) by lkcl Share This

Skype's service, when it first came out, was impossible to stop. Two hundred engineers from France Telecom were put onto the task of working out how to kill skype, and they failed. Skype uses SIP for the voice traffic - so, three years later, real-time SIP Quality-of-Service deprioritisation proxies can now be used by ISPs to trash it unless you pay them money to use their version of Skype - and suddenly the service gets great quality.

This article outlines an idea on how to dodge these kinds of problems for any traffic not just VoIP, by treating IPv4 as just another carrier (like radio waves) over which IPv6 is tunneled, and applying standard and well-known techniques such as spread-spectrum technology in creative and evil-minded ways.

The analogy of TCP/IP to Radio. The problem.

TCP/IP is very similar to directional radio waves. You can send data to a destination (an address) and you can send it on a frequency (a port). The problem is that the "airwaves" are getting extremely cluttered, with utter shit from spam, with microsoft anti-virus downloads, with viruses, with bittorrent "illegal" downloads and a multitude of badly-designed VoIP systems, the majority of which use SIP.

SIP, as I've pointed out before, is especially bad because the ports over which RTP is negotiated (RTP is the actual voice bit of SIP) are chosen by the wrong end! You therefore need to mess badly with your firewall, opening up a range of incoming UDP ports, or you need to have a SIP proxy which sits on the outside of your firewall, NAT-proxying the audio packets onto a sensible small range.

We have a situation where ISPs are desperate to make money, especially when they happen also to be TelCos, and they see VoIP as a major threat to their revenue stream. This example is what we need to learn from: VoIP is only the first in a line of protocols of traditional communication (voice) exploited ruthlessly by Cancerations (corporations that worship profit with blatant disregard for the available resources).

We have a situation where the 'written word' (letters) are being superceded by email, but that particular communications system isn't very secure - it never was - and so it gets absolutely hammered.

Instant Messaging is about the only communications system that actually works, and has made it onto the Internet mostly unmolested. The only pity is that, other than CSpace, and Skype, every other IM protocol is centrally controlled. Oh - other than our old unix friend 'talk' which for some reason nobody uses any more :)

And then there's file-sharing, which is used to communicate intellectual property. like - intelligence can truly be enslaved. Thank god for the free software movement: it recognises that intelligence nor knowledge should be restricted.

File sharing is typically used to communicate what used to be stories, and the reach of those 'stories' (mp3, mp4 and avi) is now global in reach. And the Cancerations that believe that they control these 'stories' are pretending to come down heavily on the ISPs that transmit them.

I predict that, as the last of the major 'traditional' communications successfully make their way onto the Internet, that we will see more clashes and more restrictions. For example, the Video Broadcast program Democracy is only in its infancy, but it proves the model for true communication from anyone to anyone. No centralised control. Imagine the shit-storm if that overtook government-run television and Canceration-controlled movie distribution! The best case scenario is that countries shut down their Internet at the borders of their country, which is something that China is already talking about doing.

So, the requirement to protect people from this kind of draconian abuse is very clear and very real, and we are in a position to do something about it. Not only that, but I envisage that it will be possible to optimise VPNs as a result, by messing with the way that the packets are sent.

What's the relevance of Skype?

Skype contains several stealth and firewall-busting technologies, but it doesn't go far enough. Skype was developed by the people who brought you Kazaa - the first really successful peer-to-peer file sharing technology, that the designers sold and made a fortune on, and then moved to the next Big Thing: voice. They've since moved on to video (Joost)

Skype detects and uses your HTTP proxy if you're inside a corporate firewall, and tunnels the SIP protocol over that. It detects if you've neglected to switch on your firewall, and utilises that to route other people's traffic through you. It utilises third parties to do UDP NAT-busting by a simple well-known and (IETF RFC) documented method which uses the third party to swap 'incoming' UDP port numbers which your TCP/IP stack on each end created, then drops the connection to the third party and utilises the two UDP ports, safe in the knowledge that the NATs on each end will now be correctly set up!

Also, Skype solved the problems normally associated with SIP's RTP protocol. Also, they provide Instant Messaging over their network. Also, they provide a search mechanism so that you can look up your friends. Also, they implement the usual 'IM' style of allowing communications from contact lists, so that you don't get swamped by unsolicited calls.

There are many many lessons to be learned from Skype, but the one thing that they didn't implement - despite me banging on at them that they really should do it - was this: utilising their infrastructure to add in TCP/IP tunnelling. Allowing any traffic, not just VoIP and IM and very slow fileswapping (3k/sec).

Then, about a year ago, Skype ran into a brick wall - just around the time that they sold out to Ebay (oh what a coincidence). Over eighteen months ago, the Telcos had worked out how to block Skype, and were deploying it, whole-sale. By not bothering with the peer-to-peer traffic, but by identifying the SIP (or more specifically the RTP) packets, they have taken back control. The cancer of capitalism, which, in the VoIP arena was stopped temporarily by Skype's innovation, is now 'immune' to the Skype 'cure', and marches inexorably on to continue its pathological consumption of resources.

Here's the thing: in the hands of a company like Ebay, Skype's technology has the money behind it to tell the Telco's to back off - or to do deals with them.

Unfortunately, Ebay now collects motherboard information and other identifying statistics off of your machine if you use the Windows version and you allow it to be upgraded. The days of Skype are numbered, and the designers have moved on to Joost, to do video.

Fortunately, we can learn the lessons from Skype's technology, which has been studied by several parties (myself included, at a higher level). Even Mr Cringely received a Skype phone call from somewhere in China, just like he predicted would happen, from a group claiming to not be using Skype, to let him know that they'd cracked the protocol.

What's the big idea??

The big idea is very straightforward: apply standard stealth techniques that are already known and proven to work from difference sciences, such as radio communications (in particular, spread-spectrum transmission) and cryptography (in particular, steganography).

The use of steganography is a little extreme - but it demonstrates a point which is easily done: your VPN 'overlays' traffic into the stream of, for example, HTTP traffic - a steganography-HTTP-VPN-proxy (whoa that's a mouthful) - but it is removed transparently at the other end (like rproxy). Packets are encoded into the whitespace of HTTP, into the mime-encoding of HTTP POST Content Forms, and into images.

All of these things can be detected by a pre-arranged application of spread-spectrum-technology using a Diffie-Helmann algorithm to negotiate the secret key, whereupon it then becomes near-impossible to even notice where the traffic is, because some of the traffic will be modified, and some of it won't.

Anyone trying to stop that would have a bitch-awful job. They would literally have to go back an era, starting with cutting off the Internet entirely. As a direct result, their entire economy (if they're a country) would be shot into turmoil.

But - for now, I wanted to expand on the much simpler approach, which is hinted at, above: to use just the spread-spectrum technology over IPv4 to tunnel IPv6. The great thing about this idea is that, strictly speaking, you don't need encryption, all you really need is compression (which makes it not look like a VPN, which is banned by some fascist ISPs in the U.S.) Also, you can use the spread-spectrum algorithm as a way to encode the session (port + IP address or other state information), so you can do away with that silly tunnelling header that is put on front of VPN packets!

In fact, strictly speaking, this algorithm is not really a VPN at all: it's a tunnelling system. It's a carrier wave. It's a proxy. It's a bird. no, it's a plane!

Now, here's the bit that's nice: the spread-spectrum concept doesn't have to just include port numbers, it can also cover IP addresses, and you would automatically get load-balancing over your IPv6 VPN, for free.

If you were to utilise the same principles that Skype do in their peer-to-peer communications, which is that they use relays, and they flip the relays occasionally, throughout the SIP call, you could set up routing to multiple destinations, and encode the ultimate destination IP address and port number into a combination of the UDP or TCP sequence number plus the spread-spectrum algorithm, as opposed to ... this is starting to hurt my brain :) It's Network Address Translation, using Spread-Spectrum itself to encode the 'Translation' and also scrambling the source IP address (in UDP packets), source port - and we haven't mentioned ICMP yet!

Effectively, you reimplement routing, over IPv4, but you implement it in a simple manageable way. I'm writing this on-the-fly, and I'm thinking about it... I think it might be possible to solve some of the issues of routing in peer-to-peer distributed wireless mesh networking using this spread-spectrum IP+port number approach, when attempting to get back onto IPv4 from the wireless mesh network. Amongst other things.

It's basically incredibly exciting, and I'm just scratching the surface.

Hints and Possibilities

So: we know that people are trying to control the Internet for profit, and succeeding. This is ironic, as the original requirement for the Internet was that it was supposed to be an attack-resistant defense network.

So, the only way to get round them is to move to the next level: treat IPv4 as simply the carrier wave for a new form of Internet, and fortunately IPv6 has come along and can be used as the basis for that new form of Internet.

The use of spread-spectrum technology on top of IPv4, to encode state information such as the real destination IPv6 address and port number basically allows you to completely disregard all of the normal rules that apply to IPv4. Of course, it will be necessary to obey some of them, for example, it will be necessary to obey IPv4 firewall rules, and it will be necessary to utilise that NAT-busting scheme (the one which uses a third party to set up two UDP connections: the end result is that both your NATs have the right UDP port redirections open).

But everything else is completely free-for-all, including and especially ICMP. And, if you don't want to run a firewall on your box that's running this kind of 'gateway', then ironically you open up the possibilities even more.

I especially like the fact that you don't need to add header packets. Also, the steganography idea is just wriggling the knife around a bit, because it bluntly states: "there isn't any point in you trying to work around this: we're a step ahead of you. You can carry on thinking that you can control everything, but you're deluding yourselves."

Things to watch out for

  • Entire countries or organisations cutting themselves off from the Internet. Large Communities going 'dark' - not just in communication but also in culture. Fortunately, if such a thing occurs, the citizens themselves are quite likely to rebel.

  • Migration of spam, viruses etc. onto the new Internet. There are ways to deal with this: nmap 'fingerprinting' of the machine that's doing the transmissions, finding out if it's windows, and banning it, outright.

  • Using protocols that use RSA keys or OpenID or other public key infrastructure to identify the person and the service that they're using, as a priority over-and-above the IP address - like CSpace already does.

  • Maintaining a peer-to-peer distributed database of IPv6 IP addresses, RSA keys and OpenID keys that are banned from utilising the network, and using trust metrics and/or keynote (RFC 2704) and/or reptile as the mechanism to make decisions about whether the person reporting the abuse is trustworthy.

Conclusion

The internet used to be a good thing - but it was naive of us to think that it wouldn't get abused by Cancerations. By treating the IPv4 network just like radio waves, we can utilise it to create a new Internet - and, hopefully, apply an infrastructure which is resistant to the mistakes of the past.

Luckily, if that all goes belly-up as well, then, just like in the Neal Stephenson and William Gibson Sci-fi books, we simply... move the infrastructure up to a level. Like my University lecturers liked to say: "Got a problem? Add another layer of indirection" :)

Notes and Further Reading


wireless mesh and OpenVPN, posted 25 Feb 2007 at 11:57 UTC by lkcl » (Master)

In a wireless mesh network, it's necessary to communicate not just locally but globally, but without it being attacked. and that's where OpenVPN comes in to play.

by treating IPv4 as just another carrier, and by applying spread-spectrum technology and randomising the relays, it's possible to totally bypass the problems and begin again.

i _think_ it might even be possible to solve the problems of routing between constantly-changing wireless mesh networks, by moving the routing between meshes down on to multiple IPv4 relays.

so, any IPv4 relay that happens to be acessible by one of the wireless meshes gets automatically added to the OpenVPN list of 'servers' which perform routing to other wireless meshes.

here's the neat thing: the wireless mesh network is just a geographically static version of a node in a mesh network. so, if the technology can do wireless mesh, then it can also cope with desktop machines and servers.

cool, huh?

Carrier Wave being equivelent to IP???, posted 25 Feb 2007 at 23:52 UTC by Chicago » (Journeyer)

I’m sorry but I feel that your analogy of using IP to Radio transmissions is a poor and misleading – both to people trying to understand IP4/6 who already understand the principles of Radio transmission (or wave transmission i.e. high school graduates) or people trying to understand Radio transmission who understand IP4/6.

The main difference being, that IP4 can be controlled (and I understand fully that the point of this article is to examine unstoppable methods of getting around the *misuse* of this control), where as radio waves, in so much of a sense can not – a particular carrier wave tuned to a particular frequency, and indeed directed through the use of clever or even not-so-clever aerial technology can indeed be directed “towards” a particular destination. It can not however be guaranteed to reach there, and definitely not be guaranteed to stop there.

Radio is a transmission technology, comparable to other transmission technologies, such as wires, light, magnetic, water (water powered logic circuits do exist for visual training purposes), even as one RFC states, carrier pigeons. On top of this radio transmission, you must attach some form of intelligence, be that even in the form of Carrier Wave starting and stopping (Traditional CW in Morse Code) or even more complicated intelligences such as AM, SSB, FM, RTTY and the list of “protocols” is endless, each allowing different types of information (Analogue (or another wave), Digital, or a basic alphabet).

Your article is suggesting (If I have this right) that you create a virtual network interface which instead of being a simple pipe to a single gateway, but to a distributed and ever changing gateway set. You are splitting up the stream of information and distributing it to multiple nodes and allowing it to recombine later.

If this is the case, why not drop the confusing and misleading bumph about comparing IP to Radio Carrier Waves, as I do not feel that it aids anything to your discussion.

simplistic analogy, posted 26 Feb 2007 at 07:23 UTC by lkcl » (Master)

dear Chicago,

thank you for replying. i realise that perhaps it seems that an a oversimplistic analogy and comparison has been made - however, i stand by it.

let me take the first paragraph of the wikipedia definition of 'spread spectrum':

Spread-spectrum techniques are methods by which energy generated at one or more discrete frequencies is deliberately spread or distributed in either the frequency or time domains. This is done for a variety of reasons, including the establishment of secure communications, increasing resistance to natural interference and jamming, and to prevent detection.

the above definition specifically mentions 'energy generated at one or more discrete frequencies' - but other than that, the rest of the definition holds true when substituting the words "packets appearing to come from one or more ports and IP addresses which are sent to one or more ports and IP addresses".

so the analogy does actually work. it also explains where i got the idea from.

and, hopefully, by explaining where the idea came from, other people reading the article will think "hmmm.... what other techniques can we think of that might do the same thing? water is waves, too - hmmm..."

:)

tuned receivers and sniffers, posted 26 Feb 2007 at 07:42 UTC by lkcl » (Master)

Chicago, hi,

i am assuming that you have tuned receivers (non-buggy implementations of a TCP/IP stack!). your point about radio waves not guaranteeing to be received (packet loss) and not being guaranteed to stop there (network sniffing) is a good one.

each and every part of TCP/IP transmission and receiving can be mapped onto an analogy in radio transmission and receiving: it is, after all, waves in the form of electro-magnetic energy rather than waves in the form of oh... electro-magnetic energy :)

one's down copper, fibre and through computers and routers. one's through the air.

however - we digress. a useful digression, perhaps, for someone who may be learning about TCP/IP and/or about radio waves - but a digression nonetheless.

anyway.

the mention of the analogy to spread spectrum techniques is, i believe, not irrelevant, as it allows us to look up existing spread spectrum algorithms and adapt them; perhaps even learn from such techniques and any mistakes that might have been made; etc.

in particular, it's necessary to use pseudo-random number generators that have large non-repeating periodicity.

... sorry....

dang. whilst wondering what to write next, i just started reading a bit more on the spread spectrum wikipedia entry.

_dang_ that tesla dude... he'd only just invented the radio transmitter and receiver, and _then_ immediately went on to invent spread spectrum AS WELL!

but... _daymmm_ :)

again from the wikipedia page, posted 26 Feb 2007 at 07:51 UTC by lkcl » (Master)

in the section on spread spectrum telecommunications:

Wireless Ethernet standard IEEE 802.11 uses either FHSS or DSSS in its radio interface.

so, if it's used at the ethernet level, why not also use it at the TCP/IP level, for the same purpose as described in earlier paragraphs of the wikipedia entry?

this comment i find particularly fascinating:

Note that these effects can also be achieved by using encryption and a very low-rate channel code, which can also be viewed as a spread-spectrum method, albeit more complex.

this, if i can correctly reverse the analogy, is a TCP/IP VPN. i think. i'm not sure what a 'very low-rate channel code' is, though.

confirmation, posted 26 Feb 2007 at 08:26 UTC by lkcl » (Master)

Your article is suggesting (If I have this right) that you create a virtual network interface which instead of being a simple pipe to a single gateway, but to a distributed and ever changing gateway set. You are splitting up the stream of information and distributing it to multiple nodes and allowing it to recombine later.

amongst other things - yep. a little bit of overhead is needed, to negotiate the changing gateway-set. but - the infrastructure to add multiple gateways is already part of OpenVPN. so, adding new ones and taking some away, dynamically, shouldn't be too much extra work.

already, work is ongoing to use IPv4 tunnelling to connect multiple wireless mesh IPv6 networks together.

what _hasn't_ been added to that mix - yet - is the use of spread spectrum techniques to encode the Network Address Translation.

Dont make me panic like that, posted 26 Feb 2007 at 20:10 UTC by Chicago » (Journeyer)

When I checked earlier and saw five new replies I thought my the thing I was striving to not cause (a flame war) had erupted, only to find it was yourself replying four times. Phew I guess - anyways...

Moving on with the argument about the Radio analogy - In the computer network model, if I want to send some information to a computer, then I pick a protocol, and then address it to a particular IP address and port number, and those packets go along the network as according to protocol and the rules of the routers and gateways, being forwarded over several networks till they reach their destination.

In this IP world, if someone controlling one of these routers or gateways has the ability to monitor you, stop you and even change the packets that are going through (for instance proxy’s modifying headers, NAT etc).

In Radio, if I want to talk to a particular person, the simplest way to do so is to use CW/Morse, where I pick a frequency and generate an electromagnetic wave which is propagated through the atmosphere in various ways as according to the laws of physics.

Now, if you wanted to stop the radio traffic, then you’re stuck. You can try to cause interference, or, more likely, just drown out the signal with a much stronger signal on the same frequency. But you would be unable to “adapt” that signal in any ways. You would be unable to pick the signal out of the air and replace it with something else (the closest thing you can get to that is actually a repeater station, which allows low power mobile users to communicate through the use of an automatic static station, which you broadcast to on a 600 KHz offset and it broadcasts it back on. However, the note there is that it can’t just take the original signal out of the air – there has to be that frequency difference.

--

On other notes, let’s say that I want to use VOIP (or indeed video) over this virtual network, for which I want to get a relatively high percentage of packets getting through, and also in a particular latency period. If I am starting the transmission by spreading them out to lots of different places, how does this affect the average latency, and if the packets are all taking different amounts of time to get there, how do the systems which put the information back in line hold up (I am presuming here that the re-ordering algorithms don’t actually get used that much – when I was doing VOIP testing at Uni, we found that the number of packets out of place was a minority, and then the number of packets that where only marginally out of place the majority of this minority (Based upon people testing all over the UK through to a US server and back). Because of this, the algorithm we used to re-order the packets in the playback buffer was quite primitive, and certainly did not hold up very efficiently when we spoofed the packet fragmentation at higher rates.

Are you still going to be in a position that this undetectable and unstoppable transmission mechanism is still going to be less-performance useful then the ISP’s connection-optimized own brand?

duplicate sending, increased reliability, posted 27 Feb 2007 at 00:36 UTC by lkcl » (Master)

he he sorry about that - i have a habit of coming back and thinking a bit more about what to say.

ok. where the TCP/IP - Radio-Waves analogy is oversimplfied a bit is that i say 'radio waves' but actually it's more like "radio waves transmitted through a wave-guide".

but you can clearly work that out and improve the analogy further should you so wish.

what i particularly wanted to pick up on was your point about VoIP. i believe that packet throughput and latency would be dramatically increased by the method i suggest, as opposed to using an ordinary VPN, because in the system of pre-arranging the algorithm which scrambles the packets (by selecting random sender ip addresses and random port numbers on UDP for example as the means to encode the NAT) you don't need to put on an extra VPN header!

the scrambling system, with a little bit of additional state information which needs to be arranged and/or rearranged every now and then, could be used to replace the need for VPN headers. (trying to restate it, a bit simpler).

also - a separate point, regarding Skype: from what i can gather, skype sends the same packet, duplicated, by more than one route.

by doing this, and then removing the duplicates, packets arrive more reliably and also the latency is improved, because you take the first packet to arrive, in each case.

it's a bit horrendous, in terms of throughput - but, hey, if that means 6k/s in between some of the 'relays', instead of 3k/s, then so be it! there was that paper which reported some analysis of skype. it mentioned 'supernodes'. these, i believe, are the 'relays'.

standard IPv4 routing already goes via many routes, posted 27 Feb 2007 at 00:47 UTC by lkcl » (Master)

in skype, if you look at the tech stats of a call, it says that your call goes via N relays. i've seen calls being routed via 4 relays, before.

but - remember - those 4 relays are _nothing_ as compared to some instances of IPv4 routing. on dial-up connections i've seen as many as 30 intermediate hops on a traceroute, and i am sure that other people have seen more.

also, skype on linux used to do a lot of pings and traceroutes to a depth of at least 4 hops, so that it could determine whether any of the 100 [presumably]-randomly-handed-out IP addresses (which skype connects to as part of the peer-to-peer network) were still within your local area (presumably on your same ADSL connection or on your same LAN or WAN)

what i propose is that the same sort of "relaying" system be used, between separate OpenVPN / scrambling servers. and the packets relayed on a little bit further, and maybe double-sent (via different relays), maybe not (depending on the traffic, throughput, conditions, QoS required etc.)

each scrambling server relay would have its own RSA key (because OpenVPN does!) and so each link is secure. and there is no significantly extra latency introduced than is already introduced by ordinary routing of IPv4 traffic anyway, if you get enough people using this system.

it's complex, and cool!

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page