[e2e] How TCP might look with always there ESP

[Douglas Otis]

Robert,

If you wish this scheme to be useful for SCTP on a packet basis as well as
TCP, you may wish to consider using the sequence number only to be
restrictive within a sliding window and not use it to mandate sequential
delivery.  This suggestion changes existing schemes for TLS but would allow
normal layering of security.  As security digests are larger than current
checksums or CRC fields, it would not be difficult to conclude improved
error detection as a result.

Doug

> > First we would drop the CRC checksum.  All of the ESP auth
> methods are much
> > stronger.
>
> You _may_ have a point here.  David Reed has been talking about using
> cryptographically strong sums in lieu of TCP and/or IP checksums.
>
> I'm assuming TCP checksums (and IPv4's header checksum for that
> matter) were
> designed to protect against link-layer corruption, which doesn't look all
> that much different from an active attacker.
>
> > 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 #?
>
> No.  TCP's sequence numbers are byte counters, not ESP's packet counters.
> You'd need to rewhack TCP so much to use ESP's sequence numbers that you
> wouldn't have TCP anymore.
>
> > Why do I ask, you ask?  Well I have been concentrating on good,
> end-2-end
> > ESP with a new Key Management Protocol called HIP.  And since I
> am already
> > recommending changes to the TCB API (use a hash of the Host Identity in
> > place of the IP address to decouple the internetwokring and transport
> > layers)
>
> Such a change is far more than an API change.  Doing that changes the TCP
> protocol, though perhaps not as drastically as your previous
> sequence number
> suggestion.
>
> > and since I want this to be very wireless friendly, I am looking
> > at what I can do to 'compression' TCP's overhead.
>
> Is this another argument for TCPng discussions?
>
> Dan
>