[tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

Hi all,

While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:


Section 1. Introduction

   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
   ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].

[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?


Section 2.1.  Capability Negotiation
   
   The TCP server sends the AccECN
   Option on the SYN/ACK and the client sends it on the first ACK to
   test whether the network path forwards the option correctly.

[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.


Section 7.  Security Considerations

[ms] I wonder about the security implications of "confusing" classic ECN and AccECN feedback in (passive) network monitoring solutions, most notably if packet sampling is used and no per-connection state is applied. At least theoretically, passive monitoring of "classic ECN" TCP header flags could be used for network monitoring, e.g., to estimate congestion levels in a network, no? How would such a (hypothetical) passive monitoring solution be able to distinguish the standard ECN feedback from an ongoing AccECN experiment, in particular in a sampled packet stream w/o having access to the SYN negotiation? Would there be security or safety implications when experimenting with AccECN in networks using network monitoring solutions that only support ECN as standardized by the IETF?


Thanks

Michael (chair hat off)