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

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

On 2013年11月22日 02:39, Saurabh Mohan wrote:
>
>
>> -----Original Message-----
>> From: Fan Du [mailto:fan.du@windriver.com]
>> Sent: Tuesday, November 19, 2013 1:17 AM
>> To: Saurabh Mohan
>> Cc: Christophe Gouault; Steffen Klassert; David S. Miller; Herbert Xu;
>> netdev@vger.kernel.org; Sergei Shtylyov; Eric Dumazet
>> Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec
>> pkt
>>
>> 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?
>
> So far this is not supported. If it were needed then we'd have to use another
> key on the tunnel(s) to distinguish between tunnel with same src and dst.
> In such a case there would be two keys on the tunnel (one for vti mark
> and the other one to separate out tunnels with same src and dst).
>

That's indeed what I am pointing, one vti tunnel with mark_a,
another tunnel sharing same VTI tunnel's src/dst address with
only different mark_b/wildcard mark. This configuration probably
cause vti_rcv using the non-VTI tunnel for the policy checking.

So after b2942004fb5c9f3304b77e187b8a1977b3626c9b ("ipv4/ip_vti.c:
  VTI fix post-decryption forwarding"), no other non-VTI tunnel
should be mingled with VTI tunnel, otherwise, the forward process
will be malfunctional.



-- 
浮沉随浪只记今朝笑

--fan fan