Subject: [multipathtcp] Security etc

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Nov 2010 11:32:54 +0100

I was listening to the audio as I walked to work...

Is there any particular reason why the MPTCP security can't be based on a Diffie-Hellman key exchange? This would seem perfectly suited to the problem at hand.

I was also wondering if it would be useful to exchange MPTCP signaling in the data stream as out-of-band data. I'm not sure how OOB is implemented in TCP today, but if we're lucky this data is simply ignored. In that case it would be a good place to put the signaling.

However, there is no reason that this can't be done in options, even if the data that needs to be exchanged is large: we could implement a lightweight (and irony-proof) reliable transport that rides on TCP options that simply segments the data into pieces that fit into the option space.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 08 Nov 2010 06:32:31 -0500

> I was also wondering if it would be useful to exchange MPTCP signaling in the data stream as out-of-band data. I'm not sure how OOB is implemented in TCP today, but if we're lucky this data is simp…

There is no OOB data in TCP; there's an urgent pointer, but there are 
enough problems with it that it can't be used here:
http://tools.ietf.org/html/draft-ietf-tcpm-urgent-data-07

> However, there is no reason that this can't be done in options, even if the data that needs to be exchanged is large: we could implement a lightweight (and irony-proof) reliable transport that ride…

That's true; this kind of thing has been done before, and can work. 
However, it does involve a bit of effort that may be bigger than MPTCP's 
scope.