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

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:

> 
> 
> On 3/8/2013 10:10 AM, Mark Handley wrote:
>> On 8 March 2013 15:17, Joe Touch <touch@isi.edu> 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.
>> 
>> I think we're all agreed on that.
>> 
>>> 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.
>> 
>> 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.
> 
> 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
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp