Subject: Middleboxes to aid the deployment of MPTCP

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 00:22:07 +0200

Hello,

The design of Multipath TCP (RFC6824) has been heavily influenced by 
various types of interferences caused by middleboxes. These problems 
have been solved and the protocol is deployed at a large scale by 
several smartphone vendors. One of the remaining items of the charter of 
the MPTCP working group is to "...explore whether an MPTCP-aware 
middlebox would be useful, where at least one end host is MPTCP-enabled."

One of the use cases for those MPTCP-aware middleboxes are the 
smartphones equipped with WiFi and cellular interfaces. Today, there are 
very few servers that support Multipath TCP and smartphones would 
benefit from using MPTCP over the cellular and WiFi network to a 
middlebox that would convert MPTCP into TCP and vice-versa.

The working group has discussed this issue several times and today we 
have presented a new design that supports the creation of such functions 
to convert MPTCP connections into TCP connections and vice versa. The 
design was done with MPTCP in mind, but the proposed solution could be 
more generic and applied to other use cases than MPTCP. The draft that 
describes the new design is available via:

https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt

Mirja Kuehlewind suggested to send the document on the int-area and 
tsv-area mailing lists to see whether other working groups could be 
interested by this approach. I'm available this week in Prague if 
someone wants to discuss.

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: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2017 15:31:45 -0700

Hi, all,

I've noted this before, but to share with other areas:

Although I'm not averse to middleboxes as optional optimizations, I find
the proposed mechanisms aren't quite optional -- they inject option
information into the SYN data. That information would poison a
connection to a legacy receiver if (more to the point, when) that info
isn't removed by a proxy upstream of the receiver.

TCP must be E2E and fall back to legacy endpoints without a reconnection
attempt, as required by RFC793.

These aren't generic solutions; they're attacks on a TCP connection, IMO.

Joe

On 7/18/2017 3:22 PM, Olivier Bonaventure wrote:
> have presented a new design that supports the creation of such
> functions to convert MPTCP connections into TCP connections and vice
> versa. The design was done with MPTCP in mind, but the proposed
> solution could be more generic and applied to other use cases than
> MPTCP. The draft that describes the new design is available via:
>
> interested by this approach.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 18 Jul 2017 15:43:14 -0700

> These aren't generic solutions; they're attacks on a TCP connection, IMO.
I agree. This seems be akin to stateful firewalls model that impose
artificial requirements on networking (like every TCP packet for a
connection must got through some middlebox or the connection is
dropped). We need to move things back to E2E semantics for transport
protocols-- nodes that try to maintain transport state in the network
should be considered the problem not the solution!

Tom

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2017 15:49:41 -0700

> should be considered the problem not the solution!
I'm a little less concerned with state in the network (link layers have
state too - both hard and soft).

My primary concern is this as an attack on TCP - or its equivalence to
an attack. I though the point of true TCP and lower layer security was
to prevent such attacks.

Perhaps that's why I consider TLS and TCPcrypt to be so badly misnamed.
They don't protect *TCP* at all.

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 01:05:56 +0200

Joe,
> I've noted this before, but to share with other areas:

You noted this about previous documents. The document that I mentioned 
describes a new design that answers several of the comments that you 
raised on the mptcp mailing list.

> isn't removed by a proxy upstream of the receiver.

This paragraph refers to earlier documents discussed in the MPTCP
working group. The new design does not inject option information into
the SYN data. It works like an application layer protocol that sends 
messages
in the SYN by using the TFO option. There is no risk of poisoning.

Olivier

--

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2017 16:12:26 -0700

> in the SYN by using the TFO option. There is no risk of poisoning.

OK, in that case:
- I'm still not averse to middleboxes that accelerate or enhance TCP
- IMO, TCP always needs to be able to fall back (which should be true now)
- but I remain concerned with "injection piggybacking"
    - even if this is restricted to option space, it increases the risk
of damaging an otherwise working connection
    - it flies in the face of TCP being E2E, and won't work with TCP-AO
or IPsec, which IMO means it can't be considered part of "TCP" at all

Joe

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 06:37:24 +0000

Hi Tom,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:[email-masked]] De la part de Tom Herbert
> Envoyé : mercredi 19 juillet 2017 00:43
> À : Joe Touch
> Cc : [email-masked]; Internet Area
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 

[Med] We would love to avoid requiring adding a function in the network to assist devices to make use of their multiple interfaces/paths. Nevertheless, the situation is that servers do not support MPTCP. 

