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

"Adam Langley" <> Tue, 12 August 2008 18:55 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B511328C14B; Tue, 12 Aug 2008 11:55:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3298928C14B for <>; Tue, 12 Aug 2008 11:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.327
X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ik5AGUAwsB6i for <>; Tue, 12 Aug 2008 11:55:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3AD7D28C111 for <>; Tue, 12 Aug 2008 11:55:19 -0700 (PDT)
Received: by with SMTP id b25so2440637rvf.49 for <>; Tue, 12 Aug 2008 11:55:06 -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=i0+qDJhQWpvPnkjvSj69BtBp0lZqBc41ts4e7waOI7w=; b=TA6htR4j2JmI1LuDwRc+ZqjEM+W3AS6NiOvkyPGBaKldgaN/M/5M/mUxRZkT/kPauX 6lf48MfrruCdkGDWd+oBjRPs/BZk9UkLDmiLK3PdDolUaKHl8ZJIy14lP3Uiyz3plLHR YDJSqUD/MceM6SPajhA3GeuqzfyRjfh0YpHUM=
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=apdWcfufApBuKJZVPBhge1t295tJ1Pwx2ruKI+HSQ6qU5RiLk7VjBkp4jSs50mjw1O KpTfIfYRf0dzjo6iwCMxmlFaLsph9tOPkjn+tzdgxagJEV2v4lz3WaeE3f1LBpSdwaBC GP/rr+twN36xKDenTnCTh7IhaGe/zxvX+pA44=
Received: by with SMTP id q12mr4620719rvo.260.1218567306328; Tue, 12 Aug 2008 11:55:06 -0700 (PDT)
Received: by with HTTP; Tue, 12 Aug 2008 11:55:06 -0700 (PDT)
Message-ID: <>
Date: Tue, 12 Aug 2008 11:55:06 -0700
From: Adam Langley <>
To: Sergio Freire <>
In-Reply-To: <000b01c8fc9f$4d9f3c20$e8ddb460$@pt>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <000001c8fbfe$0dba0960$292e1c20$@pt> <> <000301c8fc81$8e02d470$aa087d50$@pt> <> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt>
X-Google-Sender-Auth: 811f6ac65ad78cad
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 10:17 AM, Sergio Freire <> wrote:
> Sergio: I think it would be great to handle also additional payload. If we are changing things at this level I think it would be of great valor to handle the two cases :) I still have to look carefully at your draft.

Sadly, I don't believe that there is a good way to include extra
options space in a SYN frame in a backwards compatible manner. You're
trick of using port 0 is one such way, but obviously ties it to an
alternative port resolution scheme.

> 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
> this.
> Sergio: Actually they don't, because in that specific case the destination host would have to understand port names.

I'm suggesting that if you sent a SYN with a payload and a random
destination port to a host, that host, if the port was open, could
interpret the payload to be application level data and reply with a
SYNACK. Although you would notice that it wouldn't echo your option.

> Sergio: Right, in my thesis that was corrected. Thanks. Let me explain how segments are
> correlated: src_IP+src_port+dst_IP+dst_port. Since the destination port in SYN may be 0
> and the source port in SYNACK is always the resolved port. So, there must be another field
> to correlate, which in this case we decided to use the portname.

I understand that you've lost one of the elements of the 4-tuple that
identify a connection, I was suggesting that you could just do without
it if your source ports for conections were random. There might be a
case in which this goes wrong that I'm not thinking of right now. I
guess it is rather against the TCP spirit. Fundamentally, I don't
believe that this conflicts with my SYNACK payloads draft. The option
in the SYNACK can easilly denote the portname from the application
level data.

Also, SYN crossings are interesting with this scheme. I think they
work, but it's complicated. The ACKs, in this case, would also have to
include the portname. I think a SYN crossing where one of the sides
isn't using the portname to resolve the other goes wrong though.


Adam Langley
tcpm mailing list