Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp-converters ?

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Sun, 3 Dec 2017 20:05:25 +0000

Hi all,

The chairs would like to understand if there is interest in draft-bonaventure-mptcp-converters within the TCPM working group.

In principle, draft-bonaventure-mptcp-converters could be applicable to several TCP options, not only MPTCP. The assumption is that a document published by TCPM would be generic and apply not only to MPTCP. It is understood that a MPTCP-specific document could be handled in the MPTCP working group instead (which is CCed).

The TCPM charter states that the "WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility". Assisting the deployment of new TCP extensions could be understood as one way to ensure TCP's utility.

The chairs therefore ask for community feedback on whether to add a new milestone to the TCPM charter .

   Dec 2018     Submit document on TCP converters to the IESG for publication as an Experimental RFC

. and adopt draft-bonaventure-mptcp-converters as a starting point.

Please reply to this e-mail within the next three weeks if you are interested in working on this document in the TCPM working group (e.g., by contributing, reviewing) and if you support its acceptance in the TCPM working group. 

Please also speak up if you have any concerns regarding accepting this document in TCPM.

Thanks

Michael
(on behalf of the TCPM chairs)

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Sun, 3 Dec 2017 20:09:05 +0000

Now with the correct address of the MPTCP working group...

Sorry

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Scharf, Michael
> (Nokia - DE/Stuttgart)
> Sent: Sunday, December 03, 2017 9:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tcpm] Working group acceptance of draft-bonaventure-mptcp-
> converters ?
> 
> Hi all,
> 
> The chairs would like to understand if there is interest in draft-bonaventure-
> mptcp-converters within the TCPM working group.
> 
> In principle, draft-bonaventure-mptcp-converters could be applicable to
> several TCP options, not only MPTCP. The assumption is that a document
> published by TCPM would be generic and apply not only to MPTCP. It is
> understood that a MPTCP-specific document could be handled in the MPTCP
> working group instead (which is CCed).
> 
> The TCPM charter states that the "WG mostly focuses on maintenance issues
> (e.g., bug fixes) and modest changes to the protocol, algorithms, and
> interfaces that maintain TCP's utility". Assisting the deployment of new TCP
> extensions could be understood as one way to ensure TCP's utility.
> 
> Please reply to this e-mail within the next three weeks if you are interested
> in working on this document in the TCPM working group (e.g., by
> contributing, reviewing) and if you support its acceptance in the TCPM
> working group.
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 3 Dec 2017 12:30:06 -0800

> extensions could be understood as one way to ensure TCP's utility.

  "The client places the destination address and port number of the
   target Server in the payload of the SYN sent to the Converter by
   leveraging TCP Fast Open [RFC7413]."

I disagree with any use of TCP SYN payloads as anything other than
application data. At best, the mechanism attempts to re-create an
extension of TCPMUX, which was deprecated for good reason.

Additionally, this is claimed to be an application proxy, which would be
out of scope both for TCPM and to modify the definition of the contents
or directly manipulate the headers of any TCP segments.

My position is as follows:
    - I don't think this doc should be adopted by the WG
    - Whether the doc is adopted or not, I have no interest in
continuing to try to repair its significant (and IMO fatal) flaws

Joe

---

From: <[email-masked]>
Date: Mon, 4 Dec 2017 06:28:08 +0000

Hi Michael, all, 

I support adoption of the draft. 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Scharf, Michael (Nokia - DE/Stuttgart)
> Envoyé : dimanche 3 décembre 2017 21:09
> À : [email-masked]; multipathtcp
> Objet : [multipathtcp] Working group acceptance of draft-bonaventure-
> mptcp-converters ?
> 
> >    Dec 2018     Submit document on TCP converters to the IESG for
> publication
> > as an Experimental RFC
> >
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Mon, 4 Dec 2017 07:00:15 +0000

Hi Joe, 

Please see inline.

Cheers,
Med

> De : tcpm [mailto:[email-masked]] De la part de Joe Touch
> Envoyé : dimanche 3 décembre 2017 21:30
> À : Scharf, Michael (Nokia - DE/Stuttgart); [email-masked]; multipathtcp
> Objet : Re: [tcpm] [multipathtcp] Working group acceptance of draft-
> bonaventure-mptcp-converters ?
> 
> 
> 
> application data.

[Med] The data that are inserted in ONE single SYN is the application (proxy) data. What's is wrong with that? 

 At best, the mechanism attempts to re-create an
> extension of TCPMUX, which was deprecated for good reason.

