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

[Robert James]

Hi Andreas,

On 3/7/16, Andreas Steffen <andreas.steffen at strongswan.org> wrote:
> 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.
>

I see.  So there's no need for a custom trap; I can use the standard
XFRM interface or even the command line (in theory).

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

Ahh, so it's not a callback or hook but rather a publish/subscribe
mechanism.  If I add a policy which matches all traffic of interest, I
could subscribe charon to the XFRM Acquire message, have it recognize
the reqid, and do my magic on-the-fly config and keying.  Is that
correct?

Where in the source does charon subscribe to and handle these
messages? What's the recommended way to add a new handler?

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

And we just rely on the TCP stack to assume the packet was lost on the
wire and retransmit it? What about for nonreliable (e.g. UDP)?  Is
this preferred over caching or has caching simply not been
implemented?

>
>> 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.
>
Understood.  My goal isn't opportunistic encryption over the wide
Internet, but over a subset of it where it's possible to set up some
type of secure directory.  I don't imagine this will be the case for
the general Internet, but I do imagine it may become feasible for IoT,
SCADA, vehicular and other types of non-standard networks.