<div dir="ltr">Hello strongSwan maintainers,<br><br>I am quite concerned by the following commit, that appeared in strongSwan<br>5.5.2:<br><br>067fd2c69c25 ("child-sa: Do not install mark on inbound kernel SA")<br><br>As the title states, this patch prevents charon from setting the mark of the<br>inbound IPsec SA, while still marking the SPs and the outbound SA. This<br>behavioral change was done as a workaround for route-based VPN to work, and<br>assumed that it did not break other uses of the mark.<br><br>The patch results in several issues, by increasing order of severity:<br><br>1/ this violates strongSwan's documentation:<br><br>   mark_in = <value>[/<mask>]<br><br>     sets an XFRM mark in the inbound IPsec SA and policy. If the mask is<br>     missing then a default mask of 0xffffffff is assumed.<br><br>2/ this breaks the symmetry and coherency of SA and SP configuration.<br><br>The inbound SA is the only object that does not wear a mark. The mark is<br>precisely designed to convey information and to link objects together.<br><br>3/ this changes strongSwan's behavior with no backward compatibility option.<br><br>So I propose to write a patch to avoid changing the default behavior of<br>mark_in, while offering the ability to not mark the SA:<br><br>the most flexible solution would be to enable to split mark_in/mark_out into<br>mark_in_sa/mark_in_sp/mark_out_sa/mark_out_sp, just like "mark" may today be<br>split into "mark_in" and "mark_out".<br><br>That way, one would be free to finely mark SPs and/or SAs in conformance to<br>one's needs. The old behavior would be preserved by default.<br><br>Best Regards,<br>Christophe<br></div>