Linux IPsec Summit 2018 wishlist: Difference between revisions

From Libreswan
Jump to navigation Jump to search
No edit summary
No edit summary
Line 70: Line 70:


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.
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:
<pre>
  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.
</pre>
This is also important for TCP support.

Revision as of 03:15, 8 February 2018

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


  • 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 these:
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 these:

/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.