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

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 3 Mar 2019 23:48:16 +0000

Hi Olivier,

I have read -05. Please find below some comments/questions (with chair hat off):

- Page 8: Sorry if I missed this... Can a client ask the converter to send application data in the SYN payload data to the server (possibly even without TFO option)? Is it correct that the Convert protocol does not allow such use of SYN payload data towards the remote host?

- Page 8: What happens if the SYN,ACK from the server to the converter contains payload data (possibly even without TFO option)?

- Page 10: I wonder if the text on address sharing modes can be understood without having read RFC 4787 and RFC 6888 and whether they would be normative references (instead of informative references).

- Page 13: If the remote host used payload data in the SYN towards the converter (possibly even without TFO option), would this require any special handling in the converter?

- Page 18: Is my understanding correct that when a client sends a Connect TLV with one of its own addresses as "remote peer IP Address", then the transport converter MUST attempt to establish this connection? In other words, a converter that would _not_ set up this connection back to the client would violate the protocol specification?

- Page 25/26: Related to the first two comments: In this discussion on TFO handling, I wonder what would happen to actual payload data in the SYN or SYN,ACK of the connection between the converter and the remote peer.

- Page 29: "IANA is requested to create the "Convert versions" sub-registry.  New values are assigned via Standards Action." The term "Standards Action" is defined in RFC 8126 Section 4.9. I observe that this document specifies an experimental protocol. Why is the IANA policy not set e.g. to "RFC required"?

- Page 30: "The values in the range 1-127 can be assigned via Standards Action." Again, what is the reason for not using e.g. "RFC required" here?

- Page 34: Changes from 04 to -05 are not documented, e.g. the text below could be useful here

- Page 40: " A first difference is that the Convert protocol leverages the TFO option [RFC7413] to exchange all control information during the three-way handshake." That seems inconsistent with what is written below.

Editorial nits:

- Page 5: "Applicability document may _be_ defined in the future."

- Page 7: "making use of _new_ TCP extensions"

Best regards

Michael

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of Olivier Bonaventure
> Sent: Friday, February 8, 2019 5:51 PM
> To: [email-masked]
> Subject: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> 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/>
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: <[email-masked]>
Date: Mon, 4 Mar 2019 06:50:28 +0000

Hi Michael,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de Scharf, Michael
> Envoyé : lundi 4 mars 2019 00:48
> À : Olivier Bonaventure; [email-masked]
> Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> Hi Olivier,
> 
> - Page 8: Sorry if I missed this... Can a client ask the converter to send
> application data in the SYN payload data to the server (possibly even without
> TFO option)? Is it correct that the Convert protocol does not allow such use
> of SYN payload data towards the remote host?
> 

[Med] The Converter does not track whether a client has negotiated TFO, as such any data supplied in the initial SYN is related to the server by the converter. The following rule applies: 

   Any user data received by the Transport Converter over the upstream
   (resp., downstream) connection is relayed over the downstream (resp.,
   upstream) connection.

> - Page 8: What happens if the SYN,ACK from the server to the converter
> contains payload data (possibly even without TFO option)?

[Med] Idem as above. 

> 
> - Page 10: I wonder if the text on address sharing modes can be understood
> without having read RFC 4787 and RFC 6888 and whether they would be normative
> references (instead of informative references).

[Med] Makes sense. Updated the draft accordingly. 

> 
> - Page 13: If the remote host used payload data in the SYN towards the
> converter (possibly even without TFO option), would this require any special
> handling in the converter?

[Med] Data supplied to the converter is unambiguously distinguished from the data destined to the server. This is covered by this field: 

   The Total Length is the number of 32 bits word, including the header,
   of the bytestream that are consumed by the Convert messages.

> 
> - Page 18: Is my understanding correct that when a client sends a Connect TLV
> with one of its own addresses as "remote peer IP Address", then the transport
> converter MUST attempt to establish this connection?

[Med] This is policy-based. The converter may restrict relying MPTCP connections on its customer-facing interfaces or may relax it.  
The draft can set a default behavior, though. 

>From where I sit, I'd like to allow for a possible future extension similar to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for troubleshooting purposes.  

What is your take on this? 

 In other words, a
> converter that would _not_ set up this connection back to the client would
> violate the protocol specification?

[Med] No.

> 
> - Page 25/26: Related to the first two comments: In this discussion on TFO
> handling, I wonder what would happen to actual payload data in the SYN or
> SYN,ACK of the connection between the converter and the remote peer.

