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

[Yoshifumi Nishida <[e-mail]>]

Hi Med,

I put my comments,

On Mon, Feb 25, 2019 at 10:42 PM <[e-mail]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[e-mail]]
> *Envoyé :* lundi 25 février 2019 19:35
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Yoshifumi Nishida; [e-mail]
> *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
>
>
>
> Hi Med,
>
>
>
> Thanks for the updates. I have one question.
>
> When the converter does mptcp conversion and the client wants to use TLS
> for the connection, how TLS is used?
>
>
>
> [Med] TLS is managed e2e between the client and the server. The converter
> can only read/strip data that is supplied by the client for the conversion
> service. Unlike data exchanged between the client and the server, the data
> used for conversion purposes is supplied in clear between the client and
> the converter.
>
>
>
> From a functional standpoint, the establishment of TLS between the client
> and the server is similar to the establishment of such session when a
> NAT/NAT6 is on-path.
>

Yes, when the converter does non-mptcp conversion, I think the above texts
are correct.


> Does this means TLS will be used only between the converter and the
> server, but not used between the client and the converter?
>
> [Med] No. TLS is managed directly between the client and the converter.
> The scope is as follows:
>

In my understanding, in case of mptcp + TLS case, I think it should be (A)
architecture.
To be precise, it will be like this.


C------Converter-----S

<========><==========>

<========>

<========>

<========>

   TLS        TLS

So, I think it means mptcp + TLS case is out of focus for this draft.
(which is fine with me.)
Or, you can make a special exception to break end-to-end principle in this
case.
But, I think it would be good if the draft clarifies this point.


