Subject: [multipathtcp] Consensus call on potential MPTCP proxy work

From: <[email-masked]>
Date: Tue, 18 Apr 2017 08:17:24 +0000

Hi,
During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:
--
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.
--
Please say whether you support, or don't support, such work - so we can see if there's consensus for it.
Thanks
Phil & Yoshi

Hums during the meeting:

*         Should the MPTCP WG do any MPTCP proxy work, or do none - about 2:1 or 3:1 in favour of doing work

*         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

*         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes

*         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal
Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf
We believe the work does not require an update to the MPTCP WG charter.

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 08:24:40 +0000

Hello WG,

I fully support the MPTCP proxy work.

Cheers,

Christian.

De : multipathtcp [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 18 avril 2017 10:17
À : [email-masked]
Objet : [multipathtcp] Consensus call on potential MPTCP proxy work

Hi,

Hums during the meeting:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 08:59:57 +0000

Hi Phil,

Is there any particular reason for this mention "The WG does not develop a mechanism for the two proxies to discover each other". Isn't this conflicting partly with the need for some work to be done for configuring proxies (mentioned in the sentence right before the one I'm quoting)?

Putting that aside, I fully support this proxy work.

Cheers,
Med

Hi,

Hums during the meeting:

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 06:29:33 -0700

Hi, all,

The description below isn't sufficient to determine whether this work is
either needed or safe.

My initial conclusion is that this work is either (a) not needed at all,
(b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply
(below), but I've already commented on my concerns that conclude (c)
*based on previously assuming this was intended as an IP tunnel and used
an option with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use?
True proxies are applications and can already setup MTCP themselves.
Protocols for operators to configure proxies seem out of scope here. And
if this "proxy" path is really an IP tunnel, that's a very bad idea (TCP
over TCP), which I already noted in previous discussion.

2) what does "using the payload...to transfer a signalling message"
mean? Are you using the MPTCP control plane? or the data plane of the
MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I
understand that at least one of them puts data in the SYN that is
interpreted as something other than TCP data (i.e., control plane). That
is also a very bad idea - it interferes with MPTCPs ability to silently
fall-back to TCP when talking to legacy endpoints, and the reasons for
not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo,
Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt),
which I also already noted in previous discussion.

On 4/18/2017 1:17 AM, [email-masked] wrote:
>
> Hi,
>
> During the MPTCP meeting in Chicago we did several hums about
> potential MPTCP proxy work. Our interpretation of these hums is that
> we should do a consensus call for the following work:
>
> --
> MPTCP is now seeing widespread deployment in networks to bond together
> two accesses, such as fixed and mobile broadband, by using two MPTCP
> proxies, one in the home gateway or Customer Premises Equipment and
> one in the network. The WG develops a solution where the proxies are
> both under the control of the operator and where it is assumed that
> they are not on the default path. The solution is based on using the
> payload of an MPTCP packet to transfer a signalling message between
> the proxies. It is believed the solution will not require changes to
> RFC6824bis. The solution may require a means of configuring set-up
> information in the proxies, which would be done in coordination with
> other IETF WGs such as DHC. The WG does not develop a mechanism for
> the two proxies to discover each other.
>
> --
>
> Please say whether you support, or don’t support, such work – so we
> can see if there’s consensus for it.
>
> Thanks
>
> Phil & Yoshi
>
>  
>
> Hums during the meeting:
>
> ·         Should the MPTCP WG do any MPTCP proxy work, or do none –
> about 2:1 or 3:1 in favour of doing work
>
> ·         Should the MPTCP WG do proxy work based on option #1 in
> slide 12? Strongly more yes than no
>
> ·         Should the MPTCP WG do proxy work based on option #2 in
> slide 12? more no than yes
>
> ·         Should the MPTCP WG do proxy work based on option #3 in
> slide 12? Weak & roughly equal
>
> Ref:
> https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 14:30:14 +0000

Hi Joe,

Some comments from my side :

·         The main target use case is a CPE that is connected to many networks (cellular and fixed, typically). Please refer to https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf for more business drivers.

·         In order to enhance resilience and increase resource pooling, the CPE is MPTCP-capable.

·         Because of the lack of MPTCP support at the servers side, a proxy is introduced at the network side to assisted MPTCP connections of that CPE. Let's call this proxy: network-located proxy.

·         Because the network provider does not control hosts that are located behind a given CPE, a proxy is enabled on the CPE to transform some TCP connections into MPTCP ones.

·         The CPE is configured with its network-located proxy by means of DHCP, for example.

·         As mentioned in Phil's text, the proxies are both under the control of the operator. In particular, ** both ** the CPE and the network-proxy support the mechanism detailed hereafter (that is parse and strip any supplied data before forwarding upstream).

·         There is no tunnel/encapsulation at all. As such there is no ** TCP over TCP ** scheme. All is about plain transport mode.

o    The CPE forwards MPTCP connections it creates to its configured network-located proxy. This is exactly the same as with the data plane of SOCKS.

o    In order to inform its proxy about the ultimate destination IP address/port while ensuring 0-RTT, an information element is inserted in the payload of the SYN message of the initial subflow.

o    That information is stripped by the network-located proxy before forwarding the packet to its ultimate server.

o    In order to strengthen the solution, that information must be echoed by the proxy in the SYN/ACK as a guard against misconfigured proxies.

o    The information echoed in the SYN/ACK is used by the CPE to double check that the network-proxy complies with the solution. If not, no further MPTCP connection is established with that proxy till a TTL expires or a new proxy is configured.

o    More details can be found at https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

So:

·         "(TCP over TCP), which I already noted in previous discussion." WAS NEVER proposed.

·         The proposal does not "interfere with MPTCP's ability to silently fall-back to TCP when talking to legacy endpoints". Legacy endpoints that receive an MP_CAPABLE option (whether from an MPTCP-capable client or via a proxy) will ignore it and silently fall back to TCP. I don't see a problem here.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Joe Touch
Envoyé : mardi 18 avril 2017 15:30
À : [email-masked]; [email-masked]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Hi, all,

The description below isn't sufficient to determine whether this work is either needed or safe.

My initial conclusion is that this work is either (a) not needed at all, (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (below), but I've already commented on my concerns that conclude (c) *based on previously assuming this was intended as an IP tunnel and used an option with control plane info in the SYN data) so I won't repeat them.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use? True proxies are applications and can already setup MTCP themselves. Protocols for operators to configure proxies seem out of scope here. And if this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous discussion.

2) what does "using the payload...to transfer a signalling message" mean? Are you using the MPTCP control plane? or the data plane of the MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I understand that at least one of them puts data in the SYN that is interpreted as something other than TCP data (i.e., control plane). That is also a very bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and the reasons for not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in previous discussion.
On 4/18/2017 1:17 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi,

Hums during the meeting:

[email-masked]<mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 08:01:03 -0700

Mohammed,

I'm sorry, but when you talk about CPEs and network interconnection,
you're clearly talking (AFAICT) about using MPTCP as an IP tunnel.

That leads to TCP over TCP (where the first is inside the IP packets
you're transiting).

If that's what you're doing, it is a mistake. Layered congestion control
is never beneficial.

Joe

On 4/18/2017 7:30 AM, [email-masked] wrote:
> ·         The main target use case is a CPE that is connected to many
> networks (cellular and fixed, typically). Please refer to
> https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf
> for more business drivers.
>
> ·         Because of the lack of MPTCP support at the servers side, a
> proxy is introduced at the network side to assisted MPTCP connections
> of that CPE. Let’s call this proxy: network-located proxy.
>
> ·         Because the network provider does not control hosts that are
> located behind a given CPE, a proxy is enabled on the CPE to transform
> some TCP connections into MPTCP ones.
>
> ·         As mentioned in Phil’s text, the proxies are both under the
> control of the operator. In particular, ** both ** the CPE and the
> network-proxy support the mechanism detailed hereafter (that is parse
> and strip any supplied data before forwarding upstream).  
>
> ·         There is no tunnel/encapsulation at all. As such there is no
> ** TCP over TCP ** scheme. All is about plain transport mode.  
>
> o    The CPE forwards MPTCP connections it creates to its configured
> network-located proxy. This is exactly the same as with the data plane
> of SOCKS.
>
> o    In order to inform its proxy about the ultimate destination IP
> address/port while ensuring 0-RTT, an information element is inserted
> in the payload of the SYN message of the initial subflow.
>
> o    That information is stripped by the network-located proxy before
> forwarding the packet to its ultimate server.
>
> o    In order to strengthen the solution, that information must be
> echoed by the proxy in the SYN/ACK as a guard against misconfigured
> proxies.
>
> o    The information echoed in the SYN/ACK is used by the CPE to
> double check that the network-proxy complies with the solution. If
> not, no further MPTCP connection is established with that proxy till a
> TTL expires or a new proxy is configured.
>
> o    More details can be found at
> https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
>
>
>  
>
> So:
>
> ·         “(TCP over TCP), which I already noted in previous
> discussion.” WAS NEVER proposed.   
>
> ·         The proposal does not “interfere with MPTCP’s ability to
> silently fall-back to TCP when talking to legacy endpoints”. Legacy
> endpoints that receive an MP_CAPABLE option (whether from an
> MPTCP-capable client or via a proxy) will ignore it and silently fall
> back to TCP. I don’t see a problem here.
>
>  
>
> Cheers,
>
> Med
>
>  
>
> *De :*multipathtcp [mailto:[email-masked]] *De la part
> de* Joe Touch
> *Envoyé :* mardi 18 avril 2017 15:30
> *À :* [email-masked]; [email-masked]
> *Objet :* Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>
>  
>
> Hi, all,
>
> My initial conclusion is that this work is either (a) not needed at
> all, (b) out of scope, or (c) involves one if not two very bad ideas.
>
> *based on previously assuming this was intended as an IP tunnel and
> used an option with control plane info in the SYN data) so I won't
> repeat them.
>
> 1) what is the reason for needing MPTCP work to support proxy-proxy
> use? True proxies are applications and can already setup MTCP
> themselves. Protocols for operators to configure proxies seem out of
> scope here. And if this "proxy" path is really an IP tunnel, that's a
> very bad idea (TCP over TCP), which I already noted in previous
> discussion.
>
> interpreted as something other than TCP data (i.e., control plane).
> That is also a very bad idea - it interferes with MPTCPs ability to
> silently fall-back to TCP when talking to legacy endpoints, and the
> reasons for not using TCP data as control are discussed in
> draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for
> draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in
> previous discussion.
>
> [email-masked] <mailto:[email-masked]>

---

From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[email-masked]>
Date: Tue, 18 Apr 2017 15:39:29 +0000

Hi Phil, all,

I have a clarifying question about dual proxy work.

Does the dual proxy solution have the ability to support native MPTCP at the client and server, or is the assumption that the solution forces the two proxies to become part of a connection regardless of whether the client and server are MPTCP enabled?

Thanks,
Matt

> On Apr 18, 2017, at 4:17 AM, [email-masked] wrote:
> 
> Hi,
> Please say whether you support, or don’t support, such work – so we can see if there’s consensus for it.
>

---

From: Stefano Secci <[email-masked]>
Date: Tue, 18 Apr 2017 18:37:12 +0200

Hello WG,

