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: <1902752B0C92F943AB7EA9EE13E2DEEC1273BA9ACD@HQ1-EXCH02.corp.brocade.com>
Date:	Thu, 21 Nov 2013 10:39:53 -0800
From:	Saurabh Mohan <saurabh.mohan@...cade.com>
To:	Fan Du <fan.du@...driver.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



> -----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).