Early Review of draft-ietf-tcpm-accurate-ecn-14
review-ietf-tcpm-accurate-ecn-14-secdir-early-kelly-2021-04-15-00

Request Review of draft-ietf-tcpm-accurate-ecn-14
Requested revision 14 (document currently at 28)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2021-04-01
Requested 2021-03-06
Requested by Yoshifumi Nishida
Authors Bob Briscoe , Mirja Kühlewind , Richard Scheffenegger
I-D last updated 2021-04-15
Completed reviews Secdir Early review of -14 by Scott G. Kelly (diff)
Comments 
The main security concern for this draft is covert channel discussion which is described in the 4th paragraph in Security Consideration section.
In a nutshell, the TCP option defined in the draft can contain up to 29 byte length of undefined information for future extensions. 
However, there are some opinions that this could be utilized as a covert channel.  
As a PS doc, this draft mandates middleboxes not to remove or alter the option (Section 3.3.2) and 29 bytes is relatively large space, one may want to encode some meaningful info inside it.
This might be used for tracking or other malicious purposes, although this may not be specific to this option.

We would like to check on this point with early SECDIR reviews before finalizing the document.  We appreciate if we could get reviews on other points as well.
Assignment Reviewer Scott G. Kelly
State Completed
Request Early review on draft-ietf-tcpm-accurate-ecn by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/dCPV35Bo6lnn19jMvMBfLuH6PHs
Reviewed revision 14 (document currently at 28)
Result Has issues
Completed 2021-04-12
review-ietf-tcpm-accurate-ecn-14-secdir-early-kelly-2021-04-15-00
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