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

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

Inline [ms3]

Michael

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, March 5, 2019 8:05 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 : 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.

[ms3] To be precise, it is not entirely clear to me whether the MUST is really required. But if implementers would deal with SYN payload this way, the proposed wording would work for me.

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

[ms3] Works for me

Thanks

Michael