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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Scharf, Michael [mailto:[e-mail]]
> Envoyé : lundi 4 mars 2019 12:37
> À : BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; [e-mail]
> Objet : RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> 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.)

[Med] The above applies for both non-SYN and SYNs. We can make this explicit:

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

NEW: 
     Any user data received by the Transport Converter over the upstream
     (resp., downstream) connection is relayed over the downstream (resp.,
     upstream) connection. In particular, if the initial SYN message contains
     data in its payload (e.g., [RFC7413]), that data MUST be placed 
     right after the Convert TLVs when generating the relayed SYN.

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

[Med] We can make this 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".

[Med] Deal.

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

[Med] Good point. We can update the text as follows: 

OLD: 

   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.  The
   Transport Converter MUST use by default the TCP options that
   correspond to its local policy to establish this connection.  These
   are the options that it advertises in the Supported TCP Extensions
   TLV.


NEW:

   Upon reception of a Connect TLV, and absent any policy (e.g., rate-limit) or
   resource exhaustion conditions, a Transport Converter attempts to
   establish a connection to the address and port that it contains.  The
   Transport Converter MUST use by default the TCP options that
   correspond to its local policy to establish this connection.  These
   are the options that it advertises in the Supported TCP Extensions
   TLV.


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

[Med] Actually, this is similar to hairpining for NATs (fwiw, the default behavior is MUST be enabled; see https://tools.ietf.org/html/rfc4787#section-6).    

Whether this is enabled/disabled is deployment-specific. We can add some text if you think this is helpful. 

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