Re: [multipathtcp] draft minutes for montreal meeting

[Yoshifumi Nishida <[e-mail]>]

Hi Olivier,

Thanks for the reply.

On Wed, Aug 21, 2019 at 8:31 AM Olivier Bonaventure <
[e-mail]> wrote:

> Yoshi,
>
> > 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 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.
>

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?

>
> >    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.
>

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