How I can retrieve encryption keys for my IPsec/L2TP session?

Question

I'm investigating IPsec protocols stack with wireshark. If I need to decrypt tunnel's traffic, I use ip xfrm state command, which returns all needed stuff. During ip source code investigation, I discovered that encryption keys are retrieved from kernel via NETLINK. So, I was wondering if there is any other way to get this info from kernel bypassing the NETLINK? Perhaps, there is some ioctl to do this. I would like to know where in the kernel code these keys are stored.

Answer 1

The two main interfaces I know about are:

• netlink (which you already mention) - the linux-native option since ~2.6, enabled via the XFRM_USER kernel config-option
• pfkey (for compatibility with tools ported from KAME) - enabled via the NET_KEY kernel config-option

See here for a howto-reference about those.

In terms of userland tools, as far as I've understood it, the iproute2 tool "ip" and its "xfrm" subcommand are the newer/better way to manually manipulate ipsec SADs and SPDs on linux, as a thin-layer over the netlink interface to the xfrm module, while the "setkey" tool uses the pfkey interface (to the same module) for compatibility (and on other systems like the BSDs). I think you will not really ever (or very rarely?) on linux find a need to use the pfkey interface if you can already talk over the netlink interface other than for compatibility with existing code.

Here are some examples (1, 2) of developers communicating about handling communication with both interfaces (in my experience they are notoriously badly, and sometimes just not, documented - and I've had to work stuff out by reading the source of the xfrm modules on several occasions).

The only other ways I could think of to interface with the xfrm module would be reading data from /proc/net/xfrm_* files (depending on the kernel version and configuration those may or may not be present), hooking it with ftrace/kprobes/etc, or by writing your own kernel module to interact directly with the xfrm structs directly. I suspect that last option is nearly always a bad idea though.