ipsec over ipv6 for olpc

I got ipsec over ipv6 to work yesterday, on my laptop, server, and olpc. I couldn't get it to work using setkey or racoon, but racoon2 worked the first time.

Nowhere on the net could I find an example of a working ipv6 to ipv6 setup for linux ipsec - even though the protocol was designed for that scenario in the first place, and only painfully adapted to ipv4 scenarios over the course of years.

The setup:

OLPC   -> laptop      -> hurricane electric tunnel -> toutatis.
2/48   -> 1/48 -> /64 -> ipv4 tunnel -> ipv6 at he -> toutatis.taht.net

Yea! a static ipv6 address! Now that I have squid (from cvs), jabber, dns, web, ssh all running pure ipv6, No IPv4 on the client is now feasible. I'm free of IPv4! with Native encryption! Bwhahahahaha...

Naturally I started playing with ipsec. The initial key negotiation phase is painfully slow, especially over a 220ms internet RTT, but after that the ipsec vpn tunnel is completely transparent to the user (and opaque to the sniffer). It's pretty darn fast on local connections though.

---

All kinds of things "just worked", but I got into a world of hurt dealing with NetworkManager on the laptop providing the tunnel. NetworkMangler arbitrarily takes your interface up and down to get an ipv4 address and wipes out your pre-existing ipv6 setup when it should just co-exist. !@#!@#!@

I still haven't figured out how to make NM do the right thing. If you add static ipv6 ips on the olpc, they also get flushed when NM does its thing. Shouldn't ipv6 on a given device just stay up and let RA (router advertisement) do its thing, most of the time? There must be some kind of RS (router solicitation) message that says - "I'm not sure if I'm still on the right net"... I'd like my ssh over ipv6 connections to stay running through a dhcpv4 change whenever possible... part of the point of ipv6 stateless autoconfiguration is that you don't neeed a sharecropper's lease anymore.

---

The latest firefox beta works great running on the olpc. Much more usable,
at least for an adult, and having adblock+ running on the olpc is a real win.

---

The olpc also works (once you turn -notcp off) X11 client/server over ipv6.
It is a great X-terminal! I can think of lots of ways X could be used in this way - keeping an executable on the school server and just displaying it on the olpc would ease on major software rollouts - and allow the use of more complex software that won't fit into the memory available on the olpc. On my wireless network you simply don't notice the fact that (firefox for example) is running on a remote server, 'cept when you want to use flash. Startup time is vastly improved and scrolling is totally fast....

---

In poking about ipsec I noticed that the geode processor in the olpc has a hardware encryption block. A couple ipv6 network and ipsec benchmarks are in order, and I'm going to go fight with NetworkMangler some more...

Labels: ipsec, ipv6, networking, olpc

  ¶ 5:10 AM 0 comments

  RFC: Better future desired

I've been reading rfcs lately, working on multiple levels - 1) How does a given stateless protocol work, and 2) How is it secured, how can it be subverted? I'm doing this because 3) I'm trying to design a new stateless protocol and 4) I'd like to get it secure-able eventually - and 5) avoid any potential patent/copyright issues at the outset. I'm confident I have the latter solved now, but it took a month of review, headache, fear and worry before I felt capable of coding again.

I wish everyone was born with a "get one great lawyer free" card, that they could use up when they most needed it. I found myself missing the structure of a major corporation, badly.

I also mostly convinced myself that achieving security and statelessness were almost impossible, that security requires state - but note my equivocation "almost" and "mostly" - darn adverbs - I'm still going to give the design as-is a go and see what happens next.

This morning, I looked up, and saw Johnathan Zittrain had written an excellent article on the future of computing. It is not a bright one, particularly for independently minded programmers:

To be sure, amateurs who do not have houses to lose to litigation can still contribute to free software projects—they are judgment proof. Others can contribute anonymously, evading any claims of patent infringement since they simply cannot be found. But this turns coding into a gray market activity, eliminating what otherwise could be a thriving middle class of contributing firms should patent warfare ratchet into high gear.

While that rang especially true for me given when I'd done all month, it was his proposals for solving the spam/bot problems by creating for ever more limited, tethered, restricted (I'd call them "broken") computers that got to me. Instead of getting back to work, I started writing up a response... but then Richard Stallman fired back

It is true that a general computer lets you run programs designed to spy on you, restrict you, or even let the developer attack you. Such programs include KaZaA, RealPlayer, Adobe Flash, Windows Media Player, Microsoft Windows, and MacOS. Windows Vista does all three of those things; it also lets Microsoft change the software without asking, or command it to permanently cease normal functioning.

But restricted computers are no help, because they have the same problem, for the same reason.

The iPhone is designed for remote attack by Apple. When Apple remotely destroys iPhones that users have unlocked to enable other uses, that is no better than when Microsoft remotely sabotages Vista. The TiVo is designed to enforce restrictions on access to the recordings you make, and reports what you watch. E-book readers such as the Amazon “Swindle” are designed to stop you from sharing and lending your books.

Very good debate in both articles. Both describe at a 50 thousand feet what I'm trying to get done at ground level, in an itty, bitty, obscure corner of the internet. Today I wanted to talk about how the ntp protocol achieves a consistent and secure view of time itself.

I'm out of time now - that valuable yet non-material substance - I've got some coding to do.

Labels: ipv6, ntp, rfc, time

  ¶ 4:07 PM 0 comments

  Religion and TCP

three mostly unrelated topics this morning...

Conversation I need to think about regarding religion and non-religion. Another, Regarding privacy... and and Article that I need to think about regarding fixing TCP...

Labels: networking, privacy, religion

  ¶ 4:02 PM 0 comments

  DHCP, IPv4, home networks, and IPv6... with DNS

