Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Olivier,

I have read -05. Please find below some comments/questions (with chair hat off):

- Page 8: Sorry if I missed this... Can a client ask the converter to send application data in the SYN payload data to the server (possibly even without TFO option)? Is it correct that the Convert protocol does not allow such use of SYN payload data towards the remote host?

- Page 8: What happens if the SYN,ACK from the server to the converter contains payload data (possibly even without TFO option)?

- Page 10: I wonder if the text on address sharing modes can be understood without having read RFC 4787 and RFC 6888 and whether they would be normative references (instead of informative references).

- Page 13: If the remote host used payload data in the SYN towards the converter (possibly even without TFO option), would this require any special handling in the converter?

- Page 18: Is my understanding correct that when a client sends a Connect TLV with one of its own addresses as "remote peer IP Address", then the transport converter MUST attempt to establish this connection? In other words, a converter that would _not_ set up this connection back to the client would violate the protocol specification?

- Page 25/26: Related to the first two comments: In this discussion on TFO handling, I wonder what would happen to actual payload data in the SYN or SYN,ACK of the connection between the converter and the remote peer.

- Page 29: "IANA is requested to create the "Convert versions" sub-registry.  New values are assigned via Standards Action." The term "Standards Action" is defined in RFC 8126 Section 4.9. I observe that this document specifies an experimental protocol. Why is the IANA policy not set e.g. to "RFC required"?

- Page 30: "The values in the range 1-127 can be assigned via Standards Action." Again, what is the reason for not using e.g. "RFC required" here?

- Page 34: Changes from 04 to -05 are not documented, e.g. the text below could be useful here

- Page 40: " A first difference is that the Convert protocol leverages the TFO option [RFC7413] to exchange all control information during the three-way handshake." That seems inconsistent with what is written below.

Editorial nits:

- Page 5: "Applicability document may _be_ defined in the future."

- Page 7: "making use of _new_ TCP extensions"

Best regards

Michael

> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Olivier Bonaventure
> Sent: Friday, February 8, 2019 5:51 PM
> To: tcpm@ietf.org
> Subject: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> Hello,
> 
> We have uploaded a new version of draft-ietf-tcpm-converters-05 (see
>  https://www.ietf.org/internet-drafts/draft-ietf-tcpm-converters-05.txt )
> that includes a lot of feedback from implementors who have worked on
> client and server side implementations. Compared to the previous version,
> the main modifications are the following :
> 
> - TCP Fast Open is not strictly required anymore. Several implementors
> expressed concerns about this requirement. The TFO Cookie protects from
> some attack scenarios that affect open servers like web servers. The Convert
> protocol is different and as discussed in RFC7413, there are different ways to
> protect from such attacks. Instead of using a TFO cookie inside the TCP
> options, which consumes precious space in the extended TCP header, this
> new version supports the utilisation of a Cookie that is placed in the SYN
> payload. This provides the same level of protection as a TFO Cookie in
> environments were such protection is required.
> 
> - the Boostrap procedure has been simplified based on feedback from
> implementers
> 
> - Error messages are not included in RST segments anymore but sent in the
> bytestream. Implementors have indicated that processing such segments on
> clients was difficult on some platforms. This change simplifies client
> implementations.
> 
> - many small editorial changes to clarify the text based on implementors
> feedback
> 
> Chairs, we believe that the document is now stable. As the milestone was set
> to
> December 2018, we kindly request to organize a WGLC on -05 ASAP so that
> we can address issues that may arise during the call and prepare an updated
> version for the Prague meeting.
> 
> FWIW, both the Broadband Forum and 3GPPP are working on documents
> that leverage the protocol proposed in this draft.
> 
> Best regards,
> 
> Olivier and Med
> --
> 
> 
> Disclaimer: https://www.tessares.net/mail-disclaimer/
> <https://www.tessares.net/mail-disclaimer/>
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm