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

"Adam Langley" <agl@imperialviolet.org> Mon, 11 August 2008 23:17 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 87C593A6DA4; Mon, 11 Aug 2008 16:17:29 -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 5CC0B3A68D6 for <tcpm@core3.amsl.com>; Mon, 11 Aug 2008 16:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 iHO5WD3KGLp0 for <tcpm@core3.amsl.com>; Mon, 11 Aug 2008 16:17:27 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 694213A6DA4 for <tcpm@ietf.org>; Mon, 11 Aug 2008 16:17:27 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2049899rvf.49 for <tcpm@ietf.org>; Mon, 11 Aug 2008 16:17:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=q2ygw9GPKoQFCRtURP+RS9bddjG9I7QniAhFTURsOXU=; b=Vc2mN2ixn9Ifgu73En0+dU0xXXMdNKbfCc9DJZJ+DcZ3//V25GPKu8JEh0rqxMVjoH h23fUpzRMNDpMHadV3H1g+mHyTna8hhLgDBg+B3xobl2p4k6oJ0kUggkG6QHSmIK9Syr sKbsjdnpICNyAw/yCuJlejKV/8KzEHwI4ggBU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; 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=NoAg9RVA/AcsnGGAghkD4eA2FkKpt2W5EAZVmcpH3GiHQDb6DZvoxXcwe7WNXTvPNo ZS5a7TEnJp1RPEd7uwgLSSL7Y+nH7sfHgBgpAe3806XppCDw4I+JIRKU4mVXzpEZOuXz j2xJQAMMmAYISYQ4WEgxteIBbu84BOQSIYd+Y=
Received: by 10.140.247.11 with SMTP id u11mr3913059rvh.37.1218496628129; Mon, 11 Aug 2008 16:17:08 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Mon, 11 Aug 2008 16:17:08 -0700 (PDT)
Message-ID: <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com>
Date: Mon, 11 Aug 2008 16:17:08 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Sergio Freire" <etfreire@ua.pt>
In-Reply-To: <000001c8fbfe$0dba0960$292e1c20$@pt>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt>
X-Google-Sender-Auth: c8acd33672f28841
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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?

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.

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.

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

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.

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?


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm