netdev - RE: [PATCH] ipvs: sctp: fix checksumming on snat and dnat handlers

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: <AE90C24D6B3A694183C094C60CF0A2F6026B7137@saturn3.aculab.com>
Date:	Wed, 6 Feb 2013 09:18:53 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Simon Horman" <horms@...ge.net.au>,
	"Pablo Neira Ayuso" <pablo@...filter.org>
Cc:	<lvs-devel@...r.kernel.org>, <netdev@...r.kernel.org>,
	<netfilter-devel@...r.kernel.org>,
	"Wensong Zhang" <wensong@...ux-vs.org>,
	"Julian Anastasov" <ja@....bg>,
	"Daniel Borkmann" <dborkman@...hat.com>
Subject: RE: [PATCH] ipvs: sctp: fix checksumming on snat and dnat handlers

> From: Daniel Borkmann <dborkman@...hat.com>
> 
> In our test lab, we have a simple SCTP client connecting to a SCTP
> server via an IPVS load balancer. On some machines, load balancing
> works, but on others the initial handshake just fails, thus no
> SCTP connection whatsoever can be established!
> 
> We observed that the SCTP INIT-ACK handshake reply from the IPVS
> machine to the client had a correct IP checksum, but corrupt SCTP
> checksum when forwarded, thus on the client-side the packet was
> dropped and an intial handshake retriggered until all attempts
> run into the void.
> 
> To fix this issue, this patch i) adds a missing CHECKSUM_UNNECESSARY
> after the full checksum (re-)calculation (as done in IPVS TCP and UDP
> code as well), ii) calculates the checksum in little-endian format
> (as fixed with the SCTP code in commit 4458f04c: sctp: Clean up sctp
> checksumming code) and iii) refactors duplicate checksum code into a
> common function. Tested by myself.

If the NAT code has only modified a few bytes inside one of the SCTP
chunks, then the crc can be modified by knowing the changed bits and
the number of bytes to the end of the chunk (without looking at
any other data bytes).
That would (probably) be faster (may not really matter for INIT-ACK.

	David



--
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