Messaging Over IPv6 Headers

elias miles writes "A guy from the Swiss Unix Users Group made a cool utility that lets you chat over IPv6 packet headers. Not useful, but it's a nice hack. Read the article and download joe 6 pack."

Comments

again?

[acxr is wasted]

What is this, "nice hack" day?

Re:again?

[prockcore]

What is this, "nice hack" day?

Wake me up when it's "nice rack" day.

Re:again?

[Trespass]

"Slow news" day, dude.

Re:again?

[the uNF cola]

Or fall out from "6 pack day"

Re:again?

[Anonymous Coward]

What is this, "nice hack" day?

While IPv6 fixes many problems in IPv4, the developed world will not embrace IPv6 until many shortcomings in the protocol are addressed.

1. Cisco routers suck at IPv6. Many of cisco's routers use the router's CPU to process IPv6 packets instead of the fast-path. The reasons for this are explained in the next few points. While Juniper's routers are substantially better at IPv6 than cisco's, IT managers are often restrained by insane corporate policy that dictactes the use of cisco.
2. There are too many addresses. There are 16.7 million addresses per square metre of the earth's surface, including the oceans. This is overkill. The world does not need more than the 4 billion addresses available with IPv4, and I challenge you to come up with an application that requires that many. Assuming that you can actually come up with one, it could easily be solved with Network Address Translation, or NAT as it is commonly known.
3. IPv6 addresses are too large. An IPv6 address is 128 bits in size - 64 bits of which are reserved for addressing hosts, and 64 bits of which are reserved for routing. One thing that is cool with IPv6 is address autoconfiguration. Take your 56-bit MAC address on your ethernet card, ask for 64-bits of network prefix, bang it together with EUI-64 and you are set. The problem with a 64-bit network prefix is that routing tables become massive. Just do the math and you'll see that extreme amounts of memory are required to hold routing tables.
4. The IPv6 header is too large. An IPv4 header compact at 20 bytes in length, while the IPv6 is bloated at 40 bytes. That's right people, each one of your IP packets has twice as much overhead as before. While this may not sound much, IP networks have a requirement that the minimum MTU supported must be 576 bytes. That means that where you might have got 556 bytes of data in your IP packets, you now get 536 bytes. This means that downloading stuff will take 3.4% longer.

Sure, IPv6 allows for nice hacks like those described in this article, but is it really ready for prime time?

Re:again?

[raboofje]

With respect to point 3, autoconfiguration is indeed nice, but your statement about the routing tables is false. In fact, the size and efficiency of the routing tables are two of the great 'plus' sides of IPv6. To put is simply: since we don't have to be so thrifty with the address space, we're more free to do this properly.

As for point 4, you certainly have a point there, but with the MTU discovery in IPv6 (which prevents the (expensive!) fragmentation found in IPv4) you might actually see improvements there, too.

Re:again?

[Anonymous Coward]

Like I said before, the parent is utterly clueloss or trolling.
1) So what? Any company's routers are hardly a shortcoming of the protocol.
2) Yeah right. "... ought to be enough for everyone." We already have to use clumsy hacks to get by with the IPv4 address space and my phones don't even have IP addresses yet.
3) IPv6 routing tables are smaller because the address space doesn't have to be as fragmented as the IPv4 address space, thanks to the routing/addressing distinction (which in turn is possible because of the much larger address space)
4) Except today, with NAT, we frequently see IP over IP (for example: IPSec NAT passthrough: UDP encapsulated IP packets), which creates even more overhead, not to mention the increased computational load and failure probability due to increased complexity.
5) The developed world is already embracing IPv6, just not the western part of it.

Re:again?

[Cato]

So many half-truths, so little time...

Point 1 re 'Cisco sucks at IPv6' - do you have any data to back this up? Cisco seem to be doing fine with IPv6 deployments so I don't believe this is a real issue. More recent Cisco routers (7600, 10000, 12000 series) are hardware-based and will do IPv6 in hardware. Those that are software-based will forward IPv6 exactly like the other non-IPv4 protocols they have supported for years (DECnet, SNA, etc) - Cisco started out with multiprotocol routing not just IP. I'd be surprised if there is a big difference in performance - certainly there'll be more memory references with IPv6 addresses, but the IPv6 header (less the addresses) is shorter and simpler than the IPv4 header, so software-based routers may actually go faster on IPv6. Hardware-based routers should go at wire speed, basically.

