netdev - Re: [net-next PATCH 3/4] vxlan: Enforce IP ID verification on outer headers

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: <CAMt9YRoWs1iYxpAbw0SD6Q3GM=gBoe2dGXh-OBR3r-_=BjK8vA@mail.gmail.com>
Date:	Mon, 7 Mar 2016 15:06:00 -0800
From:	Alex Duyck <aduyck@...antis.com>
To:	David Miller <davem@...emloft.net>
Cc:	Or Gerlitz <gerlitz.or@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [net-next PATCH 3/4] vxlan: Enforce IP ID verification on outer headers

On Mon, Mar 7, 2016 at 11:09 AM, David Miller <davem@...emloft.net> wrote:
> From: Or Gerlitz <gerlitz.or@...il.com>
> Date: Mon, 7 Mar 2016 20:05:20 +0200
>
>> On Mon, Mar 7, 2016 at 7:22 PM, Alexander Duyck <aduyck@...antis.com> wrote:
>>> This change enforces the IP ID verification on outer headers.  As a result
>>> if the DF flag is not set on the outer header we will force the flow to be
>>> flushed in the event that the IP ID is out of sequence with the existing
>>> flow.
>>
>> Can you please state the precise requirement for aggregation w.r.t IP
>> IDs here? and point to where/how this is enforced, e.g for
>> non-tunneled TCP GRO-ing?
>
> I also didn't see a nice "PATCH 0/4" posting explaining this series and
> I'd really like to see that.

Sorry about that.  I forgot to add the cover page when I sent this.

The enforcement is coming from the IP and TCP layers.  If you take a
look in inet_gro_receive we have the NAPI_GRO_CB(p)->flush_id value
being populated based on the difference between the expected ID and
the received one.  So for IPv4 we overwrite it, and for IPv6 we set it
to 0.  The only consumer currently using it is TCP in tcp_gro_receive.
The problem is with tunnels we lose the data for the outer when the
inner overwrites it, as a result we can put whatever we want currently
in the outer IP ID and it will be accepted.

The patch set is based off of a conversation several of us had on the
list about doing TSO for tunnels and the fact that the IP IDs for the
outer header have to advance.  It makes it easier for me to validate
that I am doing things properly if GRO doesn't destroy the IP ID data
for the outer headers.

- Alex