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:   Thu, 27 Jan 2022 19:14:41 +0000
From:   "Drewek, Wojciech" <wojciech.drewek@...el.com>
To:     Harald Welte <laforge@...monks.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 v2 1/5] gtp: Allow to create GTP device
 without FDs

Hi Harald,

Thanks for the response,
I'll take a look on how GTP-U ECHO works and I'll try to implement it.

Regards,
Wojtek

> -----Original Message-----
> From: Harald Welte <laforge@...monks.org>
> Sent: czwartek, 27 stycznia 2022 15:41
> 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 v2 1/5] gtp: Allow to create GTP device without FDs
> 
> Hi Wojciech,
> 
> thanks for your contribution, I think in general it is a good idea.
> 
> However, I do not think this can be merged, as the resulting system would
> not be possible to use in a spec-compliant way.
> 
> > Currently, when the user wants to create GTP device, he has to
> > provide file handles to the sockets created in userspace (IFLA_GTP_FD0,
> > IFLA_GTP_FD1). This behaviour is not ideal, considering the option of
> > adding support for GTP device creation through ip link. Ip link
> > application is not a good place to create such sockets.
> 
> The GTP kernel module in its past and current form only handles G-PDU packets
> and not any other packets.  So it relies on always having a user space process
> [the one with the socket you want to make optional to handle other frames,
> such as GTP ECHO.
> 
> So if you apply your patch, you will end up creating a GTP-U instance which
> does not respond to echo requests, which is in violation of 3GPP specs and
> which will create problems in production.
> 
> So if you want to make this optional, you'd also have to implement GTP-U ECHO handling
> in the kernel, and require that in-kernel handling to be enabled when creating a GTP
> device without the socket file descriptors.
> 
> Regards,
> 	Harald
> 
> --
> - 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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