public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	David Miller <davem@davemloft.net>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: [RFC] tcp: randomize TCP source ports
Date: Thu, 07 Nov 2013 17:07:14 -0800	[thread overview]
Message-ID: <527C3942.509@hp.com> (raw)
In-Reply-To: <1383872049.9412.124.camel@edumazet-glaptop2.roam.corp.google.com>

On 11/07/2013 04:54 PM, Eric Dumazet wrote:
> TCP does proper randomization of ports on active connections only if
> bind() is used between socket() and connect()
>
> If bind() is not specifically used, kernel performs autobind, and TCP
> autobind typically uses a sequential allocation for a given (dst
> address, dst port, src address) tuple.
>
> UDP autobind does a randomization, as part of the effort to make DNS
> more secure.
>
> TCP autobind uses a global sequential number (called @hint in source
> code) with a perturbation done by secure_ipv4_port_ephemeral(),
>   so that the 'hint' of the next port is per (saddr, daddr, dport) tuple
>
> This was probably done to maximize port use and avoid hitting timewait
> sockets, but I think it should be OK to replace this stuff by a random
> selection to have more entropy in the various flow hashing functions,
> and in general higher security levels. TCP timestamps are now well
> deployed.

For perhaps most definitions of well deployed.  There is at least one 
load balancer which, while it offers TCP Window Scaling, does not also 
offer TCP Time Stamps...

By rights they should (must) be offering TCP Time Stamps, and they are, 
I am told, "working on it."

Is all going to be "well" when it is the (non-Linux) remote system which 
has the TIME_WAIT endpoint?

rick jones

  reply	other threads:[~2013-11-08  1:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08  0:54 [RFC] tcp: randomize TCP source ports Eric Dumazet
2013-11-08  1:07 ` Rick Jones [this message]
2013-11-08  2:04   ` Eric Dumazet
2013-11-08 23:26     ` Rick Jones
2013-11-08 23:42       ` Eric Dumazet
2013-11-08 23:57         ` Rick Jones
2013-11-08 13:02 ` Hannes Frederic Sowa
2013-11-08 14:03   ` Eric Dumazet
2013-11-08 14:28     ` Hannes Frederic Sowa
2013-11-08 15:11       ` Eric Dumazet
2013-11-08 17:39         ` Hannes Frederic Sowa
2013-11-09  4:47         ` Hannes Frederic Sowa
2013-11-09 15:26           ` Loganaden Velvindron
2013-11-09 18:16           ` Daniel Borkmann
2013-11-09 20:54             ` Hannes Frederic Sowa

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=527C3942.509@hp.com \
    --to=rick.jones2@hp.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.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