Re: [tcpm] SYN/ACK Payloads, draft 01

"Adam Langley" <> Thu, 14 August 2008 20:41 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id E47083A67DF; Thu, 14 Aug 2008 13:41:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AEC33A67DF for <>; Thu, 14 Aug 2008 13:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 03gY0Y8A6xPS for <>; Thu, 14 Aug 2008 13:41:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7AC013A67B7 for <>; Thu, 14 Aug 2008 13:41:53 -0700 (PDT)
Received: by with SMTP id 8so405913yxg.49 for <>; Thu, 14 Aug 2008 13:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=C08tE1GbRx1HEXw6HvnsVryCrf1hdU96Q0jVuysIf8k=; b=WxEYrUzNcivxaJlNpwwj1xk4IAKKc6PtrL3d16Wv+Sko18KMoJtjanYxHmiBjSa9+H HDIxyYqsF6OHd+OVlKotKOHca+Cz0hzz38tPbGwc7Z2yo9JquGKyvYN6oJ5hPeyCFznY ekahkotk62EGTjDpJOHWOifJlnPX8Q5IWB9wA=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=w0nnTE8i54Dr24YHngwt4G3O1HXiEIzATLnI3QdZMjWTIBdHSrBC4WmH2tS6cWQB2/ qtUGWkHzKHp+x4H8/NSB9NM8tFmWNjz5/IfkbhW1vv7hAEmG6n+W5Gbl7uf++d01/2F9 6Ke9aJToY8hMZMLLpWowmT4L2cavtYMjP4x68=
Received: by with SMTP id u21mr1011689rve.262.1218746480430; Thu, 14 Aug 2008 13:41:20 -0700 (PDT)
Received: by with HTTP; Thu, 14 Aug 2008 13:41:20 -0700 (PDT)
Message-ID: <>
Date: Thu, 14 Aug 2008 13:41:20 -0700
From: Adam Langley <>
To: Caitlin Bestler <>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <000001c8fbfe$0dba0960$292e1c20$@pt> <> <000301c8fc81$8e02d470$aa087d50$@pt> <> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3E2E@nekter> <> <78C9135A3D2ECE4B8162EBDCE82CAD77040E3F07@nekter>
X-Google-Sender-Auth: c2aa76549094ffac
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
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

On Thu, Aug 14, 2008 at 10:44 AM, Caitlin Bestler
<> wrote:
> And experience has taught me that when something looks really
> bad from a "purely theoretical" viewpoint it merely means that
> I have not yet identified the specific case where it *will*
> cause problems. So at the minimum I like to come up with
> a strong reason why something is intrinsically safe, not
> just "So far, I haven't thought of how it goes wrong."

I haven't been able to think of any case where it goes horribly wrong yet ;)

So, we're considering the case where there are no options in play.
This is a pure implementation trick.

To make it concrete, we have an SMTP server which puts "220 ESMTP\r\n" in the SYN/ACK.

If the client ACKs less than the full payload, we retransmit the
remaining bytes in the next packet.

That's not a strong reason, but I'll ponder how it could go wrong
again tonight. If you think of anything, please do say.



Adam Langley
tcpm mailing list