netdev - Re: [RFC] Fixing up TCP/UDP checksum for UDP encap. ESP4 packets in transport mode

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 22 Jun 2009 17:07:31 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Christophe Saout <christophe@...ut.de>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC] Fixing up TCP/UDP checksum for UDP encap. ESP4 packets
	in transport mode

On Thu, Apr 23, 2009 at 06:04:56AM -0000, Christophe Saout wrote:
>
> I have a working (but possibly inelegant version), which I am proposing.
> I know there are obvious things that can be improved, but I'm just
> posting it here for discussion.  Also, I'm not sure my skb handling is
> fully correct.

This patch isn't quite right.  You're wiping out the existing
checksum without verifying it at all.  Now you could argue that
IPsec would guarantee the checksum to be correct anyway.  However
this is not always the case.  Somebody might be trying something
clever like using transport mode in conjunction with NAT prior
to IPsec which means that the packet may have traversed hops
prior to it being protected by IPsec.

The correct solution is to use the encap nat_oa field to adjust
the checksum.  That's why that field exists.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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