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