Skip to main content

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

Request Review of draft-ietf-core-cocoa
Requested revision No specific revision (document currently at 03)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2018-03-06
Requested 2018-02-09
Authors Carsten Bormann , August Betzler , Carles Gomez , Ilker Demirkol
I-D last updated 2018-03-22
Completed reviews Tsvart Early review of -02 by Wesley Eddy (diff)
Opsdir Telechat review of -02 by Scott O. Bradner (diff)
Secdir Telechat review of -03 by Vincent Roca
Opsdir Telechat review of -03 by Scott O. Bradner
Tsvart Telechat review of -03 by Wesley Eddy
Genart Telechat review of -03 by Christer Holmberg
Assignment Reviewer Vincent Roca
State Completed
Request Telechat review on draft-ietf-core-cocoa by Security Area Directorate Assigned
Reviewed revision 03
Result Has nits
Completed 2018-03-22
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