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é : mardi 5 mars 2019 09:33
> À : BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; [e-mail]
> Objet : RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> 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.

[Med] The intent is to cover relaying data even when included in a SYN. 

The text does not mention the "corner case of the corner case" you indicated because the document targets deployments in single domains for which we assume that the MTU is well-managed. This is aligned with the reco in https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02#section-9:

   In summary:

   o  In some deployments an encapsulation can assume well-managed MTU
      hence no need for fragmentation and reassembly related to the
      encapsulation. 

Obviously, we don't have MTU issues for non-SYN and non-initial SYNs.  

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