Subject: Re: [QUIC] Multipath configuration WAS: QUIC privacy impact

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 24 May 2016 19:17:40 +0000

>Without knowing the protocol mechanism and specifically the security and
>privacy considerations, how should I be able to answer this?

Fair point. Just wanted to ensure I understood you correctly.

>
>Yet, for enabling/disabling multipath, I would suggest something
>equivalent to RFC 6897 Section 4.5 and possibly something like REQ1 in
>Section 5.2 in the same RFC (the latter is related to TAPS).
>
>I am an author of RFC 6897 and thus maybe I am biased here. But there was
>pretty strong consensus in the working group on those two sections, i.e.,
>that there must be a way to turn on and off multipath. Does this make
>sense to you?

Got you. It does. 

Tnx

Regards
Göran

>
>Michael
>
>
>
>-----Original Message-----
>From: Göran Eriksson AP [mailto:[email-masked]]
>Sent: Tuesday, May 24, 2016 3:07 PM
>To: Scharf, Michael (Nokia - DE); Jana Iyengar; Christian Huitema
>Cc: Olivier Bonaventure; Kyle Rose; Ryan Hamilton; Mark Nottingham; Brian
>Trammell; [email-masked]
>Subject: Re: [QUIC] QUIC privacy impact
>
>
>
>>So the bar for security and privacy is TCP, in my point of view.
>>Actually, there is no need to mention MPTCP at all. If lowering of
>>security and privacy standards compared to TCP is required, as
>>mentioned before, the charter could mention that the protocol design
>>can foresee additional, entirely optional additional protocol features,
>>on an opt-in basis.
>
>I am trying to understand what you are saying here; a) does it mean that
>user should “opt-in” to additional features and b) is multi path such an
>additional “feature”?
>
>Regards
>Göran
>