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

[Paul Wouters]

On Wed, 1 Oct 2008, John Denker wrote:

Hi John,

> 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
your enhancements.

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

See above.

> 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
that works.

>  http://www.av8n.com/computer/htm/ipv6-howto.htm#sec-ipsec

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
Makefile.inc.

> 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?

Paul