From: David Miller <davem@davemloft.net>
To: alexander.duyck@gmail.com
Cc: aduyck@mirantis.com, netdev@vger.kernel.org
Subject: Re: [net-next PATCH] IPv6: Use a 16 bit length field when computing a IPv6 UDP checksum
Date: Tue, 01 Mar 2016 16:35:44 -0500 (EST) [thread overview]
Message-ID: <20160301.163544.1175023538158578123.davem@davemloft.net> (raw)
In-Reply-To: <CAKgT0Ue-OGtHy4=f7mYRxLntgj1rgGpyD2ZojvULY_7EXykhKA@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Tue, 1 Mar 2016 13:19:28 -0800
> I was wondering what your thoughts would be about widening the size of
> the length field that we pass into csum_tcpudp_magic from a 16 bit to
> a 24 or 32 bit value? The general idea would be to shift tunnels over
> to uniformly using skb->len instead of a mix of 16 bit or 32 bit
> lengths. My thought is it might add a bit of security since it would
> invalidate the outer header checksum for the case where length has
> exceeded 65535 resulting in uh->len field being invalid anyway.
Hmmm, but wait, what is uh->len supposed to be for an ipv6 jumbogram
anyways?
It just gets truncated and the the ipv6 header payload length field
trumps whatever is in the UDP header length field right?
If that's what happens then we should uniformly use the truncated
length for the pseudo-header calculations as you originally suggested.
How UDP jumbograms as supposed to be handled wrt. udp_hdr->len should
guide our implementation.
next prev parent reply other threads:[~2016-03-01 21:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 3:10 [net-next PATCH] IPv6: Use a 16 bit length field when computing a IPv6 UDP checksum Alexander Duyck
2016-03-01 20:09 ` David Miller
2016-03-01 21:19 ` Alexander Duyck
2016-03-01 21:35 ` David Miller [this message]
2016-03-01 22:26 ` Alexander Duyck
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=20160301.163544.1175023538158578123.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=netdev@vger.kernel.org \
/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).