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?

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

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!

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

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

[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 ;)

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.

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)