[Swan] IPsec PFP support on linux

[Paul Wouters]

On Tue, 2 May 2017, Sowmini Varadhan wrote:

> But I want each 5-tuple to/from 5001 to get its own SPI. That
> is not happening in my case.

the problem I see with your approach is that you have a few options:

1) Setup a %trap policy using 1 conn per port combo.

This is kind of insane, but it would give you unique ACQUIRES on
the tuples.

2) Setup a generic trap, then ensure the policy triggering tupple
    contains the TSi/TSr or the triggering packet.

This could install the narrowed down to 5 tupple SA, but you would
not receive another ACQUIRE anymore for a while for any other ports
on the sending machine. The timer can be short but not too short
since it is also the time for claiming the SPI number as unique
before it falls back into the kernel pool. This will probably
need kernel support. It surely would need libreswan support added
to handle this.

3) Extend OE to allow per-port SA's. This would require 2)

> If I used OE, I would *never* get a per-5-tuple SPI, right?
> (I can give this a try later today but the rfc definition of OE is
> not what I have in mind- I really want PFP, not OE).

Right.

Over the years I've received a number of requests for PFP, but I've
never seen people really followup with this. Of course, I also have
a hard time seeing the use case for per-port SPI's. It seems like a
dirty hack to do firewalling "per port" on IPsec SA's, instead of
just moving the firewall rules to the endnodes and apply them after
decryption, eg on a VTI device.

>>    Note that IKEv2 also allows you to define one connection and instantiate
>>     a connection based on the trigger packet whose src/dst proto/port are
>>    included in the IKEv2 packet as traffic selectors. See RFC7296 and
>>    "narrowing".
>
> yes, the rfc's permit this, I'm not sure how to set up my
> SPD for this though.

I don't know of any userland implementing it. Which is why I suspect
the use case is weak :)

(cutting linux lists CC:s out since they refuse my email anyway)
Paul
>