Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Derek Fawcus <dfawcus+lists-wireguard@employees.org>
To: wireguard@lists.zx2c4.com
Subject: UDP checksums and inband control messages
Date: Tue, 20 Feb 2018 01:05:20 +0000	[thread overview]
Message-ID: <20180220010520.GA38119@accordion.employees.org> (raw)

I see from the code that currently the kernel UDP sockets
have checksums enabled.  I also note the message from
November speculating upon if in band control messages
should be added.

One thing I was pondering recently in the context of UDP tunnelling,
is that one doesn't really need to have UDP checksums on the
encapsulating packet, since they payload itself is eventually
protected by its IPv4 header checksum, and likewise its transport
payload being protected by its own TCP/UDP/etc checksum.
[OK - some exceptions, but valid to a first approximation]

In the case of a crypto tunnel tunnel when using a
verified / authenticated crypto algorithm, any lower level
UDP checksum is even more redundent.

The one place where UDP checksums would stil seem to be useful
is for any in band control messages, if they were themselves
not covered by the crypto layer.  i.e. c.f. OpenVPN and
its payload vs control messages.

Which then got me to thinking that one could sort of cheat,
and use the checksum field in the UDP header as an indicator
of if the payload is control or data.  All zero bits for
data, none zero (including 0xffff) for control.

This would also have the advantage that if one is using a system
without support for h/w checksum offload, one gets to save a
bit of CPU;  however that may or may not be significant depending
upon just if/when packet memory if touched, and by which cores
in a system.  i.e. I'm pondering a non Linux kernel implementation.

So - thoughts?  Is it worth doing something like this for wireguard?

DF

             reply	other threads:[~2018-02-20  0:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20  1:05 Derek Fawcus [this message]
2018-02-20  6:36 ` Rouven Czerwinski

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=20180220010520.GA38119@accordion.employees.org \
    --to=dfawcus+lists-wireguard@employees.org \
    --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).