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

Hi Michael,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, Michael
> Envoyé : lundi 4 mars 2019 00:48
> À : Olivier Bonaventure; tcpm@ietf.org
> Objet : 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?
> 

[Med] The Converter does not track whether a client has negotiated TFO, as such any data supplied in the initial SYN is related to the server by the converter. The following rule applies: 

   Any user data received by the Transport Converter over the upstream
   (resp., downstream) connection is relayed over the downstream (resp.,
   upstream) connection.

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

[Med] Idem as above. 

> 
> - 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).

[Med] Makes sense. Updated the draft accordingly. 

> 
> - 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?

[Med] Data supplied to the converter is unambiguously distinguished from the data destined to the server. This is covered by this field: 

   The Total Length is the number of 32 bits word, including the header,
   of the bytestream that are consumed by the Convert messages.

> 
> - 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?

[Med] This is policy-based. The converter may restrict relying MPTCP connections on its customer-facing interfaces or may relax it.  
The draft can set a default behavior, though. 

>From where I sit, I'd like to allow for a possible future extension similar to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for troubleshooting purposes.  

What is your take on this? 

 In other words, a
> converter that would _not_ set up this connection back to the client would
> violate the protocol specification?

[Med] No.

> 
> - 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.

[Med] This is covered by this rule:

   Any user data received by the Transport Converter over the upstream
   (resp., downstream) connection is relayed over the downstream (resp.,
   upstream) connection.

> 
> - 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"?

[Med] If we have to change the policy, I suggest we go for "IETF Review".   

> 
> - 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?

[Med] Idem.

> 
> - 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.
> 

[Med] Good catch. 

> Editorial nits:
[Med] Wiil be fixed: https://github.com/obonaventure/draft-tcp-converters/pull/55/files  

> 
> - 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
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm