All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.