[secdir] secdir review of draft-ietf-tcpm-accurate-ecn-14

["Scott G. Kelly" <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Almost Ready.

The title of this draft is, "More Accurate ECN Feedback in TCP". The document specifies a scheme (abbreviated AccECN) to provide more than one feedback signal per RTT in the TCP header. It does this by allocating a reserved header bit that was previously used for the ECN-Nonce (which has now been declared historic), and it overloads the two existing ECN flags in the TCP header.

I'm not a TCP or ECN expert, so please take my comments with a proverbial grain of salt. Thinking about this strictly as a security geek, I see three places where this scheme could be tampered with: the sender, the receiver, and the network in between them. 

The security considerations section starts off by pointing out that there will be consequences to tampering by a middlebox (the network in between), and it describes the impact as limited. 

A malicious sender is not described, and I'm not sure that any such thing reasonably exists, but I did wonder about this.

A malicious receiver (who might be motivated to interfere with AccECN in order to increase its own throughput at the expense of others) is described, and the reader is referred to section 5.3, which describes 3 different potential mitigations for this. There is also mention of the fact that the receiver might simply omit the option, pretending it had been stripped by a middlebox, but there is no known consequence (other than downgrading to plain ECN).

There is a TODO in the security considerations which must be addressed (referring to a potential covert channel), and that's why the review summary is "Almost Ready". I suggest that the security AD might want someone both TCP and security expertise to evaluate this. 


--Scott