[strongSwan-dev] strongSwan code kernel traps for opportunistic encryption

Andreas Steffen andreas.steffen at strongswan.org
Mon Mar 7 20:20:47 CET 2016

Hi Robert,

On 07.03.2016 15:49, Robert James wrote:
> strongSwan has the ability to install a kernel trap, so that when a
> packet is sent to a particular host, on the fly an SA is created and
> brought up, and then the packet is transformed via that SA.
> I'd like to know more about this.  My goal is to prototype an
> opportunistic encryption feature for strongSwan, to extend this
> feature even to hosts which don't have a set SA in the conf file, but
> where the SA parameters are discovered on the fly (perhaps via DNSSEC,
> perhaps via another means).
> 1. Can you give a high level overview of how this trap works?
A trap is created by installing an IPsec policy with a given reqid
in the Linux kernel via the XFRM interface.

> 2. Which mechanism in the Linux kernel does it use?
When an outbound IP packet matches the installed IPsec policy and
no IPsec SA exists then the kernel generates an XFRM Acquire message
containing the IP address, protocol type and port information of
the packet which triggered the event as well as the reqid of the
IPsec policy. The charon daemon is subscribed to XFRM Acquire messages
and handles the trap event.

> 3. Where is the relevant strongSwan source code for it?
The relevant code can be found in trap_manager.c:


> 4. I assume the kernel must cache the packet while the SA is being set
> up and charon is keying it.  Is there a time limit here before
> timeout? Or, since nothing has gone on the wire yet, do we have as
> much time as we need?
The native Linux IPsec stack does not cache the first packet which
triggers the aquire event. Thus it always gets lost.

> My goal is to create code which uses a similar trap to discover the
> appropriate parameters (eg via DNSSEC).  Once I have them, what is the
> best API to pass them to charon to do the keying? And, once charon has
> done the keying, how can I tell strongSwan to take it from there?
Just a word of caution. The main reason the FreeS/WAN opportunistic
encryption project failed in 2004 was the fact that only few people
and organizations had control over the reverse DNS lookup of their
IP address range.

Best regards

Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4275 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20160307/b7112b67/attachment.bin>

More information about the Dev mailing list