netdev - RE: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response

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]

Message-ID: <MW4PR11MB5776F58DE5585DEA423716A4FD309@MW4PR11MB5776.namprd11.prod.outlook.com>
Date:   Fri, 11 Feb 2022 12:48:35 +0000
From:   "Drewek, Wojciech" <wojciech.drewek@...el.com>
To:     Harald Welte <laforge@...ocom.org>
CC:     Marcin Szycik <marcin.szycik@...ux.intel.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "michal.swiatkowski@...ux.intel.com" 
        <michal.swiatkowski@...ux.intel.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pablo@...filter.org" <pablo@...filter.org>,
        "osmocom-net-gprs@...ts.osmocom.org" 
        <osmocom-net-gprs@...ts.osmocom.org>
Subject: RE: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response

Hi Harald

> -----Original Message-----
> From: Drewek, Wojciech
> Sent: piątek, 11 lutego 2022 11:27
> To: Harald Welte <laforge@...ocom.org>
> Cc: Marcin Szycik <marcin.szycik@...ux.intel.com>; netdev@...r.kernel.org; michal.swiatkowski@...ux.intel.com;
> davem@...emloft.net; kuba@...nel.org; pablo@...filter.org; osmocom-net-gprs@...ts.osmocom.org
> Subject: RE: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response
> 
> Hi Harald,
> 
> > -----Original Message-----
> > From: Harald Welte <laforge@...ocom.org>
> > Sent: piątek, 11 lutego 2022 10:16
> > To: Drewek, Wojciech <wojciech.drewek@...el.com>
> > Cc: Marcin Szycik <marcin.szycik@...ux.intel.com>; netdev@...r.kernel.org; michal.swiatkowski@...ux.intel.com;
> > davem@...emloft.net; kuba@...nel.org; pablo@...filter.org; osmocom-net-gprs@...ts.osmocom.org
> > Subject: Re: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response
> >
> > Hi Wojciech,
> >
> > On Tue, Feb 08, 2022 at 02:12:33PM +0000, Drewek, Wojciech wrote:
> > > > Remember, GTP-U uses different IP addresses and also typically completely
> > > > different hosts/systems, so having GTP-C connectivity between two GSN
> > > > doesn't say anything about the GTP-U path.
> > >
> > > Two  approaches come to mind.
> > > The first one assumes that peers are stored in kernel as PDP contexts in
> > > gtp_dev (tid_hash and addr_hash). Then we could enable a watchdog
> > > that could in regular intervals (defined by the user) send echo requests
> > > to all peers.
> >
> > Interesting proposal.  However, it raises the next question of what to do if
> > the path is deemed to be lost (N out of M recent echo requests unanswered)? It
> > would have to notify the userspace daemon (control plane) via a netlink event
> > or the like.  So at that point you need to implement some special processing in
> > that userspace daemon...
> >
> > > In the second one user could trigger echo request from userspace
> > > (using new genl cmd) at any time. However this approach would require that
> > > some userspace daemon would implement triggering this command.
> >
> > I think this is the better approach.  It keeps a lot of logic like timeouts,
> > frequency of transmission, determining when a path is considered dead, ... out
> > of the kernel, where it doesn't need to be.
> >
> > > What do you think?
> >
> > As both approaches require some support from the userspace control plane instance,
> > I would argue that the second proposal is superior.
> >
> > Regards,
> > 	Harald
> I agree that second option is better so I'll start to implementing it.
I have one question. The new cmd should be allowed to send echo request
only to the peers stored in the kernel space (PDP contexts) or the userspace
daemon has its own list of peers and any request should be allowed to be send?

Regards,
Wojtek 

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