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

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier,

On Fri, Feb 22, 2019 at 1:37 AM Olivier Bonaventure <
[e-mail]> wrote:

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

OK.


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

My intention was to make things simple by limiting the focus.
It is fine if you don't see any possibilities for potential nasty corner
cases by allowing this.
I just wanted to be on the safe side.

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

As I wrote in the response to Med, I personally think one text could be
updated to avoid confusion.

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

Although mptcp converter might be a special case for the converter, I am
thinking if the number of subflows in a mptcp session is more than 1,
simply relaying would not work with TLS. Please point it out if I overlook
something.

Thanks,
--
Yoshi