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

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

Inline [ms2] as far as not sorted out already

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

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.

[ms2] Regarding the MUST: Theoretically, the Convert TLV plus the payload could exceed the MTU... That is probably the corner case of a corner case. In that case, I actually believe it is not entirely obvious whether to really use the SYN... Anyway, I don't have a specific preference how to handle SYN payload in the converter. My concern is mainly to be (more) explicit about the fact that payload in SYN is possible in TCP, as this is IMHO something implementers could easily get wrong.

 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.

[ms2] That works  for me

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

[ms2] I agree that this is not an entirely new problem, and I don't have any preference on whether to enable/disable this by default. Yet, I believe that some warning signs would be useful in the security consideration section. 

 Michael