Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Laura Zelenku <laura.zelenku@wandera.com>
To: Aaron Jones <me@aaronmdjones.net>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: [PATCH] Respect WG protocol reserved bytes
Date: Wed, 17 Mar 2021 13:53:22 +0100	[thread overview]
Message-ID: <2240E688-898B-4F74-B954-0754464F6352@wandera.com> (raw)
In-Reply-To: <f5126d40-4ea7-193a-93dd-ab816af3bb7e@aaronmdjones.net>

If the client send some data in reserved bytes you will have logs full of errors because the message gets type from 4 bytes instead of 1 byte (like it is in protocol description).
I would like implementation respects protocol - https://www.wireguard.com/papers/wireguard.pdf . Yes, in our project we use reserved bytes.

I know that when there are zeros in reserved bytes, everything is correct. But if you receive some non-zero value in reserved bytes?

Laura

> On 17. 3. 2021, at 13:35, Aaron Jones <me@aaronmdjones.net> wrote:
> 
> On 17/03/2021 07:55, Laura Zelenku wrote:
>> Packet that respects WG protocol contains Type on first byte followed by
>> three reserved bytes. Because wireguard-go implementation uses element
>> pools it is required to make sure that reserved bytes are cleared for
>> outgoing traffic (can get dirty by "bad" clients). Clearing reserved
>> bytes is also for backwards compatibility.
> 
> Encoding the message type as a little-endian 32-bit integer already
> takes care of setting the reserved bytes to zero; e.g. for a packet of
> message type 1 (handshake initiation), its little-endian 32-bit encoding
> is the following sequence of bytes: [ 0x01 0x00 0x00 0x00 ].
> 
> This is also the approach used for checking message types on the
> receiving end, so packets whose reserved bytes are non-zero are already
> discarded as being those of unknown types of message.
> 
> Regards,
> Aaron Jones
> 


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

  reply	other threads:[~2021-03-17 12:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17  7:55 Laura Zelenku
2021-03-17 12:35 ` Aaron Jones
2021-03-17 12:53   ` Laura Zelenku [this message]
2021-03-17 13:10     ` 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=2240E688-898B-4F74-B954-0754464F6352@wandera.com \
    --to=laura.zelenku@wandera.com \
    --cc=me@aaronmdjones.net \
    --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).