From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eyal Birger Subject: Re: [PATCH ipsec-next] xfrm: Allow Output Mark to be Updated Using UPDSA Date: Thu, 10 May 2018 08:44:59 +0300 Message-ID: <20180510084459.598ce663@jimi> References: <20180509204626.56561-1-nharold@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, steffen.klassert@secunet.com, tobias@strongswan.org To: Nathan Harold Return-path: Received: from mail-wm0-f52.google.com ([74.125.82.52]:37421 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750746AbeEJFpE (ORCPT ); Thu, 10 May 2018 01:45:04 -0400 Received: by mail-wm0-f52.google.com with SMTP id l1-v6so2113298wmb.2 for ; Wed, 09 May 2018 22:45:03 -0700 (PDT) In-Reply-To: <20180509204626.56561-1-nharold@google.com> Sender: netdev-owner@vger.kernel.org List-ID: Hi Nathan, On Wed, 9 May 2018 13:46:26 -0700 Nathan Harold 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