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

[<[e-mail]>]

Hi Michael,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Scharf, Michael [mailto:[e-mail]]
> Envoyé : lundi 4 mars 2019 16:43
> À : BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; [e-mail]
> Objet : RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> Inline [ms2] as far as not sorted out already
> 
...
> >
> > > -----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.

[Med] Agree. 

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

[Med] I added this NEW text: 

    In deployments where network-assisted connections are not allowed
    between hosts of a domain (i.e., hairpinning is not allowed), 
    the Converter may be instructed to discard such connections. Absent
    explicit configuration otherwise, hairpinning is enabled by
    the Converter (sse {{fig-hairp}}.   

> 
>  Michael