[strongSwan-dev] Backward compatibility option for inbound SA/SP marking

[Tobias Brunner]

Hi Christophe,

>>> As the title states, this patch prevents charon from setting the mark of the
>>> inbound IPsec SA, while still marking the SPs and the outbound SA. This
>>> behavioral change was done as a workaround for route-based VPN to work, and
>>> assumed that it did not break other uses of the mark.
>>
>> Could you provide an example where the old behavior is necessary?  Or
>> are you just concerned with setups that already have firewall rules for
>> inbound traffic in place?  (Which might not be a problem because if no
>> mark is set on the SA the kernel does not care if the packet has a mark
>> set.)
> 
> I had in mind an existing vti use case with IPsec offloading. The
> kernel does not need the inbound SA to be marked, but the IPsec
> offloading solution benefits from the fact that SPs and SAs reference
> their vti through the mark.

I see.  VTIs themselves don't seem to require a mark on the SA or the
packets (I guess they are just selected based on the IPs), the kernel
will even apply the key configured on the VTI interface as mark to the
packet before doing the inbound policy check (it removes it again, though).

I actually never liked the inbound handling of the marks on IPsec SAs,
I'd very much preferred it if the kernel, instead of using it as
selector when looking up an SA, would simply apply the mark to decrypted
packets.

> But I am aware it is not the general case, that's why I advocate a
> configurable behavior.
> 
> A patch proposal follows, with a global boolean option in strongswan.conf.

Thanks.  But I'd actually prefer a connection specific config.  I did
something like that in the mark-inbound-sa branch.

> However
> note that the documentation and several tests in the testing/
> directory still state and assume that the inbound SA is marked.

I guess some test scenarios could be adapted (for several it's still
required to mark the packets before decryption, though, e.g. based on
UDP-encap ports).  The documentation (what's in the repo) is updated in
the branch above the wiki is updated too.

Regards,
Tobias