netdev - Re: [PATCH net-next v1 1/3] gtp: refactor to support flow-based gtp encap and decap

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:   Wed, 2 Aug 2017 14:52:46 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Andreas Schultz <aschultz@...p.net>, g@...via
Cc:     Jiannan Ouyang <ouyangj@...com>,
        osmocom-net-gprs <osmocom-net-gprs@...ts.osmocom.org>,
        netdev <netdev@...r.kernel.org>, dev@...nvswitch.org,
        laforge <laforge@...monks.org>, pshelar@...ira.com,
        wieger ijntema tno <wieger.ijntema.tno@...il.com>,
        yi y yang <yi.y.yang@...el.com>, joe@....org,
        Amar Padmanabhan <amarpadmanabhan@...com>
Subject: Re: [PATCH net-next v1 1/3] gtp: refactor to support flow-based gtp
 encap and decap

On Mon, Jul 31, 2017 at 09:21:36AM +0200, Andreas Schultz wrote:
> Hi Jiannan,
> 
> ----- On Jul 13, 2017, at 2:44 AM, Jiannan Ouyang ouyangj@...com wrote:
> 
> [...]
> 
> > -static int gtp_rx(struct pdp_ctx *pctx, struct sk_buff *skb,
> > -			unsigned int hdrlen, unsigned int role)
> > +static int gtp_rx(struct gtp_dev *gtp, struct sk_buff *skb,
> > +		  unsigned int hdrlen, struct sock *sk,
> > +		  struct metadata_dst *tun_dst)
> 
> Some time ago, there was an extensive discussion about the relation
> of PDP context and network devices. You are basically reverting one
> of the changes that was made in that context. I think it is wrong to
> couple GTP devices and PDP context the way you do here (there are
> people that disagree, though).
> 
> The GTP network device of one of two structures owning the PDP context,
> the other is the GTP socket. GTP network devices and GTP sockets should
> be strictly separated.
> 
> The GTP network device owns the IP given to the MS, handles mapping
> IP's into GTP tunnels (peer GSN + TEIDs) and hands the resulting GTP 
> packets of to the GTP socket for sending. The GTP socket decaps the GTP
> packet, find the right context and based on information therein passes
> it to the GTP network device.
> 
> By separating is that way, you can have MS with overlapping or colliding
> IP's on the same GTP socket as long as they belong to different GTP network
> devices.
> 
> We had a length discussion about whether the above scenario makes sense.
> I'm not sure if we reached a final verdict, but the 3GPP specifications
> clearly permit such a setup.

We need a netlink interface to retrieve GTP information accordingly,
this includes a top-level APN object to represent what you need. That
would allow to accomodate all usecases.