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

"Sergio Freire" <etfreire@ua.pt> Tue, 12 August 2008 13:45 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E436E3A6B0C; Tue, 12 Aug 2008 06:45:01 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11063A6B0C for <tcpm@core3.amsl.com>; Tue, 12 Aug 2008 06:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.315
X-Spam-Level:
X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FRT_BELOW2=2.154]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0LYxpb7-bkz for <tcpm@core3.amsl.com>; Tue, 12 Aug 2008 06:44:59 -0700 (PDT)
Received: from cgpmail.ua.pt (frontend-2.servers.ua.pt [193.136.173.3]) by core3.amsl.com (Postfix) with ESMTP id 0EF933A6A65 for <tcpm@ietf.org>; Tue, 12 Aug 2008 06:44:57 -0700 (PDT)
Received: from [85.241.152.64] (account etfreire@ua.pt HELO portsfreire) by frontend-2.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 157086896; Tue, 12 Aug 2008 14:44:36 +0100
From: Sergio Freire <etfreire@ua.pt>
To: 'Adam Langley' <agl@imperialviolet.org>
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com>
In-Reply-To: <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com>
Date: Tue, 12 Aug 2008 14:44:33 +0100
Message-ID: <000301c8fc81$8e02d470$aa087d50$@pt>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acj8CGOK21B8WkI8QwezEPBerq6ESAAc9PVg
Content-Language: pt
Cc: andre.zuquete@ua.pt, tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hi Adam,
First let me say that the paper I mentioned presents a possible solution for embedding data in the synchronization packets.
Our work mixes two concepts:
 a) use data in the segments during the three-way handshake, that in this case is somehow part of a TCP option which just signals its length
 b) a TCP-layer name service

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)

See detailed answers to your questions inline, bellow.

Regards,
Sergio





-----Original Message-----
From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam Langley
Sent: terça-feira, 12 de Agosto de 2008 0:17
To: Sergio Freire
Cc: tcpm@ietf.org; andre.zuquete@ua.pt
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01

On Mon, Aug 11, 2008 at 3:03 PM, Sergio Freire <etfreire@ua.pt> wrote:
> Meanwhile, if you can take a look at our work, it would be great for further
> discussion (regarding the way of extending tcp options and not the name
> service itself).

Somehow I've already read your paper, although don't have any idea
where I got the pointer from!

A few questions:

There's no legacy mode for active opens because the port name mode is
singled with a destination port number of 0, right?

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).
I'm forgetting on purpose the port access restrictions that we speak about in the paper, these can limit legacy connection.
So ultimately, you can have legacy and named connections.


You're taking the option number 0x45 for your length indicator. Lars
pointed out to me a few months ago that 254 and 255 are assigned for
this if you're using it over real networks.

Sergio: Well I don't think that is exactly correct. Looking at http://www.iana.org/assignments/tcp-parameters/ and RFC3692 and RFC4727, we can see that the reserved kind values are 253 and 254. These two are used for testing purposes as RFC3692 (I think for general testing purposes, not for a specific purpose). So, a new option would have to be assigned to specify a way of extending the available space for TCP options. In a first phase I guess 253 or 254 could be used for that since they are "generic", if what I've said earlier is correct.



Assuming that a SYN frame is sent to port 0, requesting a named TCP
service which the destination knows about: what's the source port
number of the resulting SYN/ACK? I think I'm reading that it's chosen
randomly.

Sergio: It's in the paper but let me clarify: at the server side you can bind a service to a certain name and to a specific port or else you may not specify the port number. In the last case the operating system assigns it a random port. So the SYNACK source port corresponds either to the specific port using during bind or to a random port chosen by the OS at bind time. 
Actually changing ports during a connection raises some problems like in firewalls, NAT boxes. 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).





From the table in 3.3 it doesn't appear that there's any SYNACK
payload, is that correct?


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.






It's unfortunate that there's no way for clients to gradually start
using such a scheme, but you can't extend the option space in SYNs
and, if you used non-0 destination ports, some hosts may enqueue the
payload.

Sergio: Well, that is the key point. We must figure out a out for that to not happen. Most OSes and TCP implementations ignore payload in the SYN or SYNACK segments. Payload in the ACK segment of the three-way handshake is generally understood. We used destination port 0 to force a RST on legacy server side TCP implementations. There are several options for not going through with a wrong connection with legacy systems... one is to assign a fixed destination port when using this "TCP option extension mechanism". If you change the sequencing numbers from the standard behavior, many stacks will drop the connection. But this is not 100% safe. The great idea is to have some way that traditional stacks drop the connection while new ones accept it.
We can discuss this latter in more detail, I was just giving a general overview of the problematic here.
 



In short, if my understanding is correct, I don't believe these two
schemes interfere, even on a single connection.

Are you intending on trying to get an option number assigned for this?


Sergio: Well, we would like to write two drafts: one for a generic way to extend the space available for TCP options and another one to specify a "name" that would be used to resolve to a certain service with that given name. I guess this corresponds to two TCP options. As I've mentioned above, the last one reuses the possibility created by our work or some other work like yours that can reuse the TCP payload.






Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm