netdev - Re: [net-next-2.6] XFRM: remove unused member in xfrm_encap

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CF3FE85.6040406@iki.fi>
Date:	Mon, 29 Nov 2010 21:27:01 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	David Shwatrz <dshwatrz@...il.com>
CC:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [net-next-2.6] XFRM: remove unused member in xfrm_encap_tmpl.

On 11/29/2010 09:15 PM, David Shwatrz wrote:
> But isn't something wrong here ?
> 
> According to RFC 3948:
> ...
> 3.1.2.  Transport Mode Decapsulation NAT Procedure
> 
> When a transport mode has been used to transmit packets, contained
>    TCP or UDP headers will have incorrect checksums due to the change of
>    parts of the IP header during transit.  This procedure defines how to
>    fix these checksums
> ...
> incrementally recompute the
>        TCP/UDP checksum:
> 
>        *  Subtract the IP source address in the received packet from the
>           checksum.
>        *  Add the real IP source address received via IKE to the
>           checksum (obtained from the NAT-OA)
> ...
> 
> So where do we pass the NAT-OA, received from IKE messages,  to this
> checksum recalculation process, which should be done in the kernel
> (layer 4 TCP/UDP I suppose) ?
> 
> Should'nt this process be done in the kernel ?
> 
> Isn't there something missing here ?

That's what the field was intended for. Also it's passed around by e.g.
'ip xfrm' command. The header change would break compilation of iproute2
too.

Alternatively the other RFCs say that the checksum can be just
recalculated. That's what the linux stack does: it throws the old
checksum away (ignored on local receive and recalculated on send /
forward paths). The ESP/AH packets are usually also configured to
contain a cryptographic hash, so the packet modifications are detected
even before trying to check the TCP/UDP checksum (making the check
redundant).

There's also probably some legacy reasons why the nat-oa field is useful
in kernel; and why the tcp/udp is not updated according the above
mentioned scheme. I guess doing that might speed up forwarding from one
tunnel to another where hardware checksum acceleration is not available;
maybe no one just had the time to implement it.

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