Constrained Application Protocol (CoAP) Hop-Limit Option
draft-ietf-core-hop-limit-07

** Section 1.0, What is an “involved application agent”?

** Section 1.1 Per “CoAP proxies that do not have specific knowledge that proxy loops are avoided in some way …”, how would a proxy know that?

** Section 7.  Perhaps also add that a malicious proxy can induce more subtle failures than just straight packet drops by manipulating the Hop Limit value.

** Editorial Nits:

-- Section 1.1.  Editorial. s/ The Hop-Limit option has originally been designed for a/The Hop-Limit option was originally designed for a/

-- Section 3.  Recommend being clearer on what it means for “Hop-Limit detection gets broken” when proxies on boundaries re-write the hop limit value.  Perhaps something on the order of:
s/ This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop and so Hop-Limit detection gets broken ./
This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop rendering negating the efficacy of loop detection through the Hop-Limit field.

-- Section 4.  Per “Only one information per proxy should appear in the diagnostic payload”, what is “one information” (it seems like a few words are missing here)?

-- Section 4.  Per “Doing so allows to limit the size of the TBA1 …”, this sentence doesn’t parse for me.

Firstly, thank you for writing this - also, thank you for the discussions and addressing the comments from the OpsDir review (and much thanks to Scott for providing the review).
I agree that this should have an Updates: tab, but I understand the arguments against it.

There are some very good notes in the other ballots, which I really think need to be addressed, including such clear things as Suresh's:
"CoAP messages received with a Hop-Limit option ... ***greater than '255'*** MUST be rejected" -- Since the field is only 8 bits long this will never happen, right? If so, this text about >255 needs to be removed.

Thank you for the work put into this document. I have a couple of COMMENTs (that I would appreciate to see a reply of yours) and one NIT.

Regards,

-éric

== DISCUSS ==


== COMMENTS ==

-- Section 3 --
C.1) "Because forwarding errors may occur if inadequate Hop-Limit values
   are used, proxies at the boundaries of an administrative domain MAY
   be instructed to remove or rewrite the value of Hop-Limit carried in
   received messages" Isn't this remove all usefulness of the Hop-Limit option ?

C.2) table 1, suggest to state the value of the C, U, N, R properties

-- Section 4 --
C.3) while I understand why a proxy should not add its own diagnostic information when packet should become larger than the MTU of the next link, I wonder what will happen downstream when the MTU will be exceeded...

C.4) suggest to use normative language (uppercase MAY, MUST, ...)

== NITS ==

-- Section 3 --
N.1) s/if a less value/if a smaller value/ ?

Thanks to everyone who worked on this document.

I'm a little surprised that the treatment of loops that go between HTTP and CoAP networks involves a simple observation that detection of such cases simply won't work, without any attempt at mitigation.

I'm sympathetic to the observation during WGLC that directly interworking with RFC 8586 isn't feasible, but surprised that more primitive approaches to at least preserving the CoAP Hop-Count as it crossed the HTTP network weren't considered. There are aesthetic discussions to be had around, e.g., defining an HTTP "Hop-Count" header field (which isn't acted on by the HTTP network, but serves the purpose of preserving the value during transit) or overloading the semantics (but not really the meaning) of the HTTP "Max-Forwards" header field, or (in extremis) squirreling the Hop-Count away in the `pseudonym` portion of the inserted HTTP Via header field.  But I think the high order bit here is that preserving the Hop-Count value through the HTTP network would be trivial, and would prevent the identified shortcoming of the current mechanism.

Section 1.1

It's not entirely clear to me that the original ("specific") use case
needs to be mentioned given that the document now has a generic intended
usage.

   Note that this means that a server that receives requests both via
   proxies and directly from clients may see otherwise identical
   requests with and without the Hop-Limit option included; servers with
   internal caching will therefore also want to implement this option.

We might want to have one more sentence here to expound on why (if they
implement the option, then it's okay for them to ignore it when doing a
cache lookup which would not otherwise be safe?)

Section 3