I do support the MPTCP proxy work.

Cheers,
Stefano

> Le 18 avr. 2017 à 10:17, [email-masked] a écrit :
> 
> Hi,
> ·         Should the MPTCP WG do any MPTCP proxy work, or do none – about 2:1 or 3:1 in favour of doing work
> 
> ·         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no
> 
> ·         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes
> 
> ·         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal
> 
> Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf <https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Apr 2017 20:14:08 +0200

> (b) out of scope, or (c) involves one if not two very bad ideas.

Very well put.  I'll add two more points.

First, the plain mode draft requires doing some fairly low-level things,
such as proxying a SYN and the corresponding SYN-ACK separately.  This is
not mere transport-layer proxying, and feels way too close to NAT for my
comfort.  Since in at least some deployments the plain mode proxy is
on-path, and cannot be easily circumvented by the client, it will cause
all the problems with middleboxes that this particular group is so sadly
acquainted with.

If we're going to do NAT for IPv6, then perhaps we shouldn't be doing it
in this group.  Or at all.

Second, I don't understand whether this work is specific to MPTCP.  As far
as I understand, the proposal is about interception proxying at the
transport layer, and does not rely on MPTCP: the link between the proxies
could very well be using SCTP, or MP-QUIC, or whatever the next fashionable
multipath protocol will be.  As such, I'm not sure it's in scope.

I'm opposed to this work, at least pending further clarification.

-- Juliusz

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 18 Apr 2017 20:44:17 +0000

If the client and server support mptcp the proxies should not end up in the path, so it will be transparent E2E

On 18/04/2017, 17:39, "multipathtcp on behalf of Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Phil, all,

    
    Thanks,
    Matt

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 18 Apr 2017 14:44:45 -0700

Hi Joe,

It's not tunneling. The proxy converts a tcp connection into a mptcp
connection and converts it back to a tcp connection (if necessary)
So, it won't be tcp over tcp.

MPTCP will convey control data for application (proxy) in payload. But,
MPTCP of course doesn't care the contents of payload.
It just carries data and app will parse the data. Putting data in SYN is
trying to reduce the latency and no other meaning as far as I understand.

--
Yoshi

On Tue, Apr 18, 2017 at 6:29 AM, Joe Touch <[email-masked]> wrote:

> (below), but I've already commented on my concerns that conclude (c) *based
> on previously assuming this was intended as an IP tunnel and used an option
> with control plane info in the SYN data) so I won't repeat them.
>
> Protocols for operators to configure proxies seem out of scope here. And if
> this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over
> TCP), which I already noted in previous discussion.
>
> 2) what does "using the payload...to transfer a signalling message" mean?
> Are you using the MPTCP control plane? or the data plane of the MPTCP
> connection?
>
> interpreted as something other than TCP data (i.e., control plane). That is
> also a very bad idea - it interferes with MPTCPs ability to silently
> fall-back to TCP when talking to legacy endpoints, and the reasons for not
> using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section
> 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I
> also already noted in previous discussion.
> During the MPTCP meeting in Chicago we did several hums about potential
> MPTCP proxy work. Our interpretation of these hums is that we should do a
> consensus call for the following work:
>
> --
> MPTCP is now seeing widespread deployment in networks to bond together two
> accesses, such as fixed and mobile broadband, by using two MPTCP proxies,
> one in the home gateway or Customer Premises Equipment and one in the
> network. The WG develops a solution where the proxies are both under the
> control of the operator and where it is assumed that they are not on the
> default path. The solution is based on using the payload of an MPTCP packet
> to transfer a signalling message between the proxies. It is believed the
> solution will not require changes to RFC6824bis. The solution may require a
> means of configuring set-up information in the proxies, which would be done
> in coordination with other IETF WGs such as DHC. The WG does not develop a
> mechanism for the two proxies to discover each other.
>
> --
>
> multipathtcp mailing [email-masked]://www.ietf.org/mailman/listinfo/multipathtcp
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 14:56:17 -0700

> So, it won't be tcp over tcp.
OK, but that's not proxying either.

That's (at best) connection hijacking.

> MPTCP will convey control data for application (proxy) in payload.
> But, MPTCP of course doesn't care the contents of payload. 
> It just carries data and app will parse the data. Putting data in SYN
> is trying to reduce the latency and no other meaning as far as I
> understand.

MPTCP is TCP. Putting the data in the SYN of a TCP connection is
hazardous. The goal is irrelevant.

I thought we went through this all when MPTCP was created, but it
appears insufficiently so.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 18 Apr 2017 18:12:50 -0700

Hi Joe,

> That's (at best) connection hijacking.

I won't deny it as I'm not 100% sure whether proxy is a good name or not.
But, I am thinking you might want to call NAT hijacking as well.

> hazardous. The goal is irrelevant.

In TCP, we already have a precedence such as TFO.
I think what the solution does won't exceed what TFO does.
Data in SYN will be used between the proxies and won't be sent to random
destinations.
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 18:18:36 -0700

On 4/18/2017 6:12 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
Yes, but we do know what a NAT is responsible for - i.e., it is 1:1
translation of only addresses and ports.

Doing more than that has never been part of an IETF standard, AFAICT -
for many reasons.

> In TCP, we already have a precedence such as TFO.

Sorry, to be more clear:
    Data in the SYN has been part of TCP since it was standardized.

Using the SYN data as control information is the hazardous part.

> I think what the solution does won't exceed what TFO does.
TFO changes when the SYN data is delivered, based on the fact that past
cookie information "accelerates" the 3WHS.

It does not put control plane information in the data area of the SYN.

Joe

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Apr 2017 04:06:40 +0200

>> Does the dual proxy solution have the ability to support native MPTCP
>> at the client and server, or is the assumption that the solution forces
>> the two proxies to become part of a connection regardless of whether
>> the client and server are MPTCP enabled?

> If the client and server support mptcp the proxies should not end up in
> the path

Could you please explain how that happens?

-- Juliusz

---

From: <[email-masked]>
Date: Wed, 19 Apr 2017 05:26:39 +0000

Joe,

As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.

I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

Cheers,
Med

De : Joe Touch [mailto:[email-masked]]
Envoyé : mardi 18 avril 2017 17:01
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Mohammed,

I'm sorry, but when you talk about CPEs and network interconnection, you're clearly talking (AFAICT) about using MPTCP as an IP tunnel.

That leads to TCP over TCP (where the first is inside the IP packets you're transiting).

If that's what you're doing, it is a mistake. Layered congestion control is never beneficial.

Joe

On 4/18/2017 7:30 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Joe,

So:

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Joe Touch
Envoyé : mardi 18 avril 2017 15:30
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Hi, all,

Joe

Hi,

Hums during the meeting:

---

From: <[email-masked]>
Date: Wed, 19 Apr 2017 05:46:59 +0000

Re-,

Please see inline.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de Joe Touch
Envoyé : mercredi 19 avril 2017 03:19
À : Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On Tue, Apr 18, 2017 at 2:56 PM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

I won't deny it as I'm not 100% sure whether proxy is a good name or not.
But, I am thinking you might want to call NAT hijacking as well.
Yes, but we do know what a NAT is responsible for - i.e., it is 1:1 translation of only addresses and ports.
[Med] That’s the same situation here: the CPE is assigned N addresses but cannot use all these addresses as external ones to communicate with a single path server. In order to benefit from the path diversity and the resources pooling, the CPE and proxy will collaborate as already described in other mails. One way to collaborate is to hide these N addresses (you name it).

Doing more than that has never been part of an IETF standard, AFAICT - for many reasons.

Sorry, to be more clear:

Using the SYN data as control information is the hazardous part.
[Med] It isn’t for the for the simple reason that legacy Internet nodes will never receive a SYN with CPE-supplied data and that the TCP peer is known to process the supplied data. A Guard against misconfigurations is supported: echo in a SYN/ACK.

I think what the solution does won't exceed what TFO does.
TFO changes when the SYN data is delivered, based on the fact that past cookie information "accelerates" the 3WHS.

Joe

---

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

Hi Matt, 

Yes, I confirm. 

* Native MPTCP connections can be established directly without involving a proxy. 
* If the client is not MPTCP-capable but the server is MPTCP-capable, the communication leg between the proxy and that server will be placed using MPTCP. 

Please refer to, e.g., slide 12 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf 

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:[email-masked]] De la part de
> Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
> Envoyé : mardi 18 avril 2017 17:39
> À : [email-masked]
> Cc : [email-masked]
> Does the dual proxy solution have the ability to support native MPTCP at
> the client and server, or is the assumption that the solution forces the
> two proxies to become part of a connection regardless of whether the
> client and server are MPTCP enabled?
> 
> Thanks,
> Matt
> 
> proxies, one in the home gateway or Customer Premises Equipment and one in
> the network. The WG develops a solution where the proxies are both under
> the control of the operator and where it is assumed that they are not on
> the default path. The solution is based on using the payload of an MPTCP
> packet to transfer a signalling message between the proxies. It is
> believed the solution will not require changes to RFC6824bis. The solution
> may require a means of configuring set-up information in the proxies,
> which would be done in coordination with other IETF WGs such as DHC. The
> WG does not develop a mechanism for the two proxies to discover each
> other.
> > --

---

From: Robert Skog <[email-masked]>
Date: Wed, 19 Apr 2017 06:27:24 +0000

Hi!
I fully support the work on MPTCP-Proxy.

Cheers,
/Robert

From: multipathtcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: den 18 april 2017 10:17
To: [email-masked]
Subject: [multipathtcp] Consensus call on potential MPTCP proxy work

Hi,

Hums during the meeting:

---

From: <[email-masked]>
Date: Wed, 19 Apr 2017 07:23:23 +0000

Matt,

During the discussion in Chicago, we put up a slide about 'assumptions & criteria' (for solutions) - one of which is 
>>Don’t interfere with normal MPTCP (both endpoints MPTCP enabled)

[slide 11 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf ]

-----Original Message-----
From: Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies] [mailto:[email-masked]] 
Sent: 18 April 2017 16:39
To: Eardley,PL,Philip,TUD1 R <[email-masked]>
Cc: [email-masked]
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Hi Phil, all,

Thanks,
Matt

---

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

Phil,
> MPTCP proxy work. Our interpretation of these hums is that we should do
> a consensus call for the following work:
>
> --
> proxies, one in the home gateway or Customer Premises Equipment and one
> in the network. The WG develops a solution where the proxies are both
> under the control of the operator and where it is assumed that they are
> not on the default path. The solution is based on using the payload of
> an MPTCP packet to transfer a signalling message between the proxies. It
> is believed the solution will not require changes to RFC6824bis. The
> solution may require a means of configuring set-up information in the
> proxies, which would be done in coordination with other IETF WGs such as
> DHC. The WG does not develop a mechanism for the two proxies to discover
> each other.
>

I fully support the work on MPTCP proxies. I would not focus on the 
current use case (how gateway and two proxies) but more on the 
importance of :

- being able to terminate Multipath TCP connections on a proxy somewhere 
in the network to bond different access networks when the server is not 
MPTCP capable
- using 0-rtt, i.e. the proposed solution should not require an 
additional rtt to create a connection

The solution will use data in the SYN payload to achieve 0-rtt and 
should not require changes to RFC6824bis

