lkml.org 
[lkml]   [2013]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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







\
 
 \ /
  Last update: 2013-02-06 15:01    [W:0.080 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site