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

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 8 Feb 2019 17:51:02 +0100

Hello,

We have uploaded a new version of draft-ietf-tcpm-converters-05 (see
 https://www.ietf.org/internet-drafts/draft-ietf-tcpm-converters-05.txt ) that includes a lot of feedback from implementors who have worked on client and server side implementations. Compared to the previous version, the main modifications are the following :

- TCP Fast Open is not strictly required anymore. Several implementors expressed concerns about this requirement. The TFO Cookie protects from some attack scenarios that affect open servers like web servers. The Convert protocol is different and as discussed in RFC7413, there are different ways to protect from such attacks. Instead of using a TFO cookie inside the TCP options, which consumes precious space in the extended TCP header, this new version supports the utilisation of a Cookie that is placed in the SYN payload. This provides the same level of protection as a TFO Cookie in environments were such protection is required.

- the Boostrap procedure has been simplified based on feedback from implementers

- Error messages are not included in RST segments anymore but sent in the bytestream. Implementors have indicated that processing such segments on clients was difficult on some platforms. This change simplifies client implementations.

- many small editorial changes to clarify the text based on implementors feedback

Chairs, we believe that the document is now stable. As the milestone was set to
December 2018, we kindly request to organize a WGLC on -05 ASAP so that
we can address issues that may arise during the call and prepare an updated 
version for the Prague meeting. 

FWIW, both the Broadband Forum and 3GPPP are working on documents that leverage the protocol proposed in this draft.  

Best regards,

Olivier and Med
-- 

Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 19 Feb 2019 00:31:01 -0800

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

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?

Thanks,
---
Yoshi

On Fri, Feb 8, 2019 at 8:51 AM Olivier Bonaventure <
[email-masked]> wrote:

>  https://www.ietf.org/internet-drafts/draft-ietf-tcpm-converters-05.txt )
> that includes a lot of feedback from implementors who have worked on client
> and server side implementations. Compared to the previous version, the main
> modifications are the following :
>
> - TCP Fast Open is not strictly required anymore. Several implementors
> expressed concerns about this requirement. The TFO Cookie protects from
> some attack scenarios that affect open servers like web servers. The
> Convert protocol is different and as discussed in RFC7413, there are
> different ways to protect from such attacks. Instead of using a TFO cookie
> inside the TCP options, which consumes precious space in the extended TCP
> header, this new version supports the utilisation of a Cookie that is
> placed in the SYN payload. This provides the same level of protection as a
> TFO Cookie in environments were such protection is required.
>
> - Error messages are not included in RST segments anymore but sent in the
> bytestream. Implementors have indicated that processing such segments on
> clients was difficult on some platforms. This change simplifies client
> implementations.
>
> FWIW, both the Broadband Forum and 3GPPP are working on documents that
> leverage the protocol proposed in this draft.
>
> Best regards,
>
> Olivier and Med
> --
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: <[email-masked]>
Date: Wed, 20 Feb 2019 14:43:09 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

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

   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:

====

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

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.

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?

Thanks,
---
Yoshi

On Fri, Feb 8, 2019 at 8:51 AM Olivier Bonaventure <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

- TCP Fast Open is not strictly required anymore. Several implementors expressed concerns about this requirement. The TFO Cookie protects from some attack scenarios that affect open servers like web servers. The Convert protocol is different and as discussed in RFC7413, there are different ways to protect from such attacks. Instead of using a TFO cookie inside the TCP options, which consumes precious space in the extended TCP header, this new version supports the utilisation of a Cookie that is placed in the SYN payload.. This provides the same level of protection as a TFO Cookie in environments were such protection is required.

Best regards,

Olivier and Med
--

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 21 Feb 2019 23:11:46 -0800

Hi Med,

I put my comments in lines.

On Wed, Feb 20, 2019 at 6:43 AM <[email-masked]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* tcpm [mailto:[email-masked]] *De la part de* Yoshifumi
> Nishida
> *Envoyé :* mardi 19 février 2019 09:31
> *À :* Olivier Bonaventure
> *Cc :* [email-masked]
> *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
>
>
>
> Hi Olivier,
>
>
>
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] 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.

