[secdir] Secdir review of draft-ietf-core-cocoa-03

[Vincent Roca <[e-mail]>]

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