[Med] I don't understand the reference to TCP tcpmux. But even if we assume there is a similarity between the two proposals, let's assess whether the technical reasons for deprecating tcpmux, as called in RFC7805, apply for the converter case:

      *  It modifies the TCP connection establishment semantics by also
         completing the three-way handshake when a service is not
         available.

Not applicable.

      *  It requires all new connections to be received on a single
         port, which limits the number of connections between two
         machines.

Only TCP connections that are eligible to a network-assistance service are forwarded to the converter, which listens on a service port. We used to have a design which does not restrict connections to be bound to a port number, but we modified the design as per your recommendation. If you now think that your recommendation was not a good advice for us, we can easily fix this.  

      *  It complicates firewall implementation and management because
         all services share the same port number.

This one is debatable because it is really deployment-specific. A deploying in 

      *  There are very limited deployments, and these are not used in
         an Internet context.  (The only reported use is for SGI's Data
         Migration Facility in private networks.)

Not applicable. 

> continuing to try to repair its significant (and IMO fatal) flaws

[Med] Joe, we have taken into account many of the comments you raised in the past (e.g., define the proposal as an application proxy, make use of a service port, better integrate with TFO). It would be helpful to list some of the "fatal flaws" so that we can determine whether these are new issues. Thank you.

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 4 Dec 2017 10:24:50 -0800

>     - I don't think this doc should be adopted by the WG
I too do not support the adoption for similar reasons above, even
though I'd love to see more usage of TFO and MPTCP.

TFO today is still facing bad middle-boxes issues and
demands extreme conservative heuristics to deploy (see last
presentation by Praveen in tcpm). Ultimately they need to be
applied by either the client or the proposed converters.

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 4 Dec 2017 18:50:40 +0000

On 2017-12-4, at 19:24, Yuchung Cheng <[email-masked]> wrote:
> On Sun, Dec 3, 2017 at 12:30 PM, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> I too do not support the adoption for similar reasons above

+1

Lars

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 4 Dec 2017 13:17:06 -0800

> applied by either the client or the proposed converters.

I am personally thinking it will be less impactful in case of this
converter, although I agree for general use of TFO.
In my understanding, the converters will be deployed inside ISPs where they
provide internet connections to their clients (in early deployment scenario)
So, I guess TFO will be used only between their client and their cloud for
this as they don't have to use TFO from the converters to servers.
--
Yoshi (with no hat)

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Dec 2017 16:35:46 -0800

Hi, Med,

On 12/3/2017 11:00 PM, [email-masked] wrote:
> ...

If this is an application layer proxy, then you have no direct control
over segment contents. The best you can say is that you write this
information to the socket. If you do that, then you are a simple TCP
service, not unlike any other TCP service which uses - but does not
alter - TCP, and not in-scope for TCPM.

To understand why intending to insert out-of-band info in the SYN is a
problem, see Sec 8.7 of draft-ietf-tcpm-tcp-edo.
>  ...

I did, above. Continuing to avoid each fatal flaw does not ensure you
will find a solution that is viable.

Joe

---

From: <[email-masked]>
Date: Tue, 5 Dec 2017 07:14:43 +0000

Hi Yucheng, 

Please see inline.

Cheers,
Med

> De : tcpm [mailto:[email-masked]] De la part de Yuchung Cheng
> Envoyé : lundi 4 décembre 2017 19:25
> À : Joe Touch
> Cc : multipathtcp; [email-masked]

[Med] I'm not sure to understand this point about "TFO today is still facing bad middle-boxes issues". Please note: 
- The proposal does not interfere with the deployment of TFO and its usage when supported by both endpoints. Better, it allows to pass safely TFO option. 
- The proposal leverages on TFO to establish 0-RTT proxied MPTCP connections. A first connection is established between the host and converter to retrieve a TFO cookie that is used for proxy-purposes. That cookie will be supplied by the host when including proxy-supplied data in a SYN of a subsequent connection.

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 5 Dec 2017 08:51:52 +0100

Yuchung,
> applied by either the client or the proposed converters.

Recent measurements show indeed that TFO does not work everywhere. 
However, there is a very large fraction of all the deployed IP networks 
where TFO works perfectly. The documented problems with TFO affect 
clients willing to use TFO to reach any server over the Internet. This 
is not the deployment scenario for the converters. Converters will 
either be deployed in networks that have been configured to support TFO 
or where clients always pass through the same (pool of) converters. In 
this case, a client can easily verify whether the path towards its 
converter is safe for TFO. If not, the conversion service would be 
disabled on this client.

