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

"Caitlin Bestler" <> Wed, 06 August 2008 16:55 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id C71393A67D4; Wed, 6 Aug 2008 09:55:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88D4E3A67D4 for <>; Wed, 6 Aug 2008 09:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XrKPgmspWnh8 for <>; Wed, 6 Aug 2008 09:55:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A28BA3A63CB for <>; Wed, 6 Aug 2008 09:55:08 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 06 Aug 2008 12:55:13 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7704042099@nekter>
In-Reply-To: <>
Thread-Topic: [tcpm] tcp-auth-opt issue: replay protection
Thread-Index: Acj329JZzoyPLViyRVqPCPWjBInMKwACIyCw
References: <><> <><> <><><><><> <> <>
From: Caitlin Bestler <>
To: Adam Langley <>, Joe Touch <>
Subject: Re: [tcpm] tcp-auth-opt issue: replay protection
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adam Langley wrote:
> On Wed, Aug 6, 2008 at 8:03 AM, Joe Touch <> 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