Then different use cases can be built on top of this protocol. The Home 
gateway case that we discussed in Chicago is the first one, but 
smartphones are another one.

I would suggest to separate the work in different documents :
- a first draft describing the syntax of the messages added to the SYN
- a second draft describing how the above protocol can be used to 
support hybrid access networks with two proxies
- a third draft describing how the above protocol can be used on smartphones

Other use cases are possible

Olivier

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 19 Apr 2017 11:04:47 +0300

> I fully support the work on MPTCP proxies. I would not focus on the current use case (how gateway and two proxies) but more on the importance of :
> 
> - being able to terminate Multipath TCP connections on a proxy somewhere in the network to bond different access networks when the server is not MPTCP capable
> - using 0-rtt, i.e. the proposed solution should not require an additional rtt to create a connection

+ 1.

Also, the solution should be future proof - if the server does support MPTCP, the proxy should simply relay the traffic, and not terminate the connection, allowing the client to directly connect to the server with other subflows.

Best.
Costin

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 19 Apr 2017 10:19:04 +0200

Costin,

> Also, the solution should be future proof - if the server does support MPTCP, the proxy should simply relay the traffic, and not terminate the connection, allowing the client to directly connect to…

Since the proxy is explict, the client creates an MPTCP connection to 
the proxy and the proxy creates another MPTCP connection to the final 
server. Since the proxy was the destination of the SYN, it cannot simply 
relay the traffic, but it should indicate to the client that the server 
supports MPTCP so that the next connection established by the client 
towards this server can directly bypass the proxy. This information 
about the MPTCP support on the final server could be part of the 
signalling information contained in the payload of the SYN+ACK

Olivier

---

From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[email-masked]>
Date: Wed, 19 Apr 2017 13:38:00 +0000

Hi Med,

> On Apr 19, 2017, at 2:00 AM, [email-masked] wrote:
> 
> Hi Matt, 
> 
> Yes, I confirm. 
> 

I am not sure I understand how you maintain native MPTCP connections in the dual proxy case.

I am assuming a network that is set up like you have on slide 10. 1 address on the client, 1 address on the server, multiple paths are "hidden" by the MCP's.

Do you mean to claim that installing MPTCP on the client and server will result in an MPTCP connection that "works" in the sense that it will contain multiple subflows to use the available paths in the network? How would this work without additional signaling?

Sorry if I am missing something obvious here.

Thanks,
Matt

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Apr 2017 11:11:58 -0700

On 4/18/2017 10:46 PM, [email-masked] wrote:
> ...
> [Med] It isn’t for the for the simple reason that legacy Internet
> nodes will never receive a SYN with CPE-supplied data and that the TCP
> peer is known to process the supplied data. A Guard against
> misconfigurations is supported: echo in a SYN/ACK.
>

The idea of using a magic number to protect against miscommunication
virtually ensures that there will be reliable connections with errors.
That changes TCPs semantics.

Putting data in the SYN of TFO is permitted only because of previous state.

MPTCP doesn't have that state and so it is hazardous to put data in the
SYN.

I.e., if you want TFO-like performance, figure out how to use TFO. Period.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Apr 2017 11:16:53 -0700

On 4/18/2017 10:26 PM, [email-masked] wrote:
>
> As explained in my previous message, there is no layered congestion
> control. All packets are transported over plain TCP: no encap, no tunnel.
>
I did say "if"; I now understand better what you're trying to do, but
there are plenty of parts still not addressed:

>  I really reiterate my comment to read
Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a
single MPTCP between proxies to support multiples?
- what is the congestion control interaction? I.e., does the client
think the RTT is to the proxy (which will work), or to the TCP receiver
past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion
control
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute
the entire packet?
   
    NOTE: if it reconstitutes the packet, what happens when you get an
option you don't understand? E.g., EDO?

There are still plenty of more concerns with this system. Overall, you
*still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would
be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by
reconstituting packets on the other end - a TCP connection over TCP,
which is a bad idea

So which is it? Or is it something else?

Joe

---

From: Jordan Melzer <[email-masked]>
Date: Wed, 19 Apr 2017 18:59:18 +0000

It's a conventional proxy.  There are different sockets on each side of the
proxy, different RTTs, different congestion control.  The proposal is to
find a near-zero overhead way to do this when the proxy is off-path (ie,
when it's not a simple connection hijack).  This may be totally possible
without a new RFC - Christoph Paasch suggested that SOCKS + TFO could
basically become this, but I am not sure anyone who cared either caught it
or agreed.

Re b), it's off-topic, but what would you think of a multipath tunnel that
was basically MPTCP with the retransmissions gutted out?  I had thought this
would be what BANANA is doing, but I am not clear there are any two people
in BANANA who agree on what it is.

From: multipathtcp [mailto:[email-masked]] On Behalf Of Joe
Touch
Sent: April 19, 2017 02:17 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work

As explained in my previous message, there is no layered congestion control.
All packets are transported over plain TCP: no encap, no tunnel. 

I did say "if"; I now understand better what you're trying to do, but there
are plenty of parts still not addressed:

 I really reiterate my comment to read
https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-ass
isted-mptcp-03.pdf

- is this system 1:1 per client TCP connection, or are you expecting a
single MPTCP between proxies to support multiples?
- what is the congestion control interaction? I.e., does the client think
the RTT is to the proxy (which will work), or to the TCP receiver past the
end of the MPTCP connection? 
    NOTE: if the latter, then you still end up with layered congestion
control
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the
entire packet?

    a) acting like a conventional application-layer proxy, which would be
fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by
reconstituting packets on the other end - a TCP connection over TCP, which
is a bad idea

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Apr 2017 13:03:28 -0700

On 4/19/2017 11:59 AM, Jordan Melzer wrote:
>
> It’s a conventional proxy.  There are different sockets on each side
> of the proxy, different RTTs, different congestion control.  The
> proposal is to find a near-zero overhead way to do this when the proxy
> is off-path (ie, when it’s not a simple connection hijack).  This may
> be totally possible without a new RFC – Christoph Paasch suggested
> that SOCKS + TFO could basically become this, but I am not sure anyone
> who cared either caught it or agreed.
>
>  
>
> Re b), it’s off-topic, but what would you think of a multipath tunnel
> that was basically MPTCP with the retransmissions gutted out?  I had
> thought this would be what BANANA is doing, but I am not clear there
> are any two people in BANANA who agree on what it is.
>

Why would that not be SCTP?
Joe

>  
>
>  
>
> *From:*multipathtcp [mailto:[email-masked]] *On Behalf
> Of *Joe Touch
> *Sent:* April 19, 2017 02:17 PM
> *To:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [multipathtcp] Consensus call on potential MPTCP proxy work
>
>  
>
>  
>
>  
>
> On 4/18/2017 10:26 PM, [email-masked]
> <mailto:[email-masked]> wrote:
>
>     As explained in my previous message, there is no layered
>     congestion control. All packets are transported over plain TCP: no
>     encap, no tunnel.
>
> think the RTT is to the proxy (which will work), or to the TCP
> receiver past the end of the MPTCP connection?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Apr 2017 00:07:58 +0200

> It’s a conventional proxy. There are different sockets on each side of the
> proxy

Can you please explain what's going on in Figure 5 on page 11 of
draft-boucadair-mptcp-plain-mode-10?  I read this as delaying a SYN-ACK on
the client side until a SYN-ACK on the server side is received.  How do
you implement that with different sockets?

-- Juliusz

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Apr 2017 15:17:09 -0700

> you implement that with different sockets?
Excellent point. That would more clearly confirm that this is not
application-layer (I'm excluding application access to raw Unix sockets,
which would end up running TCP in the user layer).

Joe

---

From: <[email-masked]>
Date: Thu, 20 Apr 2017 05:32:36 +0000

Hi Matt, 

What I meant by "native MPTCP connections" is that the CPE won't proxy a SYN that contains MP_CPABALE received from an MPTCP-capable client. That is, the CPE won't modify the destination IP address to the one of the network-located proxy. That SYN+MP_CPABALE will be received and handled directly by the remote server.   

Cheers,
Med

> De : Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
> [mailto:[email-masked]]
> Envoyé : mercredi 19 avril 2017 15:38
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; [email-masked]
> > * If the client is not MPTCP-capable but the server is MPTCP-capable,
> the communication leg between the proxy and that server will be placed
> using MPTCP.
> >
> 
> I am assuming a network that is set up like you have on slide 10. 1
> address on the client, 1 address on the server, multiple paths are
> "hidden" by the MCP's.
> 
> Do you mean to claim that installing MPTCP on the client and server will
> result in an MPTCP connection that "works" in the sense that it will
> contain multiple subflows to use the available paths in the network? How
> would this work without additional signaling?
>

---

From: <[email-masked]>
Date: Thu, 20 Apr 2017 05:50:32 +0000

Hi Joe,

I don’t understand your comments here:

·         The use of a 32-bit magic number is meant to distinguish application-supplied data from the one inserted by the proxy. There are other fields in the MP_CONVERT information element that help in that aim too (validation of the TLV, M-bit, for example).

·         Both entities that supply and process the data are under the control of the same operator.

·         The network-located proxy is explicitly configured on the CPE. The destination IP address of the packet is an address of that proxy, not the address of a legacy node.

·         The proxy must echo supplied data in a SYN/ACK. If a mismatch is detected by the CPE, that proxy WON’t be used for subsequent connections till a new proxy is configured, TTL expires, etc.

To sum:

·         We are acting on one single SYN of an MPTCP connection.

·         If a mismatch is detected for one single SYN of a given connection, all subsequent connections (with any remote server) won’t be relayed to that proxy.

How is this “hazardous”?

Thank you.

Cheers,
Med

De : Joe Touch [mailto:[email-masked]]
Envoyé : mercredi 19 avril 2017 20:12
À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On 4/18/2017 10:46 PM, [email-masked]<mailto:[email-masked]> wrote:
...
Using the SYN data as control information is the hazardous part.
[Med] It isn’t for the for the simple reason that legacy Internet nodes will never receive a SYN with CPE-supplied data and that the TCP peer is known to process the supplied data. A Guard against misconfigurations is supported: echo in a SYN/ACK.

The idea of using a magic number to protect against miscommunication virtually ensures that there will be reliable connections with errors. That changes TCPs semantics.

MPTCP doesn't have that state and so it is hazardous to put data in the SYN.

Joe

---

From: <[email-masked]>
Date: Thu, 20 Apr 2017 06:16:11 +0000

Re-,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[email-masked]]
Envoyé : mercredi 19 avril 2017 20:17
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On 4/18/2017 10:26 PM, [email-masked]<mailto:[email-masked]> wrote:
As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.
I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?
[Med] We are not multiplexing connections. This is explained in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2:
   The upstream MCP maps an upstream TCP connection onto a downstream
   MPTCP connection (and its associated subflows) . On the upstream MCP,
   an established MPTCP connection can be identified by the local Token
   that was assigned upon reception of the SYN segment from the Client.

- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control
[Med] The one to the proxy. This is important for subflows management and traffic distribution.

- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?
[Med] The proxy will need to strop any supplied-data in the initial SYN, and then create a state to be used for handling subsequent packets of that connection. Once a state is created, we are doing something similar to SOCKS for the data plane. There are some new features compared to SOCKS that I won't detail here. The reader may refer to https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01.

    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?
[Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touch options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modification we are doing at this level is to insert MPTCP options. And even for this case, as shown in slide 30, when there is an exhausted TCP option space in the original SYN, ** no ** MPTCP options are inserted. So, all is safe.

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?
[Med] Interoperability is needed here because the CPE and the network-located proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy data is to be standardized. Other matters like those you mentioned are key to keep in mind.

Joe

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Apr 2017 16:05:45 +0200

> What I meant by "native MPTCP connections" is that the CPE won't proxy
> a SYN that contains MP_CPABALE received from an MPTCP-capable
> client. That is, the CPE won't modify the destination IP address to the
> one of the network-located proxy. That SYN+MP_CPABALE will be received
> and handled directly by the remote server.

It will still act as a middlebox, though, with no way for the client to
avoid it.

-- Juliusz

---

From: <[email-masked]>
Date: Thu, 20 Apr 2017 14:15:03 +0000

Juliusz,

No. This is not true. 

Connections that are not eligible to network-assisted MPTCP service WON'T involve a proxy. 

Cheers,
Med

> De : Juliusz Chroboczek [mailto:[email-masked]]
> Envoyé : jeudi 20 avril 2017 16:06

---

From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[email-masked]>
Date: Thu, 20 Apr 2017 14:32:44 +0000

Hi Med,

Thanks for the response.

> On Apr 20, 2017, at 1:32 AM, [email-masked] wrote:
> 

I thought this was the case. 

Part of this proposal that I do not support is that network assistance requires connection hijacking. There is no plan to have the network assist 2 MPTCP hosts that want end-to-end connectivity.

Here is a network diagram I drew up:
https://docs.google.com/drawings/d/1VQyZgcg3aHoB0VVeCBYlc6cTVD6a0ZrwXFtw6EvNw6s/edit?usp=sharing

What I would like to see is a solution that supports the following:

The cell phone and server have on ongoing connection over Path 3. Now this phone wants to add a subflow using the WiFi interface. How could the network assist this connection to enable the use of both Path 1 and Path 2 rather than (Path 1 xor Path 2) in an end-to-end manner? In other words, how could the cell phone discover it should start a second subflow over WiFi?

Maybe there is an MPTCP-based solution. Maybe there is an out of band solution. I have not fleshed anything out at the moment, but I think network assistance in a more general sense is a useful topic to dwell on.

Thanks,
Matt

---

From: <[email-masked]>
Date: Thu, 20 Apr 2017 15:16:24 +0000

Matt, 

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 20 avril 2017 16:33
> > What I meant by "native MPTCP connections" is that the CPE won't proxy a
> SYN that contains MP_CPABALE received from an MPTCP-capable client. That
> is, the CPE won't modify the destination IP address to the one of the
> network-located proxy. That SYN+MP_CPABALE will be received and handled
> directly by the remote server.
> 
> Part of this proposal that I do not support is that network assistance
> requires connection hijacking. There is no plan to have the network assist
> 2 MPTCP hosts that want end-to-end connectivity.
> 
> The cell phone and server have on ongoing connection over Path 3. Now this
> phone wants to add a subflow using the WiFi interface. How could the
> network assist this connection to enable the use of both Path 1 and Path 2
> rather than (Path 1 xor Path 2) in an end-to-end manner?

[Med] A proposal we have to make use of path diversity corresponds to Case 6 of slide 16 (https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf). To do so, the CPE needs to be provided with a policy so that this connection is eligible to network-assisted MPTCP. These policies are discussed in https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.1. 

In addition to that policy, we have a configurable parameter to instruct the proxy to be removed from the path (see Section 5.6.1 of that draft)

==
   Whether an MCP must be maintained in the processing of an MPTCP
   connection that involve MPTCP-capable clients and server is a
   configurable parameter.
==

Note that blindly withdrawing a proxy when both the client and server are MPTCP-capable may lead to some issues: 

==
   1.  The use of private IPv4 addresses in some access networks.
       Typically, additional subflows can not be added to the MPTCP
       connection without the help of an MCP.

   2.  The assignment of IPv6 prefix only by some networks.  If the
       server is IPv4-only, subflows that are placed over IPv6 cannot be
       added to an MPTCP connection towards that server.

   3.  Some of the access networks are subject to subscription with
       volume quota.
==

 In other words,
> how could the cell phone discover it should start a second subflow over
> WiFi?

[Med] This is a general MPTCP problem: triggers to add new subflows to an MPTCP connection. We don't require a modification to that behavior. If appropriate policies are configured on the CPE (LAN), subflows will be created over existing multiple paths. Doing so allows for rich path diversity.   

> 
> Maybe there is an MPTCP-based solution.

[Med] Another proposal would be to use a means to create state for incoming connections for each CPE WAN interfaces (PCP (RFC6887)) + discover the external IP addresses allocated to the CPE, and then advertise these addresses/ports to the remote MPTCP endpoint. The remote MPTCP will create subflow using these addresses. The extension in https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02 can be used to encourage the remote endpoint to create incoming subflows.

 Maybe there is an out of band
> solution. I have not fleshed anything out at the moment, but I think
> network assistance in a more general sense is a useful topic to dwell on.

[Med] I agree.

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Apr 2017 10:24:31 -0700

Med,

On 4/19/2017 10:50 PM, [email-masked] wrote:
> ·         The use of a 32-bit magic number is meant to distinguish
> application-supplied data from the one inserted by the proxy. There
> are other fields in the MP_CONVERT information element that help in
> that aim too (validation of the TLV, M-bit, for example).
>
> ·         The network-located proxy is explicitly configured on the
> CPE. The destination IP address of the packet is an address of that
> proxy, not the address of a legacy node.
>
> ·         The proxy must echo supplied data in a SYN/ACK. If a
> mismatch is detected by the CPE, that proxy WON’t be used for
> subsequent connections till a new proxy is configured, TTL expires, etc.
>
>  
>
> To sum:
>
> ·         If a mismatch is detected for one single SYN of a given
> connection, all subsequent connections (with any remote server) won’t
> be relayed to that proxy.
>
>  
>
> How is this “hazardous”?
>

TCPM archives are full of discussions on why TFO only works for
subsequent connections to the same endpoint, due to cached cookies that
allow the SYN data to be safely interpreted *before* the end of the 3WHS.

MPTCP archives are full of discussions on why the data plane is not a
good place to put option information.

It's not practical to repeat those arguments in one email. The point is
that you're reinventing the wheel in ways that this group and other
groups already know are hazardous.

Joe

>  
>
> Thank you.
>
>  
>
> Cheers,
>
> Med
>
>  
>
> *De :*Joe Touch [mailto:[email-masked]]
> *Envoyé :* mercredi 19 avril 2017 20:12
> *À :* BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
> *Cc :* multipathtcp
> On 4/18/2017 10:46 PM, [email-masked]
>     nodes will never receive a SYN with CPE-supplied data and that the
>     TCP peer is known to process the supplied data. A Guard against

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Apr 2017 10:30:29 -0700

Med,

On 4/19/2017 11:16 PM, [email-masked] wrote:
> *Envoyé :* mercredi 19 avril 2017 20:17
> *À :* BOUCADAIR Mohamed IMT/OLN; [email-masked];
> [email-masked]
> [Med] We are not multiplexing connections. This is explained in
> https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10#section-7.2.2:
>

Great. It would be useful to explain this a lot earlier and at a higher
level.

> and traffic distribution.
So you have three congestion controls running in series? Have you
considered the impact on bufferbloat (of the buffers in the proxy) and
reactivity?

> [Med] The proxy will need to strop any supplied-data in the initial
> SYN, and then create a state to be used for handling subsequent
> packets of that connection. Once a state is created, we are doing
> something similar to SOCKS for the data plane. There are some new
> features compared to SOCKS that I won’t detail here. The reader may
> refer to
> https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01.
>    
>
If you strip user-supplied data in the SYN, you're *changing TCP
semantics* - esp. for a TFO connection.

So you really can't be doing that...

> [Med] EDO can be passed via the MPTCP proxy safely. The proxy does not
> touch options that are inserted by a TCP endpoint. The proxy is not
> required to understand those options. The only modification we are
> doing at this level is to insert MPTCP options. And even for this
> case, as shown in slide 30, when there is an exhausted TCP option
> space in the original SYN, ** no ** MPTCP options are inserted. So,
> all is safe.
>
What happens if you create a segment that's larger than the PMTU? what
do you drop or split? (there's no way to do that safely for unknown options)

> [Med] Interoperability is needed here because the CPE and the
> network-located proxy are provided by distinct vendors. For example,
> the format, location, and processing of the supplied proxy data is to
> be standardized. Other matters like those you mentioned are key to
> keep in mind.
>
If that were the case, you'd simply be defining a new application
service and asking for a TCP port number.

And you wouldn't be able to do zero-RTT opens.

Joe

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Apr 2017 22:02:41 +0200

> Connections that are not eligible to network-assisted MPTCP service

I've probably missed something, then.  I don't see anything in -10 that
says that non-eligible packets are forwarded statelessly without any
modification, including forwarding unknown IP and TCP options.  All I see
on the subject is Section 4.3 paragraph 2, which I find hardly reassuring.

My gut feeling is that either the proxy is implemented at the upper
layers, in which case it terminates all connections and hence discards any
unknown options, or it is implemented at a lower layer, allowing it to
bypass selected packets, in which case it is no longer a mere upper layer
proxy.  I just don't see how you can have it both ways.

Could you please explain what I'm missing?

-- Juliusz

---

From: <[email-masked]>
Date: Fri, 21 Apr 2017 05:31:05 +0000

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[email-masked]]
Envoyé : jeudi 20 avril 2017 19:30
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; [email-masked]
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Med,
On 4/19/2017 11:16 PM, [email-masked]<mailto:[email-masked]> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[email-masked]]
Envoyé : mercredi 19 avril 2017 20:17
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Great. It would be useful to explain this a lot earlier and at a higher level.

So you have three congestion controls running in series? Have you considered the impact on bufferbloat (of the buffers in the proxy) and reactivity?
[Med] A detailed specification will need to discuss these details once we have a WG document.

If you strip user-supplied data in the SYN, you're *changing TCP semantics* - esp. for a TFO connection.
[Med] There is a misunderstand here : the user supplied data is NOT striped/altered. What is striped is MP_CONVERT IEs (proxy supplied data).

So you really can't be doing that...
[Med] We are not doing it.

    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?
[Med] EDO can be passed via the MPTCP proxy safely. The proxy does not touch options that are inserted by a TCP endpoint. The proxy is not required to understand those options. The only modification we are doing at this level is to insert MPTCP options. And even for this case, as shown in slide 30, when there is an exhausted TCP option space in the original SYN, ** no ** MPTCP options are inserted. So, all is safe.
What happens if you create a segment that's larger than the PMTU? what do you drop or split? (there's no way to do that safely for unknown options)
[Med] This is not specific to this proposal. As a reminder, we have this problem only of the initial SYN. My take on this is to augment the MTU on the CPE and the network side to absorb MP_CONVERT. These details will be worked out in the WG endorsed document. It is likely that we inspire from the recommendations in draft-ietf-rtgwg-dt-encap-02#section-9: "assume well-managed MTU hence no need for fragmentation and reassembly".

