netdev - Re: [PATCH ipsec-next] xfrm: Allow Output Mark to be Updated Using UPDSA

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]

Date:   Thu, 10 May 2018 08:44:59 +0300
From:   Eyal Birger <eyal.birger@...il.com>
To:     Nathan Harold <nharold@...gle.com>
Cc:     netdev@...r.kernel.org, steffen.klassert@...unet.com,
        tobias@...ongswan.org
Subject: Re: [PATCH ipsec-next] xfrm: Allow Output Mark to be Updated Using
 UPDSA

Hi Nathan,

On Wed,  9 May 2018 13:46:26 -0700
Nathan Harold <nharold@...gle.com> wrote:

> Allow UPDSA to change output_mark to permit
> policy separation of packet routing decisions from
> SA keying in systems that use mark-based routing.
> 
> In the output_mark, used as a routing and firewall
> mark for outbound packets, is made update-able which
> allows routing decisions to be handled independently
> of keying/SA creation. To maintain consistency with
> other optional attributes, the output mark is only
> updated if sent with a non-zero value. Once set, the
> output mark may not be reset to zero, which ensures
> that updating the SA does not require the mark to
> be re-sent to avoid the value being clobbered.

There is an attempt to extend the 'output_mark' to support the input
direction and masking.

In the proposed implementation, output_mark is converted to type 'struct
xfrm_mark' where the semantics are as follows:

- If mark is given by XFRMA_OUTPUT_MARK (renamed to XFRMA_SET_MARK)
  then a new XFRMA_SET_MARK_MASK attribute is consulted to set the mask
  value
- if no XFRMA_SET_MARK_MASK attribute is provided, the mask is set to
  0xffffffff

Therefore, if the mask value is 0, we can regard the mark as 'not
given'.

My question is, in the context of this patch, it seems that the
"Once set, the output mark may not be reset to zero" restriction may be
lifted in favor of updating the mark only if the new mask is non zero.

Does this make sense to you?
Eyal