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: <20190607203141.tj5xnkjyitlfz5yl@sesse.net>
Date:   Fri, 7 Jun 2019 22:31:41 +0200
From:   "Steinar H. Gunderson" <steinar+kernel@...derson.no>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: EoGRE sends undersized frames without padding

On Fri, Jun 07, 2019 at 12:57:57PM -0700, Cong Wang wrote:
>> 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?

Trust me, I'm telling them they have to deal with this, too. :-)

But you can't really assume there's a switch in the middle at all (whether
hardware nor software). You can connect a NIC to a NIC with no switch in-between.

Normally, it's not the switch that adds the padding; it's done in the NIC
(MAC sublayer), so if the switch doesn't modify the packet, it can just send
it on. However, there are situations where it has to, like for instance when
stripping a VLAN tag (802.1Q-2005, section 6.5.1), since that makes the
packet shorter.

> Rather than arguing about this, please check what ethernet standard
> says. It would be much easier to convince others with standard.

The Ethernet standard? That's pretty clear; Ethernet frames are a minimum of
64 bytes (including FCS at the end, so 60 payload bytes including MAC
addresses etc.). IEEE 802.3-2015 4.2.3.3:

  The CSMA/CD Media Access mechanism requires that a minimum frame length of
  minFrameSize bits be transmitted. If frameSize is less than minFrameSize,
  then the CSMA/CD MAC sublayer shall append extra bits in units of octets
  (Pad), after the end of the MAC Client Data field but prior to calculating
  and appending the FCS (if not provided by the MAC client). The number of
  extra bits shall be sufficient to ensure that the frame, from the DA field
  through the FCS field inclusive, is at least minFrameSize bits.

4A.2.3.2.4 also says, without assuming anything about CSMA/CD:

  The MAC requires that a minimum frame length of minFrameSize bits be
  transmitted. If frameSize is less than minFrameSize, then the MAC sublayer
  shall append extra bits in units of octets (pad), after the end of the MAC
  client data field but prior to calculating, and appending, the FCS (if not
  provided by the MAC client). The number of extra bits shall be sufficient
  to ensure that the frame, from the DA field through the FCS field
  inclusive, is at least minFrameSize bits. If the FCS is (optionally)
  provided by the MAC client, the pad shall also be provided by the MAC
  client. The content of the pad is unspecified.

minFrameSize is defined in 4A.4.2:

  minFrameSize   512 bits (64 octets)

As for what to do on undersized packets, section 4.2.9 contains this
pseudocode:

  receiveSucceeding := (frameSize ≥ minFrameSize) {Reject frames too small}

To be honest, I don't see that dropping undersized frames gives any
real-world gains in the case of EoGRE, though. I'd say that the most
reasonable thing to do would be to pad on transmit, and accept undersized
frames on receive. You could argue that's wasteful for cases like the
loopback interface, but honestly, you never really know what people are going
to do with the packets (just consider the case of tcpreplay).

/* Steinar */
-- 
Homepage: https://www.sesse.net/