So which is it? Or is it something else?
[Med] Interoperability is needed here because the CPE and the network-located proxy are provided by distinct vendors. For example, the format, location, and processing of the supplied proxy data is to be standardized. Other matters like those you mentioned are key to keep in mind.
If that were the case, you'd simply be defining a new application service and asking for a TCP port number.

And you wouldn't be able to do zero-RTT opens.
[Med] 0-RTT is a key requirement for the WG.

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 21 Apr 2017 06:02:01 +0000

> Please say whether you support, or don’t support, such work – so we can see if there’s consensus for it.

I don't support doing proxy work in MPTCP.

Sure, you can probably take a sledgehammer to MPTCP and make it roughly conform to what operators believe they need here (cf. RFC1925 clause 3). But I believe that MPTCP is fundamentally the wrong starting point for solutions to this problem space.

Lars

---

From: <[email-masked]>
Date: Fri, 21 Apr 2017 06:07:31 +0000

Hi Jaliusz,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 20 avril 2017 22:03
> modification, including forwarding unknown IP and TCP options.

[Med] Two comments here: 

* We don't touch/alter existing IP/TCP options/EHs for ** both ** eligible and non-eligible flows. This is something we will call out explicitly in the document to avoid misinterpretation. We are adding MPTCP options at the TCP option level and MP_CONVERT IE in the first SYN.  That's all. 

* The document is focusing more on "what we are doing" not "what we are not doing". It says for instance: 

   Any data that is eligible to be transported over the MPTCP connection
   ^^^^^^^^^^^^^^^^^^^^^^^^
   is sent by the Client towards the MCP over the MPTCP connection.  The
   MCP then forwards these data over the regular TCP connection until
   they reach the server.  The same forwarding principle applies for the
   data sent by the Server over the TCP connection with the MCP. 

and

   Any data received by the upstream MCP over the upstream TCP
   connection will be forwarded by the MCP over the bound downstream
   MPTCP connection, assuming such data are eligible to MPTCP transport.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   The same applies for data received over the downstream MPTCP
   connection which will be forwarded by the upstream MCP over the
   upstream TCP connection.

So, other flows will be processed following any default forwarding behavior in place: that default may be NAT44, IPv4-in-IPv6 encap without NAT (DS-Lite), IPv4-in-IPv6 encap with port-restricted NAT (MAP-E, lw4o6), CLAT (464xlat), IPv4/IPv6 translation (MAP-E), ....

The text will be updated to call this out.       

  All I see
> Could you please explain what I'm missing?

[Med] 
* This is an MPTCP proxy that does not need to understand IP/TCP options that are carried in the original SYN. 
* The proxy located at the network side does only process packets that are destined explicitly to it (i.e., DST@ of the packet==proxy@). 
* Packets that are not eligible to MPTCP-assisted service, will be forwarded without involving a proxy. 
* Even if that proxy is embedded in a device that is on a default forwarding path, the proxy won't intercept those packets because the destination address != proxy@.

---

From: <[email-masked]>
Date: Fri, 21 Apr 2017 06:15:16 +0000

Lars, 

I don't see any technical argument in your message. 

Is it respectful for people to cite April 1 in a serous technical discussion?

Cheers,
Med

> Eggert, Lars
> Envoyé : vendredi 21 avril 2017 08:02
> À : Philip Eardley
> Sure, you can probably take a sledgehammer to MPTCP and make it roughly
> conform to what operators believe they need here (cf. RFC1925 clause 3).
> But I believe that MPTCP is fundamentally the wrong starting point for
> solutions to this problem space.
> 
> Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 21 Apr 2017 06:26:41 +0000

Hi,

> I don't see any technical argument in your message.

we're not asked to have a technical discussion. We're asked whether we support this work in MPTCP, and I don't, for the reasons stated. I think MPTCP is architecturally the wrong starting point for solutions to this operator problem space.

> Is it respectful for people to cite April 1 in a serous technical discussion?

I provided the reference, because it summarizes my standpoint in a - what I consider - humorous way. I do apologize if this caused offense. As I said, I do believe that you can bang MPTCP out of shape to make it do what's needed here - but that is true for other existing starting points, some of which might be a more natural fit. Or not - that's not the question we're asked to answer here.

Lars

---

From: <[email-masked]>
Date: Fri, 21 Apr 2017 06:55:25 +0000

Re-,

The initial message form Phil includes the following: "We believe the work does not require an update to the MPTCP WG charter". So, the proposal is not to modify the MPTCP WG charter to cover the proxy work (the WG charter already covers "MPTCP-aware middlebox" work), but to decide which technical approach to follow for that item in the charter.

I hopped you can explicit why "MPTCP is architecturally the wrong starting point". This is not obvious to me. Sorry but I'm a fun of https://tools.ietf.org/html/rfc7282#section-4 (Humming should be the start of a conversation, not the end). 

Lacking that information, I don't see a new element here that could lead to change the consensus reached at the Chicago meeting (of course I'm not entitled to do that call anyway). 

Cheers,
Med

> De : Eggert, Lars [mailto:[email-masked]]
> Envoyé : vendredi 21 avril 2017 08:27
> Cc : Philip Eardley; [email-masked]
> we're not asked to have a technical discussion. We're asked whether we
> support this work in MPTCP, and I don't, for the reasons stated. I think
> MPTCP is architecturally the wrong starting point for solutions to this
> operator problem space.
> 
> I provided the reference, because it summarizes my standpoint in a - what
> I consider - humorous way. I do apologize if this caused offense. As I
> said, I do believe that you can bang MPTCP out of shape to make it do
> what's needed here - but that is true for other existing starting points,
> some of which might be a more natural fit. Or not - that's not the
> question we're asked to answer here.
> 
> Lars

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 21 Apr 2017 02:00:57 -0700

Hi Joe,

> Doing more than that has never been part of an IETF standard, AFAICT - for

I am not very sure how 1 TCP: 1 MPTCP translations is complicated yet.
So, I don't have a reason to stop people exploring.

> It does not put control plane information in the data area of the SYN.

In my view, TFO relies on the info from past connections and we somehow
believe it's valid and not staled. But, it's still external info because it
is from the outside of the current connection.
This case relies on other type of external info and when we believe the
info, we will send data in SYN. I personally don't see big differences.

--
Yoshi

---

From: <[email-masked]>
Date: Fri, 21 Apr 2017 12:27:50 +0000

Re-,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:[email-masked]]
Envoyé : jeudi 20 avril 2017 19:25
À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

Med,

On 4/19/2017 10:50 PM, [email-masked]<mailto:[email-masked]> wrote:
Hi Joe,

To sum:

How is this “hazardous”?

TCPM archives are full of discussions on why TFO only works for subsequent connections to the same endpoint, due to cached cookies that allow the SYN data to be safely interpreted *before* the end of the 3WHS.
[Med] if having a “cookie” is the guarantee to “allow the SYN data to be safely interpreted *before* the end of the 3WHS”, I’d like to confirm that are conforming to that rationale:

·         TFO cookie is “used by the server side to authenticate a client initiating a TFO connection”. In our case, all MPTCP connections that include MP_CONVERT are always between the same nodes. The proxy relies upon other means to authenticate/authorize a CPE. Please refer to slide 29 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf.

·         TFO server-supplied cookies are used to prevent SYNs with spoofed IP addresses attacks: Spoofed IP addresses is not a problem in a provider network because anti-spoofing filters are in place (at access nodes, typically).

·         TFO specification acknowledges the following: “cookies are not necessary if the server has application-level protection or is immune to these attacks” (cookie-less Fast Open) and “the server may choose to generate a trivial or    even a zero-length cookie to improve performance by avoiding the cookie generation and verification”. Cached cookies are not required to supply data in 3WHS if the server if protection is in place. This is the case for the MPTCP proxy target case.

·         Last, the use of TFO cookies is not 100% safe. SYN flooding with valid cookies is still a valid threat.

MPTCP archives are full of discussions on why the data plane is not a good place to put option information.
[Med] Hmm, EDO does already that. But…more important:

·         we are not putting option information in the payload.

·         I guess you are referring to the reliable delivery of the extended option space in a SYN. This would be a valid point if we are sending data to ANY host on the Internet but we are not doing that. We are supplying data to ONE single node that is configured explicitly to a host/CPE. The provider, who configures that proxy to a host/CPE by means of DHCP, ensures that proxy complies with the specification. As a guard, the solution supports a mechanism to detect misbehaving proxies.

It's not practical to repeat those arguments in one email. The point is that you're reinventing the wheel in ways that this group and other groups already know are hazardous.
[Med] I don’t think there is a precedent of the 0-RTT proxying work. I don’t see what we are reinventing here.  I still don’t see what is “hazardous” here.

Joe

Thank you.

Cheers,
Med

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Apr 2017 09:04:09 -0700

Med,

I've made my position clear too.

I do not support this doc as MPTCP work.

I also call into question whether this is in-scope for MPTCP. MPTCP is
chartered to work within MPTCP - but this solution requires access to
raw incoming SYNs inside a different TCP connection, which is no longer
in-scope IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Apr 2017 09:05:58 -0700

On 4/21/2017 2:00 AM, Yoshifumi Nishida wrote:
> In my view, TFO relies on the info from past connections and we
> somehow believe it's valid and not staled. But, it's still external
> info because it is from the outside of the current connection.
> This case relies on other type of external info and when we believe
> the info, we will send data in SYN. I personally don't see big
> differences.

Again, TFO semantics were vetted by TCPM over a fairly long set of
discussions.

If you want TFO behavior, use TFO.

If you want to argue that this is a different way to achieve the same
results, that's a very long road of discussions to begin.

That discussion is IMO outside the scope of MPTCP (there's no zero-delay
open in its charter).

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Apr 2017 09:07:19 -0700

One final point:

> [Med] Hmm, EDO does already that. But…more important:
It also explains at length why this is not possible inside the SYN.

Again, MPTCP isn't the place to develop solutions that have been
rejected within TCPM.

Joe

---

From: <[email-masked]>
Date: Mon, 24 Apr 2017 08:23:04 +0000

Joe, 

Transforming a TCP connection into MPTCP connection will obviously need to access to SYNs to insert MPTCP options. 

This is the basic behavior of ** any ** MPTCP proxy.
 
Cheers,
Med

> Envoyé : vendredi 21 avril 2017 18:04

---

From: Joe Touch <[email-masked]>
Date: Mon, 24 Apr 2017 07:48:44 -0700

Med,

A proxy can operate at the conventional socket layer and would not have or need direct access to SYN segments. Any information needed to reconstitute the SYN at the upstream proxy could be retrieved in other ways.

You're pushing a split-TCP solution, one that (again, I repeat) the IETF has never sanctioned and I do not agree with.

Joe

> On Apr 24, 2017, at 1:23 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Joe, 
>

---

From: <[email-masked]>
Date: Mon, 24 Apr 2017 15:03:23 +0000

Re-,

Do you consider a NAT implementation as part of your first category or the second one?

BTW, the mptcp proxy documents do only describe the external behavior. No implementation-specific assumptions/details are included. 

