Subject: [multipathtcp] draft minutes for montreal meeting

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 15 Aug 2019 13:40:20 -0700

Hi,
Sorry for the delay. I uploaded a draft minutes for montreal meeting.
You can take a look at the URL below.
Please let the chairs know if you have corrections, suggestions or
questions.

https://datatracker.ietf.org/doc/minutes-105-mptcp/

Thanks,
--
Yoshi & Phil

---

From: <[email-masked]>
Date: Wed, 21 Aug 2019 11:20:43 +0000

Yoshi,
(about MPTCP + TLS) <<   Chairs:
       Anybody interested in helping Alan?
       (Note: someone was interested. but, cannot identify the name..)
my notes say “Yoshi and presumably Olivier”
(about future of WG)
<< ???:
       +1 In the past, there was general interest in the active documents.
       Some of the active individual drafts are relevant.
My notes say Sri
phil

From: multipathtcp [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: 15 August 2019 21:40
To: multipathtcp <[email-masked]>
Subject: [multipathtcp] draft minutes for montreal meeting

Hi,
Sorry for the delay. I uploaded a draft minutes for montreal meeting.
You can take a look at the URL below.
Please let the chairs know if you have corrections, suggestions or questions.

Thanks,
--
Yoshi & Phil

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 21 Aug 2019 15:31:52 +0000

Yoshi,

> https://datatracker.ietf.org/doc/minutes-105-mptcp/

Thanks for sharing these detailed minutes. I have some comments after 
having read them.

> 
>    Keith Moore:
>        Is there support in the room for working on a secure (encrypted) version
>        of MPTCP?
> 
>    Chairs:
>        Show of hands: How many would be willing to work on an encrypted version.

We proposed such a design in an infocom paper, see
https://inl.info.ucl.ac.be/publications/secure-multipath-tcp-design-impementation.html
There was running code on Linux but we have not maintained it since 
publication.
> 
>    Mirja (as individual):
>        If you want encryption, use QUIC.
> 
>    Chairs:
>        Would work on be a bad idea?
>        (a couple) and why?
> 
>    Nicolas P:
>        I think it's too heavy. Would require encryption of options. >
>    Yoshi:
>        TCPINC was oribinally intended to be used for MPTCP. But, it does not
>        encrypt options. Do we want to create an updated version?
> 
>    Mirja:
>        There is zero deployment of TCPINC. I would suggest to first get
>        deployment experience.

If people want to experiment with our implementation, this should be 
possible. My personal viewpoint is that adding full security to MPTCP is 
probably too difficult at this stage if the objective is to have a 
deployable solution.
> 
>    Markus:
>        Will there be another meeting at IETF 106?
> 
>    Chairs:
>        No decision has been made so far.
> 
>    Alan Ford (on Jabber):
>        MPTCP + TLS was proposed some time ago.
> 
>    Yoshi:
>        Someone wants to revive this?
> 
>    Alan Ford (on Jabber):
>        If someone is interested, I would contribute. The proposal was to use
>        TLS key extraction for the session security. It was only a 4 page draft
>        in -00. If there was interest in encryption at transport level, I would
>        suggest to use this as a starting point.
> 
>    Mirja:
>        If there is interest, bring it to the TLS working group.
> 
>    Marcelo:
>        TLS is used as it is.
> 
>    Mirja:
>        TLS may not be happy about an interface to expose the keys.

We also had an implementation of this approach. If would probably need 
to be updated now that TLS 1.3 has been published and that kTLS is 
available in the Linux kernel. In a nutshell, the idea was to derive two 
additional TLS keys (i.e. different keys than the ones used to 
authenticate and encrypt data) and give them to MPTCP to replace the 
keys that are exchanged during the handshake. This improves the security 
of the addition of new subflows but does not counter attacks where an 
attacker modifies encrypted payloads.

I can participate in the discussion on this if there is interest.

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 26 Aug 2019 00:27:34 -0700

Hi Phil,

Thanks for the info. I have uploaded an updated version.
--
Yoshi

On Wed, Aug 21, 2019 at 4:20 AM <[email-masked]> wrote:

> *From:* multipathtcp [mailto:[email-masked]] *On Behalf Of
> *Yoshifumi Nishida
> *Sent:* 15 August 2019 21:40
> *To:* multipathtcp <[email-masked]>
> *Subject:* [multipathtcp] draft minutes for montreal meeting
>
>
>
>
>
> Hi,
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 26 Aug 2019 00:28:08 -0700

Hi Olivier,

Thanks for the reply.

> There was running code on Linux but we have not maintained it since

Thanks for the pointer. I think this is an interesting approach.
As far as I know this has not been presented at the WG yet, not written in
an I-D. Am I correct?

> probably too difficult at this stage if the objective is to have a

Thanks for the inputs.
Just to be clear, is this approach to extend ENO as described in the
infocomm paper?
--
Yoshi