From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jeffrey Knockel <jeffk@cs.unm.edu>,
David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
"Jedidiah R. Crandall" <crandall@cs.unm.edu>,
Willy Tarreau <w@1wt.eu>,
"security@kernel.org" <security@kernel.org>
Subject: Re: [PATCH net] ip: make IP identifiers less predictable
Date: Sat, 26 Jul 2014 01:05:42 +0200 [thread overview]
Message-ID: <1406329542.14815.17.camel@localhost> (raw)
In-Reply-To: <1406313497.3363.98.camel@edumazet-glaptop2.roam.corp.google.com>
Hi,
On Fr, 2014-07-25 at 20:38 +0200, Eric Dumazet wrote:
> On Fri, 2014-07-25 at 11:35 -0700, Linus Torvalds wrote:
> > On Fri, Jul 25, 2014 at 11:09 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >
> > > We might change the hash to use both daddr & saddr to increase
> > > protection.
> >
> > .. and maybe protocol too, so that you can't easily use icmp echo
> > packets to do it for udp packets etc. The underlying jhash is
> > jhash_3words(), so that would actually be fairly natural for at least
> > ipv4 (the ipv6 case I didn't look at).
>
> Right, in fact saddr is probably not worth it.
>
> Its not like servers have dozen of IPv4 addresses anyway...
Another idea, maybe worth looking at:
Since commit 703133de331a7a ("ip: generate unique IP identificator if
local fragmentation is allowed") we started to generate fragmentation
ids in the output path for every packet that has ignore_df set, which
nearly is every packet.
We could try to push that down the stack and only insert the
fragmentation id in ip_fragment. We still need to generate the frag_id
directly from the socket layer, but we can reuse the ip6_frag_id field
in skb_shinfo for IPv4, too.
Then we actually only need to generate fragmentation ids for the VJ
compression workaround, generated from the socket->inet_id. Do we still
need this (I guess, yes)?
Does this sound worth a try or are there any unseen protocol specific
consequences I am not yet aware of? We would stop leaking too many
fragmentation ids with this change.
Thanks,
Hannes
next prev parent reply other threads:[~2014-07-25 23:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 8:07 [PATCH net] ip: make IP identifiers less predictable Eric Dumazet
2014-07-24 18:21 ` Linus Torvalds
2014-07-25 15:55 ` Jeffrey Knockel
2014-07-25 18:09 ` Eric Dumazet
2014-07-25 18:35 ` Linus Torvalds
2014-07-25 18:38 ` Eric Dumazet
2014-07-25 19:03 ` Willy Tarreau
2014-07-25 23:05 ` Hannes Frederic Sowa [this message]
2014-07-25 20:28 ` Jeffrey Knockel
2014-07-25 19:50 ` [PATCH v2 " Eric Dumazet
2014-07-25 19:54 ` Eric Dumazet
2014-07-25 19:57 ` Eric Dumazet
2014-07-25 22:35 ` Hannes Frederic Sowa
2014-07-26 6:51 ` Eric Dumazet
2014-07-26 12:21 ` Hannes Frederic Sowa
2014-07-26 6:58 ` [PATCH v3 " Eric Dumazet
2014-07-29 1:47 ` David Miller
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=1406329542.14815.17.camel@localhost \
--to=hannes@stressinduktion.org \
--cc=crandall@cs.unm.edu \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jeffk@cs.unm.edu \
--cc=netdev@vger.kernel.org \
--cc=security@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/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).