The proposed solution allows to:
* elect some flows to benefit from network-assisted MPTCP while avoiding session failures.
* Policies are configured to identify traffic that won't be forwarded via a proxy
* 0-RTT proxying
* MPTCP can be used e2e if both end points are MPTCP-capable (that is, the proxy is withdrawn from the path).
* No interference with TCP options to be negotiated between endpoints.

Do you have in mind such use cases when you referred to the "stateful firewalls model"?

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 06:39:51 +0000

Hi Joe,

Please see inline.

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de Joe Touch
Envoyé : mercredi 19 juillet 2017 01:12
À : Olivier Bonaventure; Internet Area; [email-masked]
Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP

This paragraph refers to earlier documents discussed in the MPTCP
working group. The new design does not inject option information into
the SYN data. It works like an application layer protocol that sends messages
in the SYN by using the TFO option. There is no risk of poisoning.

OK, in that case:
- I'm still not averse to middleboxes that accelerate or enhance TCP
[Med] The proposal leverages on existing IETF RFCs and BCPs to assist establishing communications over multiple paths even if the remote server is not MPTCP-capable. BTW, we integrated almost all the suggestions you made previously (e.g., use a dedicated service port, figure out how to use TFO to get TFO performance).

- IMO, TCP always needs to be able to fall back (which should be true now)
[Med] We are not interfering with this.

- but I remain concerned with "injection piggybacking"
    - even if this is restricted to option space, it increases the risk of damaging an otherwise working connection
[Med] I don’t understand your reference to the option space.

    - it flies in the face of TCP being E2E, and won't work with TCP-AO or IPsec, which IMO means it can't be considered part of "TCP" at all
[Med] Two comments here:

·         It seems that you assume all the traffic will be systematically relayed to a proxy. This is not the assumption we have in the mptcp WG.

·         The mechanisms you mentioned are known to have issues with NAT; extensions exist to soften some of them. I don’t see a new issue out there when it come to an network-assisted MPTCP proxy.

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 09:41:17 +0200

Joe,

> - I'm still not averse to middleboxes that accelerate or enhance TCP

We agree

> - IMO, TCP always needs to be able to fall back (which should be true now)

This is not a concern with the proposed design

> - but I remain concerned with "injection piggybacking"

To which section of the draft are you referring to ?

Olivier

--

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Jul 2017 10:30:05 +0200

> [Med] We would love to avoid requiring adding a function in the network to assist devices to make use of their multiple interfaces/paths. Nevertheless, the situation is that servers do not support…

If server infrastructures aren't supporting MPTCP, maybe that's the
thing that needs to be looked at...if in fact it can be helped.

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 08:46:38 +0000

Hi Erik,

That's the intuitive approach to follow but unfortunately the situation is not that obvious to get into. 

Network providers do not have a control on the servers and the terminals that are enabled by customers behind the CPE. So making use of MPTCP to grab more resources (when available) or to provide better resiliency (when a network attachment is lost) will require both endpoints to be MPTCP-capable. 

We are in a situation where customers are provided with multiple accesses but these customers do only have the QoE as if they are single-connected. 

The network-assisted MPTCP is a feature to have immediately the benefits of MPTCP without requiring that all terminals and servers are MPTCP-capable.

The design we are advocating for allows for the use of MPTCP along the path when both endpoints are MPTCP-capable and to bypass the proxy when it makes sense.

Cheers,
Med

> De : Erik Kline [mailto:[email-masked]]
> Envoyé : mercredi 19 juillet 2017 10:30
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Tom Herbert; Joe Touch; Internet Area; [email-masked]
> > [Med] We would love to avoid requiring adding a function in the network
> to assist devices to make use of their multiple interfaces/paths.
> Nevertheless, the situation is that servers do not support MPTCP.
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 19 Jul 2017 08:45:03 -0700

> Do you have in mind such use cases when you referred to the "stateful firewalls model"?

One of the problems with stateful firewalls (as well as transparent
proxies) is that they require all packets for a flow to consistently
traverse the same middlebox device. The middlebox is not addressed by
the packet, so the assumed requirement is that packets for the flow go
though the same network node by virtue of routing. For a firewall in a
single-homed site to the Internet this works because the firewall is
the only egress/ingress point to the network. If a site is
multi-homed, then the hope is that routing of packets in both
directions will go through the same point. But there is absolutely no
requirement that network layer packets for a flow are always routed
the same way, and if routing does change and packets need to flow
through different points the session breaks.

