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

["Scharf, Michael" <[e-mail]>]

Hi Med,

Please also see inline [ms]. I removed the parts that seem to be sorted out.

Michael

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, March 04, 2019 7:50 AM
To: Scharf, Michael; Olivier Bonaventure; [e-mail]
Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Michael,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[e-mail]] De la part de Scharf, Michael
> Envoyé : lundi 4 mars 2019 00:48
> À : Olivier Bonaventure; [e-mail]
> 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.
 
[ms] That is pretty clear for all data in non-SYN segments. But IMHO it opens room for interpretation _when_ to relay data included in any of the SYNs and SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or whether it would be relayed after the three-way handshake. If the handling of SYN data is an internal decision of the converter implementation, IMHO the draft could call that out explicitly. (I note that w/o TFO the use of payload in SYNs should be a corner case, albeit allowed by TCP.)

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

[ms] My question is whether the converter would relay the payload data from the server's SYN, ACK to the client in
(a) the SYN,ACK after the Convert TLV
(b) separately
(c) both is possible
(d) ... or whether this does not require any text in the specification

I think I can reverse engineer from other text in the I-D that probably (a) and (b) is allowed, i.e., the answer is (c), but can't this be made more explicit?

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

[ms] IMHO it would help to make the two different usage patterns of the bytestream more explicit along the lines of your explanation, e.g., "Data added by the Convert protocol to the TCP bytestream in the upstream connection is unambiguously distinguished from payload data in the downstream connection by the total length field in the Convert messages". Also, note that in the specific context of page 13 I wonder about payload data sent in the SYN sent from the remote host to the converter, i.e., that data is destined _to the client_.
 
> - 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? 

[ms] The exact wording in -05 is: "Upon reception of a Connect TLV, and absent any rate limit policy or resource exhaustion conditions, a Transport Converter MUST attempt to establish a connection to the address and port that it contains." A later statement somehow contradicts this MUST requirement: "The Transport Converter may discard a Connect TLV request for various reasons (e.g., authorization failed, out of resources, invalid address type).". So probably the key question is why to have a capital letter MUST in the first place? Of course, this question may matter for troubleshooting. 

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

[Med] No.

[ms] Well, in my reading such a converter policy would violates the MUST cited above, albeit that may not be the intended meaning of the MUST. Actually, I believe that the security considerations in Section 7 lack a discussion of (firewall) policies on the client-facing interfaces/network of the converter. For instance, let's assume that in the client-facing network there would be firewall policies that prevent direct TCP connections between different clients, e.g., within the same Wifi network. Depending how the converter deals with connect requests to IP addresses in the client-facing network, clients could possibly use the converter to bypass firewall policies and setup "direct" communication via the converter? Isn't bypassing firewall rules something that could be relevant for Section 7?

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

[ms] See above. I really wonder about the timing of relaying data. SYN payload data would probably be used by application protocols for some specific reason (e.g., low latency delivery). The question is therefore whether the converter would care about low latency delivery, or not. Of course, SYN payload data in TCP may be a corner case, but as the Convert protocol is all about SYNs, it seems somewhat obvious to ask how exactly "normal" SYN payload data would be handled.

Michael