Subject: [tcpm] Fwd: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 8 Mar 2013 10:14:48 +0000

Of interest to TCPM as well.

Begin forwarded message:

> From: Christoph Paasch <[email-masked]>
> Subject: [multipathtcp] Negotiating TCP extensions in the SYN-SYN/ACK
> Date: March 8, 2013 10:58:38 GMT+01:00
> To: MultiPath TCP - IETF WG <[email-masked]>
> Reply-To: <[email-masked]>
> 
> Hello,
> 
> when contacting baidu.com with an MPTCP-enabled host, I get the following trace [1]:
> 
> 10:38:33.143356 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [SEW], seq 2335683601, win 14600, options [mss 1460,sackOK,TS val 1289882 ecr 0,nop,wscale 7,MPTCP capable csum {0xc3ff03119078160a}], length 0
> 10:38:33.608817 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [S.], seq 337140084, ack 2335683602, win 14600, options [mss 1380,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,MPTCP capable csum {0xc3ff03119078160a}], length 0
> 10:38:33.608888 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [.], ack 1, win 14600, options [MPTCP capable csum {0xc3ff03119078160a,0xc3ff03119078160a},MPTCP add-addr id 1 130.104.123.102], length 0
> 10:38:33.608966 IP 130.104.228.20.48246 > 220.181.111.147.80: Flags [P.], seq 1:116, ack 1, win 14600, options [MPTCP add-addr id 8 2001:6a8:3080:2:21a3:6c82:e826:6625,MPTCP dss ack 2999963583 seq 2999963583 subseq 1 len 115 csum 0x101], length 115
> 10:38:34.075539 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [.], ack 116, win 5840, length 0
> 10:38:34.081765 IP 220.181.111.147.80 > 130.104.228.20.48246: Flags [P.], seq 1:459, ack 116, win 5840, length 458
> 
> 
> 
> So, baidu.com replies to a SYN+MP_CAPABLE with a SYN/ACK+MP_CAPABLE !
> 
> What they seem to do is to NOP all the undesired known options and echo the unknown ones in the SYN/ACK. (would have been too good to be true that they already support MPTCP ;))
> 
> The client will think that MPTCP is supported by the server, as the SYN/ACK has the MP_CAPABLE option.
> However, thanks to the fallback described in Section 3.6 of the RFC, the client will detect that the server actually does not support MPTCP and do a seamless fallback to regular TCP after it received the first ack without DATA-ACK.
> 
> 
> This shows how important it is that TCP extensions should not only rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP option.
> 
> 
> Cheers,
> Christoph
> 
> 
> [1] I use the modified tcpdump implementation with MPTCP-support:
> https://github.com/multipath-tcp/tcpdump
> 
> 
> -- 
> IP Networking Lab --- http://inl.info.ucl.ac.be
> MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be
> UCLouvain
> --
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Joe Touch <[email-masked]>
Date: Fri, 08 Mar 2013 07:19:08 -0800

Hi, all,

I'll replicate my conclusions on this here:

----

> What they seem to do is to NOP all the undesired known options and
> echo the unknown ones in the SYN/ACK. ...

That's easy to debug - it's a major error of their stack, and needs to 
be corrected.

There is no reason to address this in mptcp or any other option.

 > This shows how important it is that TCP extensions should not only
 > rely on the SYN-SYN/ACK exchange to negotiate support for a new TCP 
option.

I disagree; it shows the impact of an incorrect implementation. "Be 
generous in what you receive" doesn't include this sort of case.

Joe