Telechat Review of draft-ietf-core-cocoa-03
review-ietf-core-cocoa-03-secdir-telechat-roca-2018-03-22-00

Hello,

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.

Summary: Ready with nits

This document proposes an improved congestion control for CoAP.
Its Security Considerations section lists several RFCs whose security
discussion  may apply, and in particular [RFC7252]. This is a bit  annoying as
the security considerations section of RFC 7252 is 6 pages long. What do you
mean more precisely? What should the implementer care about?

Otherwise I agree with the authors that attacks preventing the delivery of some
packets are hard to prevent while seriously impacting CoCoA. Such attacks are
however limited to a single flow. What about the opposite (misleading the
sender and making him unresponsive to congestion signals)? This would be a more
serious issue. This is not specific to CoAP but could CoAP simplify this type
of attack?

Other comments:

** Introduction: In sentence "For non-confirmable packets, it also limits the
sending rate to 1/RTO;"
  I have problems understanding what "non-confirmable" means.

** Section 3: When saying that "CoCoA has been found to perform well in
scenarios with latencies
   ranging from the order of milliseconds to peaks of dozens of seconds,..."
   what do you mean by "latency"? Is it the transmission and/or propagation
   times? Is it related to the access method? Not very clear. And I'm a bit
   surprised by the value of "dozens of seconds »? Is it just a simulation
   parameter or is it realistic.

** Section 3: (corollary) the default initial RTO is set to 2 to 3 seconds,
i.e., well below the
  "dozens of seconds" mentioned above.

** Appendix B. Pseudocode:
  As a general comment, I don't like function definitions where input and
  output are not defined, where global versus local variables are not defined,
  where persistant variables (global or static local variables) are not
  defined. For instance, between two calls to updateRTO(), should the RTO
  variable keep its previous value (I assume it is the case) or not? Same
  question for RTTVAR_strong, RTT_strong.

  And in appendix B.1., since you provide C-type pseudo-code, it's better to
  use a final ";" during default value initialisation (or #define if this is a
  constant).

Cheers,

   Vincent