Cheers,
Med

> Envoyé : lundi 24 avril 2017 16:49
> A proxy can operate at the conventional socket layer and would not have or
> need direct access to SYN segments. Any information needed to reconstitute
> the SYN at the upstream proxy could be retrieved in other ways.
> 
> You're pushing a split-TCP solution, one that (again, I repeat) the IETF
> has never sanctioned and I do not agree with.
> 
> Joe
> 
> > Transforming a TCP connection into MPTCP connection will obviously need
> to access to SYNs to insert MPTCP options.
> >

---

From: Joe Touch <[email-masked]>
Date: Mon, 24 Apr 2017 08:23:30 -0700

> Do you consider a NAT implementation as part of your first category or the second one?
A NAT is part of the second one. You'll notice that there are no
IETF-endorsed NAT solutions - only protocols to talk directly to NATs or
methods to overcome what NATs do.

> BTW, the mptcp proxy documents do only describe the external behavior. No implementation-specific assumptions/details are included. 
When you require the MPTCP SYN to be issued before the SYN-ACK is sent
to the originating client, that is specifying split-TCP behavior that
the IETF has never endorsed.

The same is true when you try to reinvent ways to interpret SYN data
before the MPTCP 3WHS completes - reinventing TFO without TFO's protections.

Joe

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Apr 2017 17:26:15 +0200

> raw incoming SYNs inside a different TCP connection, which is no longer

On a related note -- is there a publicly available implementation of the
plain mode proxy, so we can see how deep it needs to delve into the
network stack's internals?

-- Juliusz

---

From: <[email-masked]>
Date: Tue, 25 Apr 2017 07:11:34 +0000

Just to clarify our interpretation of the various hums during the meeting.

We interpreted them as indicating there was one topic that it was worthwhile doing a consensus call on. We did not interpret the hums as indicating clear consensus that we merely needed to confirm on the list. 

So far we see:
In favour: 
[email-masked]
[email-masked]
William Ivancic <[email-masked]> 
Stefano Secci <[email-masked]>   
Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> 
David Allan I <[email-masked]> 
[email-masked] 
Robert Skog <[email-masked]> 
Olivier Bonaventure <[email-masked]> 
Costin Raiciu <[email-masked]> 

Against:  
Joe Touch <[email-masked]>
Juliusz Chroboczek <[email-masked]> 
Eggert, Lars <[email-masked]>

It is therefore important to hear views from other people. Of course it is also welcome for the technical discussion to continue (indeed, some people may want more of the technical discussion before giving their view on the consensus call).

Thanks
Phil & Yoshi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 21 April 2017 07:55

[cut]

---

From: SungHoon Seo <[email-masked]>
Date: Tue, 25 Apr 2017 11:30:05 +0000

Hello~ Phil and WG,

I fully support this proxy work in the WG.

Use case with this proxy work may increase the usage of the MPTCP, since most of the existing servers do not have MPTCP capability.

Regards,
SungHoon

> Sent: Tuesday, April 25, 2017 4:12 PM
> To: [email-masked]; [email-masked]
> We interpreted them as indicating there was one topic that it was
> worthwhile doing a consensus call on. We did not interpret the hums as
> indicating clear consensus that we merely needed to confirm on the list.
>
> So far we see:
> In favour:
> Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> David
> Allan I <[email-masked]> [email-masked] Robert
> Skog <[email-masked]> Olivier Bonaventure
> <[email-masked]>
> Juliusz Chroboczek <[email-masked]> Eggert, Lars
> <[email-masked]>
>
>
> It is therefore important to hear views from other people. Of course it is
> also welcome for the technical discussion to continue (indeed, some people
> may want more of the technical discussion before giving their view on the
> consensus call).
>
> Thanks
> Phil & Yoshi
>
> Lacking that information, I don't see a new element here that could lead
> to change the consensus reached at the Chicago meeting (of course I'm not
> entitled to do that call anyway).
>

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 Apr 2017 13:39:56 +0200

> Use case with this proxy work may increase the usage of the MPTCP, since
> most of the existing servers do not have MPTCP capability.

It may also have the opposite effect -- to lock up MPTCP in the ghetto of
proxy-to-proxy protocols, and destroy the (positive) perception of MPTCP
as a suitable end-to-end protocol.

(IMHO, upstreaming MPTCP into the Linux kernel would do more for MPTCP
deployment than anything that the IETF may do, but I guess that's somewhat
off-topic for this discussion.)

-- Juliusz

---

From: Wouter Cloetens <[email-masked]>
Date: Tue, 25 Apr 2017 13:55:37 +0200

As a hummer during the meeting, I fully support the work on MPTCP proxy 
solutions in the WG.

If I'd pressed to provide a reason, I'd start by admitting that, indeed, 
this is not perfect. It won't solve every use case and every problem. 
The plain mode draft makes no effort to fix the world in one day, which 
is, IMO, exactly why it is a good starting point for a realistic solution.
If there were a silver bullet solution, that would solve everything in a 
simple way, we'd have found it by now, and there would be no debate.
If we could practically redesign IP from the ground up for multipathing, 
channel bonding and congestion control, solved for all higher level 
protocols, then we'd be doing that.
If there were a better alternative available, we'd go for that. I've 
studied some. All have weaknesses. MPTCP, as a proxy mechanism, has a 
leg up on the competition because it defers congestion control to TCP 
and MPTCP, rather than attempting to reinvent TCP. As such, it is the 
best choice for a network topology in which at least one of the links is 
not point-to-point with a fixed upstream and downstream bandwidth budget.

A someone with an engineering mentality, I'd like to see solutions for 
real problems within my lifetime. And I'd rather build those solutions 
in a standard, interoperable way.

bfn, Wouter

-- 
Chief Home Gateway Architect     SoftAtHome  http://www.softathome.com/
https://www.linkedin.com/in/wcloetens Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010  Mobile: +32-492-277790   Conf. phone: +32-16-852097

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome’s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.

---

From: Sébastien Barré <[email-masked]>
Date: Tue, 25 Apr 2017 13:57:09 +0200

Hi all,

> Costin Raiciu <[email-masked]>
I am also in favour.
thanks,
Sébastien.

-- 
Tessares SA <http://www.tessares.net> 	Sébastien Barréº | Co-Founder & COO
[email-masked] | +32 10 39 22 55 | +32 472 24 67 40 
<mailto:sebastien.barre%40tessares.net>
Tessares SA | Hybrid Access Solutions
www.tessares.net <http://www.tessares.net>
6 Rue Louis de Geer, 1348 Louvain-la-Neuve, Belgium 
<https://www.google.com/maps?q=6+Rue+Louis+de+Geer,+1348+Ottignies-Louvain-la-Neuve,+Belgium> 

ºPraos Consulting SPRL

-- 

------------------------------
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: Matt Sargent <[email-masked]>
Date: Tue, 25 Apr 2017 16:12:36 +0000

Hi all,

> On Apr 25, 2017, at 3:11 AM, [email-masked] wrote:
> 

You can add me to the against list. I am largely in line with Lars and Juliusz.

Thanks,
Matt

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 25 Apr 2017 18:20:14 +0200

Juliusz,

> as a suitable end-to-end protocol.

I disagree. Having MPTCP proxies provides incentives to deploy MPTCP on 
endhosts. This is clearly what we observe today with the wide deployment 
of MPTCP on Android smartphones in Korea. Without proxies (in this case 
SOCKS proxies, but they have drawbacks as discussed earlier) nobody 
would have considered this deployment.

> off-topic for this discussion.)

I agree but there are already two major smartphone vendors that use the 
open-source Linux MPTCP code and have included in the Linux kernel 
version that they ship to their customers. This is an indication of the 
maturity of the solution and the benefits that users can obtain with 
MPTCP today.

Olivier

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 10:26:18 -0700

Philip,

Your note below isn't a hum; it's a vote tally.

I encourage you to avoid doing that in the future.

Joe

---

From: <[email-masked]>
Date: Wed, 26 Apr 2017 06:11:36 +0000

Hi Touch, 

Please see inline. 

Cheers,
Med

> Envoyé : lundi 24 avril 2017 17:23
> IETF-endorsed NAT solutions

[Med] I disagree, Joe. The IETF published "Standards Track" documents about NAT TCP state machines: https://tools.ietf.org/html/rfc7857#section-2, https://tools.ietf.org/html/rfc6146#section-3.5.2.2, and many other RFCs about NAT TCP behavior itself (RFC5382) or RFC6888. All these RFCs are implemented and deployed in real networks.

The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS.

Your initial argument, that is about "the IETF has never sanctioned..", is not acceptable.

 - only protocols to talk directly to NATs or
> methods to overcome what NATs do.

[Med] I disagree. See above. We are leveraging on existing IETF standard track documents. 

> 
> > BTW, the mptcp proxy documents do only describe the external behavior.
> No implementation-specific assumptions/details are included.

[Med] I don't accept this argument. The only protection in TFO is a server-supplied "cookie". The proxy work has sufficient protections to interpret data inserted in a SYN in a safe manner. 

- TFO cookie is “used by the server side to authenticate a client initiating a TFO connection”. We support a variety of authentication/authorization methods; Please refer to slide 29 of https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf.

- TFO specification acknowledges the following: “COOKIES ARE NOT NECESSARY if the server has application-level protection or is immune to these attacks” (cookie-less Fast Open) and “the server may choose to generate a TRIVIAL or even a ZERO-LENGTH COOKIE to improve performance by avoiding the cookie generation and verification”. Cached cookies are not required to supply data in 3WHS if the server if protection is in place. This is the case for the MPTCP proxy target case.  

- TFO server-supplied cookies are used to prevent SYNs with spoofed IP addresses attacks: Providers' networks are enabled with anti-spoofing filters.  

In order to avoid any confusion: the data we are talking about is not user/application supplied data but a proxy-supplied data that won't never reach the ultimate destination. We are not cloning TFO functionality.

---

From: <[email-masked]>
Date: Wed, 26 Apr 2017 06:38:40 +0000

Hi Juliusz, 

I echo Olivier here.

That's said, you are making a valid point: how to avoid the risk that proxies may prevent end-to-end MPTCP connections (if it happens that servers support MPTCP). 

This is exactly why we need a standard solution and why we have this design objective: "Avoid interference with native MPTCP connections". 

The solution we have on the table allows for this. 

Better, it allows to make use of path diversity whenever available and without requiring changes to hosts:
- That path diversity may not even be visible to an MPTCP-aware client, e.g., a host connected in LAN network that is multi-homed.
- That path diversity may not even be usable by a host, e.g., multi-path server and MPTCP-unaware client.
- That path diversity may not even be usable for MPTCP-aware endpoints, e.g., a host provided with an IPv4 address from network1 and IPv6-only prefix from network2 while the server is IPv4-only.

As a bonus, the proposal allows to withdraw a proxy from the path based on policies.

We are proposing a design that avoids to include locks out there. 

Thank you.

Cheers,
Med

> Juliusz Chroboczek
> Envoyé : mardi 25 avril 2017 13:40
> À : SungHoon Seo
> Objet : [multipathtcp] Increasing usage of MPTCP [was: Consensus call...]
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2017 23:37:40 -0700

