Re: [PATCH net-next] net/gtp: Add udp source port generation according to flow hash

[Or Gerlitz <gerlitz.or@gmail.com>]

On Thu, Feb 16, 2017 at 11:58 PM, Andreas Schultz <aschultz@tpip.net> wrote:
> Hi Or,
> ----- On Feb 16, 2017, at 3:59 PM, Or Gerlitz ogerlitz@mellanox.com wrote:
>
>> Generate the source udp header according to the flow represented by
>> the packet we are encapsulating, as done for other udp tunnels. This
>> helps on the receiver side to apply RSS spreading.
>
> This might work for GTPv0-U, However, for GTPv1-U this could interfere
> with error handling in the user space control process when the UDP port
> extension  header is used in error indications.


in the document you posted there's this quote "The source IP and port
have no meaning and can change at any time" -- I assume it refers to
v0? can we identify in the kernel code that we're on v0 and have the
patch come into play?

> 3GPP TS 29.281 Rel 13, section 5.2.2.1 defines the UDP port extension and
> section 7.3.1 says that the UDP source port extension can be used to
> mitigate DOS attacks. This would IMHO imply that the user space control
> process needs to know the TEID to UDP source port mapping.

> The other question is, on what is this actually hashing. When I understand
> the code correctly, this will hash on the source/destination of the orignal
> flow. I would expect that a SGSN/SGW/eNodeB would like the keep flow
> processing on a per TEID base, so the port hashing should be base on the TEID.

is it possible for packets belonging to the same TCP session or UDP
"pseudo session" (given pair of src/dst ip/port) to be encapsulated
using different TEID?

hashing on the TEID imposes a harder requirement on the NIC HW vs.
just UDP based RSS.