GSOC 2017: Implementing RFC 8229 "TCP Encapsulation of IKE and IPsec Packets" for Libreswan

My GSOC 2017 project aimed at implementing the RFC 8229 - TCP Encapsulation of IKE and IPsec Packets. According to this, we add support for TCP encapsulation of packets in Pluto to route out of stringent networks allowing only TCP traffic.

The project is in its initial stages right now and we are working on figuring out the features from the draft that we need to implement. This page documents the project.

These are some points from the RFC that we wanted to implement:

• The SPI field in ESP header must be non-zero.
• Before sending any of the IKE or ESP packet streams, a peer must send a fixed sequence of six bytes "IKETCP" so that IKE/ESP traffic is distinguishable. This is only required at the start of the TCP connection. The responder must wait to receive all six bytes before parsing other packets.
• A responder peer must always keep listening on the configured TCP port in case a session is initiated. And if TCP encapsulation is used then the subsequent IKE SA and Child SAs must be sent over this TCP connection.
• When the TCP connection is torn down for any reason, the TCP originator should create a new connection sending the "IKETCP" bytes at the start. The responder must receive traffic for old SAs on this new TCP connection even if there's a change of ports.
• A partially received message due to a broken connection must always be discarded. In case a peer can't recognize a stream, it must tear down the tcp connection but should only tear down the IKE SA if the issue is with the IKE packet syntax.
• If MOBIKE is also being used, pluto must support dynamically changing between UDP and TCP when interfaces change.
• A peer must silently drop NAT keep-alives when using TCP encapsulation. TCP/TLS keep alives may be used by peers but it must not be an indicator of IKE liveliness, for that IKE informational packets should be used.
• Multiple IKE SAs must not share a single TCP connection, unless one is a rekey of an existing SA.

As of the completion of the project duration, I have been able to implement the following functionalities into Pluto:

• Listen on a TCP port for connections using the config parameter listen-tcp = portno.
• Tell Pluto to connect to a server over TCP directly with the conn parameter tcponly = yes and specify tcp server port with tcp-remoteport = portno.
• If we want to try over UDP first and then fallback to TCP, then set tcponly = no (default).
• Currently rekey does work, but it tears down the old TCP connection and creates a new one.