
Netdev Day 1: IPsec - ibotty
https://jvns.ca/blog/2018/07/11/netdev-day-1--ipsec/
======
cryptonector
IPsec is extremely difficult to use correctly, or even at all.

Part of the problem is that IPsec deals in authenticating peers and
authorizing them to the IP addresses they sport, but IP address numbering is
fluid and difficult to tie to authentication or authorization databases. All
too often sites permit large prefixes to all clients with certificates from
some CA.

Another part of the problem is that IPsec protects _IP_ , not TCP and friends.
This means that part of a TCP connection's packet flows may be protected by
SAs with one peer, and later by SAs with... a different peer -- this may sound
strange, but given the issues w/ authorizing IP addresses (see above) this is
very much possible.

The right answer is to tie the upper level protocols (e.g., TCP) to IPsec
policy automatically so that for the entire lifetime of a connection the local
and peer IDs are "latched". This has been specified [0] (disclaimer: I'm the
author), but not implemented. API-wise this would manifest as socket options
you could set and/or get to specify or learn local credentials, peer name,
quality of protection, etc.

[0] [https://tools.ietf.org/html/rfc5660](https://tools.ietf.org/html/rfc5660)

~~~
huhtenberg
> _IPsec is extremely difficult to use correctly, or even at all._

No, it's not.

Some IPsec implementations are kludgy and lack proper granularity/control over
their configurations. It is also very flexible, so you can of course
misconfigure it to the point where the whole setup becomes a royal
clusterf#ck, but doesn't mean it is "extremely difficult to use correctly". It
works really well for a wide range of common scenarios, each of which is not
that hard to configure once one knows what they are doing.

~~~
click170
Some of the obstacles really hit you when your working with different systems,
if you connect the same systems then just mirror the config but when each end
uses different terminology it can get confusing unless you know what you're
doing. I don't think I'd agree that it's _extremely_ difficult but it's
nontrivial sometimes.

~~~
sathackr
Try to connect TLS/SSL VPNs from different vendors....

------
kev009
Great post!

One nice thing about having the data path in kernel is that you aren’t context
switching to userspace and back, nor doing the associated copyin/copyout to
move data between address spaces. This can be further leveraged to do inline
crypto offload, with Chelsio’s T6 NIC and Intel QuickAssist chipsets. This
means it’s quite possible to do 100gbit IPSec networking with commodity
hardware. With KTLS it may be possible to do that with other VPN technology
too though!

It may also be helpful to think of IPSec as layer 3ish while TLS is 4ish.

------
victor106
Another good(but old) IPSec article

[http://www.unixwiz.net/techtips/iguide-
ipsec.html](http://www.unixwiz.net/techtips/iguide-ipsec.html)

------
benmmurphy
our company integrates with some other companies and we do this using simple
TCP connections to a single host+port. most of the companies for some reason
use IPSEC and it is always a massive frustration to get stuff working.

if you have a failure before phase 1 is negotiated you generally have no idea
what is wrong. generally it is either because a) the other side has not
configured their firewall or b) there is some kind of mismatch in the phase 1
parameters. however, it is generally impossible to tell which one it is
because either IPSEC protocol doesn't support status messages or it is not
configured because of 'security' to generate status messages. also, in the
case where there is a mismatch apparently it is very difficult for the
operators at the other end to extract the information from the logs about what
is wrong :/

you get a similar problem with phase 2. if there is something wrong the setup
will just fail and you will only know there is a problem with phase 2 but not
the reason why.

compare this with TLS and I can generally identify what the problem with a
failed handshake is from either the status messages or by looking at the
client/server hello.

IPSEC is also more a pain to deploy than TLS. for TLS protected connections we
just whitelist 2 IPs and run our integration on two boxes for high
availability. really simple. for IPSEC now we either have two buy two pieces
of expensive CISCO hardware to give us a HA VPN connection or we need to duct-
tape up two strongswan boxes with automated failover to give us HA. not fun.

i understand why people might want to use IPSEC if they want to encrypt all
the traffic between two networks transparently. but for encrypting individual
point-to-point connections it is massively overkill. i suspect people end up
using IPSEC for point-to-point encryption because they see it as difficult to
add TLS support to existing software but don't know about options like stunnel
([https://www.stunnel.org/](https://www.stunnel.org/)).

------
lossolo
[https://www.netdevconf.org/0x12/session.html?toward-an-
ebpf-...](https://www.netdevconf.org/0x12/session.html?toward-an-ebpf-based-
clone-of-iptables)

This will be great, power of XDP in simple interface.

------
sbr464
Wanted to recommend Viscosity if anyone is looking for a solid OpenVPN or
IPSec client. Been using with PFsense and others reliably for years now.
Excited to try wireguard out. Thinking about building a native MacOS client
for it.

------
Sir_Cmpwn
>What does xfrm mean? I don’t know!

transform. `man ip-xfrm`

~~~
ronjouch
Thanks. I agree with Julia, it's a weird name: `x` is often associated to Xorg
tools, and there's this scary `rm` at the end that evokes some kind of remove
tool.

EDIT maybe "X" to mean "cross/transform" is an American-ism. Going for the
first time in the US, it took me a while to compute that "Ped Xing" street
signs should be read "pedestrian crossing" :D (and immediately think: why not
a simple evocative symbol of a road with someone walking on it?!)

~~~
Sir_Cmpwn
X is a rotated cross, so x-ing is read as cross-ing, which makes more sense. X
for trans- is also pretty common, like xfer for transfer.

~~~
adito
TIL, xfer means transfer

------
jlgaddis
If you find yourself needing to set up a VPN, do yourself a favor and use
OpenBSD and IKEv2 (until WireGuard gets mainlined / becomes more
prominent/widespread, at least).

------
justincormack
TLS can re-handshake in the middle of a stream at any point, which makes
handoff from userspace much more tricky. From what I remember the kernel
implementation does not support that...

~~~
djwatson24
IIRC TLS renegotiation was removed in TLS 1.3

------
floatboth
Heh, so opportunistic IPsec is a thing. That reminds me of
[http://www.tcpcrypt.org](http://www.tcpcrypt.org)

------
tamalsaha001
Now there is kTLS.

------
huhtenberg
Mods, please fix the title - It's IPsec, not IPSec.

Kindly, the pedantry department.

~~~
sctb
Updated!

------
cbhl
> For some reason that might be obvious but that I don’t understand yet (??)
> people don’t want to do key exchange in the kernel.

It took me years to figure out that "user space" literally means a regular
program running on the computer. Like, when you go "gcc -o hello hello.cc"
that means "user space".

Whereas "kernel space" means downloading the kernel, make, copying it to /boot
(or installing it in a VM), rebooting the computer, switching back to your
stable kernel, repeat. So much more work, and security bugs mean that some
attacker can access kernel memory space and methods (eek!).

~~~
mav3rick
"user space" programs regularly transition to "kernel space" via syscalls.
That's how they access resources and "get things done".

~~~
cbhl
Ah, yes, I was thinking about this in terms of "how does a developer iterate
on this" and not in terms of execution. But yes, of course even "hello world"
needs to execute a syscall in kernel space to display anything.

