public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Harald Welte <laforge@gnumonks.org>
To: Tom Herbert <tom@herbertland.com>
Cc: David Miller <davem@davemloft.net>,
	Tom Herbert <tom@quantonium.net>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Rohit Seth <rohit@quantonium.net>
Subject: Re: [PATCH net-next 12/14] gtp: Configuration for zero UDP checksum
Date: Thu, 21 Sep 2017 09:55:22 +0800	[thread overview]
Message-ID: <20170921015522.sv5netrlcj5vebys@nataraja> (raw)
In-Reply-To: <CALx6S35NP_BJ8oHwjkOZkNYJa=g7hWeUiNMZ5WNj-2FQaksCeQ@mail.gmail.com>

Hi Tom,

On Wed, Sep 20, 2017 at 11:09:29AM -0700, Tom Herbert wrote:
> On Mon, Sep 18, 2017 at 9:24 PM, David Miller <davem@davemloft.net> wrote:
> > From: Tom Herbert <tom@quantonium.net>
> >> Add configuration to control use of zero checksums on transmit for both
> >> IPv4 and IPv6, and control over accepting zero IPv6 checksums on
> >> receive.
> >
> > I thought we were trying to move away from this special case of allowing
> > zero UDP checksums with tunnels, especially for ipv6.
> 
> I don't have a strong preference either way. I like consistency with
> VXLAN and foo/UDP, but I guess it's not required. Interestingly, since
> GTP only carries IP, IPv6 zero checksums are actually safer here than
> VXLAN or GRE/UDP.

Just for the record: I don't care either way and I defer to the kernel
networking developers to decide if they want to have zero UDP checksum
in GTP or not.

The 3GPP specs don't say anything about UDP checksums.  So there's no
requirement to use them, and hence operation without UDP checksums
should be compliant.  Cisco GTP implementation has udp checksumming
configurable, so other implementations also seem to provide both ways.

In general, I would argue one wants UDP checksumming of GTP in all
setups, as while the inner IP packet might be protected, the GTP header
itself is not, and that's what contains important data suhc as the TEID
(Tunnel Endpoint ID).  But that's of course just my personal opinion,
and I'm not saying we should prevent people from using lower protection
if that's what they want.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

  reply	other threads:[~2017-09-21  4:49 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-19  0:38 [PATCH net-next 00/14] gtp: Additional feature support Tom Herbert
2017-09-19  0:38 ` [PATCH net-next 01/14] iptunnel: Add common functions to get a tunnel route Tom Herbert
2017-09-19  7:30   ` kbuild test robot
2017-09-19  0:38 ` [PATCH net-next 02/14] vxlan: Call common functions to get tunnel routes Tom Herbert
2017-09-19  0:38 ` [PATCH net-next 03/14] gtp: Call common functions to get tunnel routes and add dst_cache Tom Herbert
2017-09-19  4:17   ` David Miller
2017-09-19 12:09     ` Harald Welte
2017-09-19 17:44       ` David Miller
2017-09-20 15:37       ` Andreas Schultz
2017-09-24  1:33         ` Harald Welte
2017-09-19 16:05     ` Tom Herbert
2017-09-19  0:38 ` [PATCH net-next 04/14] gtp: udp recv clean up Tom Herbert
2017-09-19  7:44   ` kbuild test robot
2017-09-19 11:32   ` Harald Welte
2017-09-19  0:38 ` [PATCH net-next 05/14] gtp: Remove special mtu handling Tom Herbert
2017-09-19 11:42   ` Harald Welte
2017-09-19 18:12     ` Tom Herbert
2017-09-19  0:38 ` [PATCH net-next 06/14] gtp: Eliminate pktinfo and add port configuration Tom Herbert
2017-09-19  0:38 ` [PATCH net-next 07/14] gtp: Support encapsulation of IPv6 packets Tom Herbert
2017-09-19  4:19   ` David Miller
2017-09-19 12:12     ` Harald Welte
2017-09-19 17:42       ` David Miller
2017-09-20  0:11         ` Tom Herbert
2017-09-19 11:53   ` Harald Welte
2017-09-19  0:38 ` [PATCH net-next 08/14] gtp: Support encpasulating over IPv6 Tom Herbert
2017-09-19  4:19   ` David Miller
2017-09-20 18:03     ` Tom Herbert
2017-09-20 19:45       ` David Miller
2017-09-20 20:40         ` Tom Herbert
2017-09-21  0:04           ` Harald Welte
2017-09-21  0:16             ` Tom Herbert
2017-09-19 11:59   ` Harald Welte
2017-09-19  0:38 ` [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone Tom Herbert
2017-09-20 15:27   ` Andreas Schultz
2017-09-20 15:57     ` Tom Herbert
2017-09-20 16:07       ` Andreas Schultz
2017-09-20 16:24         ` Tom Herbert
2017-09-21  0:13           ` Harald Welte
2017-09-21  0:55             ` Tom Herbert
2017-09-21 15:12               ` Harald Welte
2017-09-21 16:43                 ` Tom Herbert
2017-09-24  2:16                   ` Harald Welte
2017-09-24 15:55                     ` Tom Herbert
2017-09-24 16:25                       ` Harald Welte
2017-09-24 17:18                         ` Tom Herbert
2017-09-19  0:39 ` [PATCH net-next 10/14] gtp: Add support for devnet Tom Herbert
2017-09-19  0:39 ` [PATCH net-next 11/14] net: Add a facility to support application defined GSO Tom Herbert
2017-09-19  4:21   ` David Miller
2017-09-19  0:39 ` [PATCH net-next 12/14] gtp: Configuration for zero UDP checksum Tom Herbert
2017-09-19  4:24   ` David Miller
2017-09-20 18:09     ` Tom Herbert
2017-09-21  1:55       ` Harald Welte [this message]
2017-09-21 22:41         ` Tom Herbert
2017-09-19  0:39 ` [PATCH net-next 13/14] gtp: Support for GRO Tom Herbert
2017-09-19 11:57   ` kbuild test robot
2017-09-19 12:03   ` Harald Welte
2017-09-19  0:39 ` [PATCH net-next 14/14] gtp: GSO support Tom Herbert
2017-09-19 12:43 ` [PATCH net-next 00/14] gtp: Additional feature support Harald Welte
2017-09-19 15:59   ` Tom Herbert
2017-09-19 23:19     ` Harald Welte
2017-09-19 23:47       ` Tom Herbert
2017-09-21 15:38         ` Harald Welte
2017-09-20 15:34       ` Andreas Schultz

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=20170921015522.sv5netrlcj5vebys@nataraja \
    --to=laforge@gnumonks.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=rohit@quantonium.net \
    --cc=tom@herbertland.com \
    --cc=tom@quantonium.net \
    /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