If I'm reading the draft correctly, then it has the same property of
maintaining transport state in the network so it implies the same
requirement that all packets for a flow follow the same path.
Personally,  would find it ironic that a a protocol to allow muli-path
transport would require the network layer to be single path.

Tom

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 17:51:17 +0200

Tom,
> though the same network node by virtue of routing. 

The proposed converter has one IP address and a reserved port number. 
Packets follow norm routing path towards this address.

> For a firewall in a
> through different points the session breaks. >

The motivation for the proposed converters is that the destination does 
not support MPTCP. To enable the client to leverage the benefits of 
MPTCP (e.g. in the access networks) the MPTCP connection is terminated 
on the converter. The client uses the different paths between it and the 
converter.

Olivier

--

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 15:57:33 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Tom Herbert [mailto:[email-masked]]
> Envoyé : mercredi 19 juillet 2017 17:45
> Cc : Joe Touch; [email-masked]; Internet Area
> the packet,

[Med] This is not the actual proposal. The proxy is explicitly configured so that all packets are sent to it directly. That is, the destination address of outgoing packets will be set to the one of that proxy.  

 so the assumed requirement is that packets for the flow go
> through different points the session breaks.

[Med] I fully agree with you. But, we are not in a transparent/implicit mode. 

> requirement that all packets for a flow follow the same path.

[Med] We don't have such requirement.  The proxy is not supposed to be on one of the default forwarding paths; all what we require is that it is reachable using any of the available paths. Subflows can be placed using any or all of the available paths.

> transport would require the network layer to be single path.

[Med] Sorry, but we don’t have such constraint/requirement. See my explanation above.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 19 Jul 2017 09:02:48 -0700

> That's the intuitive approach to follow but unfortunately the situation is not that obvious to get into.
I can give a little background on the Linux situation. There have been
several attempts to get MPTCP into the stack over the past few years.
Each time the patches were rejected primary because of complexity and
invasiveness. I believe in the initial attempt there were something
like 7,000 LOC change to tcp and that was whittled down to 5K on the
next attempt IIRC. It is not impossible to get the code in the stack,
but it's going to take more work to minimize code change and convince
the maintainer the complexity is justified.

> Network providers do not have a control on the servers and the terminals that are enabled by customers behind the CPE. So making use of MPTCP to grab more resources (when available) or to provide b…
Network providers don't control CPE is either. I know iOS has support
for MPTCP, AFAIK Android does not (Erik is that correct?). If Android
were shipping it that would be a strong datapoint towards getting
support in Linux.

Tom

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 18:16:26 +0200

Tom,

> were shipping it that would be a strong datapoint towards getting

In South Korea, at least 8 popular models of Android smartphones from at 
least two different vendors are shipped to endusers with MPTCP included 
in their kernel even if MPTCP is not yet part of the mainline Linux 
kernel. This deployment is described in
https://www.ietfjournal.org/multipath-tcp-deployments/

In June, when Apple announced that they would allow any app to use MPTCP 
in iOS11, they also mentioned that they would help to push MPTCP 
upstream in the Linux kernel. This will obvisouly require non-trivial 
engineering efforts.

Olivier

--

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 09:32:35 -0700

> This is not a concern with the proposed design 
Prove that is true if/when TCP-AO is enabled.
Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 09:35:32 -0700

On 7/19/2017 1:46 AM, [email-masked] wrote:
> So making use of MPTCP to grab more resources (when available) or to provide better resiliency (when a network attachment is lost) will require both endpoints to be MPTCP-capable. 
That is both correct and appropriate.

Doing tricks to demonstrate that an attacker (i.e., something that
modifies TCP segments on path) can do otherwise should not be considered
a viable alternative.
Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 09:43:01 -0700

> To which section of the draft are you referring to ?
It starts in the arch discussion in Sec 2:

   As shown in Figure 3, the Converter places its supplied information
   inside the handshake packets. 

That's what I refer to as "injection piggybacking"

   With TCP, the Converter protocol places the destination address and
   port number of the final Server in the payload of the SYN.

And that is the part that violates RFC793 semantics when that SYN reaches the final destination rather than the server-side proxy.

To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things.

Joe

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 18:34:56 +0000

Joe,

As mentioned in a previous message in this thread, TCP-AO extensions (6978) to pass NATs will be required otherwise TCP-AO will fail because of:

-    Manipulating multiple addresses

-    At least one of the source IP addresses will be rewritten.

