Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option

[Pasi Sarolahti <[e-mail]>]

On 20 Jul 2015, at 11:49, Scheffenegger, Richard <[e-mail]> wrote:

>> * It is required that at most one Echo option is included per segment. Is
>> there any reason to limit the number of options? I couldn't immediately
>> see why having multiple instances of the option would cause problems, or
>> could it?
> 
> Yes, there are issues with that, and they are plentiful. The easy way out was to side-step this, and only allow (just as with every other TCP option so far) only a single instance of the option, and only reflect the option most recently observed by the receiver.
> 
> Issues include, but are not limited to
> o) semantics
> o) ordering
> o) meddleboxes
> o) receiver state
> o) implementation issues

Ok. I thought that “just echo what you saw in latest segment” might have been sufficient, perhaps in the same order than in incoming packet. Middleboxes might have issues even with single option.

So if there were multiple different uses for this mechanism, one would need to make a choice, or bundle the data somehow.

The semantics of what to echo seems difficult question even with single option: if the first segment includes the option and second does not, and ACK is sent only after the second segment, is it correct to echo the option from the first segment? This is pretty difficult to answer without knowing what the intended uses are. It could be that different uses need different semantics.

>> * "A TCP sender MAY send an empty TCP Echo option with Length=2 on the
>> SYN..." - this would not have to be limited just to SYNs, right? Can't think
>> of any useful reason for sending empty echo pings mid-connection (some
>> sort of diagnostics, perhaps?), but can't see any reason to disallow that
>> either. Also, it might be helpful clarification to note that when ExID is
>> used, length will be different.
> 
> We did not want this document to specify a full in-session negotiation protocol - as that problem has been discussed on the list earlier, it's a hard issue and beyond the scope of what we want to achive with this draft.

I did not propose in-session negation, but only asked if it is possible to send a zero-payload Echo option? Might be silly, but does not seem harmful. Now that I better read the draft, it seems to allow this in earlier text, which is ok, I guess.

>> * "it is NOT RECOMMENDED to send easily decipherable data in the clear as
>> data in the TCP Echo option..." - I don't think this recommendation is
>> necessary. Depends on the intended use, I guess. There are other ways for
>> encrypting TCP header when that is needed.
> 
> Even when only the receiver can decode (or make educated guesses about) the contents of a field that is supposed to be immutable, it has shown issues in the past (reference early cubic implementations, that could be persuaded to give very large shares of bandwidth to a receiver that slightly modifies the TCP timestamp echo value). We also believe that this recommendation (not even a SHOULD or MUST) is in-line with RFC7258. 

Fine, it may be necessary to protect against cheating receivers, depending on what the option is used for. Ideally RFC 7258 should be addressed with a common solution so that one does not need to obfuscate each protocol field or option separately. But as you say, the language here is not too restrictive.

- Pasi