Point 2 - there are already 1 billion cell phones in the world, and perhaps 30% of those are already IP-enabled. If you add in VoIP phones at home, and the myriad of new devices such as TiVOs, you can easily see how a mere 4 billion addresses is not enough - remember that India and China alone have 2 billion people. NAT is a hack that prevents simple deployment of more complex applications that aren't merely client to server - P2P apps work much more easily without NAT.

Point 3 - routing tables too large. Routing tables won't grow in size as you imply - if anything they are smaller for the true core routers, since IPv6 was designed to scale better using CIDR-like techniques for route aggregation, i.e. only a short prefix is stored and fewer prefixes should be needed. Your proposal for using the Ethernet-style MAC address doesn't work for ADSL, leased lines, and many other non-Ethernet media.

Point 4 - this is true for MTU-sized packets, but of course the host can send larger packets (frequently 1500 bytes or so), reducing this overhead. A 1 to 3 % overhead doesn't sound like much given IPv6's other advantages.

The fact that IPv6 allows stupid hacks like this is irrelevant. IPv6 is going to happen, it's just a question of time - my ADSL ISP already offers IPv6 as a checkbox option at no extra cost.

Re:again?

[gd23ka]

1. Cisco will step up support of IPv6 the more of it|s customers adopt it.

2. A long time ago somebody said 640K of ram is enough.

3. Not true. Just because the network addresses themselves doubled in size (8 bytes) that still doesn\t mean routing tables will bloat, explode and spiral out of control. The size of a routing table is determined more by how many subnets there are than how large the entry in that table is. They\ll just double in size and we can certainly handle that.

4. I can live with a performance hit of 3.4% . I|m not going to do your math but you claim it's 3.4% at 576 bytes... Pray tell me how much is it at 1536 bytes? 1.3%? How much is it at 2048 bytes? less than\ 1% ...

Re:again?

[psmears]

I would have ignored this as a troll, but it's been modded "+4 Interesting" so it's probably worth providing some perspective to the points raised..

1. Cisco routers suck at IPv6

Even if true, this can hardly be described as a shortcoming with the protocol (though I agree it might be a problem in its deployment).

2. There are too many addresses

In what way is it a problem to have too many addresses available? It's not compulsory to use them all ;-). Indeed it's necessary to have them, since it's not possible to allocate the addresses in a way that doesn't waste addresses, and that's also scaleable, since it must be possible to perform aggregation in a way that reduces the size of the routing tables...

NAT is not a solution to everything. In particular it prevents a lot of peer-to-peer type applications (and I don't just mean downloading MP3s - IP telephony is a good example!)

3. IPv6 addresses are too large.

Erm... 128 bits is four times the size of IPv4's 32 bits. That means that the routing tables will take up at most four times what they do at the moment. Even assuming 200,000 prefixes (an overestimate according to this, the full FIB can be stored in under 10Mb. The full BGP table (including attributes) would obviously be larger - but we're hardly talking "extreme amounts of memory"!

4. The IPv6 header is too large

This is plain misleading. For most links the MTU is 1500 bytes or larger, so the difference is closer to 1%. For links where the overhead is significant (e.g. dial-up links) it's normal to use PPP header compression, which all but eliminates the extra overhead.

Re:again?

[orasio]

1. Cisco routers suck at IPv6.
Who cares????????
Just as long as there is one good provider, people can start buying, and others will improve or lose.

2,3 & 4. There are too many addresses.

There is not such thing as too many addresses. There is such thing as too few, and it is called IPv4. NAT is just plain ugly and a dirty hack.

You cannot rely on routers translating packet headers, because networks tend to grow faster than processors.

With IPv6 one of the policies is to improve latency on top of throughput, and it is very reasonable, considering that you can buy more throughput, but latency is fixed.

I mean, those are not issues that need to be solved, they are part of the advantages of the protocol.

Why not make this broadcast public keys?

[Anonymous Coward]

As in the "radio stations" which broadcast some OTP numbers / instructions for spies / whatever, why not make this broadcast public keys of those whom you know along with your normal traffic. Then you could run a modified Joe Sixpack in the background and gather the keys that way.

Or broadcast DNS information (suitably protected), creating a distributed naming service without DNS servers :-)

The motivation behind broadcasting is that if all the rest of the world is against you, your odds are so small that you will lose. But if the bad guys only get like 1 % of the rest of the world, you have a chance of winning. Supermegaprobabilisticexpialidocius!

amusing fact

