Re: [tcpm] tcp-auth-opt issue: replay protection

Adam Langley wrote:
> 
> On Wed, Aug 6, 2008 at 8:03 AM, Joe Touch <touch@isi.edu> wrote:
> > Does anyone know what happens to other options? I.e., aren't
> timestamps
> > recomputed, SACK options recalculated, etc.? It seems like the
> options
> > need to be revisited when a segment goes out the door anyway, and a
> > stack that just replays segments is what might be considered
> "broken"...
> 
> I can speak for the Linux stack:
> 
> Buffers are kept around for retransmissions, but the buffers only
> maintain the segment data. TCP and IP headers are recreated without
> any reference to any previous transmissions.
> 
> 

That's also true of most TCP offload solutions I've seen.
Fundamentally, it is easier for almost all implementations
to keep a descriptor of a transmitted segment around (and
not allow the client to re-use its buffer) than it is to
keep a full copy of the formed TCP segment around. After
all, even in networks with atrocious drop rates the typical
TCP segment will NOT be retransmitted. Since retransmission
is the exception MOST implementations would rather redo
the TCP header construction than use memory to remember
exactly what they did last time. It's easier to just remember
enough so that you will generate the same output.

Specialized designs and/or prototypes are more likely to
do things like follow strict layering where they might
actually store the entire frame to simplify interfaces.
But those designs, in my experience, will be the exception.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm