RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Good suggestion, Tom. Thanks. Cheers, Med > -Message d'origine- > De : Tom Herbert [mailto:t...@herbertland.com] > Envoyé : jeudi 20 juillet 2017 17:39 > À : BOUCADAIR Mohamed IMT/OLN > Cc : Joe Touch; Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet : Re: [Int-area]

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On Thu, Jul 20, 2017 at 8:26 AM, wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -Message d'origine- >> De : Joe Touch [mailto:to...@isi.edu] >> Envoyé : jeudi 20 juillet 2017 16:37 >> À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-, Please see inline. Cheers, Med > -Message d'origine- > De : Joe Touch [mailto:to...@isi.edu] > Envoyé : jeudi 20 juillet 2017 16:37 > À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; tsv- > a...@ietf.org > Objet : Re: [Int-area] Middleboxes to aid the deployment

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On 7/19/2017 10:43 PM, mohamed.boucad...@orange.com wrote: > ... >>> The converter is not intended to be used for all TCP connections. In >>> the draft we explain how an MPTCP endpoint can bypass the converter if >>> the destination server supports MPTCP. For TCP-AO, my recommendation >>> would

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On 7/19/2017 10:39 PM, mohamed.boucad...@orange.com wrote: > Hi Joe, > > The text can always be worked out. This is not an IETF LC :) Agreed - I was explaining that the current text - and many of the responses in this chain, both from you and others, continues to be confusing. > The main point

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-, Please see inline. Cheers, Med > -Message d'origine- > De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch > Envoyé : mercredi 19 juillet 2017 21:58 > À : Olivier Bonaventure; Internet Area; tsv-area@ietf.org > Objet : Re: [Int-area] Middleboxes to aid the

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Joe, The text can always be worked out. This is not an IETF LC :) The main point is that we are following your suggestion to define the solution as an application proxy using a dedicated port number. Cheers, Med > -Message d'origine- > De : Joe Touch [mailto:to...@isi.edu] >

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On 7/19/2017 11:43 AM, mohamed.boucad...@orange.com wrote: > I don't understand your argument here, especially because you are the one who > proposed me the following (check mptcp archives, April 20, 2017) which we > endorsed in the latest version of the specification: > > "If that were the

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On 7/19/2017 11:39 AM, mohamed.boucad...@orange.com wrote: >> Doing tricks to demonstrate that an attacker (i.e., something that >> modifies TCP segments on path) can do otherwise should not be considered >> a viable alternative. > [Med] We are defining an application proxy that assist the user

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-, I don't understand your argument here, especially because you are the one who proposed me the following (check mptcp archives, April 20, 2017) which we endorsed in the latest version of the specification: "If that were the case, you'd simply be defining a new application service and

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-, Please see inline. Cheers, Med > -Message d'origine- > De : Joe Touch [mailto:to...@isi.edu] > Envoyé : mercredi 19 juillet 2017 18:36 > À : BOUCADAIR Mohamed IMT/OLN; Erik Kline > Cc : Tom Herbert; Internet Area; tsv-area@ietf.org > Objet : Re: [Int-area] Middleboxes to aid the

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Joe, As mentioned in a previous message in this thread, TCP-AO extensions (6978) to pass NATs will be required otherwise TCP-AO will fail because of: -Manipulating multiple addresses -At least one of the source IP addresses will be rewritten. The proxy design does not induce a new

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

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

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Tom, Network providers don't control CPE is either. I know iOS has support for MPTCP, AFAIK Android does not (Erik is that correct?). If Android were shipping it that would be a strong datapoint towards getting support in Linux. In South Korea, at least 8 popular models of Android smartphones

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On Wed, Jul 19, 2017 at 1:46 AM, wrote: > Hi Erik, > > That's the intuitive approach to follow but unfortunately the situation is > not that obvious to get into. > I can give a little background on the Linux situation. There have been several attempts to get MPTCP

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Tom, Do you have in mind such use cases when you referred to the "stateful firewalls model"? One of the problems with stateful firewalls (as well as transparent proxies) is that they require all packets for a flow to consistently traverse the same middlebox device. The middlebox is not

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-, Please see inline. Cheers, Med > -Message d'origine- > De : Tom Herbert [mailto:t...@herbertland.com] > Envoyé : mercredi 19 juillet 2017 17:45 > À : BOUCADAIR Mohamed IMT/OLN > Cc : Joe Touch; tsv-area@ietf.org; Internet Area > Objet : Re: [Int-area] Middleboxes to aid the

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On Tue, Jul 18, 2017 at 11:37 PM, wrote: > Hi Tom, > > Please see inline. > > Cheers, > Med > >> -Message d'origine- >> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Tom Herbert >> Envoyé : mercredi 19 juillet 2017 00:43 >> À : Joe Touch >>

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Erik, That's the intuitive approach to follow but unfortunately the situation is not that obvious to get into. Network providers do not have a control on the servers and the terminals that are enabled by customers behind the CPE. So making use of MPTCP to grab more resources (when

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Joe, Please see inline. Cheers, Med De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch Envoyé : mercredi 19 juillet 2017 01:12 À : Olivier Bonaventure; Internet Area; tsv-area@ietf.org Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP On 7/18/2017

RE: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Tom, Please see inline. Cheers, Med > -Message d'origine- > De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Tom Herbert > Envoyé : mercredi 19 juillet 2017 00:43 > À : Joe Touch > Cc : tsv-area@ietf.org; Internet Area > Objet : Re: [Int-area] Middleboxes to aid the

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On 7/18/2017 3:43 PM, Tom Herbert wrote: >> TCP must be E2E and fall back to legacy endpoints without a reconnection >> attempt, as required by RFC793. >> >> These aren't generic solutions; they're attacks on a TCP connection, IMO. >> > I agree. This seems be akin to stateful firewalls model

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote: > Hi, all, > > I've noted this before, but to share with other areas: > > Although I'm not averse to middleboxes as optional optimizations, I find > the proposed mechanisms aren't quite optional -- they inject option > information