Olivier

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: <[email-masked]>
Date: Tue, 5 Dec 2017 07:52:24 +0000

Hi Joe,

Please see inline. 

Cheers,
Med

> De : Joe Touch [mailto:[email-masked]]
> Envoyé : mardi 5 décembre 2017 01:36
> À : BOUCADAIR Mohamed IMT/OLN; Scharf, Michael (Nokia - DE/Stuttgart);
> [email-masked]; multipathtcp

[Med] Thank you for the pointer (which I'm very familiar with), but I failed to identify the exact text you are pointing to. 

As a reminder, the proxy-data supplied in a SYN to a converter is made after a negotiation happened between a host and a converter. So, it is safe to supply that proxy-data to the converter.

> > [Med] Joe, we have taken into account many of the comments you raised in
> the past (e.g., define the proposal as an application proxy, make use of a
> service port, better integrate with TFO). It would be helpful to list some
> of the "fatal flaws" so that we can determine whether these are new
> issues. Thank you.
> 
> I did, above.

[Med] We did also seriously considered the design to take into account your inputs. What is amazing is that some of these inputs are now presented as "flaws": e.g., the use of a service port (refer to your pointer to tcpmux) or that TFO is broken in presence of middleboxes.

 Continuing to avoid each fatal flaw does not ensure you
> will find a solution that is viable.

[Med] Listing what you think are "fatal flaws" would be natural in a technical discussion. Claiming without sharing/revealing is not helpful, IMO. Thank you.

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Dec 2017 06:39:11 -0800

Med,

Cutting to the points:

- expressing the IP/port in-band is fine; saying it is "in the SYN"
directly is not
    - as a user of TCP, an application-layer program does not have that
control

- if this is really (as you say) an application proxy" then let's assume
you just indicate "send the IP/port as the first data in the stream"
    - in that case, you are an application and not a change to TCP, so
*out of scope for* TCPM
    - in that case, you also basically undermine a given service (moving
its port AND changing its stream contents) for the purpose of increasing
use of some TCP options (this is where the history of TCPMUX RFC1078 is
useful - see RFC7805).

Either way, my view is this document should not be adopted by TCPM.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 5 Dec 2017 12:55:41 -0800

On Mon, Dec 4, 2017 at 11:51 PM, Olivier Bonaventure <
[email-masked]> wrote:

> where TFO works perfectly. The documented problems with TFO affect clients
> willing to use TFO to reach any server over the Internet. This is not the
> deployment scenario for the converters. Converters will either be deployed
> in networks that have been configured to support TFO or where clients
> always pass through the same (pool of) converters. In this case, a client
> can easily verify whether the path towards its converter is safe for TFO.
> If not, the conversion service would be disabled on this client.

Oliviier / Med:

You are right that the converters can be engineered to work well on
TFO-friendly paths, and do not interfere other TFO deployment. I was only
pointing that the middle-box issues may restrict the 0-RTT benefit. I
should make this clear: my comments about TFO isn't the reason to reject
adoption. My rationale for the objection is similar to Joe's points.

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 5 Dec 2017 22:48:23 +0000

Hi Joe, all,

Regarding "*out of scope for* TCPM":  Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. It is perfectly valid to question whether a document is indeed allowed by the current charter. Yet, keep in mind that we could also discuss rechartering TCPM if there was a need. Of course, rechartering TCPM would, amongst others, require very strong working group consensus and IESG approval.
 
The first prerequisite for any work in TCPM is clear interest, energy, and consensus in the community. For the moment, we try to understand if these requirements are fulfilled, or not.

Thanks

Michael

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, December 05, 2017 3:39 PM
> To: [email-masked]; Scharf, Michael (Nokia - DE/Stuttgart)
> <[email-masked]>; [email-masked]; multipathtcp
> <[email-masked]>
> Subject: Re: [tcpm] [multipathtcp] Working group acceptance of draft-
>     - as a user of TCP, an application-layer program does not have that control
> 
> - if this is really (as you say) an application proxy" then let's assume you just
> indicate "send the IP/port as the first data in the stream"
>     - in that case, you are an application and not a change to TCP, so *out of
> scope for* TCPM
>     - in that case, you also basically undermine a given service (moving its port
> AND changing its stream contents) for the purpose of increasing use of some
> TCP options (this is where the history of TCPMUX RFC1078 is useful - see
> RFC7805).
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Dec 2017 20:26:15 -0800

On 12/5/2017 2:48 PM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> Hi Joe, all,
>
> Regarding "*out of scope for* TCPM":  Whether a document is in scope of TCPM, or not, depends on the TCPM charter wording. 
Although I appreciate that's strictly true, I doubt the charter would
change to include "haiku development".

By the same token, IMO, this doc falls into one of two categories:

1) if, as is, it proposes direct placement of out-of-band data in the
SYN payload, I think it is a bad idea and not worth pursuing in TCPM

