IETF Logo Mail Archive

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

"Adam Langley" <agl@imperialviolet.org> Tue, 15 July 2008 18:29 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 B53EC3A6B3A; Tue, 15 Jul 2008 11:29:20 -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 4BEA93A6B5A for <tcpm@core3.amsl.com>; Tue, 15 Jul 2008 11:29:19 -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=[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 VRBPXUyRUx+0 for <tcpm@core3.amsl.com>; Tue, 15 Jul 2008 11:29:18 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 91B603A6AF6 for <tcpm@ietf.org>; Tue, 15 Jul 2008 11:29:18 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so4708442rvf.49 for <tcpm@ietf.org>; Tue, 15 Jul 2008 11:29:46 -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=ul24djLZIahrWv9+09+rwZxQaZ1AxZH4FGCnZYtL/yk=; b=YYGdQnzAAwIm7NYwjS9Bta+46euNdFKtU2S/2ncpNry/0MtbnkUOp6udwPueG+v+VD XjH77X+mMQ57ImeAgkd7SQTt54+Z3SzW7q0kOqsxTGK0Pyb/BeGpv9nv59+0uOQjtsZs Z63TPQehPkxDk5mOOdabnFj7e+i6MyTnsMa4I=
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=dYDYe0KjI1QK3O5o1adYp9GYY1DGhDgtwKDU/HBFzoYwXARQ8i2dbVAehzLlrsE/aq aq4PzNpIkIwwN670K2QGrTgpY4qbs9eTAcNC9fMwmiumHJqA836UikOUi8LofkQRkOqd O0D1VWUbFaKSwTrrwemUlIaQc/yy0xKZQ+Y7o=
Received: by 10.141.74.18 with SMTP id b18mr7647172rvl.159.1216146585912; Tue, 15 Jul 2008 11:29:45 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Tue, 15 Jul 2008 11:29:45 -0700 (PDT)
Message-ID: <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com>
Date: Tue, 15 Jul 2008 11:29:45 -0700
From: Adam Langley <agl@imperialviolet.org>
To: Lloyd Wood <L.Wood@surrey.ac.uk>
In-Reply-To: <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk>
X-Google-Sender-Auth: e7faaf52b09507fd
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 Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood <L.Wood@surrey.ac.uk> wrote:
> This looks awfully like reinventing transactional TCP to me - and IIRC the
> reason that never got widely adopted was the increased potential for DOS
> attacks by tying up memory early on with a loaded SYN.
>
> What am I missing?

There's a short section in the draft comparing it to T/TCP, but the
quick version:
  * For a given SYN there's one bit of additional state required (and
the draft says that a host can completely ignore a SYNACK Payload
Permitted bit if it's under heavy load and using cookies etc)
  * There's no payload in the SYN, so you can't send data to an
application from an unverified source address

In short, I don't believe that any of the T/TCP objections apply to
this draft, although I could be wrong. I suggest that the similarities
with it are only superficial.

Cheers

AGL

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

v2.23.0 | Report a Bug | By Email