[tcpm] draft-ietf-tcpm-converter: Praveen's Comment

[<[e-mail]>]

Hi Praveen, all,

During the Prague meeting, you raised a comment about the inability of your implementation to send data in a SYN without enabling TFO.
I suggest to following change to the draft to take into account your comment:

OLD:


   Standard TCP ([RFC0793], Section 3.4<https://tools.ietf.org/html/rfc0793#section-3.4>) allows a SYN packet to carry

   data inside its payload but forbids the receiver from delivering it

   to the application until completion of the three-way-handshake.  This

   restriction was motivated by two concerns.  First, duplicate SYNs can

   cause problems for some applications that rely on TCP [RFC7413<https://tools.ietf.org/html/rfc7413>].

   Second, TCP suffers from SYN flooding attacks [RFC4987<https://tools.ietf.org/html/rfc4987>].  TCP Fast

   Open [RFC7413<https://tools.ietf.org/html/rfc7413>] solves these two problems for applications that can

   tolerate replays by using the TCP Fast Open option that includes a

   cookie.  However, the utilization of this option consumes space in

   the limited TCP extended header.  Furthermore, there are situations,

   as noted in Section 7.3 of [RFC7413]<https://tools.ietf.org/html/rfc7413#section-7.3> where it is possible to accept

   the payload of SYN packets without creating additional security risks

   such as a network where addresses cannot be spoofed and the Transport

   Converter only serves a set of hosts that are identified by these

   addresses.  For these reasons, this specification does not mandate

   the use of the TCP Fast Open option when the Client sends a

   connection establishment packet towards a Transport Converter.  The

   Convert protocol includes an optional Cookie TLV that provides

   similar protection as the TCP Fast Open option without consuming

   space in the extended TCP header.


NEW:


   Standard TCP ([RFC0793], Section 3.4<https://tools.ietf.org/html/rfc0793#section-3.4>) allows a SYN packet to carry

   data inside its payload but forbids the receiver from delivering it

   to the application until completion of the three-way-handshake.  This

   restriction was motivated by two concerns.  First, duplicate SYNs can

   cause problems for some applications that rely on TCP [RFC7413<https://tools.ietf.org/html/rfc7413>].

   Second, TCP suffers from SYN flooding attacks [RFC4987<https://tools.ietf.org/html/rfc4987>].  TCP Fast

   Open [RFC7413<https://tools.ietf.org/html/rfc7413>] solves these two problems for applications that can

   tolerate replays by using the TCP Fast Open option that includes a

   cookie.  However, the utilization of this option consumes space in

   the limited TCP extended header.  Furthermore, there are situations,

   as noted in Section 7.3 of [RFC7413]<https://tools.ietf.org/html/rfc7413#section-7.3> where it is possible to accept

   the payload of SYN packets without creating additional security risks

   such as a network where addresses cannot be spoofed and the Transport

   Converter only serves a set of hosts that are identified by these

   addresses.  For these reasons, this specification does not mandate

   the use of the TCP Fast Open option when the Client sends a

   connection establishment packet towards a Transport Converter.  The

   Convert protocol includes an optional Cookie TLV that provides

   similar protection as the TCP Fast Open option without consuming

   space in the extended TCP header.



   o  Implementation Note: For implementations which do not allow to

      insert data in the payload of a SYN without making use of TFO

      option, a cookie-less TFO mode is used.  Considerations related to

      the use of the Cookie TLV apply also for such cookie-less TFO

      mode.

Please let us know if this change addresses your concern.

Thank you.

Cheers,
Med