On Thu, Aug 10, 2017 at 02:08:52AM +0900, Lorenzo Colitti wrote:
> On systems that use mark-based routing it may be necessary for
> routing lookups to use marks in order for packets to be routed
> correctly. An example of such a system is Android, which uses
> socket marks to route packets via different networks.
> Currently, routing lookups in tunnel mode always use a mark of
> zero, making routing incorrect on such systems.
> This patch adds a new output_mark element to the xfrm state and
> a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
> mark differs from the existing xfrm mark in two ways:
> 1. The xfrm mark is used to match xfrm policies and states, while
>    the xfrm output mark is used to set the mark (and influence
>    the routing) of the packets emitted by those states.
> 2. The existing mark is constrained to be a subset of the bits of
>    the originating socket or transformed packet, but the output
>    mark is arbitrary and depends only on the state.
> The use of a separate mark provides additional flexibility. For
> example:
> - A packet subject to two transforms (e.g., transport mode inside
>   tunnel mode) can have two different output marks applied to it,
>   one for the transport mode SA and one for the tunnel mode SA.
> - On a system where socket marks determine routing, the packets
>   emitted by an IPsec tunnel can be routed based on a mark that
>   is determined by the tunnel, not by the marks of the
>   unencrypted packets.
> - Support for setting the output marks can be introduced without
>   breaking any existing setups that employ both mark-based
>   routing and xfrm tunnel mode. Simply changing the code to use
>   the xfrm mark for routing output packets could xfrm mark could
>   change behaviour in a way that breaks these setups.
> If the output mark is unspecified or set to zero, the mark is not
> set or changed.
> Tested: make allyesconfig; make -j64
> Tested: https://android-review.googlesource.com/452776
> Signed-off-by: Lorenzo Colitti <lore...@google.com>

I'm fine with the patch, but it does not apply to ipsec-next.
Could you rebase the patch onto:



Reply via email to