[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT Traversal



Henry Spencer writes:
> On Thu, 28 Feb 2002, Tero Kivinen wrote:
> > Implementations own local policy. If the implementation knows for sure
> > that it's TCP/UDP stack does not care about checksums, it can simply
> > zero them.
> There is no such thing as a (standard conforming) TCP/UDP stack which does
> not care about checksums.  Checking checksums is mandatory; discarding

Note, that we are talking about packets which are already verified
using the MAC of the ESP payload. We are not talking about the random
packets received from the network. Also for those packets we know that
the UDP and TCP checksums are incorrect because we know that some NAT
device between has changed the ip-addresses and it could not fix the
checksums because the checksum was encrypted.

For those cases I think it is ok for an implementation to mark the
packet after decryption and MAC verification that it had correct
tcp/udp checksum so that the operating system stack can then notice
that ok, I should not do checksum checks for this packet, as something
inside my system already claimed that it is ok.

Another option is to recalculate the checksum either completely or by
incremental method. This ignoring of the checksum is completely
internal to the operating system stack, the incorrect checksum does
cannot go out from the host (if the packet is forwarded then the
checksum must be updated). 

> packets with bad checksums is mandatory.  A UDP implementation may
> optionally choose not to include a checksum with a packet it generates (by
> setting the checksum field to zero), but it must still check checksums on
> incoming packets and discard bad ones.  A TCP implementation does not even
> have that little bit of flexibility; the TCP checksum is not optional. 
> See RFC 1122. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/