The proxy design does not induce a new issue for TCP-AO.

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de Joe Touch
Envoyé : mercredi 19 juillet 2017 18:33
À : Olivier Bonaventure; Internet Area; [email-masked]
Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 18:39:24 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Joe Touch [mailto:[email-masked]]
> Envoyé : mercredi 19 juillet 2017 18:36
> À : BOUCADAIR Mohamed IMT/OLN; Erik Kline
> Cc : Tom Herbert; Internet Area; [email-masked]
> > So making use of MPTCP to grab more resources (when available) or to
> provide better resiliency (when a network attachment is lost) will require
> both endpoints to be MPTCP-capable.
[Med] OK. 

> modifies TCP segments on path) can do otherwise should not be considered

[Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay TCP packets.

---

From: <[email-masked]>
Date: Wed, 19 Jul 2017 18:43:16 +0000

Re-, 

I don't understand your argument here, especially because you are the one who proposed me the following (check mptcp archives, April 20, 2017) which we endorsed in the latest version of the specification:

"If that were the case, you'd simply be defining a new application service and asking for a TCP port number."

Are you saying that you suggested us a bad design choice?

Thank you.

Cheers,
Med

> Envoyé : mercredi 19 juillet 2017 18:43
> And that is the part that violates RFC793 semantics when that SYN reaches
> the final destination rather than the server-side proxy.
> 
> To be clear, I'm not interested in further trying to "fix" this mechanism
> so it can work. It can't and it shouldn't IMO. Let's use our cycles for
> more productive things.
> 
> Joe
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 21:37:16 +0200

> Prove that is true if/when TCP-AO is enabled.

I don't think that TCP-AO is a use case for the proposed converters. If 
an application requests TCP-AO, then it indicates that it expects 
authentication until the server. I do not see a benefit of having 
authentication on a subset of the path.

Olivier

--

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 21:40:05 +0200

Joe,
> To be clear, I'm not interested in further trying to "fix" this mechanism so it can work. It can't and it shouldn't IMO. Let's use our cycles for more productive things.

I agree that we disagree on this point. As I said in the draft, I would 
like to thank you once again for your comments that have been very 
helpful in improving the draft compared to earlier iterations.

Olivier

--

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:43:21 -0700

On 7/19/2017 11:34 AM, [email-masked] wrote:
>
> Joe,
>
>  
>
> As mentioned in a previous message in this thread, TCP-AO extensions
> (6978) to pass NATs will be required otherwise TCP-AO will fail
> because of:
>
TCP-AO-NAT is experimental.

It also has nothing to do with whether the TCP options are covered -
that's determined by the MKT on a per-connection basis, and is opaque to
on-path devices.

An on-path device that manipulates TCP options would break TCP-AO-NAT if
the MKT covers the options.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:45:01 -0700

> [Med] We are defining an application proxy that assist the user to maximize the use of its available network resources. The proxy relies on IETF defined BCPs (defined by behave and tsvwg) to relay…
Application proxies don't relay TCP segments. They don't even see TCP
segments.

And they can't work unless the client opens a connection to the proxy;
if the client opens a connection to the server, then intercepting and
modifying the TCP segments in-flight is called an attack on TCP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:45:57 -0700

> Are you saying that you suggested us a bad design choice?
The text I saw talks about SYN packets.

If this is at the application layer - and doesn't hijack TCP connections
to other IP addresses - then it's fine, but then the ID is very badly in
need of revision. I'm working off the text I saw.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:47:25 -0700

On 7/19/2017 12:37 PM, Olivier Bonaventure wrote:
> I don't think that TCP-AO is a use case for the proposed converters.

You don't get to decide that. If you use TCP, then TCP-AO could be
enabled on the client.

Joe

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Jul 2017 21:51:57 +0200

Joe,
> You don't get to decide that. If you use TCP, then TCP-AO could be

The converter is not intended to be used for all TCP connections. In the 
draft we explain how an MPTCP endpoint can bypass the converter if the 
destination server supports MPTCP. For TCP-AO, my recommendation would 
be that the default policy of the client would be to never use the 
converter if TCP-AO is requested by the application.

Olivier

--

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 12:57:46 -0700

On 7/19/2017 12:51 PM, Olivier Bonaventure wrote:
> The converter is not intended to be used for all TCP connections. In
> the draft we explain how an MPTCP endpoint can bypass the converter if
> the destination server supports MPTCP. For TCP-AO, my recommendation
> would be that the default policy of the client would be to never use
> the converter if TCP-AO is requested by the application.

How do you know you're using the converter? Is the initial connection to
that converter? Or does the converter hijack (the latter is the
implication of the text, AFAICT).

Joe

---

From: <[email-masked]>
Date: Thu, 20 Jul 2017 05:39:03 +0000

Hi Joe, 

The text can always be worked out. This is not an IETF LC :)

