netdev - Re: [PATCH net-next v4 4/7] gtp: consolidate gtp socket rx path

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] [day] [month] [year] [list]

Date:   Thu, 23 Feb 2017 22:17:35 +0100
From:   Harald Welte <laforge@...monks.org>
To:     Tom Herbert <tom@...bertland.com>
Cc:     netdev <netdev@...r.kernel.org>,
        osmocom-net-gprs <osmocom-net-gprs@...ts.osmocom.org>,
        timo lindhorst <timo.lindhorst@...velping.com>,
        Andreas Schultz <aschultz@...p.net>,
        pablo <pablo@...filter.org>
Subject: Re: [PATCH net-next v4 4/7] gtp: consolidate gtp socket rx path

Hi Tom,

On Thu, Feb 23, 2017 at 10:07:03AM -0800, Tom Herbert wrote:
> I'm looking at the GTP encapsulation, it's not particularly complex.
> Is there any real reason why we can't just implement a netdev
> interface with static tunnels and configuration to do performance
> testing and development? For instance, if we want to add GSO/GRO
> support to GTP that's all we really need, the control plane should be
> inconsequential in that case.

As outlined several times in this thread, GTP tunneling is not
symmetric.  The current mainline code can only act as one of the two
roles (GGSN/G-GW), not as the other one.  The rationale is that in 3GPP
networks, that is the only point in the network that takes native IP
data (e.g.from the internet) and puts it into GTP.  At all other places
in the network, you don't have this combination.  By the time the inner
IP data arrives at the mobile phone, it is no longer encapsulated in
GTP, as the lower layers have been adapted one or multiple times to
other protocols by other network elements.

There's a patch that has recently been submitted which adds the
capability for the SGSN/S-GW side of a GTP-U tunnel, but that patch has
so far not been merged (due to concersn about its netlink interface),
and the patch *only* exists for testing, it has no real-world
application in 3GPP networks.

So as of now, it is not possible to run both endpoints of a tunnel in
Linux.

> > For performance testing, you would need a SGSN-side implementation of
> > I'll try to cook up some instructions extending
> > https://osmocom.org/projects/openggsn/wiki/OpenGGSN to cover also
> > sgsnemu for a basic use case of establishing one single tunnel.  That's
> > of course like a manual "HOWTO" and not yet anything that can be tested
> > automatically.
> >
> That would be good. Thanks!

I've spent some hours earlier today on this, I expect the document to be
ready at some point over the weekend.

-- 
- 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)