wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Andrejs Hanins <ahanins@gmail.com>
To: wireguard@lists.zx2c4.com
Subject: [PATCH 0/1] Fix broken inner checksums for non TCP/UDP protocols
Date: Fri, 10 Aug 2018 11:06:16 +0300	[thread overview]
Message-ID: <20180810080617.20283-1-ahanins@gmail.com> (raw)

Hi,
    I'm using GRE tunnel (transparent Ethernet bridging flavor) over Wireguard
interface to be able to bridge L2 network segments. The typical protocol chain
looks like this IP->GRE->EthernetHeader->IP->UDP. UDP here is the packet sent
from the L2 network segment which is tunneled using GRE over Wireguard. Indeed,
there is a checksum inside UDP header which is, as a rule, kept partially
calculated while packet travels through network stack and outer protocols are
added until the packet reaches WG device which exposes NETIF_F_HW_CSUM feature
meaning it can handle checksum offload for all protocols.

    But the problem here is that skb_checksum_setup called from skb_encrypt
handles only TCP/UDP protocols under top level IP, but in my case there is a
GRE protocol there, so skb_checksum_help is not called and packet continues its
life with unfinished (broken) checksum and gets encrypted as-is. When such
packet is received by other side and reaches L2 networks it's seen there with
a broken checksum inside the UDP header.

    The fact that Wireguard on the receiving side sets skb->ip_summed to
CHECKSUM_UNNECESSARY partially mitigates the problem by telling network stack
on the receiving side that validation of the checksum is not necessary, so
local TCP stack, for example, works fine. But it doesn't help in situations
when packet needs to be forwarded further (sent out from the box). In this case
there is no way we can tell next hop that checksum verification for this packet
is not necessary, we just send it out with bad checksum and packet gets dropped
on the next hop box.

    I think the issue of the original code was the wrong usage of
skb_checksum_setup, simply because it's not needed in this case. Instead, we
can just rely on ip_summed skb field to see if partial checksum needs to be
finalized or not. Note that many other drivers in kernel follow this approach.

    I'm not a kernel networking expert, but additional change (paranoid?)
could be to call skb_checksum_setup followed by skb_checksum_help for packets
which don't have CHECKSUM_PARTIAL in order to make sure we handle some buggy
packets. This trick is done in checksum_setup from xen-netback. But I'm
really not sure whether it's needed in Wireguard case...

____________
BR, Andrey

Andrejs Hanins (1):
  Calculate inner checksums for all L4 protocols (was for TCP/UDP only).

 src/send.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.17.1

             reply	other threads:[~2018-08-10  7:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-10  8:06 Andrejs Hanins [this message]
2018-08-10  8:06 ` [PATCH 1/1] Calculate inner checksums for all L4 protocols (was for TCP/UDP only) Andrejs Hanins
2018-08-12  8:13 ` [PATCH 0/1] Fix broken inner checksums for non TCP/UDP protocols Jason A. Donenfeld
2018-08-13 11:11   ` Andrey H.
2018-10-18 16:36     ` Jason A. Donenfeld
     [not found]       ` <0d8cad17-593a-9e96-eb4e-dc01c87743fe@gmail.com>
     [not found]         ` <be9f1e51-6ed4-3d21-2c20-c7ed6d31aadb@gmail.com>
2018-10-27  1:23           ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180810080617.20283-1-ahanins@gmail.com \
    --to=ahanins@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).