Date: Mon, 14 May 2012 11:03:10 +0200 From: David George <dgeorgester@gmail.com> To: freebsd-hackers@freebsd.org Subject: FreeBSD IPSec adventures Message-ID: <CA%2BLg%2BWEsNUcOHFOdn1nNvpAiB18abkyUgqmjkKc1oVrPoEv4jw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello All.
I have been working on a project where the goal has been to convert
the FreeBSD IPSec stack to a userspace application. The project is
pretty far along, so I thought I would dump my
observations/experiences with regards the IPSec stack here. (Hopefully
this is the correct forum)
1) SADB_X_SPDUPDATE (PFKEY call to update an existing Security Policy)
I found that FreeBSD creates a new policy with a new unique Security
Policy ID when performing an SP update. There appears to be no
definitive RFC for this behaviour, I found this text in an IETF memo
titled "MOBIKE Extensions for PF_KEY":
"
SADB_X_SPDUPDATE:
If an existing SPD entry should be updated, the IKEv2
implementation sends a SADB_X_SPDUPDATE message to the kernel.
This massage has the following format:
<base, policy, address(SD),[lifetime(HS)]>
The kernel responds with a message of the form:
<base, policy, address(SD), [lifetime(HSC)]>
The meaning of the payloads is the same as for the SADB_X_SPDADD
message. All the content of a SPD entry can be changed except the
sadb_x_policy_id field and the source/destination addresses, which
are the inner addresses in tunnel mode. However, the tunnel
endpoint addresses, which only exist in tunnel mode, can be
changed using a SADB_X_SPDUPDATE message.
"
I think that the approach of not modifying the policy ID is the more
sensible; and as it turns out, was something that my work required.
Does anyone know why FreeBSD takes this approach?
2) ESP + Authentication Crypto Performance
I ran into some performance issues when using ESP with any
authentication. The problem is that only one crypto device can be used
for the ESP transform. This makes it impossible to use AESNI with
ESP+auth with FreeBSD as it stands, which amounts to a major
performance penalty. This looked tricky to resolve properly, as it
seems to be an infrastructural problem.
3) SHA1 Performance
I also had some problems with the opencrypto software SHA1
performance. By substituting the opencrypto sha1 call with an openssl
library call the time to do a 1000B hash reduced to under half. Has
anyone else noted SHA1 performance problems?
Would be great to have some comments from FreeBSD gurus.
Kind regards,
David George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BLg%2BWEsNUcOHFOdn1nNvpAiB18abkyUgqmjkKc1oVrPoEv4jw>