====
>    [RFC1919 <https://tools.ietf.org/html/rfc1919>].  In particular, a Transport Converter achieves the
>
>    following:
>
>
>
> [Med] The answer is Yes, it does even allow to negotiate some options
> directly between the client and the server:
>
>
>
> (1)
>
>
>

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
2: don't support "server has feature X, but client doesn't" cases
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.

> [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:
>
>
>
>    interfere with end-to-end TLS connections [RFC8446 <https://tools.ietf.org/html/rfc8446>] between the
>

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.

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Fri, 22 Feb 2019 09:11:10 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : vendredi 22 février 2019 08:12
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; Olivier Bonaventure; [email-masked]
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Med,

On Wed, Feb 20, 2019 at 6:43 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Please see inline.

Cheers,
Med

De : tcpm [mailto:[email-masked]<mailto:[email-masked]>] De la part de Yoshifumi Nishida
Envoyé : mardi 19 février 2019 09:31
À : Olivier Bonaventure
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Olivier,

   Converter. "

[Med] This text is to decide if a connection has to go via the converter.

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.

====

   following:

(1)

(2)

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.

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

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

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 22 Feb 2019 10:18:29 +0100

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

The first one is clearly the most important one. I’m not aware of implementations that have explored the second case. 

>    BTW, do the implementations support both modes?

Taking MPTCP as an example, the motivation is that if the server supports MPTCP, it might be more interesting for a smartphone to establish the MPTCP connection directly to the final server. If the server does not support MPTCP, then it is better for the smartphone to establish first a connection to the converter to benefit from MPTCP in the access network. 
> 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…

The question becomes what are the options that the converter advertises in the SYN that it sends to the final server. One could imagine a converter that uses feature X for specific servers even if clients do not use it. A simple example is the timestamp option. Windows does not currently use timestamps
AFAIK while Linux uses them by default. A converter running on Linux and used by a Windows client would naturally advertise the timestamp option when interacting with a remote server. The same could apply to other options.

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

yes. TLS uses the bytestream and the 0-rtt convert protocol is fully transparent to the bytestream

Olivier

--

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 22 Feb 2019 10:37:13 +0100

Yoshi,

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.

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.

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.

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

interfere with end-to-end TLS connections [RFC8446] between the

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

---

From: <[email-masked]>
Date: Mon, 25 Feb 2019 07:30:23 +0000

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:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 22 février 2019 10:11
À : Yoshifumi Nishida
Cc : [email-masked]
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Yoshi,

Please see inline.

Cheers,
Med

Hi Med,

Please see inline.

Cheers,
Med

Hi Olivier,

   Converter. "

====

   following:

(1)

(2)

Thanks,
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 25 Feb 2019 10:35:29 -0800

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?
Does this means TLS will be used only between the converter and the server,
but not used between the client and the converter?

Other parts look good to me.
--
Yoshi

On Sun, Feb 24, 2019 at 11:30 PM <[email-masked]> wrote:

> *De :* tcpm [mailto:[email-masked]] *De la part de*
> [email-masked]
> *Envoyé :* vendredi 22 février 2019 10:11
> *À :* Yoshifumi Nishida
> *Cc :* [email-masked]
> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* vendredi 22 février 2019 08:12
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Yoshifumi Nishida; Olivier Bonaventure; [email-masked]
> [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.
>
>
>
> 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.
>
> [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
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 25 Feb 2019 10:36:27 -0800

Hi Med,

> [Med] This text is to decide if a connection has to go via the converter.
I see. I was confused. Sorry.
But, how about having more explicit texts here? something like:

When establishing a connection, the client can, depending on local
policies, choose
whether it utilizes Transport converter or not. When a Tranconvert
converter is used, the client create the connection via the converter...
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 25 Feb 2019 10:40:45 -0800

Hi Olivier,

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

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

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

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

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

---

From: <[email-masked]>
Date: Tue, 26 Feb 2019 06:42:57 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : lundi 25 février 2019 19:35
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; [email-masked]
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

[Med] Great. These updates will be included in -06.

--
Yoshi

On Sun, Feb 24, 2019 at 11:30 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Thank you.

Cheers,
Med

De : tcpm [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : vendredi 22 février 2019 10:11
À : Yoshifumi Nishida
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 22 février 2019 08:12
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; Olivier Bonaventure; [email-masked]<mailto:[email-masked]>
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Med,

Please see inline.

Cheers,
Med

Hi Olivier,

   Converter. "

====

   following:

(1)

(2)

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Tue, 26 Feb 2019 06:53:40 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : lundi 25 février 2019 19:36

Hi Med,

On Fri, Feb 22, 2019 at 1:11 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Please see inline.

Cheers,
Med

Hi Med,

Please see inline.

Cheers,
Med

Hi Olivier,

   Converter. "

When establishing a connection, the client can, depending on local  policies, choose
whether it utilizes Transport converter or not. When a Tranconvert converter is used, the client create the connection via the converter...

[Med] What about the following:

OLD:

   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.  In the latter case, the Client initiates a connection
               ^^^^^^^^^^^^^^^^^^
   towards the Transport Converter and indicates the IP address and port
   number of the Server within the connection establishment packet.
   Doing so enables the Transport Converter to immediately initiate a
   connection towards that Server, without experiencing an extra delay.
   The Transport Converter waits until the receipt of the confirmation
   that the Server agrees to establish the connection before confirming
   it to the Client.

NEW:
   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.  In the latter case (that is, the conversion service is used),
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the Client initiates a connection towards the Transport Converter
   and indicates the IP address and port number of the Server within
   the connection establishment packet. Doing so enables the Transport
   Converter to immediately initiate a connection towards that Server,
   without experiencing an extra delay. The Transport Converter waits
   until the receipt of the confirmation that the Server agrees to
   establish the connection before confirming it to the Client.

--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 27 Feb 2019 01:10:13 -0800

Hi Med,

I put my comments,

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

> *Envoyé :* lundi 25 février 2019 19:35
> *Cc :* Yoshifumi Nishida; [email-masked]
> [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?
>

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.

---

From: <[email-masked]>
Date: Wed, 27 Feb 2019 09:41:23 +0000

Hi Yoshi,

Please see inline.

Cheers,
Med

Envoyé : mercredi 27 février 2019 10:10

Hi Med,

I put my comments,

On Mon, Feb 25, 2019 at 10:42 PM <[email-masked]<mailto:[email-masked]>> wrote:

Cc : Yoshifumi Nishida; [email-masked]<mailto:[email-masked]>

Hi Med,

Yes, when the converter does non-mptcp conversion, I think the above texts are correct.
[Med] If it is OK for simple TCP, then it should be OK for MPTCP:

·         Subflows are externally seen as simple TCP connections.

·         MPTCP glue is at the TCP level.

·         The establishment of TLS between the client/server is done using the initial subflow.

·         The same external IP address is used by the converter for all subflows of a given MPTCP connection.

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

[Med] This is out of scope.

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.

[Med] We added this NEW text: ““It is out of scope of this document to elaborate on considerations related to the use of TLS in the Client-Converter connection leg to exchange conversion-supplied data”