Subject: [Last-Call] Opsdir last call review of draft-ietf-core-echo-request-tag-11

From: Jürgen Schönwälder via Datatracker <[email-masked]>
Date: Mon, 30 Nov 2020 15:00:02 -0800

Reviewer: Jürgen Schönwälder
Review result: Has Nits

The document defines enhancements for the CoAP protocol that close a
number of security issues. Operationally most relevant is likely the
Echo option, which can help to reduce the abuse of CoAP for DDoS
amplification. The proposed Request-Tag	option resolve ambiguities
with block transfers and as such is most relevant for some CoAP
applications but less so for the Internet as a whole.

The document is well written, it was a pleasure to read it. I believe
the document is ready to be published except two nits that confused
me while reading through the document:

- The number of 152 bytes mentioned in section 2.4:

  3*152 would be 456 octets, I am not sure why this is the "typical
  size of a frame on the wire sent across the Internet". Either
  explain how you obtained this number of consider removing it in case
  it does depend on assumptions that are not guaranteed to be always
  true. One option could also be to simply drop this sentence.

- The difference between Figure 2 and Figure 3 is rather subtle.

  I actually diffed the figures to find it. My understanding is that
  it is really only the labels t0 and t1 and e0 and e1. One could
  perhaps change the figures to make it more explicit when t0 (e0)
  take place, perhaps also clarifying the text a bit. There is perhaps
  some confusion caused by the notion of time t0, t1, the notion of
  events e0, e1, and the notion of tag values labeled (t0) and (e0).
  The text says "The server verifies freshness by checking that e0
  equals e1, where e0 is the cached value when the Echo option value
  was generated, and e1 is the cached value at the reception of the
  request." I found this confusing. It think what you are trying to
  say is that the tag value cached at event e0 is the same as the tag
  value received at event e1, no?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Dec 2020 01:22:45 +0100

Hi Juergen,

> - The number of 152 bytes mentioned in section 2.4:

I think you are discussing this paragraph:

       *  Amplification mitigation should be used when the response
          would be more than three times the size of the request,
          considering the complete frame on the wire as it is typically
          sent across the Internet.  In practice, this allows UDP data
          of at least 152 Bytes without further checks.

I think this is trying to say that responses of 152 bytes are not requiring amplification mitigation under this rule, so there seems to be an assumption that the request would have been about 152/3 ~ 51 bytes, which is close to, but smaller than an 40-byte IP, an 8-byte UDP, and a minimal 4-byte CoAP header, which is 52 bytes, but then there are Ethernet headers and trailers, making the request 70 bytes (or 50 bytes for IPv4, which then becomes the minimum Ethernet frame of 64 bytes).  The maximum response would then be 3*70=210 bytes on the wire, minus 18+48 bytes Ethernet/IP/UDP, leading to 154 bytes “UDP Data”.  I don’t know.

>  size of a frame on the wire sent across the Internet”.

Typical size of the frame (or packet?) of the request, not of any packet on the Internet.

I’m sure this could be phrased in a way that is a bit easier to follow.

The number to be explained is not so much the 152 (the exact value of which I don’t really understand), but the three.

> Either

Indeed.

> - The difference between Figure 2 and Figure 3 is rather subtle.

Very subtle.  “Cthulhu!” vs. “Comic Sans” (and t vs. e).

Grüße, Carsten