[e2e] How TCP might look with always there ESP

[Angelos D. Keromytis]

In message <5.1.0.14.2.20010717091427.02495ea0 at localhost>, Robert Moskowitz wri
tes:
>
>First we would drop the CRC checksum.  All of the ESP auth methods are much 
>stronger.

There is no real advantage to doing this AFAICT; if you're doing software-only
ESP, the cost of the crypto (even if it's RC4/MD5) greatly overwhelms the
cost of the CRC. On the other hand, the potential for bugs because of this
layering violation is greater than zero. It's not clear what the cons and pros
are.

However, if you always had ESP, chances are you have some kind of hardware
support. Today, you can buy either dedicated crypto boards (I know of at least
4 different PCI boards by different vendors that can do better than fast
ethernet 3DES/SHA-1 ESP), or NICs with IPsec support (I know of one, with
another one probably coming out soon). In both cases, it's easy to see how
the boards can be induced to calculate the TCP CRC; in fact, the NIC that
supports IPsec already can do IP and TCP checksumming for both directions
of traffic.

(Side note: for some obscure reason, said feature does not work
in conjunction with IPsec, although there's no reason it couldn't; perhaps
more amusing is the fact that the firmware on these cards is broken and causes
the cards to hang in some cases where output TCP/UDP checksumming is done on
the NIC).

The best argument against TCP CRC checksumming in hardware lies with the
placement of the TCP header: at the begining of the packet. This means the NIC
has to buffer the packet (or at least receive all of it before it can start
transmitting), since it needs to stick the checksum in the TCP header. IPsec
processing, on the other hand, can easily be done in a "streaming" fashion,
since the authenticator is at the end of the packet.

>But what about sequence numbers?  ESP has a seq # also.  Can it be used in 
>place of TCPs?  What restrictions need be placed on ESP's seq #?

The main problem of course is that the ESP replay-protection counter counts
packets, whereas the TCP sequence number counts bytes. As such, it would
interact really badly with things like PMTU discovery or data aggregation --
anything that would cause the same data to be retransmitted despite the fact
that it has already been received (the sender will not know it, of course).
If you go down this path....good luck :-)

>Anything else?

VJ-style compression could eliminate the source/destination ports (since these
can be uniquely identified by the SPI --- *after* the TCP handshake, or at
least the first SYN).
-Angelos