[Med] This is covered by this rule:

   Any user data received by the Transport Converter over the upstream
   (resp., downstream) connection is relayed over the downstream (resp.,
   upstream) connection.

> 
> - Page 29: "IANA is requested to create the "Convert versions" sub-registry.
> New values are assigned via Standards Action." The term "Standards Action" is
> defined in RFC 8126 Section 4.9. I observe that this document specifies an
> experimental protocol. Why is the IANA policy not set e.g. to "RFC required"?

[Med] If we have to change the policy, I suggest we go for "IETF Review".   

> 
> - Page 30: "The values in the range 1-127 can be assigned via Standards
> Action." Again, what is the reason for not using e.g. "RFC required" here?

[Med] Idem.

> - Page 40: " A first difference is that the Convert protocol leverages the
> TFO option [RFC7413] to exchange all control information during the three-way
> handshake." That seems inconsistent with what is written below.
> 

[Med] Good catch. 

> Editorial nits:
[Med] Wiil be fixed: https://github.com/obonaventure/draft-tcp-converters/pull/55/files

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 4 Mar 2019 00:13:15 -0800

Hi Med,

I put my comment in lines.

On Wed, Feb 27, 2019 at 1:34 AM <[email-masked]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[email-masked]]
> *Envoyé :* mercredi 27 février 2019 10:10
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Yoshifumi Nishida; [email-masked]
> *Objet :* Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
>
>
>
> Hi Med,
>
>
>
> I put my comments,
>
>
>
> On Mon, Feb 25, 2019 at 10:42 PM <[email-masked]> wrote:
>
> 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.
>
>
>
> 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:
>

I don't think this is always true.
If mptcp client uses multiple subflows for the mptcp connection, how does
it looks to the server?
I believe it should be a single connection on the serve side.
But, this means when you convert mptcp into tcp, you'll need to merge
multiple TCP connections into a single TCP connection.
This merging process will not be very easy when TLS are used for subflows.

>
>
> 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.)
>
> [Med] This is out of scope.
>

ok.

>
>
> 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 to the draft :
>
>
>
> “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.”.
>

Hmm. I'm not very sure if this text can apply mptcp cases well.
I am not fully sure what is conversion-supplied data is, however, I think
mptcp case is the case where a client wants to use TLS between the client
and the server.

Thanks,
--
Yoshi

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Mar 2019 11:36:48 +0000

Hi Med,

Please also see inline [ms]. I removed the parts that seem to be sorted out.

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 04, 2019 7:50 AM
To: Scharf, Michael; Olivier Bonaventure; [email-masked]
Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Michael,

Please see inline. 

Cheers,
Med

 
[ms] That is pretty clear for all data in non-SYN segments. But IMHO it opens room for interpretation _when_ to relay data included in any of the SYNs and SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or whether it would be relayed after the three-way handshake. If the handling of SYN data is an internal decision of the converter implementation, IMHO the draft could call that out explicitly. (I note that w/o TFO the use of payload in SYNs should be a corner case, albeit allowed by TCP.)

[Med] Idem as above. 

[ms] My question is whether the converter would relay the payload data from the server's SYN, ACK to the client in
(a) the SYN,ACK after the Convert TLV
(b) separately
(c) both is possible
(d) ... or whether this does not require any text in the specification

I think I can reverse engineer from other text in the I-D that probably (a) and (b) is allowed, i.e., the answer is (c), but can't this be made more explicit?

[ms] IMHO it would help to make the two different usage patterns of the bytestream more explicit along the lines of your explanation, e.g., "Data added by the Convert protocol to the TCP bytestream in the upstream connection is unambiguously distinguished from payload data in the downstream connection by the total length field in the Convert messages". Also, note that in the specific context of page 13 I wonder about payload data sent in the SYN sent from the remote host to the converter, i.e., that data is destined _to the client_.

[ms] The exact wording in -05 is: "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." A later statement somehow contradicts this MUST requirement: "The Transport Converter may discard a Connect TLV request for various reasons (e.g., authorization failed, out of resources, invalid address type).". So probably the key question is why to have a capital letter MUST in the first place? Of course, this question may matter for troubleshooting. 

 In other words, a

[Med] No.

