NetBSD IP security in practice

[Erik Fair]

Who among us is using IP security in practice (production)?

Are you using it just for VPN/tunneling, or in transport mode?

How well does it perform?

What quirks does it have?

How does our documentation stack up? Was it clear enough by itself, or did you have to consult other sources to get IP security to work on NetBSD?

curious,

Erik <***@netbsd.org>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Who among us is using IP security in practice (production)? [...]

What's "IP security"? D'you mean the stuff usually called IPsec?

Your failure to use the term argues against that interpretation, but
the rest of the message seems to refer to a specific thing, and that's
the most plausible thing you could be talking about, it seems to me.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[h***@iij.ad.jp]

Hi Erik-san,

I'm using IP security in router product based on NetBSD.

Post by Erik Fair
Who among us is using IP security in practice (production)?
Are you using it just for VPN/tunneling, or in transport mode?

I'm using it for

1. IPsec-VPN (many use cases, simple ESP tunnel)
2. L2TP-VPN (many use cases, L2TP tunnel + ESP transport)
3. Secure Logging (sometimes, syslog + ESP transport)

I feel 99% of use cases are tunneling.

Post by Erik Fair
How well does it perform?

I'm using "options IPSEC", it is KAME IPsec implementation.
"options FAST_IPSEC" should be better than KAME.

Interoperability of AH and ESP is fine.

Throughput (bps or pps) is not fine. I think throughput problem
is not caused by IPsec itself, IP stack is slower than other
implementation today. Especially, throughput of NetBSD IP stack
is slower on SMP environment.

I'm using /usr/sbin/racoon (and many local hacks) for key exchange,
but raccoon is too old implementation. There are some newer and
better implementation of IKE. I think replacing old racoon is happy.

Post by Erik Fair
What quirks does it have?

Lookup of SPDB and SADB become slower when using large DB.
If you use many numbers of transport mode IPsec communications,
or concentrate many numbers of VPN tunnels, this may causes troubles.
some LIST_FOREACH() spends very long time.

Workings of phil_run_hook() cause a misunderstanding when using
combination of some tunneling protocol and transport mode IPsec.
Filters don't works for decapsulated(inner) packet. For example,
if you use gif tunnel and transport mode IPsec, filters for gif
may not work. see ipsec.c line 550 for detail. I think reconsiderations
for filtering manners for packets which encapsulated using IPsec.

Post by Erik Fair
How does our documentation stack up? Was it clear enough by itself, or did you have to consult other sources to get IP security to work on NetBSD?

man pages are good enough for programmer's view.
I don't know about documentations for network users.

Thanks,
----------
Internet Initiative Japan Inc.

Product Technology Section,
Product Development Division,
SEIL Business Unit

SUENAGA Hiroki <***@iij.ad.jp>

[Edgar Fuß]

Post by Erik Fair
Who among us is using IP security in practice (production)?

We have been using IPsec in production until a year or two ago.
During that period, we were physically split across two sites. At times, we even had most of the ~150 clients at the new site, but nearly all of the servers (including NFS and LDAP) at the old site because the server room at the new site was still under construction! So we tunneled accross the university network.

Post by Erik Fair
Are you using it just for VPN/tunneling, or in transport mode?

We were using an IPsec ESP tunnel and racoon with fixed master secrets.

Post by Erik Fair
How well does it perform?

At the slower end, we had an old P4 machine which could almost cope with the 100MBit connectivity there.

Post by Erik Fair
What quirks does it have?

I don't remember. We had one strange issue with pf which, on one end, sometimes consistently eated up the SYN packets of the TCP handshake. It would, from time to time, seem to randomly chose a client to sabotage and then drop its SYNs for some minutes. No, no errors in the configuration: all block rules had `log' in them and nothing was logged.
We never managed to track this down and circumvented it by switching from pf to ipf.

Post by Erik Fair
How does our documentation stack up? Was it clear enough by itself,
or did you have to consult other sources to get IP security to work on NetBSD?

I think I set it up with the documentation only, but maybe I used other sources like my bookshelf, Wikipedia or the like.

All this was on 4.0.1, 386 on one and amd64 on the other end.
Of course, it was not exactly fun to have some hundred NFS clients connected to the server through a 100MBit tunnel plus IPsec latency, but it did work! We even installed new machines (with FAI) across the tunnel.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

I have been using transport-mode IPsec for years, with racoon with psk
or with certificates, to protect traffic for an unusual remote
filesystem that lacks adequate native security. I have also been using
tunnel-mode in a normal VPN situation. All of this has been with the
KAME-derived IPsec implementation ("options IPSEC").

I've run this on i386 and sparc64, with no real problems.

The documentation seems adequate for those who are familiar with the
standards. I have not looked at from the point of view of someone who
doesn't really understand IPsec to start with.

Certificate handling in racoon is messy. Part of this is that there's
no clear plan (in the wider world) for what kind of certificate one
should have to allow which kind of IPsec SA to be instantiated.

The other issue is that I am not clear on if there is adequate support
dynamic-remote-peer VPN (road warrior type, vs site-site), which often
involves provisioning a private/internal address for the remote host to
use inside a tunnel.

[Edgar Fuß]

Post by Greg Troxel
The other issue is that I am not clear on if there is adequate support
dynamic-remote-peer VPN (road warrior type, vs site-site), which often
involves provisioning a private/internal address for the remote host to
use inside a tunnel.

I thought that was exactly the point the L2TP-over-IPsec-Matroshka was good for: you can't use tunnel mode when you don't have a local IP to tunnel.
Or is there a more intelligent way than PPP-over-L2TP-over-UDP-over-IPsec-over-IP-over-whatever?
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Edgar Fuß

Post by Greg Troxel
The other issue is that I am not clear on if there is adequate support
dynamic-remote-peer VPN (road warrior type, vs site-site), which often
involves provisioning a private/internal address for the remote host to
use inside a tunnel.

I thought that was exactly the point the L2TP-over-IPsec-Matroshka was
good for: you can't use tunnel mode when you don't have a local IP to
tunnel.
Or is there a more intelligent way than
PPP-over-L2TP-over-UDP-over-IPsec-over-IP-over-whatever?

There is a way to do the equivalent of DHCP using IKE as the control
protocol. So you have a RFC1918 address behind some NAT, do IPsec with
NAT-T to get to the VPN gateway, and then get a perhaps-public
inside-enterprise-firewall address over the IKE control connection, and
then configure that somehow and use it for packets that are heading into
the tunnel.

I have seen this work with a proprietary VPN implementation on a
proprietary OS. I've never tried to do it with NetBSD.