netdev - Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170206140418.dwiofucns5eolgel@nataraja>
Date:   Mon, 6 Feb 2017 15:04:18 +0100
From:   Harald Welte <laforge@...monks.org>
To:     Andreas Schultz <aschultz@...p.net>
Cc:     pablo <pablo@...filter.org>, netdev <netdev@...r.kernel.org>,
        Lionel Gauthier <Lionel.Gauthier@...ecom.fr>,
        openbsc <openbsc@...ts.osmocom.org>
Subject: Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context

Dear All,

On Thu, Feb 02, 2017 at 04:07:23PM +0100, Andreas Schultz wrote:
> ----- On Feb 2, 2017, at 3:46 PM, pablo pablo@...filter.org wrote:
> > On Thu, Feb 02, 2017 at 03:38:07PM +0100, Andreas Schultz wrote:
> >> ----- On Feb 2, 2017, at 3:28 PM, pablo pablo@...filter.org wrote:
> >> > I suggest you just call kfree_rcu() from 4/6.
> >> > 
> >> > Regarding holding socket reference, see my comment for patch 1/6.
> >> 
> >> This is going to be a problem at this stage of the changes.
> >> 
> >> The final goal is to have a reference from the socket to the pdp context.
> > 
> > Is this just a cleanup? Or you need this sk caching for some follow up
> > work?
> 
> It's not caching, the plan is to completely remove the socket from the
> GTP netdevice (as far as that is possible without breaking the existing API).

I agree this is the way to go.  When I originally thought about the GTP
kernel tunneling module early on, I was not aware of the fact that
operators actually in practise run multiple "virtual GGSNs" on one IP
address/port.  From a pure technical point of view you would say "why
bother"?  They could just use separate IP addresses for each of them.
However, the reailty is that each new IP address that an operator uses
for a GGSN results in paper forms required to be exchanged between this
operator and all his roming partners, followed-up by manual
re-configuration of the policies on all of those roaming partners.  This
is time-consuming and error-prone, but hey, it's how the procedures
between GSMA members seem to work ;)

> A GGSN or PGW can serve multiple APN's on the same GTP-U socket. Those APN's
> can have overlapping IP address ranges. The only sensible way to handle
> this, is to have a netdevice per APN. This breaks the current 1:1 relation
> between sockets and netdevices.

Indeed.  So the question is how to do this best and how to keep
backwards compatibility of the netlink interface.  I don't claim to have
answers to that, sorry.

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