netdev - Re: [PATCH ipsec, resend 0/1] xfrm: set-mark default behavior changes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190112100158.GE8742@gauss3.secunet.de>
Date:   Sat, 12 Jan 2019 11:01:58 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Benedict Wong <benedictwong@...gle.com>
CC:     <netdev@...r.kernel.org>, <nharold@...gle.com>,
        <lorenzo@...gle.com>, <maze@...gle.com>
Subject: Re: [PATCH ipsec, resend 0/1] xfrm: set-mark default behavior changes

On Fri, Jan 11, 2019 at 12:14:11PM -0800, Benedict Wong wrote:
> A behavior change introduced in 9b42c1f179a6 (“xfrm: Extend the
> output_mark to support input direction and masking”) results in a
> change in:
> 
> 1. Default outbound behavior with regards to route lookup marks, and
> 2. Inbound behavior for SAs used to decapsulate packets when the output
>      mark (as specified in 4.14 to 4.18) is set.
> 
> This patch set restores the previous default outbound behavior,
> resolving (1), but behavior change (2) will require more discussion.
> 
> Specifically, in (2), a SA with a "output mark" set will now have that
> Mark imposed on the inbound packet (As opposed to the previous
> output-mark behavior where the inbound packet's mark would not be
> touched). This is less of a concern, as it is limited to the case where:
> 
> 1. SA output mark is set
> 2. SA is using non-transport mode
> 3. SA is configured for inbound decapsulation (local dst IP)
> 
> Critically, conditions 1 and 3 imply a configuration that output mark
> was not designed to support. The only valid use case for this seems
> to be the loopback case (as IP addresses would apply bidirectionally).
> As such, we believe that this behavioral change is acceptable as is.

There was no need to resend this without changes. I still had this
patchset in my queue. I'm ok with the change, but you did not Cc
all the authors of the patch you want to fix. So please resend once
again with Cc to all the authors, so that they have a chance to
review this change.

Thanks!