netdev - Re: [PATCH v7 net-next 00/13] gtp: Additional feature support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 28 Oct 2017 18:47:59 +0200
From:   Harald Welte <laforge@...monks.org>
To:     Tom Herbert <tom@...ntonium.net>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Andreas Schultz <aschultz@...p.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Rohit LastName <rohit@...ntonium.net>
Subject: Re: [PATCH v7 net-next 00/13] gtp: Additional feature support - Part
 I

Hi Tom,

On Sat, Oct 28, 2017 at 09:16:01AM -0700, Tom Herbert wrote:
> Here is what the Kconfig for the EXPERIMENTAL option says:
> 
> "This is an experimental implementation that allows encapsulating IPv6
> over GTP and using GTP over IPv6 for testing and development purposes.
> This is not a standards conformant implementation for IPv6 and GTP.
> More work is needed to reach that level."
> 
> I don't see any ambiguity here about it not being standards complete.
> Nor is there any ambiguity about the its purpose to enable further
> development and the fact that more work is needed.

As stated repeatedly: I have no issue with an *incomplete* implementation,
but I have a problem with an *incompatible* one that takes left turns
where the spec takes right turns.

An *incomplete* implementation could still interoperate with other
implementations but is e.g. missing some optional bits.  It can later
extended with those missing bits and wills stay compatible to users of
the incomplete as well as to any later complete implementation.

An *incompatible* implementation is what I have issues with.

> This a foundation for an IPv6 datapath and is sufficient to do
> benchmarking and performance to determine the prospects of replacing
> proprietary HW with commodity servers running Linux kernel. 

I completely agree with that.

> This is a forward step to get IPv6 into GTP, and frankly the _only_ code that
> has been proposed. There is no reason why someone can't build upon
> this to make a first rate conformant implementation.

I also agree with this.  However, I don't think it makes sense to have it in
the kernel given it implements something that's actually not GTP as per
the relevant specs.  No matter how many disclaimers you put at it,
people will still assume it's GTP if it's called GTP.  And if it's only
useful for benchmarking the poential of a later proper IPv6
implementation, I don't think it should go in.

> In any case, I've invested as much time in this as I can for now. I'll
> leave it up to DaveM to decide if we wants to take all, none, or some
> subset of these patches.

Thanks.  As indicated, I'm planning some testing later this weekend on
the non-IPv6 patches, and am happy to add my Acked-by and/or re-submit
those to Dave after that.

For sure, the kernel networking maintainer can merge any patches,
including the proposed IPv6 patches as-is, and I will accept that.  But
my vote as the original author and co-maintainer of the kernel GTP code
goes politely and respectfully against that - as I have made quite clear
by now.

Thanks + Regards,
	Harald

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