Subject: [multipathtcp] Fwd: [tcpinc] Going forward without protecting TCP headers

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 11 Mar 2015 23:17:31 -0700

Hi,
I'm guessing this may have some impacts on mptcp.
If tcpinc go to this direction, are we going to use solutions like
draft-bonaventure-mptcp-tls-00 for prong 2 approach?

Thanks,
--
Yoshi

---------- Forwarded message ----------
From: Tero Kivinen <[email-masked]>
Date: Wed, Mar 11, 2015 at 5:24 AM
Subject: [tcpinc] Going forward without protecting TCP headers
To: [email-masked]

In the Honolulu meeting we had long discussion about whether to
protect the TCP headers or not. There were several people who
considered the main idea of tcpinc, to be to protect against
passive attacks, and did not care that much about active attacks,
i.e. didn't care for protection of the TCP headers. There were
also few people in favor of protection of header bits, i.e.
protect against active attacks.

Everybody wanted to protect data for integrity, i.e. MAC of data
stream and protection against replay. As most people in he
meeting did not seem to want to have protection against active
attacks, it was decided that those people who do want protect TCP
header, would send email to the list and explain why they want it
and what features needs to be protected.

I sent out the request for such comments at 2014-11-15:

http://www.ietf.org/mail-archive/web/tcpinc/current/msg00393.html

In my analysis of the email thread, there were two people who
said they would like to have some TCP features to be protected:

http://www.ietf.org/mail-archive/web/tcpinc/current/msg00396.html
http://www.ietf.org/mail-archive/web/tcpinc/current/msg00403.html

There were more than dozen people discussing this in the meeting, and
while people expressed opinions supporting the two options, we believe
that there is more support for going for not protecting the header.
Moreover, we believe that at this stage it is more important to make a
decision and move forward.

Based on this the tcpinc chairs have decided that we will go with
the option of NOT protecting the TCP headers.

This means that in Dallas IETF we should work forward based on
this decision.
--
[email-masked]

_______________________________________________
Tcpinc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 12 Mar 2015 08:40:37 +0100

Yoshifumi,

> draft-bonaventure-mptcp-tls-00 for prong 2 approach?

I think that Multipath TCP would be a better starting point than TCP for 
the TCPINC work because Multipath TCP brings two important benefits :
  - Multipath TCP already includes a way to deal with RST attacks
  - Multipath TCP enables the utilisation of multiple paths, which 
brings a new dimension to the problem space.

With Multipath TCP, a host that detects a problem on a path (e.g. MAC 
failure) can opt to stop using this path and move the connection to 
another path to hopefully counter the attacker. With regular TCP, this 
is not possible. The MPTCP working has shown that with RFC6824 and the 
deployed MPTCP stack it is already possible to deal with various types 
of middleboxes. If there is middlebox interference on a path and several 
paths exist, MPTCP implementations already stop using the path with 
interference.

I think that draft-bonaventure-mptcp-tls-00 could be a very good 
starting point to design a TCPINC like solution for MPTCP, but of course 
my viewpoint might be biased...

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 14 Mar 2015 14:22:37 -0700

Hi Olivier,

On Thu, Mar 12, 2015 at 12:40 AM, Olivier Bonaventure <
[email-masked]> wrote:

>  - Multipath TCP enables the utilisation of multiple paths, which brings a
> new dimension to the problem space.

> failure) can opt to stop using this path and move the connection to another
> path to hopefully counter the attacker. With regular TCP, this is not
> possible. The MPTCP working has shown that with RFC6824 and the deployed
> MPTCP stack it is already possible to deal with various types of
> middleboxes. If there is middlebox interference on a path and several paths
> exist, MPTCP implementations already stop using the path with interference.
>

It might be a good starting point, but one concen is tcpinc is focusing on
TCP in general.
The solution for mptcp may not be applied to other situations, which won't
be applicable for tcpinc.
We might need to explore solutions without relying on tcpinc.

I think that draft-bonaventure-mptcp-tls-00 could be a very good starting
> point to design a TCPINC like solution for MPTCP, but of course my
> viewpoint might be biased...

I also think so.
Another possibility is to cherry-pick the ideas proposed for tcpinc or
check some authors to update them for mptcp.

Thanks,
--
Yoshi