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