Slashdot Mirror


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

6 of 70 comments (clear)

  1. Why not make this broadcast public keys? by Anonymous Coward · · Score: 5, Interesting

    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!

  2. Covert Channel by espo812 · · Score: 5, Interesting

    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.

    --

    espo
    1. Re:Covert Channel by cdemon6 · · Score: 4, Interesting

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

    2. Re:Covert Channel by drinkypoo · · Score: 2, Interesting

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  3. No need for destination options by xYoni69x · · Score: 4, Interesting

    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.

    --
    void*x=(*((void*(*)())&(x=(void*)0xfdeb58)))();
  4. Re:again? by Anonymous Coward · · Score: 2, Interesting
    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?