[ms] Well, in my reading such a converter policy would violates the MUST cited above, albeit that may not be the intended meaning of the MUST. Actually, I believe that the security considerations in Section 7 lack a discussion of (firewall) policies on the client-facing interfaces/network of the converter. For instance, let's assume that in the client-facing network there would be firewall policies that prevent direct TCP connections between different clients, e.g., within the same Wifi network. Depending how the converter deals with connect requests to IP addresses in the client-facing network, clients could possibly use the converter to bypass firewall policies and setup "direct" communication via the converter? Isn't bypassing firewall rules something that could be relevant for Section 7?

[ms] See above. I really wonder about the timing of relaying data. SYN payload data would probably be used by application protocols for some specific reason (e.g., low latency delivery). The question is therefore whether the converter would care about low latency delivery, or not. Of course, SYN payload data in TCP may be a corner case, but as the Convert protocol is all about SYNs, it seems somewhat obvious to ask how exactly "normal" SYN payload data would be handled.

Michael

---

From: <[email-masked]>
Date: Mon, 4 Mar 2019 14:42:44 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Scharf, Michael [mailto:[email-masked]]
> Envoyé : lundi 4 mars 2019 12:37
> À : BOUCADAIR Mohamed TGI/OLN; Olivier Bonaventure; [email-masked]
> Objet : RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05
> 
> Hi Med,
> 
> [Med] The Converter does not track whether a client has negotiated TFO, as
> such any data supplied in the initial SYN is related to the server by the
> converter. The following rule applies:
> 
> [ms] That is pretty clear for all data in non-SYN segments. But IMHO it opens
> room for interpretation _when_ to relay data included in any of the SYNs and
> SYN,ACK, i.e., whether it would be relayed in SYN segments as well, or
> whether it would be relayed after the three-way handshake. If the handling of
> SYN data is an internal decision of the converter implementation, IMHO the
> draft could call that out explicitly. (I note that w/o TFO the use of payload
> in SYNs should be a corner case, albeit allowed by TCP.)

[Med] The above applies for both non-SYN and SYNs. We can make this explicit:

OLD: 

NEW: 
     Any user data received by the Transport Converter over the upstream
     (resp., downstream) connection is relayed over the downstream (resp.,
     upstream) connection. In particular, if the initial SYN message contains
     data in its payload (e.g., [RFC7413]), that data MUST be placed 
     right after the Convert TLVs when generating the relayed SYN.

> I think I can reverse engineer from other text in the I-D that probably (a)
> and (b) is allowed, i.e., the answer is (c), but can't this be made more
> explicit?
> 

[Med] We can make this explicit. 

> [Med] Data supplied to the converter is unambiguously distinguished from the
> data destined to the server. This is covered by this field:
> 
> [ms] IMHO it would help to make the two different usage patterns of the
> bytestream more explicit along the lines of your explanation, e.g., "Data
> added by the Convert protocol to the TCP bytestream in the upstream
> connection is unambiguously distinguished from payload data in the downstream
> connection by the total length field in the Convert messages".

[Med] Deal.

 Also, note
> that in the specific context of page 13 I wonder about payload data sent in
> the SYN sent from the remote host to the converter, i.e., that data is
> destined _to the client_.
> 
> [Med] This is policy-based. The converter may restrict relying MPTCP
> connections on its customer-facing interfaces or may relax it.
> From where I sit, I'd like to allow for a possible future extension similar
> to what is defined for SBCs in https://tools.ietf.org/html/rfc6849 for
> troubleshooting purposes.
> 
> [ms] The exact wording in -05 is: "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." A later statement somehow contradicts this MUST requirement:
> "The Transport Converter may discard a Connect TLV request for various
> reasons (e.g., authorization failed, out of resources, invalid address
> type).". So probably the key question is why to have a capital letter MUST in
> the first place? Of course, this question may matter for troubleshooting.
> 

[Med] Good point. We can update the text as follows: 

OLD: 

   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.

NEW:

   Upon reception of a Connect TLV, and absent any policy (e.g., rate-limit) or
   resource exhaustion conditions, a Transport Converter attempts 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.

> [ms] Well, in my reading such a converter policy would violates the MUST
> cited above, albeit that may not be the intended meaning of the MUST.
> Actually, I believe that the security considerations in Section 7 lack a
> discussion of (firewall) policies on the client-facing interfaces/network of
> the converter. For instance, let's assume that in the client-facing network
> there would be firewall policies that prevent direct TCP connections between
> different clients, e.g., within the same Wifi network. Depending how the
> converter deals with connect requests to IP addresses in the client-facing
> network, clients could possibly use the converter to bypass firewall policies
> and setup "direct" communication via the converter? Isn't bypassing firewall
> rules something that could be relevant for Section 7?