[Eudial]

suug (Swiss Unix User Group) means "suuck" in swedish.

Re:amusing fact

[Anonymous Coward]

here's another amusing fact
the swiss don't, as a group, speak swedish.

Re:amusing fact

[Anonymous Coward]

HA HA HA, so amusing, HA HA HA.

Some word in one language means something contrary in another language, that's amusing to who? 12 year old kids?

I think neither swiss nor swedish people care since

1) most swedish wouldn't encounter the abbrev. out-of-context without the explanation
2) most swiss don't know what some arbitrary abbrev. means in a totally unrelated language and if they do, they're educated enough not to find it "amusing" anyway.

Grow up.

Re:amusing fact

[MasTRE]

> suug (Swiss Unix User Group) means "suuck" in swedish.

As it does in Romanian!

I know this comment is not very useful (unless you're taking up Romanian), but it's a "nice hack" ;)

Re:amusing fact

[Anonymous Coward]

I find your faux-maturity amusing.

Re:amusing fact

[Anonymous Coward]

They don't, as a group, speak anything, having three national languages.

Re:amusing fact

[Anonymous Coward]

Right, because Swedish implies 'sweden,' whereas the Swiss are from Switzerland.

Re:amusing fact

[stevejsmith]

Hristos a inviat! Eh, or is it a little late for that?

Re:amusing fact

[grazzy]

vilket troligen är vad dom ägnar sig åt när dom inte skriver meningslösa program...

Re:amusing fact

[Anonymous Coward]

Make that four: fr, it, de, rm.

Re:amusing fact

[Anonymous Coward]

But about 60% speak swiss german. And guess what 'suug' means in swiss german ... ;-)

Re:amusing fact

[glitch!]

Right, because Swedish implies 'sweden,' whereas the Swiss are from Switzerland. ...Where they make the watches...

(If you're not a Python fan, never mind.)

Re:amusing fact

[ancalagon]

>> suug (Swiss Unix User Group) means "suuck" in swedish.
> As it does in Romanian!

Well, it also means "suck" in swiss german. But the usage is different, however, you can't translate "that sucks" into "das suugt".

Re:amusing fact

[MasTRE]

Haha, quite a bit late - unless you want to wish me that for the 4th of July too ;)

Re:amusing fact

[stevejsmith]

Meh...it's all I knew. Well, besides pa and bunica. And unless your my grandmother, I couldn't very well say "pa bunica" :-/

Could save a life...

[Alan Holman]

This method of sending messages might seem stupid now, but in the long run a James Bond like spy might do something like this to save a life. Hmm, or maybe spies are such jocks that computer code alludes them. Any unorthodox method of sending a message is important, though.

Re:Could save a life...

[Anonymous Coward]

maybe spies are such jocks that computer code alludes them

Maybe you shouldn't subscribe to the tired cliche that athletic ability precludes intelligence -- especially considering that you yourself can't spell. The word you wanted is "eludes."

Re:Could save a life...

[tiled_rainbows]

Any unorthodox method of sending a message is important

Nice, that would include the spreadsheet I put together to translate ASCII into a string of x'es and spaces to append to email sign-offs. like:

Love,
Snugglebunny
xx x xx xx xxx xx xx xxx x xxx xx xxx x xx xxx

NB: The above example doesn't mean anything, it's just an example

Evil bit

[countach]

But does the hack interfere with the Evil Bit(tm)?

And when the system becomes mainstream, and the spammers start sending you messages, will they set the Evil Bit?

IPv6?

[Xeth]

Hah, typical slashdot, this is a dupe. There was already a story on Science Fiction today.

Honesty is the best policy

[caluml]

The initial idea was to make something very stupid using IPv6

Well, at least he's upfront about it :)

Re:Honesty is the best policy

[trompete]

When you want to send an IM to somebody's IP, you have to type:

0x00000000000000.............0000.......45AEG6A4


by the time you finish typing their IP, you don't even want to talk to them anymore :-P

Re:Honesty is the best policy

[Leffe]

something very stupid

I am going to write a IPv4 emulator for IPv6 >:)

Re:Honesty is the best policy

[WoofLu]

Too bad, it already exists.

Well, it's not an emulator, but more like a proxy which maps the IPv4 space in IPv6 address space and does automatic proxying, so you can have full v6 nodes on your network, and still access v4 services.

It's called NAT-PT, and you can find its relative RFC here: http://www.ietf.org/rfc/rfc2766.txt

