Subject: [tcpinc] Benoit Claise's No Objection on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

From: Benoit Claise <[email-masked]>
Date: Fri, 10 Nov 2017 00:50:18 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-tcpinc-tcpcrypt-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nothing against the publication of this document but ... as for any
experimental RFCs, we must describe the criteria for a successful experiment
(evaluation)?

---

From: Daniel B Giffin <[email-masked]>
Date: Thu, 16 Nov 2017 22:31:50 -0800

Oh right!

I've added this section:

	9.  Experiments

   Some experience will be required to determine whether the tcpcrypt
   protocol can be deployed safely and successfully across the diverse
   environments of the global internet.

   Safety means that TCP implementations that support tcpcrypt are able
   to communicate reliably in all the same settings as they would
   without tcpcrypt.  As described in [I-D.ietf-tcpinc-tcpeno]
   Section 9, this property can be subverted if middleboxes strip ENO
   options from non-SYN segments after allowing them in SYN segments; or
   if the particular communication patterns of tcpcrypt offend the
   policies of middleboxes doing deep-packet-inspection.

   Success, in addition to safety, means that hosts which implement
   tcpcrypt actually enable encryption when they connect to each other.
   This property depends on the network's treatment of the TCP-ENO
   handshake, and can be subverted if middleboxes merely strip unknown
   TCP options or if they terminate TCP connections and relay data back
   and forth unencrypted.

   Ease of implementation will be a further challenge to deployment.
   Because tcpcrypt requires encryption operations on frames that may
   span TCP segments, kernel implementations are forced to buffer
   segments in different ways than are necessary for plain TCP.  More
   implementation experience will show how much additional code
   complexity is required in various operating systems, and what kind of
   performance effects can be expected.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Nov 2017 15:37:33 +0800

Thanks.

Regards, Benoit
> .