[Med] Actually, this is similar to hairpining for NATs (fwiw, the default behavior is MUST be enabled; see https://tools.ietf.org/html/rfc4787#section-6).    

Whether this is enabled/disabled is deployment-specific. We can add some text if you think this is helpful. 

> [ms] See above. I really wonder about the timing of relaying data. SYN
> payload data would probably be used by application protocols for some
> specific reason (e.g., low latency delivery). The question is therefore
> whether the converter would care about low latency delivery, or not. Of
> course, SYN payload data in TCP may be a corner case, but as the Convert
> protocol is all about SYNs, it seems somewhat obvious to ask how exactly
> "normal" SYN payload data would be handled.
> 
> Michael

---

From: <[email-masked]>
Date: Mon, 4 Mar 2019 15:21:19 +0000

Yoshi,

“I don't think this is always true.
If mptcp client uses multiple subflows for the mptcp connection, how does it looks to the server?
I believe it should be a single connection on the serve side.”

The server will always see the same source address/port.

“But, this means when you convert mptcp into tcp, you'll need to merge multiple TCP connections into a single TCP connection.”

The glue is done at the TCP level by the converter.

“This merging process will not be very easy when TLS are used for subflows.”

Why? I think the disconnect is that you seem to imply that data from various segments are multiplexed in the same segment upstream.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]]
Envoyé : lundi 4 mars 2019 09:13
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; [email-masked]
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Med,

On Wed, Feb 27, 2019 at 1:34 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

Please see inline.

Cheers,
Med

De : Yoshifumi Nishida [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 27 février 2019 10:10
À : BOUCADAIR Mohamed TGI/OLN
Cc : Yoshifumi Nishida; [email-masked]<mailto:[email-masked]>
Objet : Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Hi Med,

I put my comments,

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

Please see inline.

Cheers,
Med

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

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:

I don't think this is always true.
If mptcp client uses multiple subflows for the mptcp connection, how does it looks to the server?
I believe it should be a single connection on the serve side.
But, this means when you convert mptcp into tcp, you'll need to merge multiple TCP connections into a single TCP connection.
This merging process will not be very easy when TLS are used for subflows.

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.)
[Med] This is out of scope.

ok.

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.

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

Hmm. I'm not very sure if this text can apply mptcp cases well.
I am not fully sure what is conversion-supplied data is, however, I think mptcp case is the case where a client wants to use TLS between the client and the server.

Thanks,
--
Yoshi

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Mar 2019 15:43:01 +0000

Inline [ms2] as far as not sorted out already

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 04, 2019 3:43 PM
To: Scharf, Michael; Olivier Bonaventure; [email-masked]
Subject: RE: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Re-,

Please see inline. 

Cheers,
Med

OLD: 

NEW: 

[ms2] Regarding the MUST: Theoretically, the Convert TLV plus the payload could exceed the MTU... That is probably the corner case of a corner case. In that case, I actually believe it is not entirely obvious whether to really use the SYN... Anyway, I don't have a specific preference how to handle SYN payload in the converter. My concern is mainly to be (more) explicit about the fact that payload in SYN is possible in TCP, as this is IMHO something implementers could easily get wrong.

 Also, note

OLD: 

NEW:

[ms2] That works  for me

[ms2] I agree that this is not an entirely new problem, and I don't have any preference on whether to enable/disable this by default. Yet, I believe that some warning signs would be useful in the security consideration section. 

 Michael

---

From: <[email-masked]>
Date: Tue, 5 Mar 2019 07:05:24 +0000

Hi Michael,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 4 mars 2019 16:43
...
> > > I have read -05. Please find below some comments/questions (with chair
> hat
> > > off):
> > >
> [ms2] Regarding the MUST: Theoretically, the Convert TLV plus the payload
> could exceed the MTU... That is probably the corner case of a corner case. In
> that case, I actually believe it is not entirely obvious whether to really
> use the SYN... Anyway, I don't have a specific preference how to handle SYN
> payload in the converter. My concern is mainly to be (more) explicit about
> the fact that payload in SYN is possible in TCP, as this is IMHO something
> implementers could easily get wrong.

[Med] Agree. 

> [Med] Actually, this is similar to hairpining for NATs (fwiw, the default
> behavior is MUST be enabled; see https://tools.ietf.org/html/rfc4787#section-
> 6).
> 
> [ms2] I agree that this is not an entirely new problem, and I don't have any
> preference on whether to enable/disable this by default. Yet, I believe that
> some warning signs would be useful in the security consideration section.

