Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

"Scharf, Michael (Michael)" <> Tue, 25 August 2015 10:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C2571B29B3 for <>; Tue, 25 Aug 2015 03:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2XHoat81AJqt for <>; Tue, 25 Aug 2015 03:05:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A5651AD2EE for <>; Tue, 25 Aug 2015 03:05:10 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 2AB8DB543E7A6; Tue, 25 Aug 2015 10:05:06 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id t7PA51e4015801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Aug 2015 12:05:04 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 25 Aug 2015 12:05:01 +0200
From: "Scharf, Michael (Michael)" <>
To: David Mazieres <>, Stephen Farrell <>, Stephen Kent <>, "" <>
Thread-Topic: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
Date: Tue, 25 Aug 2015 10:05:01 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2015 10:05:16 -0000

> In fact, it's possible to fit a 32-byte ECDH parameter into a SYN-ACK segment today.  That means even without large SYN options, we can imagine making TCPINC zero latency.  Realistically, doing so will > require a gross hack in which TCP-ENO compactly encodes timestamp and SACK availability, window scaling, etc., in lieu of larger options.  I don't expect people would be very happy with something like > that from day one.  But we don't want to shut the door to such an optimization either, in case TCPINC becomes a runaway success.  (We've been careful to leave a bunch of reserved suboptions in the TCP-> ENO spec just in case we need extra bits for such optimizations.)

I've not followed this thread. But this discussion about long options in SYN, modifying existing TCP options, etc. really scares me. I've always thought TCPINC's objective is to provide *payload* encryption, and negotiating this should IMHO not require any complex option.

I am also confused about the actual technical details in this discussion. In my understanding, the SYN-ACK for any modern high-speed TCP stack has to carry MSS (4 bytes), windows scale (3 bytes), and SACK permitted (2 bytes). This means that at most 31 bytes are left (in theory, we have plenty of other TCP extensions consuming parts of it). Also, I believe some middleboxes/firewalls may act upon those options in the SYN-ACK, i.e., they cannot easily be replaced or encoded in a more compact way. As a result, I somehow don't understand how to get a 32 byte value into SYN-ACK without EDO (draft-ietf-tcpm-tcp-edo). And for EDO there are deployment challenges with using it in the SYN-ACK, see the discussion in TCPM.

In any case, this sort of discussion on SYN option space IMHO should be taken to the TCPM list.