[Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities
paul at xelerance.com
Wed Oct 1 11:42:26 EDT 2008
On Wed, 1 Oct 2008, John Denker wrote:
> I recently brought up IPsec over IPv6. I'm happy to report
> it was mostly uneventful.
Good to hear.
> 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.
There is currently only one basic test for ipv6 located at
testing/pluto/ipv6-basic-pluto-01. I would love to see more
test scenarios there.
> 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.
Since you have just done this, how about doing an example
config to be installed in /etc/ipsec.d/examples and perhaps
a README.IPv6 with your findings and issues to date?
> 3) When using kernel IPsec, it is allowable and often
Note that "kernel IPsec" is confusing, hence our insistence
to talk about KLIPS or NETKEY.
> 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.
Tuomo, do you agree that "%none" would work better then "%defaultroute"
in most cases?
> 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.
Recently, the updown scripts were split into a klips and a netkey
version, so if you have modifications for us to _start.netkey, we
would like to review and test those and if possible incorporate
> 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.
I did not realise this was possible. Can you give a little more
detail on how this works?
> 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).
The option for this is the leftsourceip= option, though I am
not sure if it will work fine with IPv6. Please let me know if
I would like to start a README.IPv6 based on your email and your
weg page, if you have no objections. I'll also incorporate some
of the information in the man page for ipsec.conf.
> 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.
There is an option now to reread hostnames in the configuration
file to better support dynamic DNS. See USE_DYNAMICDNS in
> 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) ...
The current idea to implement is to do a key exchange inline,
and treat the connection as 'anonymous ipsec', until it gets
upgraded via channel bonding (eg via OE or GSS) to a more trusted
state. This is being drafted in the IETF BTNS ("Better Then Nothing
Security" working group).
> instead of trying to use reverse DNS, which seems to have
> lots of problems. We need to think about this some more.
DNSSEC with keys in the forward using ID_USER_FQDN?
More information about the Dev