From: Andreas Schultz <aschultz@tpip.net>
To: Or Gerlitz <ogerlitz@mellanox.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Jamal Hadi Salim <jhs@mojatatu.com>, pablo <pablo@netfilter.org>,
laforge <laforge@gnumonks.org>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] net/gtp: Add udp source port generation according to flow hash
Date: Thu, 16 Feb 2017 22:58:11 +0100 (CET) [thread overview]
Message-ID: <576077949.135577.1487282291666.JavaMail.zimbra@tpip.net> (raw)
In-Reply-To: <1487257141-11706-1-git-send-email-ogerlitz@mellanox.com>
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.
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.
All together, I think adding an additional UDP source port argument to
the PDP context might be a better solution.
Andreas
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
>
> found in code inspection.. compile tested only
>
>
> drivers/net/gtp.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
> index bda0c64..ff1244b 100644
> --- a/drivers/net/gtp.c
> +++ b/drivers/net/gtp.c
> @@ -564,6 +564,7 @@ static netdev_tx_t gtp_dev_xmit(struct sk_buff *skb, struct
> net_device *dev)
> {
> unsigned int proto = ntohs(skb->protocol);
> struct gtp_pktinfo pktinfo;
> + __be16 src_port;
> int err;
>
> /* Ensure there is sufficient headroom. */
> @@ -572,6 +573,8 @@ static netdev_tx_t gtp_dev_xmit(struct sk_buff *skb, struct
> net_device *dev)
>
> skb_reset_inner_headers(skb);
>
> + src_port = udp_flow_src_port(dev_net(dev), skb, 0, 0, true);
> +
> /* PDP context lookups in gtp_build_skb_*() need rcu read-side lock. */
> rcu_read_lock();
> switch (proto) {
> @@ -596,7 +599,7 @@ static netdev_tx_t gtp_dev_xmit(struct sk_buff *skb, struct
> net_device *dev)
> pktinfo.iph->tos,
> ip4_dst_hoplimit(&pktinfo.rt->dst),
> 0,
> - pktinfo.gtph_port, pktinfo.gtph_port,
> + src_port, pktinfo.gtph_port,
> true, false);
> break;
> }
> --
> 2.3.7
next prev parent reply other threads:[~2017-02-16 21:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-16 14:59 [PATCH net-next] net/gtp: Add udp source port generation according to flow hash Or Gerlitz
2017-02-16 21:58 ` Andreas Schultz [this message]
2017-02-22 21:29 ` Or Gerlitz
2017-02-22 21:47 ` Tom Herbert
2017-02-23 9:35 ` Andreas Schultz
2017-02-23 14:00 ` Pablo Neira Ayuso
2017-02-23 16:35 ` Tom Herbert
2017-02-23 16:50 ` Harald Welte
2017-02-23 17:01 ` David Miller
2017-02-23 13:49 ` Pablo Neira Ayuso
2017-02-23 13:58 ` Or Gerlitz
2017-02-23 14:21 ` Andreas Schultz
2017-02-23 16:42 ` Pablo Neira Ayuso
2017-02-23 17:19 ` Andreas Schultz
2017-02-23 17:54 ` David Miller
2017-03-15 16:14 ` Or Gerlitz
2017-03-15 16:25 ` Pablo Neira Ayuso
2017-02-23 16:42 ` Tom Herbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576077949.135577.1487282291666.JavaMail.zimbra@tpip.net \
--to=aschultz@tpip.net \
--cc=davem@davemloft.net \
--cc=jhs@mojatatu.com \
--cc=laforge@gnumonks.org \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).