Subject: [multipathtcp] Today's session

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Nov 2010 09:42:50 +0100

I was again listening to IETF radio on my way to work today... A few points about today's session:

- security

A big risk with any kind of mobility or multihoming is redirection attacks. In the case of multipath TCP that would be where A and B communicate and C sets up a subflow to A claiming to be B. This is an issue that doesn't exist in traditional TCP so in order to be equally secure to existing TCP this needs to be solved. Exchanging keys in the clear solves this problem for off-path attackers, but not for attackers with sniffing capability. Diffie-Hellman or hash chains protect against attackers with sniffing capability but not agains attackers that can modify packets. The latter can perform men in the middle attacks against Diffie-Hellman or hash chains, but attackers with this capability don't need the redirection attack anyway. Also, the sniffing capability is pretty common, the modification capability isn't.

- data centers

The assumption that hosts in a datacenter would be sending data at line rate as a single session seems highly artificial to me. First of all, LAN technologies are not meant to provide 100% bandwidth 100% of the time. If everyone in an apartment building jumps under the shower at the same time water doesn't come out at full rate either. So getting 500 Mbps to the outside for each host is not necessarily a problem. Second, local bulk data transfer is not the most common type of communication in my experience, usually servers in data centers talk to large numbers of systems in the outside world so they use a number of separate sessions concurrently, so ECMP can work adequately without having multipath.

- checksums vs bit error rates

Andrew seemed to take Costin's remark about checksums in the datacenter to mean that the TCP checksum would be disabled. That's not what he was talking about. And even if it was, the ethernet bit error rates would be largely meaningless because of the 32-bit CRC used with ethernet. But what Costin was talking about was disabling the _extra_ checksums that would detect the modification of data by middleboxes. So in all cases the regular TCP checksum would still be present.

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 10 Nov 2010 16:55:02 +0800

Hi Iljitsch,

> The assumption that hosts in a datacenter would be sending data at line rate as a single session seems highly artificial to me. First of all, LAN technologies are not meant to provide 100% bandwidt…

I agree with you that server - client chat doesn't necesarily generate that much traffic. The traffic patterns I was refering to are intra data center, running apps like Map Reduce and Google File System. There huge amounts of data get shifted when doing computations on the locally-saved web.

Cheers,
Costin