netdev - Re: [RFC ipsec-next 3/4] net: xfrm: support multiple VTI tunnels

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKD1Yr2-XOHHsph9k2YfUSnVzjci9WJ8Kbq_K_t9gzKH-L4nwA@mail.gmail.com>
Date:   Thu, 21 Dec 2017 02:12:30 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org,
        Steffen Klassert <steffen.klassert@...unet.com>,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
        Nathan Harold <nharold@...gle.com>
Subject: Re: [RFC ipsec-next 3/4] net: xfrm: support multiple VTI tunnels

On Tue, Dec 19, 2017 at 2:56 AM, David Miller <davem@...emloft.net> wrote:
> > - ICMP errors are similar to input, except the search is for the
> >   outbound XFRM state, because the only data that is available is
> >   the outbound SPI. Thus, ICMP errors are only processed if the
> >   ikey is the same as the same as the okey. AFAICS this is
> >   consistent with GRE tunnels, but not with existing VTI
> >   behaviour.
>
> I think you will need to sort out the VTI ICMP behavior difference
> with what exists now.

Thanks for the feedback. I've sent out a new series that addresses this.

I had to make some minor changes to the common ip tunnel lookup
functions to make it work, because currently, a tunnel can only be
looked up by i_key. https://patchwork.ozlabs.org/patch/851558/ .