From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
WireGuard mailing list <wireguard@lists.zx2c4.com>,
Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>,
Dave Taht <dave.taht@gmail.com>,
"Rodney W . Grimes" <ietf@gndrsh.dnsmgr.net>
Subject: Re: [PATCH net v2] wireguard: use tunnel helpers for decapsulating ECN markings
Date: Mon, 27 Apr 2020 17:09:29 -0600 [thread overview]
Message-ID: <CAHmME9rUCYuBCFbw=yhNPqDDJWD3ZUQ_R9xjQ-yp6DXA9_iScA@mail.gmail.com> (raw)
In-Reply-To: <20200427211619.603544-1-toke@redhat.com>
On Mon, Apr 27, 2020 at 3:16 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> WireGuard currently only propagates ECN markings on tunnel decap according
> to the old RFC3168 specification. However, the spec has since been updated
> in RFC6040 to recommend slightly different decapsulation semantics. This
> was implemented in the kernel as a set of common helpers for ECN
> decapsulation, so let's just switch over WireGuard to using those, so it
> can benefit from this enhancement and any future tweaks.
>
> RFC6040 also recommends dropping packets on certain combinations of
> erroneous code points on the inner and outer packet headers which shouldn't
> appear in normal operation. The helper signals this by a return value > 1,
> so also add a handler for this case.
Thanks for the details in your other email and for this v2. I've
applied this to the wireguard tree and will send things up to net
later this week with a few other things brewing there.
By the way, the original code came out of a discussion I had with Dave
Taht while I was coding this on an airplane many years ago. I read
some old RFCs, made some changes, he tested them with cake, and told
me that the behavior looked correct. And that's about as far as I've
forayed into ECN land with WireGuard. It seems like it might be
helpful (at some point) to add something to the netns.sh test to make
sure that all this machinery is actually working and continues to work
properly as things change in the future.
next prev parent reply other threads:[~2020-04-27 23:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 14:46 [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN markings Toke Høiland-Jørgensen
2020-04-27 19:53 ` Jason A. Donenfeld
2020-04-27 20:42 ` Toke Høiland-Jørgensen
2020-04-27 21:16 ` [PATCH net v2] wireguard: use " Toke Høiland-Jørgensen
2020-04-27 23:09 ` Jason A. Donenfeld [this message]
2020-04-28 9:00 ` Toke Høiland-Jørgensen
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='CAHmME9rUCYuBCFbw=yhNPqDDJWD3ZUQ_R9xjQ-yp6DXA9_iScA@mail.gmail.com' \
--to=jason@zx2c4.com \
--cc=dave.taht@gmail.com \
--cc=davem@davemloft.net \
--cc=ietf@gndrsh.dnsmgr.net \
--cc=netdev@vger.kernel.org \
--cc=olivier.tilmans@nokia-bell-labs.com \
--cc=toke@redhat.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).