IPv6 has a feature that was innovative and useful back when it was designed in the mid-90s, called stateless autoconfiguration. An IPv6 enabled machine can automatically create an IPv6 address for itself, get on a network, and figure out how to access the internet.

This solves a tough problem that occurs on just about every network I've ever run into - two devices will automatically configure themselves with the same static IPv4 address, disabling both devices (or at the very least, making access to them a flaky experience). Worse, usually that automatically configured device comes up on an ip address that is dedicated to crucial infrastructure - the main router for a home, for example, is usually on 192.168.0.1. Bring up another device intended to be a main router for that home, (say you are adding a wireless access point) and it too comes up on 192.168.0.1. Unless you have a private ethernet port handy (which requires some knowledge of networking), usually you have to temporarily disable the main router - disconnecting your kids from their second life sessions - and bring up the new one, change its default IPv4 address - find a static allocation for it - write it down - remember to use the right netmask - (all of which requires some knowledge of networking), save it, reboot both routers, and then proceed to configuring the new one.

On larger networks, someone randomly bringing up a machine on a static ip address can be catastrophic.

Now, DHCP has become the standard way to assign new "dynamic" IP addresses in a NATted IPv4 network. It's come quite a long way - from, at first, only being able to assign IP addresses, to now being able to specify dns servers, time servers, netbios servers, serve up boot files, statically assign some IP addresses, dynamically do others, etc, etc.

Early versions of the DHCP server code helped turn most of us into landless cyberserfs - there was no way to assign and route static ip addresses sanely back in the 90s - so most end users went dynamic early, as the end users could not be trusted to assign their own gear the right addresses, and statically assigning the wrong addresses could be catastrophic to the whole network. ISPs ended up authenticating via protocols like ppp, and assigning dynamic addresses, because it was easier, and safer - not because it was right - or better - using static addressing would have simplified billing and firewalling (and worm/virus control) considerably, then and now.

Dynamic addressing also made it much harder to create services at home. It moved the domain name system into the province of the ISP rather than into the home or small business. This has led to such steps backwards as not having DNS running at all on most small networks - meaning that printers can't get assigned sane names like "printer.hm.taht.net", ditto for your daughter's machine - instead, people manually remember and type in IP addresses whenever they want to talk to machines inside of their own network. (solutions to this have appeared in Netbui, Bonjour and dnsmasq, but I'm already way off where I intended to go with this piece.

Most people don't even know how to discover the IP addresses of machines in their own network - they are no longer connecting to each other, but to the internet...

I think that people dig "the Net" so much more than "their home" is because that the net is so much easier to use than their own gear!

It's not just DHCP's fault - routing was also painful in a sometimes connected via modem internet environment, and CIDR was just getting started. There were no good solutions back then to these problems.

The cyberserfdom created by this flaw is reflected by the terminology used by DHCP itself. You get a IP "Lease", which you have to "Renew" periodically. Although the documentation uses "server" and "client" terminology, I translate that into "Master" and "Sharecropper" when I'm feeling depressed.

Static IP addressing, assigned via DHCP, appeared in later versions, keying off the MAC address of an ethernet card, much like IPv6 stateless autoconf works. Back in the 90s, you used to have to manually enter your own name servers, now DHCP handles it for you. Getting on a "normal" ipv4 network today is as simple as enabling dhcp and turning on your machine, and setting up a "normal" ipv4. I rarely see a well configured small dhcp network, with static addressing for printers, etc, usually people end up manually assigning the static ips rather than getting DHCP to do it. More often than I care to remember, they assign static ips in the dynamic lease range, leading to all sorts of oddities (that newer dhcp servers generally detect).

It's not that people are stupid. This is hard stuff to get right all the time.

At the lowest level of the protocol, you have to get that IP address right... and you need to be able to access a nameserver in order to do anything on the internet. It is helpful to also run your own dns at home... (DNS translates www.example.com into 127.0.0.2 on my machine)

Running DNS at home? I almost never ever see that... DNS servers take up a lot of memory and very few routers supported it until recently. Everybody seems to think that www.example.org is the only correct form of a computer name - most of the people with vanity names just use them for websites instead of managing their home network. People just plug in their airport and laptop and expect to be on the internet, no where else.

Setting up good DNS is hard, for a lot of reasons - security, complexity, and the warts in a major program and protocol. It is still highly desirable to run your own DNS at home - it also speeds up web access - but solutions are emerging that make it less probable you will need to do so in the future.

I wish a lot more programmer energy had gone into making home/small business DNS services easier. I've been running my own DNS servers for 20 years and I STILL don't get it completely right, and never on the first time.

ANYWAY.

IPv6 solves the "get IP address" problem well. Actually, it oversolves it. It solves it so well that it introduces new problems. While a human being can remember "my printer is on 192.168.0.50", I find it impossible to remember or even type in the fact that my olpc is on [2001:470:806f:2d7:217:c4ff:fe10:b811] which is what its full IPv6 autoconfigured address looks like. It's GREAT that it's on the net... all by itself... routing - announcing its existence -

Theoretically.

Regrettably one crucial piece of stateless autoconf, went into DHCP, but didn't make it into IPv6 - the ability to get a nameserver automatically. Thus, the friendly internet of http://ipv6.google.com becomes http://[2001:4860:0:2001::68] (if you can remember that, you are a better person than me) unless you do something about it.

There's a few solutions, DHCPv6 and RDNSS announcements in radvd (covered in RFC 4339 rfc 5006) - which I'll get to in my next blog. (I'll fix up this one a bit later too)

Labels: dhcp, dns, ipv6, networking

  ¶ 4:32 PM 10 comments