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

"Adam Langley" <agl@imperialviolet.org> Fri, 01 August 2008 19:23 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 AA5953A6895; Fri, 1 Aug 2008 12:23:39 -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 1FF5C3A6895 for <tcpm@core3.amsl.com>; Fri, 1 Aug 2008 12:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.207
X-Spam-Level:
X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_LWHUGE=1.54]
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 2fg-12VL+64F for <tcpm@core3.amsl.com>; Fri, 1 Aug 2008 12:23:38 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 61D823A6827 for <tcpm@ietf.org>; Fri, 1 Aug 2008 12:23:38 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1048590rvf.49 for <tcpm@ietf.org>; Fri, 01 Aug 2008 12:23:57 -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=Ekunz3QInRDMxMDDq3MHNv+QzhjzBx+r0tL1cTO0Is8=; b=eMVfdXzf+d1d7/C7tLbHi23GEtIuIAAAmGLc9IhL+IQyOxUiy3x7g1IdONPg7wpkng q0Z35LyxWbOjhxFK0HgiLn6qq3DNDU6d2UGQ/2DYJwIwEqb8YpEoOJtzERxkxpgzUdIi 24Ga0KJX0Q5a+AWbcv91atftWV4p0QC7ZQzGA=
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=IfKe8HjbF8MqzlSexhivuIXxjg/P6K7xOfnkxr5e5pyo/ZakzX0Mz5GGrNbM/WuMc1 eqfbDkkjSRUqD4c/N06k4q9BM3JCBVvBzUoa2+5v1HwT0j8qK00EOX43880qocA8YS95 R23rCeGYq9FPd+8KUutu3HKkPDKPf09nSeqkM=
Received: by 10.141.193.1 with SMTP id v1mr6133682rvp.245.1217618637292; Fri, 01 Aug 2008 12:23:57 -0700 (PDT)
Received: by 10.141.186.3 with HTTP; Fri, 1 Aug 2008 12:23:57 -0700 (PDT)
Message-ID: <396556a20808011223u57d3f4dk39b491ab5f9aa277@mail.gmail.com>
Date: Fri, 1 Aug 2008 12:23:57 -0700
From: "Adam Langley" <agl@imperialviolet.org>
To: "Matt Mathis" <mathis@psc.edu>
In-Reply-To: <Pine.LNX.4.64.0808011500230.28027@tesla.psc.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <Pine.LNX.4.64.0808011500230.28027@tesla.psc.edu>
X-Google-Sender-Auth: cd355a15d11a3399
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads (RESEND)
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 Fri, Aug 1, 2008 at 12:04 PM, Matt Mathis <mathis@psc.edu> wrote:
> Doesn't this create a huge opportunity for a DoS attack, since an attacker
> can send requests with forged from addresses, and the server has to
> burn cycles and/or commit memory, when it is never going to see the next
> packet?

The additional requirements on the server when processing a SYN under
my scheme are:
  * At most, an additional 12 bytes of state in the request sock. At
least, another 5 bytes (depending on alignment etc)
  * Generating 8 random bytes
  * Transmitting an additional 45 bytes in the SYNACK frame (3 bytes
of option + 8 random bytes + 32 bytes of elliptic curve point + 2
bytes header)

The additional storage isn't that bad. Currently, in Linux a
tcp_request_sock is 96 bytes:
(gdb) print ((struct tcp_request_sock *) 0)[1]
Cannot access memory at address 0x60

So the additional space isn't that great. Random number generation
isn't too bad either. Also, the spec explicitly says that hosts can
decide not to support it under load (e.g. if they are switching to SYN
cookies).

I did consider defining a special echo option to save on the server's
storage, but decided that I didn't think it was worth the extra
complexity.

Of course, these are subjective judgements; one might reasonably
consider that to be too much work for a SYN.


Cheers

AGL

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