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

"Adam Langley" <> Tue, 12 August 2008 16:15 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 1BAD828C0F5; Tue, 12 Aug 2008 09:15:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F6493A6A40 for <>; Tue, 12 Aug 2008 09:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hz0A6D9nGBXG for <>; Tue, 12 Aug 2008 09:15:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 41A213A6956 for <>; Tue, 12 Aug 2008 09:15:00 -0700 (PDT)
Received: by with SMTP id b25so2386215rvf.49 for <>; Tue, 12 Aug 2008 09:14:28 -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=NkEXp8g58UIlM7lPv0HRKJSkFNhgFL6xCxy65JUYA1c=; b=hlW5+7ELt5ALZXHFnOgHw3PqK7pQSIPLSAd9pOiGJ1jM/RepprzU6/2j8oPi2QJMAw iu+5KPsxh6Pgc0mqHMq3rg7GWGpJGkm5Mnrl1GBYhSDBnsy9xCSLFSZIQV56eNSLLlKK wgn84THCLY/kGcl1qW2pvkwdnHvcZIzBL11n8=
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=Gc511gG2vOoenJB6BdkOtxt/rx7e4Z515a/nnA5sz5g7Uh/4kT0iOnm0ttWJpnT1TC C90Ttxbv9ybXxMRHaFFwVz7zUWvv7+NdNFIEt1Oro0Jrj0XpPWIR6263S2fEdXtQbZFx cWc++2qwbiPVfteQ/ZyW3BFQslkfLaz8xFI2Q=
Received: by with SMTP id t3mr4519293rvn.124.1218557668319; Tue, 12 Aug 2008 09:14:28 -0700 (PDT)
Received: by with HTTP; Tue, 12 Aug 2008 09:14:28 -0700 (PDT)
Message-ID: <>
Date: Tue, 12 Aug 2008 09:14:28 -0700
From: Adam Langley <>
To: Sergio Freire <>
In-Reply-To: <000301c8fc81$8e02d470$aa087d50$@pt>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <000001c8fbfe$0dba0960$292e1c20$@pt> <> <000301c8fc81$8e02d470$aa087d50$@pt>
X-Google-Sender-Auth: ee9ce0214b130d61
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 Tue, Aug 12, 2008 at 6:44 AM, Sergio Freire <> wrote:
> What we intend to do is to split this two concepts and propose:
>  a) a way to extend the space available for TCP options, by reusing the payload of TCP segments
>  b) a generalization of the TCP-layer name service using the functionality provided by a)

For a) also see [1], although it doesn't do anything for including
extra data in the SYN frame.

> Sergio: I'm not sure if I've understood correctly but I think so. In our model you can establish a connection to a named service. The connection can be either established from a legacy client or from an "enhanced" portname aware client. If the connection is established from a legacy client, then it must be established to the fixed port number where the service was bound (and not 0). If the client is portname aware, then it can either establish a connection to destination port number 0 (and the given portname) or to the specific destination port number (if the service was bound to a specific port number).

Right, it's just unfortunate that a client connecting to a portname
cannot fallback to a default portnumber. (For example, connecting to
"http", but also setting the destination port to 80 for server which
don't understand that). However, I don't believe that there's any way
to do that.

> Actually changing ports during a connection raises some problems like in firewalls, NAT boxes.

Indeed, NATs strike again. I believe most of them would fail in this situation.

> We have to chose another approach like Joe Touch's suggestion of a randomly chosen destination port number at client side (see portnames draft from J.Touch).

However, if you aren't setting dport to 0 to signal that the SYN is
special, then hosts may interpret the payload of the SYN frame to be
application level data. Joe's portname draft uses options to avoid

> Sergio: No. There is payload in the SYNACK, which corresponds to the same payload we used in the SYN. We use it to correlate both packets. There was a typo bug in the initial paper in that table though. I think it's correct as it is now.

In the bottom right cell of the table, the final ACK is only acking
ISN_s + 1, should it not be ISN_s + 1 + L? (Unless the echoed data in
the SYNACK isn't acked). Also, I don't understand why you need this to
correlate the packet - you have the destination port in the SYNACK.



Adam Langley
tcpm mailing list