Re: [tcpm] Faster application handshakes with SYN/ACK payloads

"Adam Langley" <agl@imperialviolet.org> Thu, 31 July 2008 21:19 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 E4D2228C21A; Thu, 31 Jul 2008 14:19:17 -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 1AFCC28C2BF for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 14:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Egzx2UJuTZ8t for <tcpm@core3.amsl.com>; Thu, 31 Jul 2008 14:19:16 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 5751F28C15E for <tcpm@ietf.org>; Thu, 31 Jul 2008 14:19:16 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so654901rvf.49 for <tcpm@ietf.org>; Thu, 31 Jul 2008 14:19:34 -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=JnulgKJC5vGOfx7koCz7V8NXYj/D9qfOL1MQa0i29Ao=; b=dbd0t/w1TTAaKAnJleTzs0j6MyPpAllb4Y9ES5l8sOEIeKXmYChV04VWGNvl1VvIRI KXhnRbljcMUe9ZFulfjW9Mj+ASdTqKFfb7VaU7hq2F1TeVr518ORFItbYbCp1KD5iq2j GgSIrsPUAnPRf/fGsUZj+iysB20IEdijRTlDU=
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=ltDYeDqWQgP8iPZ4n+H33cCSdE2VBD0dK1zBpyxDCk0OwITwQexX0UTF1EX+VL4ZCA OhIg9zIuQVwFR/f2E7YF8ZD415o4/NnMh18muxRhF4xoH0xlvx4LHqChB7yyZ0gkZkiu xcCO5vknB3nPxgb6NRNm1IWqWSdkuI3f60Q24=
Received: by 10.141.185.3 with SMTP id m3mr5542885rvp.40.1217539174716; Thu, 31 Jul 2008 14:19:34 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 14:19:34 -0700 (PDT)
Message-ID: <396556a20807311419n7b38dcf5x573634fab230de88@mail.gmail.com>
Date: Thu, 31 Jul 2008 14:19:34 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Murali Bashyam" <mbcoder@gmail.com>
In-Reply-To: <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com>
X-Google-Sender-Auth: c93527cc8089a800
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads
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 Thu, Jul 31, 2008 at 2:07 PM, Murali Bashyam <mbcoder@gmail.com> wrote:
> There are firewalls that drop SYN packets carrying payload, since it's
> considered anomalous behaviour (rightly so given today's end-user
> behaviour). Doesn't that defeat the purpose here? I suppose TCP options have
> been explored and ruled out for some reason?

See the section "Can't you fit the client's public value in the SYN?"
for a discussion about using options space for this.

Middleware is a quotidian worry for these sorts of proposals. I'm not
proposing that a payload be carried in the SYN packet, but rather the
SYN/ACK packet. However, you may have meant all packets with a SYN
flag set.

The spec talks about how to back off in the face of such middleware,
and I believe that's the best that can be done. Since this is an
opportunistic protocol, detection and downgrade at the client is fine.
My current implementation doesn't do it yet, but will if there's any
call for it.


Cheers,

AGL

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