Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing
draft-ietf-core-echo-request-tag-14
Yes
Francesca Palombini
(Barry Leiba)
No Objection
Robert Wilton
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
Note: This ballot was opened for revision 12 and is now closed.
Francesca Palombini
Yes
Erik Kline
No Objection
Comment
(2021-02-15 for -12)
Sent
[[ nits ]] [ section 2.4 ] * "causing overheads" -> "causing overhead"
Martin Duke
No Objection
Comment
(2021-02-05 for -12)
Sent
5.1 This is optional, but please replace "blacklisted" with "deny-listed". 6. What is a "preemptive" echo value?
Murray Kucherawy
No Objection
Comment
(2021-02-18 for -12)
Sent
There are several SHOULDs (e.g., near the top of page 8, and again at the end of Section 2.3) that left me wondering why an implementer would do something other than what it says. Since SHOULD offers a choice, some advice would be helpful here. Otherwise, maybe those ought to be MUSTs. I suggest giving them all a once-over to see if any such advice would be helpful to include.
Robert Wilton
No Objection
Roman Danyliw
No Objection
Comment
(2021-02-17 for -12)
Sent
Thank you for writing this mitigation for draft-mattsson-core-coap-actuators. ** Section 5. Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible? ** Section 5. However, this may not be an issue if the communication is integrity protected against third parties and the client is trusted not misusing this capability. -- Why is the use of integrity presented as only a possibility here? Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...” -- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients? ** Appendix A helpfully tries to lay out recommendations. A few comments: -- all of the recommendations here have option values much larger than the permitted minimum of 1-byte. In addition to the recommendations, could the circumstances of the lower bound also be discussed -- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network address reachability). For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness
Warren Kumari
No Objection
Comment
(2021-02-17 for -12)
Not sent
Much thanks to Juergen Schoenwaelder for the OpsDir review, and the authors for addressing the comments... It's a good and easy read.
Éric Vyncke
No Objection
Comment
(2021-02-16 for -12)
Sent
Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated). Eliot Lear (in copy) has also reviewed the document as IoT directorate reviewer at: https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-12-iotdir-telechat-lear-2021-02-05/ So, please address/reply to his comment. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.2 -- "The Echo option value is a challenge from the server to the client..." Just wondering whether "echo" is the right choice for the option as it is too close to ICMP_ECHO_REQUEST, why not "challenge" ? I would have expected some statements related to non-idempotent requests (generic statement) and then specific examples such as actuators. -- Section 2.2.1 -- Are the authors confident enough to state a minimum length of 1 octet ? If the intent of the document is to prevent replay attack, then I wonder whether one octet is enough... Unsure whether Section 5 (security considerations) addresses this issue correctly.
Barry Leiba Former IESG member
Yes
Yes
(for -12)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -12)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -12)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2021-08-30 for -13)
Sent
I really like the changes made in the -13 overall; thank you for adding in all the additional discussion. I only have editorial/nit-level comments remaining. Section 2.5.2 The information extracted by the server from the request Echo value has different sources of truth depending on the application. I think that the "sources of truth" phrase might be a source of confusion for some readers. I'd consider something more like: % The request Echo value conveys freshness information to the server, % and the freshness is applied to some data or information related % to the request. which then transitions decently into "Understanding who or what is the authoritative source of that information helps the server implementer decide ..." If all that the server extracts is information which the client is authorized to provide arbitrarily, (which is another way of saying that the server has to trust the client on whatever Echo is used for), then the server can issue Echo values that do not need to be (nit) I'd suggest "whatever Echo is being used for" (add "being") In most other cases, there are properties extracted of which the server is the authority ("The request must not be older than five minutes" is counted on the server's clock, not the client's) or which [If my above suggestion is used, that removes the word "extracted", this use of "extracted" should probably be reworded as well.] Section 3.5.1 When security services are provided by DTLS, this can only be confirmed if there was no CoAP retransmission of the request, the request was responded to, and the server performs replay protection. (nit) I think the server would either "perform replay detection" or "[provide/use] replay protection" -- performing protection is not a common phrasing. way, the server can rely on a conforming client to set the Request- Tag option when required, and thereby have confidence the integrity of the assembled body. (nit) "have confidence in" Appendix A This method is suitable both for time and for event base freshness (e.g. by clearing the cache when an event occurs), and independent of the client authority. (nit) "for time- and for event-based freshness" (and again a couple paragraphs later)
Deborah Brungard Former IESG member
No Objection
No Objection
(for -12)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -12)
Not sent