Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt

[Fan Du <fan.du@windriver.com>]

Hi, Saurabh

On 2013年11月19日 05:38, Saurabh Mohan wrote:
>
>
>> -----Original Message-----
>> From: Christophe Gouault [mailto:christophe.gouault@6wind.com]
>> Sent: Thursday, November 07, 2013 4:56 AM
>> To: Steffen Klassert
>> Cc: David S. Miller; Herbert Xu; netdev@vger.kernel.org; Saurabh Mohan;
>> Sergei Shtylyov; Eric Dumazet
>> Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec
>> pkt
>>
>> Hello Steffen,
>>
>> I am also interested in knowing Saurabh's intentions regarding the
>> behavior of policies bound to vti interfaces.
>>
> The semantics is to match the policy "src 0.0.0.0/0 dst 0.0.0.0/0 proto any"
> That is the only policy that VTI should use. The mark is needed to
> distinguish and limit the policy to a specific vti tunnel interface only.
> There is no other policy that may be applied to a vti interface.
> The fact that traffic is going over the tunnel  interface implies that it
> must be encrypted/decrypted. Applying the above policy is a way
> to achieve that.

I'm not much experienced with VTI usage practical production usage scenario, but
I have one question about the necessity of policy checking on VTI receiving part.
- A VTI tunnel is hashed by destination address and i_key when creating them;
- After each tunneled IP packet delivered to vti_rcv, the first step is looking
   for the right tunnel, this is done by using tunneled IP packet outer source and
   destination address without any key matching rule involved.

If there are any other tunnel with the same source/destination address, but not
the same mark in place, the tunnel lookup in the vti_rcv will properly not hit
VTI tunnel, but the non-VTI tunnel. So the VTI net device statistics will not be
accurate, and what's the point of checking policy for the wrong tunnel interface?

Or the VTI tunnel is the only tunnel with this specific source/destination address
in the production deployment. Again the upper layer 4 will check the policy after
all, that's the right place to do the policy checking.

So IMO, it's unnecessary to check policy for a net_device like VTI, actually I hold
a patch of removing the VTI policy checking due to net-next closure for the moment.

>> However, please note that setting a policy with a wildcard selector
>> works in both cases (before or after this patch), so a common test case
>> can be defined.
>>
>> Actually the *previous* patch on vti (7263a5187f9e vti: get rid of nf
>> mark rule in prerouting) introduced significant changes, and implies
>> behaviors dependant on the kernel version, but it seemed to meet
>> Saurabh's agreement, as the following thread witnesses:
>>
>> http://www.spinics.net/lists/netdev/msg253134.html
>>
> Getting rid of the pre-routing mark, which had to be done outside of
> the vti tunnel code was prone to misconfiguration.
> Though it is unfortunate that it creates a kernel version dependency.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
浮沉随浪只记今朝笑

--fan fan