I
> On Apr 25, 2017, at 11:11 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Touch, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.

> The IETF has also a "Standards Track" document called SOCKSv5 (RFC1928) that is splitting the TCP connection. We are adhering to the logic of that RFC but without the drawbacks of SOCKS.

Can you clarify where you see split TCP in RFC1928, or are you confusing it with this, which adds split TCP to a SOCKS proxy:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf

...
> - TFO cookie is “used by the server side to authenticate a client initiating a TFO connection”. We support a variety of authentication/authorization methods; Please refer to slide 29 of https://www…

Can you confirm that your approach has the same level of protection as TFO cookies? 

> - TFO specification acknowledges the following: “COOKIES ARE NOT NECESSARY if the server has application-level protection or is immune to these attacks” (cookie-less Fast Open) and “the server may…
Please explain your application level protection or why you think this approach is immune to cookieless attacks. Or are you just embracing the result of those attacks as valid?

> In order to avoid any confusion: the data we are talking about is not user/application supplied data but a proxy-supplied data that won't never reach the ultimate destination. We are not cloning TF…

Agreed.
That might actually be OK.

Joe

---

From: <[email-masked]>
Date: Wed, 26 Apr 2017 07:11:29 +0000

Hi Joe,

Please see inline.

Cheers,
Med

Envoyé : mercredi 26 avril 2017 08:38

I
On Apr 25, 2017, at 11:11 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:
Hi Touch,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Joe Touch [mailto:[email-masked]]
Envoyé : lundi 24 avril 2017 17:23
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work

On 4/24/2017 8:03 AM, [email-masked]<mailto:[email-masked]> wrote:
Re-,

Do you consider a NAT implementation as part of your first category or
the second one?
A NAT is part of the second one. You'll notice that there are no
IETF-endorsed NAT solutions

[Med] I disagree, Joe. The IETF published "Standards Track" documents about NAT TCP state machines: https://tools.ietf.org/html/rfc7857#section-2, https://tools.ietf.org/html/rfc6146#section-3.5.2.2, and many other RFCs about NAT TCP behavior itself (RFC5382) or RFC6888. All these RFCs are implemented and deployed in real networks.
Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.
[Med] NAT64 (RFC6146) is not a patch AFAIK.

