[tcpm] TCP Long Options

"Adam Langley" <agl@imperialviolet.org> Tue, 01 July 2008 16:49 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 C07563A691C; Tue, 1 Jul 2008 09:49:52 -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 A3DB63A691C for <tcpm@core3.amsl.com>; Tue, 1 Jul 2008 09:49:50 -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 NxUr90tkn7aE for <tcpm@core3.amsl.com>; Tue, 1 Jul 2008 09:49:48 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id B447C3A67D9 for <tcpm@ietf.org>; Tue, 1 Jul 2008 09:49:48 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so1731642rvf.49 for <tcpm@ietf.org>; Tue, 01 Jul 2008 09:49: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:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=ZIET0oRo58VShxnE+Up2GsCxuaFolux3fkGi7cL/UIM=; b=o51zwRVDbBzukusYNcAFuVHji/3XiBzMe2MtgEL0iUY40OoqHguvBOjRkSE1j7ySWL N4quigwtaO6JoL4HXWr+e0rwlRjzuhKwONG3ROJ8A2Mx1x/SweGrEAHioNlpIU5SY2jr WRSdQx7O2/qYqA2mVa8xk1IWJKM7imy97Ykbk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=umEsKKy/5yzlIrdghA5VPTVOrFL3+2Z6IbJfrTsqQ4BM4S8QCQKrkVpZJeSLmF6rQC SkPiIx8vH35IhTYulT3hjrZVYGS8LGPM3QX0UeysFJTjFWJf+ul0H7N0gqAMtN/OUL4S tvaZ7XKMH9rUV5iL93Io3dtyTMZLg2llmpCsg=
Received: by 10.141.23.7 with SMTP id a7mr3740974rvj.58.1214930997205; Tue, 01 Jul 2008 09:49:57 -0700 (PDT)
Received: by 10.141.37.3 with HTTP; Tue, 1 Jul 2008 09:49:57 -0700 (PDT)
Message-ID: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com>
Date: Tue, 01 Jul 2008 09:49:57 -0700
From: Adam Langley <agl@imperialviolet.org>
To: tcpm@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
X-Google-Sender-Auth: 3ca456172c01e9d2
Subject: [tcpm] TCP Long Options
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

I've revived an old draft, with the original author's permission: TCP
Long Options[1]

For a SYN packet with window scale, MSS, TS, SACK permitted and MD5
options (and the associated word alignment padding) we have already
filled the 40 byte option space. Not to mention that SACK permitted is
a waste in such a packet since no SACK blocks can fit in the following
frames.

TCP-AO will probably truncate the MAC by 4 bytes to add space for a
single SACK block, but even packets without authentication options
have only 20 bytes of option space left in a typical SYN [2]. This is
hampering experimentation, esp in the cryptographic space because you
can't fit even a reasonable elliptic curve key in the remaining
space[4]. Even with the current feature set, extra SACK blocks are
known to be helpful in certain situations[3].

I suggest to the working group that reaching consensus on a long
options standard would be positive for TCP.

http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt

Experimental, Linux implementation:

http://marc.info/?l=linux-netdev&m=121435555619591&w=2

Changes since 03

   1.  Change the option numbers specified to placeholders:
       "TBD-IANA-KIND1" and "TBD-IANA-KIND2".

   2.  Change the requirement that all segments include the LO option,
       if negotiated, to a SHOULD NOT unless the options require it.
       The reasoning behind the initial requirement was for
       implementation ease but, having implemented it myself, the
       ability to use the fast path processing for LO connections
       outweighs that.

   3.  Change the units of the LO option from bytes to words.  This was
       ambiguous in the 03 draft and, since padding to four bytes was
       required anyway, it seemed best to remove one extra way that the
       option could be invalid.


[1] http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt
[2] SYN options take 20 bytes in modern Linux kernels with default
sysctl settings
[3] http://portal.acm.org/citation.cfm?id=1259591.1260102&coll=GUIDE&dl=GUIDE
[4] Assuming this it isn't to be the last option ever, we leave 4
bytes of space. With the 2 byte option header, we have 14 bytes, or
112 bits for a key. Using Pollard's Rho algorithm we need 14*3 = 42
bytes to store a point. Granting the attacker only 1 PB of space
(approx cost < €200K) they can store 2**44 points, so one in 2**12
points are distinguished. So the attacker can break such a key almost
instantly: 2**12 operations on average.


AGL

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