6 pack day?

[Anonymous Coward]

Bah. I drink that much in the time between waking up and having a shower. 24/day is closer to the truth. And yes I am a) unemployed, and b) a serious drunk. So sue me or commit me or something.

Covert Channel

[espo812]

This is known as a covert channel. Depending on what is going on this is useful or a security risk. For example, an employee could smuggle out data from a network possibly under the radar of most IDSes and the eyes of net admins. Replace employee with political prisioner, or spy, or whathave you.

Re:Covert Channel

[CySurflex]

For example, an employee could smuggle out data from a network possibly under the radar of most IDSes and the eyes of net admins

that would be security through obscurity - which we all know can not be relied on. Now if those messages were also encrypted with 512bit keys, then it would be something, but then you might as well include the message in the actual data part of the packet.

Re:Covert Channel

[CausticWindow]

Security risk, not security.

Re:Covert Channel

[LongJohnStewartMill]

that would be security through obscurity - which we all know can not be relied on.

The point of a covert channel is obscurity. You could add security on top of it, but putting the message into the data part would defeat the whole purpose of the covert channel. You are trying to find some way to get processes/machines/people to communicate within the confines of the operating system, and without anything/anybody else knowing about it.

An simple example? Say all the normal channels for process communication are blocked. No pipes, no sockets, etc. You can't use files. The only thing you can do is monitor the activity of the other process (ie the 'ps' command). By monitoring, say, memory allocation of the other process, two processes could communicate, sending the data byte by byte. Once a byte is sent, the receiving process could increment its memory to confirm. Then the sender increments its memory to send the next byte, etc.

The point of covert channels is that no matter how secure a system appears to be, it is possible for leaks because of things like this (probably more complex).

Re:Covert Channel

[cdemon6]

>>> This is known as a covert channel. Depending on what is going on this is useful or a security risk.

The german ct magazine had a working hack about a year ago which allowed network io over dsn query headers and could circumvent firewalls. Sounds like this might be pretty much the same problem, and i consider it a rather serious one because io based on such techniques may be slow because the is much more overhead than data per packet, but it *is* working and i don't know of any firewall which could prevent this. please correct me if i'm wrong in this point, of course ;)

Re:Covert Channel

[Lord_Dweomer]

"Replace employee with political prisioner, or spy, or whathave you."

I believe the Politically Correct term you were looking for is 'terrorist'.

Re:Covert Channel

[nnet]

Blocking icmpv6 will stop it.

Re:Covert Channel

[Anonymous Coward]

He's thinking about the DNS tunnel. Are you going to deny DNS resolution? Proxying won't help and blocking is inacceptable. The covert channel is in the data, so randomizing protocol data won't help either. You can at best detect patterns in DNS usage, but leaks of small amounts of data are IMHO undetectable.

Re:Covert Channel

[espo812]

i don't know of any firewall which could prevent this. please correct me if i'm wrong in this point

According to the article: I found the Destination Options header having no use yet. So make it have one

I'm not sure what the standard says about what this field should say. And even if it defines something, another question is what stacks will actually do with this field. Anyway - one way to stop this would be to zero this field on everything going out and comming into the firewall. The problem, of course, is that if this field actually serves a pourpose this will break the functionality. A way to detect and monitor this type of channel is to inspect that field on all the packets. If stacks are zeroing the field, then it should be easy to detect machines employing this technique. But as soon as a major vendor releases a stack that doesn't do that, this ceases to be a good detection method.

This all makes some big assumptions. How many admins will actually recognize this threat? How many will care? How many will take steps to mitigate it?

The thing I find fascinating is he invented and implemented this method without realizing what he was doing.

Re:Covert Channel

[nnet]

... He's thinking about the DNS tunnel...

I'm not.

Re:Covert Channel

[Anonymous Coward]

No wonder you're still posting without +1 bonus.

Re:Covert Channel

[Anonymous Coward]

You might not be able to on a network with MAC (Mandatory Access Control) and a really tight security policy.

Of course in order to embed something in protocol headers, you'd have to have an uncontrolled (or compromised) machine, but it would be feasible (albeit unlikely) that the access control would work by having untrusted clients allocate streams on the firewall for dedicated (and controlled) purposes.

But while this is not a feasible information leak channel due to the requirement of low-level access, covert channels are, in general, ways around strict security policies.

Re:Covert Channel

[drinkypoo]

