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]
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-,
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
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
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-,
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
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]
>
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
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-,
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-,
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
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
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
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
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
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-,
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
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
>>
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
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
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
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
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
23 matches
Mail list logo