From: David Miller <davem@davemloft.net>
To: rick.jones2@hp.com
Cc: fernando@gont.com.ar, eric.dumazet@gmail.com,
security@kernel.org, eugeneteo@kernel.sg, netdev@vger.kernel.org,
mpm@selenic.com
Subject: Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable
Date: Thu, 21 Jul 2011 16:13:01 -0700 (PDT) [thread overview]
Message-ID: <20110721.161301.1825037422957926629.davem@davemloft.net> (raw)
In-Reply-To: <4E28AC3D.1010907@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 21 Jul 2011 15:46:21 -0700
> On 07/21/2011 03:17 PM, David Miller wrote:
>> From: Fernando Gont<fernando@gont.com.ar>
>> Date: Wed, 20 Jul 2011 22:32:18 -0300
>>
>>> Does it make sense to go in this direction rather than simply
>>> randomize
>>> the IPv6 Fragment Identification?
>>
>> We could, but that's actually a bit more work.
>>
>> You have to avoid recycling IDs to the same destination host otherwise
>> a retransmit could use the same ID and overlap with a previous set of
>> frags, causing corruption.
>
> I think you mean ID reuse rather than packet retransmit no?
>
> It is the same "frankengram" issue present in IPv4 with its now puny
> 16 bit id field. Doesn't that pretty much rely on layer4 or higher
> checksums to avoid corruption?
We've had documented cases where checksums match after recycling the
fragment ID space in ipv4, that's why we have all of the special
code in the ipv4 fragmentation handling to work around that problem.
next prev parent reply other threads:[~2011-07-21 23:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4E24BE94.7010301@gont.com.ar>
[not found] ` <1311082696.2375.26.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
[not found] ` <1311089463.2375.42.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
2011-07-19 20:47 ` [PATCH net-next-2.6] ipv6: make fragment identifications less predictable Eric Dumazet
2011-07-19 20:56 ` Matt Mackall
2011-07-20 6:50 ` Eric Dumazet
2011-07-20 8:25 ` Eric Dumazet
2011-07-20 10:27 ` Eric Dumazet
2011-07-21 1:32 ` Fernando Gont
2011-07-21 22:17 ` David Miller
2011-07-21 22:46 ` Rick Jones
2011-07-21 23:13 ` David Miller [this message]
2011-07-21 23:37 ` Fernando Gont
2011-07-22 0:07 ` David Miller
2011-07-22 0:34 ` Rick Jones
2011-07-22 1:18 ` Fernando Gont
2011-07-22 4:26 ` 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=20110721.161301.1825037422957926629.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=eugeneteo@kernel.sg \
--cc=fernando@gont.com.ar \
--cc=mpm@selenic.com \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
--cc=security@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;
as well as URLs for NNTP newsgroup(s).