netdev - Re: EoGRE sends undersized frames without padding

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: <76cc5356-e5f9-c46b-63b6-879ea9053f95@gmail.com>
Date:   Fri, 7 Jun 2019 16:25:56 -0700
From:   Gregory Rose <gvrose8192@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>,
        "Steinar H. Gunderson" <steinar+kernel@...derson.no>
Cc:     Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: EoGRE sends undersized frames without padding


On 6/7/2019 12:57 PM, Cong Wang wrote:
> On Thu, Jun 6, 2019 at 12:36 AM Steinar H. Gunderson
> <steinar+kernel@...derson.no> wrote:
>> On Wed, Jun 05, 2019 at 06:17:51PM -0700, Cong Wang wrote:
>>> Hmm, sounds like openvswitch should pad the packets in this scenario,
>>> like hardware switches padding those on real wires.
>> Well, openvswitch say that they just throw packets around and assume they're
>> valid... :-)
> _If_ the hardware switch has to pad them (according to what you said),
> why software switch doesn't?

Well one thing I can think of is that there are things that can be done 
in HW that become very
expensive in SW.  CRC checking and packet padding are expensive in SW.

>
>> In any case, if you talk EoGRE to the vWLC directly, I doubt it accepts this,
>> given that it doesn't accept it on the virtual NICs.
>>
>>>> Yes, but that's just Linux accepting something invalid, no? It doesn't mean
>>>> it should be sending it out.
>>> Well, we can always craft our own ill-formatted packets, right? :) Does
>>> any standard say OS has to drop ethernet frames shorter than the
>>> minimum?
>> I believe you're fully allowed to accept them (although it might be
>> technically difficult on physical media). But that doesn't mean everybody
>> else has to accept them. :-)
> Sure, Linux is already different with other OS'es, this also means Linux
> doesn't have to reject them.
>
>>>>> Some hardware switches pad for ETH_ZLEN when it goes through a real wire.
>>>> All hardware switches should; it's a 802.1Q demand. (Some have traditionally
>>>> been buggy in that they haven't added extra padding back when they strip the
>>>> VLAN tag.)
>>> If so, so is the software switch, that is openvswitch?
>> What if the other end isn't a (virtual) switch, but a host?
> Rather than arguing about this, please check what ethernet standard
> says. It would be much easier to convince others with standard.
>
> Depends on what standard says, we may need to pad on xmit path or on
> forwarding path (switch), or rejecting shorter frames on receive path.
>
> Thanks.

I am used to Ethernet switches dropping undersized and bad CRC frames.  
Sure, if the incoming frame is
valid and then because of transformations in the packet due to 802.1q 
specs or any other reasons (NSH comes
mind) then the packet must be padded and the correct checksum computed 
by the switch.  That's fine.

But if the incoming packet to the switch is malformed (undersized and 
bad CRC in this case) then switches can
and probably will drop the packet.

It appears that openvswitch does not.  Steinar and I are discussing that 
situation on a different list.

Thanks,

- Greg