Messages in this thread | | | Date | Wed, 06 Feb 2013 08:14:44 -0500 | From | jamal <> | Subject | Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask. |
| |
Hi Steffen,
On 13-02-05 03:12 AM, Steffen Klassert wrote: >> For example, executing the below commands in that order succeed: >> ip -6 xfrm policy flush >> ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out mark 1 mask 0xffffffff >> ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out > The policy with mark 1 is the first we find. The policy passes the > mark check and if the flow matches the selectors, we use this policy. > >> But it fails in the reverse order: >> ip -6 xfrm policy flush >> ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out >> ip -6 xfrm policy add src fd00::1/128 dst fd00::2/128 dir out mark 1 mask 0xffffffff >> RTNETLINK answers: File exists > With this scenario, we would find the policy with mark and mask 0 first. > This policy passes the mark check too. So we would use this policy if the > flow matches the selectors, but the flow asked for a policy with mark 1.
I think the intent Romain is expressing is reasonable and should resolved at insertion time(xfrm_policy_insert()). i.e even though the policy (such as mark=1) is inserted afterwards, at insertion time if it proves it is more specific and not duplicate, it should be inserted ahead of the mark=0. The runtime check will work then.
cheers, jamal
| |