netdev - Re: [PATCH net-next-2.6] ipv6: make fragment identifications less predictable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E2781A2.8020905@gont.com.ar>
Date:	Wed, 20 Jul 2011 22:32:18 -0300
From:	Fernando Gont <fernando@...t.com.ar>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, security@...nel.org,
	Eugene Teo <eugeneteo@...nel.sg>,
	netdev <netdev@...r.kernel.org>, Matt Mackall <mpm@...enic.com>
Subject: Re: [PATCH net-next-2.6] ipv6: make fragment identifications less
 predictable

On 07/20/2011 07:27 AM, Eric Dumazet wrote:
> Le mercredi 20 juillet 2011 à 10:25 +0200, Eric Dumazet a écrit :
> 
>> Please hold on, I'll make a different patch series to ease stable teams
>> job. It appears inetpeer & ipv6 are really not an option for old
>> kernels.
>>
>> Common patch for all kernels :
>> 1) Fix the problem without inetpeer help
>> --- 
>> Patches for next kernels
>> 2) random split as suggested by Matt Mackal
>> 3) Use inetpeer cache to scale identification generation
> 
> Here is the first patch, applicable on net-2.6 / linux-2.6 and stable
> kernels.

Does it make sense to go in this direction rather than simply randomize
the IPv6 Fragment Identification?

Keep in mind that IPv6 routers don't perform fragmentation, that that
the IPv6 identification is 32-bits long.

Thanks,
-- 
Fernando Gont
e-mail: fernando@...t.com.ar || fgont@....org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html