[e2e] How TCP might look with always there ESP

[Robert Moskowitz]

At 12:37 PM 7/17/2001 -0400, Angelos D. Keromytis wrote:

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

The point is.  You are doing ESP.  Given that can you save on TCP?  The 
answer gotten here is:  Yeah, somewhat.  ESP in software or hardware is not 
TOO much an issue.  We already have devices altering TCP checksums, as they 
are playing with the IP headers that are included in the checksum 
calculation.  So a hardware ESP implementation could strip off or re-add 
the checksum just as well as a software one.

Plus if the kernel 'knew' that ESP was in use, end-2-end, then it COULD be 
tuned to the change.


> >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 :-)

oops.  yeah.  No can do, it seems.  ESP and TCP sequence numbers have a 
considerably different set of symantics.  Thanks.

>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).

This assumes port level SAs.  the basic HIP design is for 'kernel' level 
SAs.  So I don't think I can add this.