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: <MW4PR11MB5776D18B1DA527575987CB1DFD2D9@MW4PR11MB5776.namprd11.prod.outlook.com>
Date:   Tue, 8 Feb 2022 14:12:33 +0000
From:   "Drewek, Wojciech" <wojciech.drewek@...el.com>
To:     Harald Welte <laforge@...ocom.org>,
        Marcin Szycik <marcin.szycik@...ux.intel.com>
CC:     "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: sobota, 5 lutego 2022 17:52
> To: Marcin Szycik <marcin.szycik@...ux.intel.com>
> Cc: netdev@...r.kernel.org; michal.swiatkowski@...ux.intel.com; Drewek, Wojciech <wojciech.drewek@...el.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 Marcin, Wojciech,
> 
> I would prefer to move this patch to right after introducing the
> kernel-socket mode, as the former makes no sense without this patch.
Sure thing

> 
> Now that this patch implements responding to the GTP ECHO procedure,
> one interesting question that comes to mind is how you would foresee
> outbound GTP echo procedures to be used in this new use pattern.
> 
> With the existing (userspace creates the socket) pattern, the userspace
> instance can at any point send GTP ECHO request packets to any of the
> peers, while I don't really see how this would work if the socket is in
> the kernel.
> 
> The use of the outbound ECHO procedure is not required for GTP-U by TS
> 29.060, so spec-wise it is fine to not support it.  It just means
> that any higher-layer applications using this 'socketless' use pattern
> will be deprived of being able to check for GTP-U path failure.
> 
> IMHO, this is non-negligable, as there are no other rqeust-response
> message pairs on the GTP-U plane,  so transmitting and receiving ECHO
> is the only way a control plane / management instance has to detect
> GTP-U path failure.
> 
> So without being able to trigger GTP-ECHO, things could look prefectly
> fine on the GPT-C side of things, but GTP-U may not be working at all.
> 
> 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.
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.
What do you think?

Regards,
Wojtek

> 
> Regards,
> 	Harald
> 
> --
> - 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)