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

[Olivier Bonaventure <[e-mail]>]

Yoshi,

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

I’m fine to discuss the support for connections initiated by servers in another document. This would make the current draft simpler and I’m not aware of plans to support this feature currently.

2: don't support "server has feature X, but client doesn't" cases 

I think that this should be left to implementations. Converters will have local policies/heuristics to decide which options they will place in the SYN that they send to server. These policies might enable the utilisation of feature X even if it is not used by the client, but this would not cause problems.

3: clients don't directly send SYNs to server when they need converter. (no transparent mode)

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

My objective is to simplify the draft. If you think that some parts correspond to a kind of transparent mode, let me know and I will update them.

 

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 [https://tools.ietf.org/html/rfc8446" title='"The Transport Layer Security (TLS) Protocol Version 1.3"' target="_blank" class="" rel="nofollow">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. 

The converter does not process any bytestream, it only relays the bytestream from the upstream connection to the downstream one and vice versa. Once the convert TLVs have been exchanged at the beginning of the bytestream, all data sent by the client is relayed to the server and vice versa. SOCKS operates this way as well, expect that it is more chatty and uses several round-trip-times  

Olivier