[tcpm] Security issues of AccECN (was: RE: AccECN field order)

["Scharf, Michael" <[e-mail]>]

Only on remark [ms2] regarding the issue of a covert channel due to „forward compatibility“…

From a security perspective, it is not clear to me whether allowing arbitrary unspecified bytes in a TCP option is a good idea *at all*. It will be interesting to hear the opinion from SEC area on that. Personally, I am not convinced that this really makes sense, but I my concerns are not strong enough to formally push back. I’ll leave it to others to think about whether this is a bug or a feature.

[BB] Well, let's first try to deal with security ourselves:
* Octets that are explicitly declared as part of an option cannot be used for a buffer overflow attack. I don't really need to, but I could add the following text to the forward compatibility wording:
    A receiver considers octets beyond those it uses, but within the specified length, as if they are padding.
* And such octets cannot be any different from the current ability of a sender to add padding. So there's no new attack possible here.
* And there's no need to specify a max length for any AccECN Option, which would just unnecessarily limit flexibility.

[ms] I have more thought about the covert channel that some unspecified bytes in a standards track TCP option could offer… In particular if the AccECN option gets widely deployed and used, would some malicious users find those bytes useful? For what? For instance, what in the AccECN protocol design prevents use of these “padding” bytes as super-cookie? To me, it is much more important to think about abuse of whatever we standardize *now*, instead of engineering for some entirely unknown future. I am not a security expert, but I suggest a careful analysis of any security implications of the AccECN option. We seldomly specify new TCP options and malicious users will certainly look for “opportunities” in the spec. So far, I don’t know whether that whole idea of forward compatibility is a feature or a bug.

[BB] If that were a problem, it could already be done, because (by my reading of RFC793) it is valid to set the data offset to stretch out the padding to any length within the max option space limits.

[ms2] I don’t understand. RFC 793 mandates that padding is composed of zeros, i.e., a firewall or IDS could detect a non-zero covert channel in the padding (and even remove the padding). Also, there are IMHO no reasonable engineering reasons for making the padding longer than needed, i.e. such a covert channel could be detected as anomality. As far as I understand RFC 793, a middlebox could also safely remove the additional padding w/o impacting a standard-compliant TCP connection.

[ms2] Allowing arbitrary bytes in a TCP option is IMHO a very different story, in particular if you allow the values to have non-zero values and forbid middleboxes to check or remove parts of the option that are not standardized by the IETF. If I correctly understand draft -13, an attacker could transmit 29 bytes payload at the end of the AccECN option, in any TCP connection, for any purpose.

[ms2] I think the „forward compatibility“ (e.g., Section 3.3.2 in the I-D) needs a very careful security analysis. As far as I understand, this whole idea of „forward compatibility“ is not needed for using the *currently* standardized AccECN options. IMHO you could just remove that „forward compatibility“ idea w/o impacting the rest of the AccECN protocol as currently specified (including the current format of the two options). If the idea of „forward compatibility“ stays in the document, IMHO the security section needs a dedicated discussion regarding potential misuse as covert channel. This could either be a security or privacy issue, depending on who puts what additional bytes into the option and claims that these bytes to be AccECNv2.

Michael