I'd suggest mentioning that C/U/N/R and the formatting of Table 1 also
match up with Table 4 (Section 5.10) of RFC 7252, since without that
reference for comparison it's a bit hard to know how to interpret the
C/U/N/R columns in the table.

   Nevertheless, the presence of such proxies will not prevent infinite
   loop detection if at least one CoAP proxy which support the Hop-Limit
   option is involved in the loop.

nit: s/support/supports/

   A CoAP proxy which understands the Hop-Limit option MAY be
   instructed, using a configuration parameter, to insert a Hop-Limit
   option when relaying a request which do not include the Hop-Limit
   option.

In light of the other discussion about how strongly to recommend
Hop-Limit's usage, do we want to revisit MAY vs. SHOULD here?  (My
apologies if we already did and I missed it.)

   The initial Hop-Limit value should be configurable.  If no initial
   value is explicitly provided, the default initial Hop-Limit value of
   16 MUST be used.  This value is chosen to be sufficiently large to
   guarantee that a CoAP request would not be dropped in networks when
   there were no loops, but not so large as to consume CoAP proxy
   resources when a loop does occur.  [...]

It would have been nice to have an updated rev that includes feedback
from, e.g., the secdir reviewer.  That is to say, I also think that
"guarantee" is too strong here.

      Note: If a request with a given value of Hop-Limit failed to reach
      a server because the hop limit is exhausted, then the same failure
      will be observed if a less value of the Hop-Limit option is used
      instead.

nit: s/less/smaller/

Section 4

   To ease debugging and troubleshooting, the CoAP proxy which detects a
   loop includes its information in the diagnostic payload under the

nit: given the subsequent discussion, maybe s/its information/an
identifier for itself/?

   conditions detailed in Section 5.5.2 of [RFC7252].  That information
   MUST NOT include any space character.  The information inserted by a

Does "space character" just mean ASCII 0x20, or any character with the
WSpace property?

   Each intermediate proxy involved in relaying a TBA1 (Hop Limit
   Reached) error message prepends its own information in the diagnostic
   payload with a space character used as separator.  Only one
   information per proxy should appear in the diagnostic payload.  Doing

Does this mean that a proxy is expected to inspect the diagnostic
payload for its own identifier before prepending?

Section 5

   By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option
   following the guidelines in Section 3.  The HTTP-to-CoAP Proxy MAY be
   instructed by policy to insert a Hop-Limit option only if a Via
   (Section 5.7.1 of [RFC7230]) or CDN-Loop header field [RFC8586] is
   present in the HTTP request.

It seems like a descriptive "may" would work okay here, if desired.

   By default, the CoAP-to-HTTP Proxy inserts a Via header field in the
   HTTP request if the CoAP request includes a Hop-Limit option.  The
   CoAP-to-HTTP Proxy MAY be instructed by policy to insert a CDN-Loop
   header field instead of the Via header field.

(same here)

   When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the
   loop detection may get broken if the proxy-forwarded traffic
   repeatedly crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies.

It feels like we could say more here -- if the hc and ch proxies use
mapping rules such that proxy identifiers are preserved across a
protocol-translation round-trip, wouldn't loop detection still work?

Section 7

It seems that any attacker in a position to add or modify a hop-limit
option would be able to drop the request or forge a response anyway, so
there's not much of a new DoS risk.

However, in addition to the topology leakage in the diagnostic payload,
I think that an attacker could use small hop-limit values to probe the
topology of a network into which it is making requests, finding the
smallest hop-limit value that allows the request to succeed.

Table 1:

This table is missing a legend for what the meaning of a blank cell is for the CUNR flags. I assume they are boolean True or false, and that empty implies false, but this could be clarified.

* Section 3

"CoAP messages received with a Hop-Limit option ... ***greater than '255'*** MUST be rejected"

Since the field is only 8 bits long this will never happen, right? If so, this text about >255 needs to be removed.

* I would have expected that a CoAP option with NoCacheKey bits all zero would need to match in order to be served from the cache. Checking also for smaller values of Hop Limit for sending stored responses seems to (IMHO) complicate things for little benefit.