Linux IPsec Summit 2018 wishlist

From Libreswan
Revision as of 18:54, 15 February 2018 by Paul Wouters (talk | contribs)
Jump to navigation Jump to search

A scratchpad for things we'd like to talk about during the ipsec meetup

INVALID_SPI acquires

When one endpoint crashes and restarts, and does not need to send traffic, it will lead to traffic for because the other end's ESP/AH packets are getting lost without triggering any ACQUIRE.

It would be nice of the kernel could send a rate limited INVALID_SPI message, so the node can see if it has an ondemand/ready tunnel that it should bring up.

larval acquire saying "transport mode" - would be nice to not say mode at all

src 192.0.2.100 dst 192.1.2.23
	proto esp spi 0xSPISPIXX reqid REQID mode transport
	replay-window 0 
	sel src 192.0.2.100/32 dst 192.1.2.23/32 proto icmp type 8 code 0 dev eth0

add support for Populate-From-Packet flag. Cause acquires for each different policy hit

some clarification or documentation for IPsec SA flags

FLAG := noecn | decap-dscp | nopmtudisc | wildrecv | icmp | af-unspec | align4 | esn
EXTRA-FLAG-LIST := [ EXTRA-FLAG-LIST ] EXTRA-FLAG
EXTRA-FLAG := dont-encap-dscp

ip xfrm policy help shows:

FLAG := localok | icmp

XFRM-PROTO := esp | ah | comp | route2 | hao
MODE := transport | tunnel | beet | ro | in_trigger
LEVEL := required | use

some clarification or documentation for /proc values

/proc/sys/net/core/xfrm_acq_expires
/proc/sys/net/core/xfrm_aevent_etime
/proc/sys/net/core/xfrm_aevent_rseqth
/proc/sys/net/core/xfrm_larval_drop

fixup for userland using xfrm.h include

Our kernel_netlink.c code contains: 

#include "linux/xfrm.h" /* local (if configured) or system copy */
#include "libreswan.h" /* before xfrm.h otherwise break on F22 */

Depending on how new gcc/glibc/userland and/or kernel is we need to swap these two lines :(

Introduce some kind of #ifdef _KERNEL_ that protects xfrm.h from loading too much kernel related defines, so we only get the XFRM_ values we need to have available in userland. Now on older glibc we get: 

In file included from /source/programs/pluto/linux-copy/linux/xfrm.h:4:0,
                 from /source/programs/pluto/kernel_netlink.c:54:
/usr/include/netinet/in.h:99:5: error: expected identifier before numeric constant
     IPPROTO_HOPOPTS = 0,   /* IPv6 Hop-by-Hop options.  */
     ^
In file included from /source/linux/include/libreswan.h:76:0,
                 from /source/programs/pluto/kernel_netlink.c:55:
/usr/include/netinet/in.h:209:8: error: redefinition of ‘struct in6_addr’
 struct in6_addr
        ^
In file included from /source/programs/pluto/linux-copy/linux/xfrm.h:4:0,
                 from /source/programs/pluto/kernel_netlink.c:54:
/usr/include/linux/in6.h:32:8: note: originally defined here
 struct in6_addr {
        ^
[more errors left out]

Note that we have linux-copy/linux/xfrm.h because sometimes we need newer XFRM values then the system provided version has, eg if people upgrade kernel but not glibc.

Comply with RFC 7296 NAT-T requirements

The kernel currently marks an IPsec SA as not natted or encaps-udp. It rejects packets based on this. To comply to the RFC, it should: 

   When either side is using port 4500, sending ESP with UDP encapsulation is
   not required, but understanding received UDP-encapsulated ESP packets
   is required.  UDP encapsulation MUST NOT be done on port 500.  If
   Network Address Translation Traversal (NAT-T) is supported (that is,
   if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
   all devices MUST be able to receive and process both UDP-encapsulated
   ESP and non-UDP-encapsulated ESP packets at any time.  Either side
   can decide whether or not to use UDP encapsulation for ESP
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST use UDP encapsulation for ESP.

This is also important for TCP support.

crypto module loading problems

The problem of not autoloading crypto modules means we have to manually load modules. We don't want the daemon to be able to load kernel modules, so we have a helper script that loads everything that could possibly be needed before the daemon starts. The problem is that sometimes loading a crypto module is bad. Sometimes there is something new we don't load.

A new recent issue is with containers, we cannot even run our helper to load kernel modules anymore.

the kernel should really be able to auto load all crypto and IPsec related modules on demand.

also, how to detect af_key is the old PF_KEY api is removed? we detect af_key using /proc/net/pfkey as /proc/net/xfrm_stat is not available everywhere

Retrieved from "https://libreswan.org/wiki/index.php?title=Linux_IPsec_Summit_2018_wishlist&oldid=21246"