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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5291D324.3020808@windriver.com>
Date:	Sun, 24 Nov 2013 18:21:24 +0800
From:	Fan Du <fan.du@...driver.com>
To:	Saurabh Mohan <saurabh.mohan@...cade.com>
CC:	Christophe Gouault <christophe.gouault@...nd.com>,
	Steffen Klassert <steffen.klassert@...unet.com>,
	"David S. Miller" <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not
 ipsec pkt



On 2013年11月22日 02:39, Saurabh Mohan wrote:
>
>
>> -----Original Message-----
>> From: Fan Du [mailto:fan.du@...driver.com]
>> Sent: Tuesday, November 19, 2013 1:17 AM
>> To: Saurabh Mohan
>> Cc: Christophe Gouault; Steffen Klassert; David S. Miller; Herbert Xu;
>> netdev@...r.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@...nd.com]
>>>> Sent: Thursday, November 07, 2013 4:56 AM
>>>> To: Steffen Klassert
>>>> Cc: David S. Miller; Herbert Xu; netdev@...r.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html