[Med] I added this NEW text: 

    In deployments where network-assisted connections are not allowed
    between hosts of a domain (i.e., hairpinning is not allowed), 
    the Converter may be instructed to discard such connections. Absent
    explicit configuration otherwise, hairpinning is enabled by
    the Converter (sse {{fig-hairp}}.

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 5 Mar 2019 08:32:53 +0000

Inline [ms3]

Michael

> Sent: Tuesday, March 5, 2019 8:05 AM
> > > > - Page 8: Sorry if I missed this... Can a client ask the
> converter to
> > send
> > > > application data in the SYN payload data to the server (possibly
> even
> > > without
> > > > TFO option)? Is it correct that the Convert protocol does not
> allow such
> > > use
> > > [ms] That is pretty clear for all data in non-SYN segments. But
> IMHO it
> > opens
> > > room for interpretation _when_ to relay data included in any of the
> SYNs
> > and
> > > whether it would be relayed after the three-way handshake. If the
> handling
> > of
> > > draft could call that out explicitly. (I note that w/o TFO the use
> of
> > payload

[ms3] To be precise, it is not entirely clear to me whether the MUST is really required. But if implementers would deal with SYN payload this way, the proposed wording would work for me.

> > > > - Page 18: Is my understanding correct that when a client sends a
> Connect
> > > TLV
> > > > with one of its own addresses as "remote peer IP Address", then
> the
> > > transport
> > > Converter MUST attempt to establish a connection to the address and
> port
> > that
> > > type).". So probably the key question is why to have a capital
> letter MUST
> > in
> >    Upon reception of a Connect TLV, and absent any policy (e.g.,
> rate-limit)
> > or
> > > > converter that would _not_ set up this connection back to the
> client
> > would
> > > discussion of (firewall) policies on the client-facing
> interfaces/network
> > of
> > > there would be firewall policies that prevent direct TCP
> connections
> > between
> > > network, clients could possibly use the converter to bypass
> firewall
> > policies
> > behavior is MUST be enabled; see
> https://tools.ietf.org/html/rfc4787#section-
> > 6).
> >
> > Whether this is enabled/disabled is deployment-specific. We can add
> some text
> > if you think this is helpful.
> >

[ms3] Works for me

Thanks

Michael

---

From: <[email-masked]>
Date: Tue, 5 Mar 2019 08:55:28 +0000

Re,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 5 mars 2019 09:33
> [ms3] To be precise, it is not entirely clear to me whether the MUST is
> really required. But if implementers would deal with SYN payload this way,
> the proposed wording would work for me.

[Med] The intent is to cover relaying data even when included in a SYN. 

The text does not mention the "corner case of the corner case" you indicated because the document targets deployments in single domains for which we assume that the MTU is well-managed. This is aligned with the reco in https://tools.ietf.org/html/draft-ietf-rtgwg-dt-encap-02#section-9:

   In summary:

   o  In some deployments an encapsulation can assume well-managed MTU
      hence no need for fragmentation and reassembly related to the
      encapsulation. 

Obviously, we don't have MTU issues for non-SYN and non-initial SYNs.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 14 Mar 2019 23:34:55 -0700

Hi Med,

On Mon, Mar 4, 2019 at 7:21 AM <[email-masked]> wrote:

> “But, this means when you convert mptcp into tcp, you'll need to merge
> multiple TCP connections into a single TCP connection.”
>
>
>
> Why? I think the disconnect is that you seem to imply that data from
> various segments are multiplexed in the same segment upstream.
>

Sorry for my slow response. I did some small experiments to examine this
and took some time to setup.
After I've checked, I've found the concept of the converter can work
properly with TLS.
I'm sorry for the confusion. I am now fine with the current statement on
this point.
--
Yoshi

---

From: <[email-masked]>
Date: Fri, 15 Mar 2019 07:28:37 +0000

Hi Yoshi,

Great!

Thank you for double checking.

Cheers,
Med

Envoyé : vendredi 15 mars 2019 07:35

Hi Med,

On Mon, Mar 4, 2019 at 7:21 AM <[email-masked]<mailto:[email-masked]>> wrote:
Yoshi,

Sorry for my slow response. I did some small experiments to examine this and took some time to setup.
After I've checked, I've found the concept of the converter can work properly with TLS.
I'm sorry for the confusion. I am now fine with the current statement on this point.
--
Yoshi