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] [day] [month] [year] [list]
Message-Id: <20090517.155122.63991120.davem@davemloft.net>
Date:	Sun, 17 May 2009 15:51:22 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	christophe@...ut.de
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH] Fixing up TCP/UDP checksum for UDP encap. ESP4
 packets in transport mode

From: Christophe Saout <christophe@...ut.de>
Date: Thu, 23 Apr 2009 18:04:56 +0200

> I was happily running an transport-mode IPSEC connection where I was
> running NAT at one endpoint.  This means that decrypted packets can be
> forwarded to another machine, as opposed to being delivered to a local
> application.
> 
> Later I was forced to encapsulate the IPSEC traffic into UDP because I
> had no choice but pass through a NAT device.  Then, unfortunately,
> things started to break.  The machine that would receive the answer to a
> TCP/SYN packet from the gateway box (that decrypts the packed and then
> forwards it) discarded the packets because of a wrong TCP checksum.
> 
> I checked the kernel code - esp4.c is just setting CHECKSUM_UNNECESSARY
> on these packets, so that they are accepted by local applications.
> However, when the packages leaves the machine via a NIC, the packet
> still carries the broken checksum.  I checked the RFC on the issue and
> one of the suggestions is to recompute the checksum for carried TCP/UDP
> packets.
> 
> 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.

Thanks for reporting this.  It seems we've choosen the simplest
of the 3 implementation options given in section 3.1.2 or
RFC 3948.

It definitely breaks that case you are using, and the only way
to fix it up is to recompute the checksum.

I'll think about this some more and figure out how exactly we
should fix this.

Thanks again.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