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: https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/sa/trap_manager.c;h=85e2207751a5072e5fe41fb3a0dce107b5e33b77;hb=HEAD
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 ====================================================================== Andreas Steffen [email protected] strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]==
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
