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

"Sergio Freire" <> Tue, 12 August 2008 21:37 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3DA463A6CAC; Tue, 12 Aug 2008 14:37:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8437E3A6CAC for <>; Tue, 12 Aug 2008 14:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.956
X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RKtGn5pJIoFz for <>; Tue, 12 Aug 2008 14:37:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C8D743A6C62 for <>; Tue, 12 Aug 2008 14:37:29 -0700 (PDT)
Received: from [] (account HELO portsfreire) by (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 118392266; Tue, 12 Aug 2008 22:37:12 +0100
From: Sergio Freire <>
To: 'Adam Langley' <>
References: <> <000001c8fbfe$0dba0960$292e1c20$@pt> <> <000301c8fc81$8e02d470$aa087d50$@pt> <> <000b01c8fc9f$4d9f3c20$e8ddb460$@pt> <>
In-Reply-To: <>
Date: Tue, 12 Aug 2008 22:37:09 +0100
Message-ID: <000301c8fcc3$938a8450$ba9f8cf0$@pt>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acj8rPLpJTrw3FumQuC8aYNVBeG5nQAFCD+Q
Content-Language: pt
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="utf-8"
Content-Transfer-Encoding: base64

Hi Adam.
Again, inline :)
Sergio Freire

-----Original Message-----
From: [] On Behalf Of Adam Langley
Sent: terça-feira, 12 de Agosto de 2008 19:55
To: Sergio Freire
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01

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.

Sergio: well, we must figure out the best way to achieve this. Using a destination port 0 was a solution we devised in our specific case. Again, we want to generalize this and consider other possibilities like the one depicted on my next comment.

> 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: Yeap! That is an option we are considering: resetting the connection if the SYNACK does not contain the given TCP 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.

Sergio: yes, by maintaining the connection elements (the 4-tuple) during connection solves many problems. Yet, there's a possibility of connecting to wrong services (e.g. imagine a server that is bound to some X port... the client issues a connection and the randomly chosen destination port at client side is X... this will collide with an existing service). But again, this can be "solved" looking at the SYNACK reply, for example.
About your draft, let me take a look first.

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.

Sergio: Nice that you thought about this. In fact, we didn't considered simultaneous connections mainly because nobody seems to be using them. 
Besides that, the paradigm is like a client/server model: the client tries to connect to a server which is bound to a name.
The client itself does not have a name. So, it does not make too much sense to think on this case using this paradigm, unless the connection comes from the socket server but that does not make sense.
If the client and the server both have names, then SYN crossing would make sense.


Adam Langley

tcpm mailing list