Checksum goals in IPFF:
1. support for IPsec ESP NAT (+PAT)
2. ILNP
3. Device Mangling
4. be short
IPsec NAT, ILNP, Device Mangling, be short, be fast
ooooo
+++- IP-layer checksum + protects all data + TCP-layer checksum (data only)
++-+ IP-layer checksum + protects all data
+++- IP-layer checksum; header only + port + TCP-layer checksum (data only)
++-- IP-layer checksum; header only + TCP-layer checksum (data+port)
---+ TCP-layer checksum; covers IP pseudo-header (like IPv6)
We can't defend vs Mangling devices fully, sadly. (without encryption)
What if data-mangling device (NAT), changes port, and re-computes new
good checksum on it... ?
Server will accept a valid-data of a packet, that doesn't belong to the
session.
Basically, due to "shortness" requirements, it is hard to build better
checksums than in IPv6. (TCP checksum covers parts of IP)
Only thing, is that I consider upgrading IPFF TCP to CRC32, which will
take 4 more bytes of overhead.
ILNP-like concept can be done at transport-layer (like MP-TCP).
--
-Alexey Eromenko "Technologov"