netdev - Re: Sending undersized ARP packets with VXLAN L3 interface

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: <CAMYYbY7pp4WDBnFmoeK6D9BdUnuZ-v5fw1hH2V6zxM9GRRK=Mg@mail.gmail.com>
Date:	Mon, 1 Sep 2014 16:26:56 +0200
From:	Martin Rusko <martin.rusko@...il.com>
To:	Vlad Yasevich <vyasevich@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Sending undersized ARP packets with VXLAN L3 interface

>>>>>
>>>>> No. The short frame is perfectly valid, over the VXLAN.
>>>>> The system doing the decap and forwarding should be where any padding is added if necessary.
>>>>>
>>>
>>> Well, RFC 7348 is not dealing with padding at all. Both deployment
>>> scenarios listed in RFC, as well as most of the existing real life
>>> deployments today (in my opinion) use VXLAN for bridged traffic. In
>>> other words, frame encapsulated by VTEP is received first over some
>>> ethernet interface (physical or virtual) which implies that the frame
>>> is at least 64 bytes long already.
>>>
>>> Perhaps we're going to see more VXLAN interfaces in L3 mode, yet it
>>> might be safer not to count on receiving VTEP doing the right thing
>>> (pad small packets with zeros).
>>>
>>>>
>>>> If that's the case, then Martin is most likely seeing a HW bug on the switch.
>>>> I wonder how common such a bug might be?
>>>>
>>>> -vlad
>>>>
>>>
>>> I see this on Vmware distributed virtual switch. Perhaps soon I will
>>> be able to test it against HP 5930 switch. I'm going to try how Linux
>>> bridge copes with it, now.
>>
>> Linux bridge will do just fine as it will pass the frame off to the hw driver
>> which should pad things appropriately.
>>
>> -vlad
>>
>
> I can confirm that, now.

I also tried a setup with Xen hypervisor and HVM guest connected to
bridge with vxlan interface. In any combination I tried, it pretty
much didn't care about the ethernet packet size.

Haven't had chance to test it with hardware switch yet, so it's only
causing problems with Vmware so far, when inner ethernet frame is not
padded.

>
> Vlad, I'm going to recompile 3.16.1 kernel with your patch.
>

Vlad's patch works perfectly. I asked the authors of RFC 7348 to
eventually clarify if any padding should be required for the inner
frames. Shall the patch be included in the mainline kernel or not?

/Martin
--
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