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

[<[e-mail]>]

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.

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 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]<mailto:[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]<mailto:[e-mail]>] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : vendredi 22 février 2019 10:11
À : Yoshifumi Nishida
Cc : [e-mail]<mailto:[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]<mailto:[e-mail]>]
Envoyé : vendredi 22 février 2019 08:12
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; Olivier Bonaventure; [e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Hi Yoshi,

Please see inline.

Cheers,
Med

De : tcpm [mailto:[e-mail]<mailto:[e-mail]>] De la part de Yoshifumi Nishida
Envoyé : mardi 19 février 2019 09:31
À : Olivier Bonaventure
Cc : [e-mail]<mailto:[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