[Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

[John Denker]

Hi Folks --

I recently brought up IPsec over IPv6.  I'm happy to report
it was mostly uneventful.

For me, this is important.  It means I don't need to fool
with NAPT traversal ever again.

Of course this is using pluto with kernel IPsec via netkey, 
not using klips.

For the next level of detail on all of this, see
  http://www.av8n.com/computer/htm/ipv6-howto.htm
especially
  http://www.av8n.com/computer/htm/ipv6-howto.htm#sec-ipsec


Some suggestions:

1) There ought to be more documentation about using kernel
 IPsec instead of klips.  The documentation is very sketchy
 on this topic, and soon degenerates into unhelpful whining 
 about ancient political issues.  Also this part of the
 documentation contains some broken links.

2) Similarly, there ought to be more documentation of using
 openswan over IPv6.  I talked to some people who weren't
 even sure it would work.  There is not a single mention of 
 "connaddrfamily" in the /doc directory, unless my grep is 
 missing something (although it is mentioned properly on 
 the ipsec.conf manpage).  Some examples would be nice.

3) When using kernel IPsec, it is allowable and often
 advantageous to specify "interfaces=%none".  This ought
 to be prominently documented somewhere.  And if you ask
 me, it ought to be the default when using kernel IPsec.
 And connections ought to be routed using the actual route,
 not the "defaultroute".  This is easy to do using 
 "ip route get to ....".  I have scripts that do this, but
 it ought to become the standard built-in behavior.

4) When using kernel IPsec, if you use tcpdump or some such
 to look at the interface (e.g. eth0), by the time tcpdump
 gets its hands on the packet, it has already been decrypted.
 As a workaround, it pays to define an alias device (e.g. 
 eth0:1) so you can get your hands on the packets fresh off
 the wire, before they are decrypted.  The problem and the
 workaround ought to be documented somewhere.

5) Openswan IPsec works even when the first hop is a 6/4\6 tunnel 
 via a "6to4" device, i.e. IP protocol 41.  The 6to4 device is 
 weird enough that we might have expected some trouble.  One 
 slightly tricky point is that you need not (and must not) 
 specify a leftnexthop when using this device.  This ought 
 to be documented somewhere.

6) When using kernel IPsec, when the host is performing IPsec
 for a subnet, if the peer tries to contact the host via its 
 address on the subnet, the traffic gets thrown away.  This 
 ought to be documented somewhere.  Klips was better behaved 
 in this regard (although some deft fiddling with the routing 
 tables was required).

For the next level of detail on all of this, see
  http://www.av8n.com/computer/htm/ipv6-howto.htm
especially
  http://www.av8n.com/computer/htm/ipv6-howto.htm#sec-ipsec

================

Some open issues:

IPv6 very substantially changes the roadwarrior scenario, 
in a good way.  It begins to look like little more than a 
thinly-disguised dynamic DNS situation.  We need to think
about this some more.

Also, IPv6 substantially changes the OE scenario, in a good
way.  One could imagine contacting the peer directly to ask
for keys (perhaps via port 79=finger or port 113=ident) ...
instead of trying to use reverse DNS, which seems to have
lots of problems.  We need to think about this some more.