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] [day] [month] [year] [list]

Message-ID: <CAMYYbY7PXt=-eJ2BU1YO6biEL1F3NRq-=6NdQ-nJGmhXXOWKbA@mail.gmail.com>
Date:	Thu, 11 Sep 2014 18:16:44 +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

On Mon, Sep 1, 2014 at 4:26 PM, Martin Rusko <martin.rusko@...il.com> wrote:
>>>>>>
>>>>>> 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.
[...]
> 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.

Perhaps nobody is reading this anymore, but at least it will make it
to the archive for reference. :-)

So I tested also how HP 5930 switch handles small inner frames. They
were padded. So it's in line with what Stephen said, that the
receiving VTEP should pad frames to minimum size before sending them
to the medium where size check is enforced.

Regards,
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