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

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

Message-ID: <MW4PR11MB577686D883EEBDB2C9E0FEB2FD309@MW4PR11MB5776.namprd11.prod.outlook.com>
Date:   Fri, 11 Feb 2022 10:27:14 +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: 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.

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)