Since netfilter can filter based on the contents of packets (at least for IPv4), I would imagine that it can now or can soon handle traffic like this in IPv6.

No need for destination options

[xYoni69x]

The Joe 6 Pack uses IPv6 destination options to specify a special option that contains the chat message...
The actual IPv6 packet being sent is an ICMPv6 echo-reply packet that seems to contain all nulls.
This makes the destination option seem a bit redundant...
You could implement this using nothing but ICMP (over either IPv4 or IPv6).

In the ICMP echo data, build some kind of header:

(4 bytes) magic identifier, i.e. 0xBAADF00D
(n bytes) message
(4 bytes) CRC-32 checksum of the previous n+4 bytes

The CRC-32 checksum is there to differentiate between "chat-pings" and "real pings".

I started to implement this as a special ping program (so you could do something like ping 1.2.3.4 --msg hi!) and maybe will finish it when I'm less busy.

Re:No need for destination options

[sleeper0]

Implemented by hping2

you can either do
hping 1.2.3.4 -e your_message_here
or
hping 1.2.3.4 -E file-to-embed

have fun!

Re:No need for destination options

[xYoni69x]

Awesome! This is just like what I was going to do, only way better. Thanks! =)

Poll

[whovian]

Those of you to whom this article reminds you of the *nix 'talk' command, raise your hand.

/me raises hand

Re: Your sig

[EnVisiCrypt]

01011001 01101111 01110101 00100000 01100011 01100001 01101110 00100000 01110100 01100001 01101011 01100101 00100000 01111001 01101111 01110101 01110010 00100000 01000100 01001101 01000011 01000001 00100000 01100001 01101110 01100100 00100000 01110011 01101000 01101111 01110110 01100101 00100000 01101001 01110100 00101110 00100000 01001000 01100101 01111000 00100000 01101001 01110011 00100000 01100110 01101111 01110010 00100000 01101100 01100001 01101101 01100101 01110010 01110011 00101110 00100000 01000010 01101001 01101110 01100001 01110010 01111001 00100000 00110000 01110111 01101110 01110011 00100000 01101010 00110000 00110000 00101110

Oh, and mods, buzz off unless you feel like converting the binary.

how about chatting over ping?

[avel599]

"sonar"

From the description of the Debian package:

Description: console chat via ICMP (ping) echo-request packets sonar implements a peer to peer chat using ICMP (ping) echo-request packets, which means nearly stealth communication between two hosts without a central server.

It has an ncurses-based interface with basic support for multiple windows and chats with different peers. It is a reference implementation for the u23 project of the Chaos Computer Club Cologne (http://koeln.ccc.de)

Re: Your sig

[xYoni69x]

The following code acts as a method of circumvention and is therefore illegal:

#include <stdio.h>

static char msg[] = "01011001 01101111 01110101 00100000 01100011 01100001 01101110 00100000 01110100 01100001 01101011 01100101 00100000 01111001 01101111 01110101 01110010 00100000 01000100 01001101 01000011 01000001 00100000 01100001 01101110 01100100 00100000 01110011 01101000 01101111 01110110 01100101 00100000 01101001 01110100 00101110 00100000 01001000 01100101 01111000 00100000 01101001 01110011 00100000 01100110 01101111 01110010 00100000 01101100 01100001 01101101 01100101 01110010 01110011 00101110 00100000 01000010 01101001 01101110 01100001 01110010 01111001 00100000 00110000 01110111 01101110 01110011 00100000 01101010 00110000 00110000 00101110";

int main()
{
char *p;
unsigned char c = 0;
int x = 0;

for(p = msg; *p; p++) {
if(*p != '0' && *p != '1')
continue;

c <<= 1;
if(*p == '1')
c |= 1;

if(!(++x & 7))
printf("%c", c);
}

return 0;
}

Re: Your sig

[EnVisiCrypt]

With your circumvention device, you have cost an estimated Eleventy Billion dollars in sales for my organization. Expect to hear from my lawyers.

Perfect Hack For MacHack

[Rosyna]

All good hacks for MacHack must be useless. You will get boo'ed and "usefull" will be screamed at you otherwise.

Big Deal

[Anonymous Coward]

Wake me up when someone figures out how to send porn over IPv6 headers.

Great...

[Anonymous Coward]

The IP6 ink is barely dry, the standard isn't globally deployed to the masses yet - and people are already writing apps to generate and send broken packets.

I thought IP6 was supposed to help eliminate such foolish tricks.