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] [day] [month] [year] [list]
Date:	Tue, 14 Jan 2014 08:51:38 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Christophe Gouault <christophe.gouault@...nd.com>
Cc:	netdev@...r.kernel.org, Saurabh Mohan <saurabh.mohan@...tta.com>
Subject: Re: [PATCH RFC v2 0/13] vti4: prepare namespace and interfamily
 support.

On Tue, Jan 07, 2014 at 05:11:00PM +0100, Christophe Gouault wrote:
> 
> Sorry for my late comments, I had to delay my tests due to Christmas and
> New Year's celebrations.

Sorry for the delay on my side, I had to setup a testcase
for vti with namespaces first.

> 
> I have a few comments about your proposed patches:
> 
> In input, the vti tunnel processing does not follow the usual tunnel
> processing. Conventionally, the packets are first decapsulated, then
> only the skbuff interface is changed to the tunnel interface. In the vti
> code, the interface is changed before IPsec decryption, hence before
> decapsulation.
> 
> It results in a configuration asymmetry when we later support cross
> netns: the outer SAs and SPs must be defined in the outer netns, while
> the inner SAs and SPs must be defined in the inner netns.

You are absolutely right here. I'll change this to do the namespace
transition after the decapsulation in the vti_rcv_cb() callback.
Then in and outbound states/policies must be defined in the outer
namespace. I'll send another RFC version of that patchset during the
next days.

Thanks for pointing this out!
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