netdev - Re: [PATCH ipsec-next] net: xfrm: support setting an output mark.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 11 Aug 2017 12:55:12 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Lorenzo Colitti <lorenzo@...gle.com>
CC:     <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <jhs@...atatu.com>, <herbert@...dor.apana.org.au>
Subject: Re: [PATCH ipsec-next] net: xfrm: support setting an output mark.

On Fri, Aug 11, 2017 at 02:11:33AM +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 <lorenzo@...gle.com>

Patch applied to ipsec-next, thanks Lorenzo!