All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eyal Birger <eyal.birger@gmail.com>
To: Nathan Harold <nharold@google.com>
Cc: netdev@vger.kernel.org, steffen.klassert@secunet.com,
	tobias@strongswan.org
Subject: Re: [PATCH ipsec-next] xfrm: Allow Output Mark to be Updated Using UPDSA
Date: Thu, 10 May 2018 08:44:59 +0300	[thread overview]
Message-ID: <20180510084459.598ce663@jimi> (raw)
In-Reply-To: <20180509204626.56561-1-nharold@google.com>

Hi Nathan,

On Wed,  9 May 2018 13:46:26 -0700
Nathan Harold <nharold@google.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

  reply	other threads:[~2018-05-10  5:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 20:46 [PATCH ipsec-next] xfrm: Allow Output Mark to be Updated Using UPDSA Nathan Harold
2018-05-10  5:44 ` Eyal Birger [this message]
2018-05-10 18:14   ` Nathan Harold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180510084459.598ce663@jimi \
    --to=eyal.birger@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nharold@google.com \
    --cc=steffen.klassert@secunet.com \
    --cc=tobias@strongswan.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.