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

Message-ID: <CAM_iQpVFq8TdnHSOsC7+6tK3KEoeyF1SFOQ-DheLW7Y=g77xxg@mail.gmail.com>
Date:   Fri, 7 Jun 2019 12:57:57 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     "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 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?

>
> 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.