netdev - Re: [PATCH net-next v2 07/12] gtp: use ephemeral source port

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]

Date:   Sat, 12 Dec 2020 14:40:59 +0100
From:   Jonas Bonn <jonas@...rbonn.se>
To:     Harald Welte <laforge@...monks.org>
Cc:     netdev@...r.kernel.org, pablo@...filter.org
Subject: Re: [PATCH net-next v2 07/12] gtp: use ephemeral source port

Hi Harald,

On 12/12/2020 11:07, Harald Welte wrote:
> Hi Jonas,
> 
> On Fri, Dec 11, 2020 at 01:26:07PM +0100, Jonas Bonn wrote:
>>  From 3GPP TS 29.281:
>> "...the UDP Source Port or the Flow Label field... should be set dynamically
>> by the sending GTP-U entity to help balancing the load in the transport
>> network."
> 
> You unfortuantely didn't specifiy which 3GPP release you are referring to.
> 

Sorry about that.  I'm looking at v16.1.0.

> At least in V15.7.0 (2020-01)  Release 15 I can only find:
> 
> "For the messages described below, the UDP Source Port (except as
> specified for the Echo Response message) may be allocated either
> statically or dynamically by the sending GTP-U entity.  NOTE: Dynamic
> allocation of the UDP source port can help balancing the load in the
> network, depending on network deployments and network node
> implementations."
> 
> For GTPv0, TS 29.060 states:
> 
> "The UDP Source Port is a locally allocated port number at the sending
> GSN/RNC."
> 
> unfortuantely it doesn't say if it's a locally allocated number globally
> for that entire GSN/RNC, or it's dynamic per flow or per packet.

I could interpret that to mean that the receiving end shouldn't be too 
bothered about what port a packet happens to come from...  That said, 
dynamic per flow is almost certainly what we want here as this is mostly 
about being able to trigger receive side scaling for network cards that 
can't look at inner headers.

> 
> As I'm aware of a lot of very tight packet filtering between GSNs,
> I would probably not go for fully dynamic source port allocation
> without some kind of way how the user (GTP-control instance) being
> able to decide on that policy.
> 

Sure... sounds reasonable.  A flag on the link setup indicating dynamic 
source port yes/no should be sufficient, right?

/Jonas