The main point is that we are following your suggestion to define the solution as an application proxy using a dedicated port number. 

Cheers,
Med

> Envoyé : mercredi 19 juillet 2017 21:46
> À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; tsv-
> [email-masked]
> > I don't understand your argument here, especially because you are the
> one who proposed me the following (check mptcp archives, April 20, 2017)
> which we endorsed in the latest version of the specification:
> >
> > "If that were the case, you'd simply be defining a new application
> service and asking for a TCP port number."
> >

---

From: <[email-masked]>
Date: Thu, 20 Jul 2017 05:43:49 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : mercredi 19 juillet 2017 21:58
> How do you know you're using the converter?

[Med] The converter is explicilty configured (e.g., locally configured or y means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07). 

 Is the initial connection to
> that converter?

[Med] When a connection is eligible to network-assisted MPTCP, the first subflow will be established via the converter. Subsequent flows will be established with that proxy involved. Packets are sent with destination IP address set to the one of the converter. 

 Or does the converter hijack (the latter is the

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 20 Jul 2017 08:19:03 +0200

Joe,

> implication of the text, AFAICT).

Consider a simple implementation using LD_PRELOAD to overload the 
connect system call on Linux. When the application issues connect, it 
has already set the required socket options that apply for this new 
connection. The converter implementation uses the destination address of 
the connect system call to create the TLV message and sets the TFO 
socket option to send it during its own connect with the converter. If 
the application had requested TFO, then the converter library simply 
uses the regular connect call and everything is fine.

Olivier

--

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jul 2017 07:37:20 -0700

> The text can always be worked out. This is not an IETF LC :)
Agreed - I was explaining that the current text - and many of the
responses in this chain, both from you and others, continues to be
confusing.

> The main point is that we are following your suggestion to define the solution as an application proxy using a dedicated port number.
As feedback for the doc, that could be made more explicit, including in
the title (this is an application proxy, not typically referred to as
middleboxes).

That also includes limiting the doc to using TCP app-layer APIs and
describing any behavior that *might* happen at the segment level as just
that - hypothetical, perhaps desired, but NOT the mechanism being proposed.

FWIW.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jul 2017 07:39:33 -0700

On 7/19/2017 10:43 PM, [email-masked] wrote:
> ...
AOK. If these are independent TCP connections that are explicitly
addressed, they should be described as such. The current doc implies SYN
translation - whether that's an implementation optimization (limited to
successful TFO SYNs) or not needs to be very clearly described as such
as well.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jul 2017 07:51:36 -0700

On 7/19/2017 11:19 PM, Olivier Bonaventure wrote:
> connection. The converter implementation uses the destination address
> of the connect system call to create the TLV message and sets the TFO
The Linux API is not the TCP API. The TCP API is a generic,
implementation-independent interface to upper layer protocols and
applications.

This mechanism needs to be described in terms of the TCP API.

Yes, the app can SEND data to the socketpair before the connection is
established, per RFC793 (note - I'm using 793 terms, not unix terms
here). There's nothing in RFC7413 (TFO) that confirms that TFO will
succeed on a new connection and that RFC explicitly admits it did not
introduce an API extension by which an application can read (RECEIVE)
SYN data before the connection is established:

   But the client's socket may have data available to read before it's
   connected.  This document does not cover the corresponding API
   change.

I.e., it's important to explain what you're doing using the TCP API, not
the features of an implementation (the latter can be helpful as an
example, e.g., in an appendix, though).

Joe

---

From: <[email-masked]>
Date: Thu, 20 Jul 2017 15:26:33 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 20 juillet 2017 16:37
[Med] Calling out those confusing points would help.  

> > The main point is that we are following your suggestion to define the
> solution as an application proxy using a dedicated port number.

[Med] Looks like a good idea to me.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 20 Jul 2017 08:38:51 -0700

> [Med] Looks like a good idea to me.
That use of the term middleboxes as opposed to proxy was also
confusing to me. I'd also suggest not to call this a netwotk function,
that has other connotations that don't apply here.

Tom

---

From: <[email-masked]>
Date: Thu, 20 Jul 2017 15:40:10 +0000

Good suggestion, Tom.

Thanks.

Cheers,
Med

> Envoyé : jeudi 20 juillet 2017 17:39
> Cc : Joe Touch; Olivier Bonaventure; Internet Area; [email-masked]