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

From: Christoph Paasch <[email-masked]>
Date: Fri, 08 Mar 2013 10:58:38 +0100

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

---

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

On 3/8/2013 1:58 AM, Christoph Paasch wrote:
> 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

---

From: Mark Handley <[email-masked]>
Date: Fri, 8 Mar 2013 18:10:54 +0000

On 8 March 2013 15:17, Joe Touch <[email-masked]> wrote:
> That's easy to debug - it's a major error of their stack, and needs to be
> corrected.

I think we're all agreed on that.

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

Unfortunately that's the same reason ECN is still largely undeployed
15 years on - new functionality really must not cause previously
working things to break, even if other people have done stupid things.
 Otherwise you get condemned in the real world as undeployable and
join the very large stack of other undeployed RFCs.

MPTCP gets this right, though not for this reason - the same check is
needed for option-stripping middleboxes on the return path to avoid
the server thinking something has been negotiated and the client
thinking it has not.

- Mark

---

From: Joe Touch <[email-masked]>
Date: Fri, 08 Mar 2013 10:14:37 -0800

> the server thinking something has been negotiated and the client

Well, I'd rather not see new TCP options expect to have to have an 
active challenge-response *solely* to get around this sort of error.

Joe

---

From: Michio Honda <[email-masked]>
Date: Fri, 8 Mar 2013 23:06:46 +0100

Just a note, we should distinguish middleboxes from buggy endpoints.
Exchanging options on data packets just confirms that a middlebox does not affect options.
Preventing from such a buggy endpoint should happen independently, for example, defining a rule like "Returning value of the option MUST differ from the original one".

Cheers,
- Michio

On Mar 8, 2013, at 7:14 PM, Joe Touch wrote:

> Well, I'd rather not see new TCP options expect to have to have an active challenge-response *solely* to get around this sort of error.
> 
> Joe
> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

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

Hi, Michio,

> Preventing from such a buggy endpoint should happen independently, for example, defining a rule like "Returning value of the option MUST differ from the original one".

That works, but it then requires that options include parameters so that 
the return value can vary. TCP is not overall designed to be robust to 
buggy or incorrect implementations, and adding this capability for 
options just encourages wasted space in the SYN and SYN/ACK - precisely 
where we have the least of it available.

Joe