From: Ben Hutchings <bhutchings@solarflare.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: <netdev@vger.kernel.org>
Subject: Re: Question with secure_ipv4_port_ephemeral() implementation
Date: Sun, 22 Apr 2012 15:21:02 +0100 [thread overview]
Message-ID: <1335104462.3209.377.camel@deadeye> (raw)
In-Reply-To: <201204221420.GJB51054.OtHOFSQJFOVMFL@I-love.SAKURA.ne.jp>
On Sun, 2012-04-22 at 14:20 +0900, Tetsuo Handa wrote:
> Ben Hutchings wrote:
> > As I understand it, that 8-bit counter was used for all connections, so
> > in order to spoof the source of a TCP connection it was only necessary
> > to guess 24 bits of the ISN. On a sufficiently fast network, it would
> > now be feasible to carry out a brute force attack that ACKs all possible
> > ISNs before the handshake times-out. That's not yet feasible if the
> > attacker has to guess all 32 bits of the ISN.
>
> So, the purpose was to make the initial sequence number more random. OK.
>
> > The original reason for periodically regenerating the secret was that
> > the hash function was quite weak and the secret could presumably be
> > found in a reasonably short time. So, without regeneration, the hash
> > also has to be stronger.
>
> My concern is the purpose of making the automatic local port number selection
> algorithm less random. That commit removed uptime factor from factors that
> determine starting point of available local port scanning (due to removal of
> periodic get_random_bytes() calls).
>
> 368 static inline u32 inet_sk_port_offset(const struct sock *sk)
> 369 {
> 370 const struct inet_sock *inet = inet_sk(sk);
> 371 return secure_ipv4_port_ephemeral(inet->inet_rcv_saddr,
> 372 inet->inet_daddr,
> 373 inet->inet_dport);
> 374 }
>
> secure_ipv4_port_ephemeral() no longer depends on uptime.
>
> 565 int inet_hash_connect(struct inet_timewait_death_row *death_row,
> 566 struct sock *sk)
> 567 {
> 568 return __inet_hash_connect(death_row, sk, inet_sk_port_offset(sk),
> 569 __inet_check_established, __inet_hash_nolisten);
> 570 }
>
> inet_sk_port_offset() no longer depends on uptime.
> It returns same port offset for same addresses.
[...]
All this randomisation is concerned with preventing spoofing attacks by
attackers that can't see any packets routed to the spoofed address. If
they can see the return packets then this is all in vain, which is why
we generally want cryptography at the transport or application level.
But if they can't then the port offset remains secret - right?
(Port randomisation is not very useful on it own due to the small number
space, but see
<http://en.wikipedia.org/wiki/DNS_cache_poisoning#Prevention_and_mitigation>.)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2012-04-22 14:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 12:30 Question with secure_ipv4_port_ephemeral() implementation Tetsuo Handa
2012-04-22 3:29 ` Ben Hutchings
2012-04-22 5:20 ` Tetsuo Handa
2012-04-22 14:21 ` Ben Hutchings [this message]
2012-04-22 14:38 ` Tetsuo Handa
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=1335104462.3209.377.camel@deadeye \
--to=bhutchings@solarflare.com \
--cc=netdev@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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