[tcpinc] Benoit Claise's No Objection on draft-ietf-tcpinc-tcpeno-13: (with COMMENT)

[Benoit Claise <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-13: 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-tcpeno/



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

Nothing against the publication of this document but ... as for any
experimental RFCs, we must describe the criteria for a successful experiment
(evaluation)? Same remark for draft-ietf-tcpinc-tcpcrypt-09 I have seen section
9, which explains why this is experimental. It's only part of the info.

Note sure that everybody has seen Eric Vyncke's OPS DIR review:

The document describes an _experimental_ TCP option to negotiate at the TCP
layer the use of opportunistic encryption at layer-4 for the transparent
benefit of applications (which do not support TLS for example).

Section 4.2 describes an 'application-aware' bit which seems to tell the other
TCP party that the upper-layer are aware but to be honest the text describing
this bit could really be improved. Does it allow a responder to signal that it
supports TLS? Or something else? I like the idea of application giving hints to
the other TCP party to avoid useless double encryption but the description of
this bit is really unclear.

The specification takes really care of the TCP option size by compressing a lot
of the information pieces. I wonder whether allowing only 95 'TEP' (TCP
encryption protocols) is not a constraint... suggestion to allow a specific TEP
value signaling that the value is on 16 bits for example.

This is an experimental protocol, so, we can guess that the authors will
experiment around the following issues in order to improve the protocol:

-          Lack of authentication (and encryption without authentication has
little value) even if section 5 talks about it

-          No wording around MSS negotiation (as encryption could potentially
reduce the useful MSS)

-          The role of middle boxes will be important (see also section 8.1
where SLB proved to an annoyance), removing the ENO

-          Suggestion to also test NAT64 middle boxes
I hope this helps to improve this useful proposal