>
> In scope:
>
>
>
> C------Converter-----S
>
> <====================>
>
>          TLS
>
>
>
> Out of scope:
>
>
>
> (a)
>
>
>
> C------Converter-----S
>
> <========><==========>
>
>    TLS        TLS
>
>
>
> (b)
>
>
>
> C------Converter-----S
>
> /====================\
>
> |<=======>           |
>
> |   TLS              |
>
> \====================/
>
>          TLS
>
>
>
>
>
> Other parts look good to me.
>
>
>
> [Med] Great. These updates will be included in -06.
>
>
>
> --
>
> Yoshi
>
>
>
> On Sun, Feb 24, 2019 at 11:30 PM <[e-mail]> wrote:
>
> Hi Yoshi,
>
>
>
> I suggest to make the following modifications to the draft to clarify the
> scope as you suggested:
>
> https://github.com/obonaventure/draft-tcp-converters/pull/55/files
>
>
>
> Please let us know if these changes solve your concern ?
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* tcpm [mailto:[e-mail]] *De la part de*
> [e-mail]
> *Envoyé :* vendredi 22 février 2019 10:11
> *À :* Yoshifumi Nishida
> *Cc :* [e-mail]
> *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
>
>
>
> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[e-mail]]
> *Envoyé :* vendredi 22 février 2019 08:12
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Yoshifumi Nishida; Olivier Bonaventure; [e-mail]
> *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
>
>
>
> Hi Med,
>
>
>
> I put my comments in lines.
>
>
>
> On Wed, Feb 20, 2019 at 6:43 AM <[e-mail]> wrote:
>
> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* tcpm [mailto:[e-mail]] *De la part de* Yoshifumi
> Nishida
> *Envoyé :* mardi 19 février 2019 09:31
> *À :* Olivier Bonaventure
> *Cc :* [e-mail]
> *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
>
>
>
> Hi Olivier,
>
>
>
> Thanks for the updates. I personally think there are several points to be
> clarified in the draft.
>
>
>
> 1: It seems that there are two modes in the converter architecture. One is
> clients use server's addresses for destination and the other is clients use
> converter's addresses for destination.
>
>
>
> [Med] For connections that are eligible to the conversion service, the destination address is ALWAYS set to the one the converter. For other connections which BYPASS the converter, the client contacts the server directly. Which connections are eligible to the conversion service is policy-based. This is covered by this text:
>
>
>
>    This document does not assume that all the traffic is eligible to the
>
>    network-assisted conversion service.  Only a subset of the traffic
>
>    will be forwarded to a Transport Converter according to a set of
>
>    policies.  These policies, and how they are communicated to
>
>    endpoints, are out of scope.  Furthermore, it is possible to bypass
>
>    the Transport Converter to connect directly to the servers that
>
>    already support the required TCP extension(s).
>
>
>
> What I meant was the following sentence in the draft. Is this ok?
>
>
>
>    "When establishing a connection, the Client can, depending on local
>
>    policies, either contact the Server directly (e.g., by sending a TCP
>
>    SYN towards the Server) or create the connection via a Transport
>
>    Converter. "
>
>
>
> [Med] This text is to decide if a connection has to go via the converter.
>
>
>
>    But, clients need to use convert protocol to utilize converters. there
> won't be a transparent proxy like converter.
>
>    When I think in this way, I am wondering what's the advantages for
> clients to use server's address for their destinations.
>
>
>
> [Med] I’m not sure which case you are referring to. In order to use the
> conversion service, packets MUST be sent directly to the converter. This is
> clearly covered by this text, for example:
>
>
>
> If clients always send SYNs to converters and don't directly send them to
> servers as you mentioned, I have nothing to add.
>
> Because I personally don't see a good reason to support it in this
> proposal.
>
>
>
> [Med] Great. This comment is then fixed.
>
>
>
> ====
>
>    The Transport Converter adheres to the main principles drawn in
>
>    [RFC1919 <https://tools.ietf.org/html/rfc1919>].  In particular, a Transport Converter achieves the
>
>    following:
>
>
>
>    o  Listen for client sessions;
>
>
>
>    o  Receive from a client the address of the final target server;
>
>
>
>    o  Setup a session to the final server;
>
>
>
>    o  Relay control messages and data between the client and the server;
>
>
>
>    o  Perform access controls according to local policies.
>
> ==============
>
>
>
>    BTW, do the implementations support both modes?
>
>
>
> 2: In my understanding, this version of converter supports "client has
> feature X, but server doesn't" cases while it doesn't support "server has
> feature X, but client doesn't" cases. Or, can we do both cases? It seems to
> me this point is a bit unclear in the draft.
>
>
>
> [Med] The answer is Yes, it does even allow to negotiate some options
> directly between the client and the server:
>
>
>
> (1)
>
>
>
>    The main advantage of network-assisted conversion services is that
>
>    they enable new TCP extensions to be used on a subset of the path
>
>    between endpoints, which encourages the deployment of these
>
>    extensions.  Furthermore, the Transport Converter allows the client
>
>    and the server to directly negotiate TCP options for the sake of
>
>    native support along the full path.
>
>
>
> (2)
>
>
>
>    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.
>
>
>
>    Upon reception of an extended 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.  It MUST include the options of the 'TCP Options' subfield
>
>    in the SYN sent to the Server in addition to the TCP options that it
>
>    would have used according to its local policies.  For the TCP options
>
>    that are listed without an optional value, the Transport Converter
>
>    MUST generate its own value.  For the TCP options that are included
>
>    in the 'TCP Options' field with an optional value, it MUST copy the
>
>    entire option for use in the connection with the destination peer.
>
>    This feature is required to support TCP Fast Open.
>
>
>
> Can you please clarify what is unclear in this text? Thank you.
>
>
>
> I just thought that it might be good if we can be a bit more specific
> about what is not trying to solve.
>
> For example, in my understanding, these are not supported in this draft.
> (BTW, I think this is good thing.)
>
> 1: servers do not initiate connection to converters
>
>
>
> [Med] The document describes how this can be achieved using existing
> tools. That’s said, defining specific Convert objects to manage incoming
> connections is definitely out of scope.
>
>
>
> 2: don't support "server has feature X, but client doesn't" cases
>
>
>
> [Med] Nothing prevent this in the current spec.
>
>
>
> 3: clients don't directly send SYNs to server when they need converter.
> (no transparent mode)
>
>
>
> [Med] This is clearly mentioned in the abstract:
>
>
>
>    This specification assumes an explicit model, where the proxy is
>
>    explicitly configured on hosts.
>
>
>
> By limiting the focus, I thought we can avoid having lengthy discussions
> on nasty corner cases.
>
> We can discuss more complex architecture in future versions after we see
> this idea works well.
>
> [Med] Agree. See one item below.
>
>
>
>
>
> 3: I am not sure how TLS works when converter does mptcp conversions.
>
>     When a client have multiple subflows to a mptcp converter and use TLS
> for all subflows, can we establish an end-to-end TLS session between the
> client and the server?
>
>
>
> [Med] Establishing an e2e TLS connection in the presence of a converter is
> similar to establishing such session in the presence of CGNs. This is
> already captured in the draft:
>
>
>
>    Similar to address sharing mechanisms, the architecture does not
>
>    interfere with end-to-end TLS connections [RFC8446 <https://tools.ietf.org/html/rfc8446>] between the
>
>    Client and the Server (Figure 3).
>
>
>
> Do you see a specific problem?
>
>
>
> Please let me explain a bit more and point it out if I miss something.
>
>
>
> In case of mptcp converter, I think the connection will be like the below.
>
>
>
> 1: client and converter establishes a mptcp session and it has multiple
> subflows. (say, subflows are s1, s2, .. s5)
>
> 2: converter and server establish a single tcp connection.  (say r1)
>
>
>
> Now, if all s1 from s5 use TLS for their connections and we want to use
> TLS for r1 as well, I think the converter will need to decrypt the payloads
> in s1 .. s5 and encrypt them for r1.
>
> But, this will mean that TLS session is separated by the converter.
>
>
>
> [Med] I see. The draft focuses mainly on the case where TLS is used
> between the client and the server. Under such conditions, the behavior is
> similar to the one for handling TLS in the presence of CGNs.
>
>
>
> If TLS is to be used between the client and the converter and between the
> client and the server, this is not considered as a key requirement for the
> target deployments. Nevertheless, the document describes one first approach
> to illustrate how TLS can be used while ensuring 0-RTT proxying. That is,
> TLS is used between the client and the converter only to retrieve a Cookie
> TLV.
>
>
>
> If TLS is also to be used in proxied connections, 0-RTT TLS1.3 should be
> used between the client/converter otherwise we lose the 0-RTT proxying
> feature of the protocol. We do suggest to declare those considerations out
> of scope.
>
>
>
> An approach that can be considered when 0-RTT TLS1.3 is used, would be
> that the data to be sent to the server is governed by the e2e security
> association, while data destined explicitly to the converter are governed
> with the client/converter security association. The converter does not need
> to encrypt/decrypt data destined to the server.
>
>
>
>
>
> Thanks,
>
> --
>
> Yoshi
>
>