Can you clarify where you see split TCP in RFC1928,
[Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see “split TCP” in the plain-mode draft.

I though you are making the same analysis, you have done for the MPTCP proxy, for SOCKS too: i.e., mix implementations-specific design choices with the base specification itself. FWIW, the typical exchanges that are observed when MPTCP is used with a SOCKS implementation is as follows:

=====
(MP Client) ->    TCP SYN    ->  (MCP)
                   <- TCP SYN/ACK <-
                   ->    TCP ACK    ->
                   -> SOCKS Method Request ->
                   <-    TCP ACK   <-
                    <- SOCKS Method Response  <-
                    ->   TCP ACK   ->
                    -> SOCKS Authentication Request ->
                    <-    TCP ACK     <-
                    <- SOCKS Auth. Response <-
                    ->   TCP ACK   ->
                    -> SOCKS Connection Request  -> (MCP)
                    <-   TCP ACK                   <- (MCP)
                                                      (MCP)  -> TCP SYN  -> (Server)
                                                      (MCP)  <- SYN/ACK  <- (Server)
                    <- SOCKS Connection Response   <-(MCP) -> TCP ACK -> (Server)
                    ->   TCP ACK  ->
======

or are you confusing it with this, which adds split TCP to a SOCKS proxy:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf

[Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior.

...
The same is true when you try to reinvent ways to interpret SYN data
before the MPTCP 3WHS completes - reinventing TFO without TFO's
protections.

[Med] Yes, I confirm.

Agreed.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Apr 2017 10:34:09 -0700

Med,

On 4/26/2017 12:11 AM, [email-masked] wrote:
> ...
>
> Trying to create standards to patch the broken idea of a NAT and make
> it less interfering with existing protocols is not the same thing as
> standardizing the NAT itself.
>
IMO, it is - it's a patch to help support the deprecation of IPv4 in the
global Internet. I don't see that as the role for an MPTCP proxy.

>
> The IETF has also a "Standards Track" document called SOCKSv5
> (RFC1928) that is splitting the TCP connection. We are adhering to the
> logic of that RFC but without the drawbacks of SOCKS.
>
>  
>
Nothing in RFC1929 talks about translating SYNs - it doesn't even
mention specific TCP segments at all, but refers only to the standard
TCP API, where user data would be available only after the 3WHS between
the client and the SOCKS proxy.

Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN
generating an outgoing SYN before the client SYN/ACK is returned. You
don't mention split-TCP (and it has taken more than too long to figure
out that's what's going on here), but that is what you show.
> [Med] Bingo. That is exactly my point. We need to avoid mixing
> implementation details with base specifications. That is exactly the
> reason why I said earlier that mptcp proxy documents only describe the
> external behavior.
>
OK, so keep ALL discussions of SYN (or any segment translation) out of
this document - including the figures.

If you can explain this using the existing TCP API, e.g.,
OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure.

But nowhere in that API does TCP tell you when a SYN arrives *before*
sending a SYN-ACK.

-----
As to your TFO argument, the problem is this:

    - what happens to the first MPTCP connection from proxy to proxy?
            why do you treat this differently than a typical MPTCP, and
what information lets you do so?

I don't see anything in this doc that qualifies as what TFO calls either
a cookie between sessions or any substitute based on authentication or
authorization.

I agree that you're not strictly cloning TFO - IMO, you're trying to
reinvent TFO without leveraging the experience the community has
developed in that process, and IMO you're repeating some of the mistakes
on that journey.

Joe

---

From: <[email-masked]>
Date: Thu, 27 Apr 2017 06:53:56 +0000

Hi Joe,

Please see inline.

Cheers,
Med

Envoyé : mercredi 26 avril 2017 19:34

Med,

On 4/26/2017 12:11 AM, [email-masked]<mailto:[email-masked]> wrote:
...
Trying to create standards to patch the broken idea of a NAT and make it less interfering with existing protocols is not the same thing as standardizing the NAT itself.
[Med] NAT64 (RFC6146) is not a patch AFAIK.
IMO, it is - it's a patch to help support the deprecation of IPv4 in the global Internet. I don't see that as the role for an MPTCP proxy.
[Med] The main point Joe is that the IETF has standard track documents that specify a TCP state machine when NAT is used. We are leveraging that state machine for the MPTCP proxy work.

Can you clarify where you see split TCP in RFC1928,
[Med] I don’t see “split TCP” in RFC1928 in the same way I don’t see “split TCP” in the plain-mode draft.
Nothing in RFC1929 talks about translating SYNs
[Med] I guess you meant RFC1928. Translating packets is not explicited in the text, but it is hinted. For example, the text says the following:

   When a TCP-based client wishes to establish a connection to an object
   that is reachable only via a firewall (such determination is left up
   to the implementation), it must open a TCP connection to the
   appropriate SOCKS port on the SOCKS server system.

How a connection from a client to a server with DST@=SOCKS_Proxy will be relayed to that remote server without gluing connections in both sides? That “glue” can be seen as translating packets by means of SNAT/DNAT.

(side note: I’m sure that RFC1928 will never be published as it is in 2017. I hear from here people that will argue that RFC1928 is underspecified)

- it doesn't even mention specific TCP segments at all, but refers only to the standard TCP API, where user data would be available only after the 3WHS between the client and the SOCKS proxy.
[Med] That’s also the case for the MPTCP proxy. The user data will be available ONLY once the 3WHS is completed.

Figure 5 of Sec 5.2 of your document clearly shows an incoming SYN generating an outgoing SYN before the client SYN/ACK is returned. You don't mention split-TCP (and it has taken more than too long to figure out that's what's going on here), but that is what you show.
or are you confusing it with this, which adds split TCP to a SOCKS proxy:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.9915&rep=rep1&type=pdf

[Med] Bingo. That is exactly my point. We need to avoid mixing implementation details with base specifications. That is exactly the reason why I said earlier that mptcp proxy documents only describe the external behavior.
OK, so keep ALL discussions of SYN (or any segment translation) out of this document - including the figures.
[Med] I’m personally fine with your proposal, but I’m sure we will have a lot of comments asking for more details. Figures are not normative; they are provided for illustration purposes.

If you can explain this using the existing TCP API, e.g., OPEN/CLOSE/ABORT/STATUS and SEND/RECEIVE (RFC793 Sec 3.9), then sure.

But nowhere in that API does TCP tell you when a SYN arrives *before* sending a SYN-ACK.

-----

    - what happens to the first MPTCP connection from proxy to proxy?
[Med] Do you mean the first MPTCP connection that is proxied? Or the first subflow of a proxied MPTCP connection?

            why do you treat this differently than a typical MPTCP, and what information lets you do so?
[Med] Can you please explicit your question? Are you referring to a multipath client, multipath server, or proxy?

-    No change is required for MPTCP-unaware clients and servers.

-    MPTCP processing at the MPTCP-aware server follows the base MPTCP specification.

-    MPTCP processing at the MPTCP-aware client in the dual-proxy case follows the base MPTCP specification.

-    MPTCP processing at the MPTCP-aware client in the single-proxy case will require to supply the MP_CONVERT in the initial subflow. A part from that, it follows the base MPTCP specification.

-   MPTCP processing at the proxy will require to process the MP_CONVERT information in order to create a forwarding state for that MPTCP connection. A part from that, it follows the base MPTCP specification.

I don't see anything in this doc that qualifies as what TFO calls either a cookie between sessions or any substitute based on authentication or authorization.
[Med] I already provided a pointer to the slides where this is discussed. You can also refer to draft-nam-mptcp-deployment-considerations-01#section-5.3<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#section-5.3>:

   The Network Provider that manages the various network attachments
   (including the MCPs) may enforce authentication and authorization
   policies using appropriate mechanisms.  For example, a non-exhaustive
   list of methods to achieve authorization is provided hereafter:

   o  The network provider may enforce a policy based on the
      International Mobile Subscriber Identity (IMSI) to verify that a
      user is allowed to benefit from the aggregation service.  If that
      authorization fails, the Packet Data Protocol (PDP) context
      /bearer will not be mounted.  This method does not require any
      interaction with the MCP.

   o  The network provider may enforce a policy based upon Access
      Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
      to control the CPEs that are authorized to communicate with an
      MCP.  These ACLs may be installed as a result of RADIUS exchanges,
      for instance ([I-D.boucadair-mptcp-radius<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#ref-I-D.boucadair-mptcp-radius>]).  This method does not
      require any interaction with the MCP.

   o  The MCP may implement an Ident interface [RFC1413<https://tools.ietf.org/html/rfc1413>] to retrieve an
      identifier that will be used to assess whether that client is
      entitled to make use of the aggregation service.  Ident exchanges
      will take place only when receiving the first subflow from a given
      source IP address.

   o  The device that embeds the MCP may also host a RADIUS client that
      will solicit an AAA server to check whether connections received
      from a given source IP address are authorized or not
      ([I-D.boucadair-mptcp-radius<https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#ref-I-D.boucadair-mptcp-radius>]).

I agree that you're not strictly cloning TFO - IMO, you're trying to reinvent TFO without leveraging the experience the community has developed in that process, and IMO you're repeating some of the mistakes on that journey.
[Med] I strongly disagree with this. We are leveraging on the guards as discussed in TFO specification:

-    Anti-spoofing filters are in place in the access segment.

-   TFO specification describes a cookie-less scheme if the server is immune.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Apr 2017 10:08:56 -0700

Med,

On 4/26/2017 11:53 PM, [email-masked] wrote:
> ...
>
> IMO, it is - it's a patch to help support the deprecation of IPv4 in
> the global Internet. I don't see that as the role for an MPTCP proxy.
>
> [Med] The main point Joe is that the IETF has standard track documents
> that specify a TCP state machine when NAT is used. We are leveraging
> that state machine for the MPTCP proxy work.
>

A NAT is - at best - a variant of a router.

MPTCP is not a router. It is a transport protocol stack.

You're not changing the TCP state machine - you're claiming that two TCP
connections are somehow tied together inside the TCP stack - that's a
fundamental change to the definition of TCP that is far outside the
scope of this WG.

> [Med] I guess you meant RFC1928. Translating packets is not explicited
> in the text, but it is hinted. For example, the text says the following:
>
>  
>
> How a connection from a client to a server with DST@=SOCKS_Proxy will
> be relayed to that remote server without gluing connections in both
> sides?
>
It's called a conventional proxy. The 3WHS completes to the SOCKS
server, then the SOCKS server opens a new connection.

"open a TCP connection" means finishing the 3WHS.

> That “glue” can be seen as translating packets by means of SNAT/DNAT.
>
>  
>
> (side note: I’m sure that RFC1928 will never be published as it is in
> 2017. I hear from here people that will argue that RFC1928 is
> underspecified) 
>

They can update that RFC if they want. However, that RFC specifies a
conventional application layer proxy - see Section 3.

>  
>
> - it doesn't even mention specific TCP segments at all, but refers
> only to the standard TCP API, where user data would be available only
> after the 3WHS between the client and the SOCKS proxy.
>
> [Med] That’s also the case for the MPTCP proxy. The user data will be
> available ONLY once the 3WHS is completed.
>

So a SYN arrives at the MPTCP proxy from the client. What happens next?

If the answer isn't "complete the 3WHS to the client", it's wrong. But
that's not what FIg 5 in your doc shows.

> [Med] I’m personally fine with your proposal, but I’m sure we will
> have a lot of comments asking for more details. Figures are not
> normative; they are provided for illustration purposes.
>

How do you achieve zero-delay E2E otherwise? Or are you assuming
zero-delay only within the MPTCP connection?

> [Med] Do you mean the first MPTCP connection that is proxied?
>
Yes.

> Or the first subflow of a proxied MPTCP connection?
>
>
> [Med] Can you please explicit your question? Are you referring to a
> multipath client, multipath server, or proxy?
>

I'm asking how the MPTCP connection between the two proxies is different
from a typical MPTCP connection as currently specified.

> -    MPTCP processing at the MPTCP-aware client in the single-proxy
> case will require to supply the MP_CONVERT in the initial subflow. A
> part from that, it follows the base MPTCP specification.
>
> -   MPTCP processing at the proxy will require to process the
> MP_CONVERT information in order to create a forwarding state for that
> MPTCP connection. A part from that, it follows the base MPTCP
> specification.
>
I'm less interested in the details of the MPTCP options than in how the
API changes.

The current MPTCP API opens initial connections only in response to user
calls to OPEN. That doesn't appear to be the case here.

>
> I don't see anything in this doc that qualifies as what TFO calls
> either a cookie between sessions or any substitute based on
> authentication or authorization.
>
> [Med] I already provided a pointer to the slides where this is
> discussed. You can also refer to
> draft-nam-mptcp-deployment-considerations-01#section-5.3
> <https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-01#section-5.3>:
>
>
>  
>

You're talking about authorizations of users and access control. TFO is
authorizing connections in order to decide if they're new or old.
They're different things.

> developed in that process, and IMO you're repeating some of the
> mistakes on that journey.
>

And I disagree that you have proven your server to be immune.

Joe

---

From: <[email-masked]>
Date: Fri, 28 Apr 2017 06:42:55 +0000

Hi Joe,

Please see inline.

Cheers,
Med

Envoyé : jeudi 27 avril 2017 19:09

Med,

On 4/26/2017 11:53 PM, [email-masked]<mailto:[email-masked]> wrote:
...
IMO, it is - it's a patch to help support the deprecation of IPv4 in the global Internet. I don't see that as the role for an MPTCP proxy.
[Med] The main point Joe is that the IETF has standard track documents that specify a TCP state machine when NAT is used. We are leveraging that state machine for the MPTCP proxy work.

A NAT is - at best - a variant of a router.
[Med] Hmm…a router does not act on port numbers.

MPTCP is not a router. It is a transport protocol stack.
[Med] Same as a NAT that relies on transport ports to demux connections. This is why we have TCP/UDP BEHAVE RFCs.

You're not changing the TCP state machine - you're claiming that two TCP connections are somehow tied together inside the TCP stack - that's a fundamental change to the definition of TCP that is far outside the scope of this WG.
[Med] We are not changing the TCP state machine, we are relying on the one defined in standards track IETF documents.

How a connection from a client to a server with DST@=SOCKS_Proxy will be relayed to that remote server without gluing connections in both sides?
It's called a conventional proxy. The 3WHS completes to the SOCKS server, then the SOCKS server opens a new connection.
[Med] The external behavior is that a received SYN will trigger an outgoing SYN. What happens inside the proxy itself is implementation-specific.

They can update that RFC if they want. However, that RFC specifies a conventional application layer proxy - see Section 3.

So a SYN arrives at the MPTCP proxy from the client. What happens next?
[Med] It extracts the address/port of the remote server and sends a SYN to that address/port.

If the answer isn't "complete the 3WHS to the client", it's wrong. But that's not what FIg 5 in your doc shows.
[Med] The proxy can (1) complete the 3WHS to the client; the document says the following:

   “Conceptually, the MCP acts as a relay between an upstream MPTCP
   connection and a downstream TCP connection.”

   “The MCP maps an upstream MPTCP connection (and its associated
   subflows) onto a downstream TCP connection.”

   “At this point, there are two established connections.  The endpoints
  of the upstream Multipath TCP connection are the Multipath TCP Client
   and the MCP.  The endpoints of the downstream TCP connection are the
   MCP and the Server.  These two connections are bound by the MCP.”

or (2) can proceed a la NAT (e.g., Fig 5).

We have trade-offs: if we complete the 3WHS before an answer is received from the server, we lose the following feature that we would like to offer:

Whether we need to have both or recommend one approach is be worked out once we have a WG document.
The specification is not frozen and your suggestions/comments will be taken into account.

How do you achieve zero-delay E2E otherwise? Or are you assuming zero-delay only within the MPTCP connection?
[Med] We are achieving 0-RTT MPTCP proxying because :

·         We don’t have out of band signaling to communicate with the proxy (for the record, there are +10 TCP messages when SOCKSv5 is in use).

·         The initial SYN includes the information about the ultimate server; that server will be contacted immediately.

For example, because we are leveraging on BEHAVE RFCs, a proxied MPTCP connections will experience the same delay as a TCP connection that goes through a CGN/NAT64.

-----

I'm asking how the MPTCP connection between the two proxies is different from a typical MPTCP connection as currently specified.
[Med] OK, thanks. It is not different.

-   MPTCP processing at the proxy will require to process the MP_CONVERT information in order to create a forwarding state for that MPTCP connection. A part from that, it follows the base MPTCP specification.
I'm less interested in the details of the MPTCP options than in how the API changes.

The current MPTCP API opens initial connections only in response to user calls to OPEN. That doesn't appear to be the case here.

-

You're talking about authorizations of users and access control. TFO is authorizing connections in order to decide if they're new or old. They're different things.
[Med] They are different things but achieve the same purpose: preserve the server from misuse/abuse/DoS. Whether MPTCP proxy has to check new/old connections is deployment-specific.

 ...

And I disagree that you have proven your server to be immune.
[Med] Can you provide an example of attack you have in mind for the MPTCP proxy?

Joe

---

From: "Meyer, Ullrich, Vodafone DE" <[email-masked]>
Date: Fri, 28 Apr 2017 12:31:01 +0000

Dear all,

herewith I want to declare very clearly our (Vodafone) interest on that
MPTCP proxy work within the IETF. The work has our plenary support.

Kind regards,

Ullrich Meyer 
Senior Engineer Service Design
VPN Solution Engineering within
Group Network Engineering and Delivery
FixLine: +49 69 2169 3290
Mobile: +49 172 190 3120
Email: [email-masked]

Vodafone GmbH, Düsseldorfer Straße 15, 65760 Eschborn
vodafone-deutschland.de 

Die gesetzlichen Pflichtangaben finden Sie unter
www.vodafone.de/pflichtangaben 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 25. April 2017 09:12
An: BOUCADAIR Mohamed IMT/OLN <[email-masked]>;
[email-masked]
Cc: [email-masked]
Betreff: RE: [multipathtcp] Consensus call on potential MPTCP proxy work

We interpreted them as indicating there was one topic that it was worthwhile
doing a consensus call on. We did not interpret the hums as indicating clear
consensus that we merely needed to confirm on the list.

So far we see:
In favour:
[email-masked]
[email-masked]
William Ivancic <[email-masked]> Stefano Secci
<[email-masked]> Henderickx, Wim (Nokia - BE/Antwerp)
<[email-masked]> David Allan I <[email-masked]>
[email-masked] Robert Skog <[email-masked]> Olivier
Bonaventure <[email-masked]>
Costin Raiciu <[email-masked]>

Against:

Thanks
Phil & Yoshi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 21 April 2017 07:55

[cut]

Lacking that information, I don't see a new element here that could lead to
change the consensus reached at the Chicago meeting (of course I'm not
entitled to do that call anyway).

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 08:46:28 -0700

Ullrich,

FYI - the IETF is a place for individual expression, not corporate
endorsement.

So you, individually, support this work. Nothing else.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 08:53:43 -0700

Med,

There are two possibilities, as I already stated:

    a) this is a conventional proxy, which is fine with me

    b) this is a split-TCP proxy, which is out of scope IMO for this
group and I do not support

It's not feasible to endorse this work while letting this issue "float".

The current doc is fairly clear on being (b).

I have made my position clear and given the appropriate ADs a heads-up.

Joe

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Apr 2017 20:23:11 +0200

>> that state machine for the MPTCP proxy work.

I think that's an important point.

> However, that RFC [1928, ed.] specifies a conventional application layer
> proxy

I think that's an important counterpoint.

-- Juliusz

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Apr 2017 11:57:00 -0700

> I think that's an important point.
And I think it is incorrect, at least for the split-TCP case.

At no point in the TCP state machine in RFC793 does the receipt of a SYN
cause a new SYN to be generated to a different destination.

Joe

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Apr 2017 21:46:30 +0200

> And I think it is incorrect, at least for the split-TCP case.

Yes, I think that what Mohammed is saying is that the "plain mode proxy",
as currently defined, requires NAT-style techniques.  I'd argue that this
makes it neither plain nor a proxy.

-- Juliusz