Linux IPsec Summit 2018 wishlist: Difference between revisions
Paul Wouters (talk | contribs) No edit summary |
Paul Wouters (talk | contribs) 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.