2) if, instead, it is corrected to explain that its use of the data
channel for proxy information is simply a conventional application data
path, then it would not be a "modification of TCP" at all (minor or
otherwise). If that isn't clearly out of scope for TCPM, I do not know
what is or ever would be (can we start haiku next, in that case?)

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 6 Dec 2017 08:47:07 +0100

Joe, Michael,

> what is or ever would be (can we start haiku next, in that case?)

The converter draft clearly defines an application level protocol that 
leverages TFO. This draft defines the format of the messages that are 
exchanged at the beginning of the bytestream in both directions. There 
is no out-of-band data in the SYN.

I guess that the main reason why our AD suggested to discuss this draft 
in the tcpm working group is that it could help the deployment of new 
TCP options. History shows that deploying news TCP options on client and 
servers is a very long process. If we can speedup or encourage this 
deployment, then this will be beneficial for TCP even if at this stage 
the main use case comes from Multipath TCP where there is a clear 
benefit in having Multipath TCP on a a subset of the end-to-end path.

I'll let the ADs comment on whether converters are in scope of a 
specific working group.

Olivier

--

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 6 Dec 2017 09:35:27 +0000

> 1) if, as is, it proposes direct placement of out-of-band data in the SYN
> payload, I think it is a bad idea and not worth pursuing in TCPM

The IETF has also decided to specify TCPINC, which also uses out-of-band data in the payload, albeit in a very different context. In the TCPINC case, the consensus was to launch a new working group, given the complexity of the protocol and the required security expertise. As far as I can see, this document would be simpler than TCPINC.

Michael

---

From: <[email-masked]>
Date: Wed, 6 Dec 2017 09:55:31 +0000

Hi Joe, 

Thank you for clarifying. This is helpful. 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 5 décembre 2017 15:39
> - if this is really (as you say) an application proxy"

[Med] I confirm. We are adhering to Section 3 of RFC1919: 
   * Listen for client sessions.
   * Receive from a client the address of the final target server.
   * Setup a session to the final server.
   * ...

 then let's assume
>     - in that case, you are an application and not a change to TCP, so

[Med] This is actually a fair comment. The document does not change TCP, sure. It is scoped initially to assist establishing MPTCP connections when servers are not MPTCP-capable while ensuring a 0-RTT proxy service and without inducing an overhead. Because some voiced that this proposal may be generalized to assist deploying other TCP options, hence this discussion. 

> use of some TCP options (this is where the history of TCPMUX RFC1078 is

[Med] I already commented on tcpmux and RFC7805. Most of items in 7805 do not apply to the converter specification. 

If the only reason is: 

I'd like to warrant that this is exactly what popular protocols are doing (e.g. SOCKS). Should the IETF obsoletes SOCKS for that? I guess, no.

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Dec 2017 06:22:35 -0800

On 12/6/2017 1:35 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> The IETF has also decided to specify TCPINC, which also uses out-of-band data in the payload, albeit in a very different context. 

TCPINC is a case study in bad decisions that IMO we should not try to
repeat, from insufficient pushback on option squatting, to use of
out-of-band data in the SYN payload, to assigning a new option to an
experimental protocol, to not actually protecting TCP itself (except in
a very small subset of control info).

In all cases, my position on these issues has not changed and I will
continue to oppose them.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Dec 2017 06:27:17 -0800

Med,

> I'd like to warrant that this is exactly what popular protocols are doing (e.g. SOCKS). Should the IETF obsoletes SOCKS for that? I guess, no.  
TCPMUX was deprecated *as part of TCP* for these reasons.

IMO, SOCKS is no better. In both cases, capable systems are better
served by a tunnel than application layer proxies that provide
insufficient alternatives, because they end up pushing Internet service
up to Layer 7, where it will eventually need to be reinvented and the
problem being solved (e.g., desire to better support TCP options) will
occur again.

However, as I said, there's no reason to avoid this approach if this
remains at the application layer, from an process perspective. It just
has no benefit or utility in being developed in TCPM.

Joe