Re: [core] Review of draft-fz-core-coap-pm-03

[Giuseppe Fioccola <[e-mail]>]

Hi Marco,
Thanks a lot for your detailed comments.
We are working on a new version and we will submit the new version by Monday.
Please find my further replies inline tagged as [GF].

Regards,

Giuseppe

From: core <[e-mail]> On Behalf Of Marco Tiloca
Sent: Sunday, February 26, 2023 8:30 PM
To: [e-mail]
Subject: [core] Review of draft-fz-core-coap-pm-03

Hi all,

Please see below some comments; I hope this helps to improve the document.

(some points were raised during the CoRE interim meeting on 2023-02-15)

Best,
/Marco

===

[High-level comments]

* When reading the latest version, I found it pretty hard to navigate the different variants of the proposed measurement approach.

   I suggest to revise the document so that the different variants are also introduced upfront and later detailed in a more systematic way. When doing so, it can be worth categorizing the different variants based on the following orthogonal dimensions:

   - The use of the different measurement bits, alone or combined.
   - Intermediaries not present or present.
   - Measurement done end-to-end, hop-by-hop, or both together.
   - No security, or DTLS, or OSCORE, or DTLS and OSCORE together.

   For each variant, it would also help to highlight its peculiar features, advantages and limitations. That might also help understanding if any variant is not worth having altogether.

[GF]: Yes, we will revise section 5 on Application Scenarios. Note that it is supposed that a reader is familiar with sQuare Bit (RFC9341, draft-ietf-ippm-explicit-flow-measurements) and Spin Bit (RFC9312)

* Across the different alternatives, when is it possible to take measurements only in one direction, and what are the necessary conditions to take measurements bidirectionally?

[GF]: You can always do measurements in one direction (also in case of empty ACKs). For bidirectional measurements, it is required to have traffic in both directions.

* Navigating the possible variants become especially harder when proxies are considered. For that case, it would be helpful to clarify what changes and what becomes possible/impossible to achieve through the different measurement bits, especially when OSCORE is used end-to-end between the origin client and server.

[GF]: We will consider different cases: non-proxying endpoints, collaborating proxies, non-collaborating proxies, non collaborating and non-chaching proxies.

* When using OSCORE, having the PM option as inner or outer does not have to be mutually exclusive. That is, measurements can be performed both at the ends, and in the individual hops, by having the option both outer and inner.

   However, if the PM option is used (also) as an outer option, shouldn't the outer option also be (at least) integrity-protected, to be reliably processed by the intended consumer? This would require using also DTLS hop-by-hop, or an (additional) OSCORE association with an intermediary (see draft-tiloca-core-oscore-capable-proxies).

[GF]: We will add this consideration.

* It would help to include a clear-cut unambiguous taxonomy of roles for the entities participating in the measurement, i.e., the origin client and server, proxies, observers/probes and network functions.

* I don't understand the definition of the C bit. It mentions a blending of the Q bit and S bit, but the text suggests more a blending of the Q bit and the D bit mentioned in Section 2.2, although the latter is never individually used in the proposed approach.

[GF]: The C bit is a combination of Q bit and D bit, in order to incorporate RTT information in the Q bit signal. I will check the description.

* Examples of message exchanges with ongoing measurements would also help, even if provided as appendices.

[GF]: Some information from RFC9341 and draft-ietf-ippm-explicit-flow-measurements can be included but I do not want to copy much text here.

* How and to what extent do the measurement indicators become less effective or less meaningful if using CoAP Observe (RFC 7641)? There would be no bidirectional exchanges after the first one, but only multiple notification responses sent at unpredictable times.

[GF]: In this case, you can only monitor one direction.


[Abstract]

* "both end-to-end and on-path"

   This is more commonly phrased as "end-to-end and hop-by-hop", as later done in Sections 2.1 and 2.2.

* It would be good to clarify here already in which respect performance is measured (i.e., round trip time and message loss).

[GF]: Ok


[Requirement Language]

* This disclaimer typically comes in a Section 1.1 "Terminology" within the "Introduction" section. Such a section would also reference to documents whose terminology is expected to be known by the reader.

* The disclaimer should be more correctly about BCP 14 as composed of RFC 2119 and RFC 8174. If you are using markdown, you can simply include the line "{::boilerplate bcp14}".

[GF]: Ok


[Section 1]

* "by marking a message as Confirmable (CON) with ACKs."

   I think you mean: "by marking a message as Confirmable (CON), as to be retransmitted if not acknowledged by an ACK message"

[GF]: Yes, I will revise.

* "In case of CoAP reliable mode there are Message IDs and ACKs, that could ..."

   Proposed rephrasing: "For CON messages, Message IDs and ACKs could ..."

[GF]: good suggestion

* "eventually be used"

  Do you mean "potentially be used" ?

[GF]: Yes

* "In case of CoAP unreliable mode, there is no ACK and, ..."

   Proposed rephrasing: "For NON messages, no ACKs are used and, ..."

[GF]: Ok

* "COAP environment to satisfy the low resources of constrained nodes"

   Proposed rephrasing: "a CoAP environment including resource-constrained nodes"

[GF]: Ok

* "And it is in any case limited to RTT and end-to-end losses."

   What is "it"? Does it refer to performance measurement as per the state of the art?

[GF]: Yes

* "verify and meet the operational requirements"

   Do you mean "verify that the operational requirements are met" ?

[GF]: Yes

* "requiring just a minimal amount of collaboration from the endpoints"

   What is instead the expectation of collaboration of intermediaries?

[GF]: it means that the algorithm is straightforward compared to alternative methods. Please have a look at draft-ietf-ippm-explicit-flow-measurements

* "[I-D.ietf-ippm-explicit-flow-measurements] defines different combinations of bits because the number of bits in QUIC is limited and different experiments have been done."

   I am not sure about what this sentence is trying to say. Perhaps do you mean the following?

   "[I-D.ietf-ippm-explicit-flow-measurements] defines different combinations of bits. Such flexibility is convenient when using a protocol with a limited number of eligible bits to exploit, e.g., QUIC."

[GF]: Yes, we will revise.

* The last paragraph mentions only RTT and message loss as relevant CoAP performance metrics measurable with the proposed approach.

   This clashes with the third paragraph saying that the state of the art (="it") is "... in any case limited to RTT and end-to-end losses."

   Then, either: i) the last sentence of the third paragraph is unfair and can just be removed, and this proposal is focused on having a simple measuring method; or ii) this last paragraph should also say how the proposed method is useful for measuring additional metrics than RTT and message loss.

[GF]: Yes, this paragraph can also say how the proposed method is useful for additional metrics than RTT and loss

* Please include a Section 1.1 "Terminology". Besides the content suggested in a comment above, please define the term "probe". That's a better term to use in the document instead of the analogous "observer", since the latter might be interpreted as a CoAP client using Observe (RFC7641).

[GF]: Yes


[Section 2]

* "CoAP [RFC7252] defines a number of options that can be included in a message. For this reason, a new PM option for CoAP, carrying Performance Measurement (PM) bits is the approach followed by this document."

   I am not sure how to interpret this paragraph.

   On one hand, further options have been defined in other documents than RFC 7252. Perhaps you mean that CoAP admits messages to include options for signaling features/extensions.

   In any case, the second sentence reads like "a new option has been defined *because* CoAP allows to".

   It is probably just better to replace the paragraph with something like: "The approach proposed in this document relies on a new Performance Measurement (PM) Option for CoAP defined in Section 3, whose value includes PM bits."

[GF]: Yes, I agree.

* "For this reason, the idea is to re-apply only the S bit and Q bit."

   Compared to what complete set of bits? Also, a few lines before, the bits for "Loss and Delay events" are also mentioned as included among the possible PM bits.

[GF]: I will revise.

[Section 2.1]

* s/Each side of the connection/Each communicating endpoint

[GF]: Ok

* "every fixed number of packets"

   Taking the point-of-view of a message sender, can you rephrase in the form: "each time a fixed number of messages have been ... " ?

[GF]: Yes

* "The Spin bit is set by both sides to the same value for as long as one round trip lasts and then it toggles the value."

   Is this strictly related to the RTT for a request-response exchange? If so:

     - Can this be expressed as follows? "When sending a new request, a client sets the spin bit to the opposite value it had in the immediately previously sent request to the same server. Then, the server echoes the same value of the spin bit of the request in the spin bit of the response."

[GF]: Ok, I will review

     - Based on the text in Section 7, this does not assume or require that NSTART is equal to 1 (see Section 4.7 of RFC 7252). How is the performance measurement through the S bit affected when NSTART is greater than 1?

     - How does a server set the Spin bit when sending notifications to a client using Observe? Is it still relevant?

[GF]: If Observe is used, it may be possible to monitor only one direction but without S bit that needs bidirectional traffic.

* This overview of the different bits and their usage would benefit from figures providing examples of message exchanges over time.

[GF]: A reader should read the related documents, at least RFC9341 and draft-ietf-ippm-explicit-flow-measurements. I think we can consider this in a later version to avoid DOWNREF.

[Section 2.2]

* "... in this way each endpoint can detect a packet loss if it receives less packets than expected."

   If the endpoint is not receiving something expected, that's sufficient to detect packet loss. Perhaps you mean: "... in this way each endpoint can detect a packet loss if it receives less packets than the other endpoint has sent."

[GF]: Yes

* "A single packet in a period of the square wave can be selected and set to the opposite value of that period."

   What has to be set? Which bit? (carrying on reading makes guess that it's the C bit introduced in Section 4).

   Also, how is the single packet practically selected? Is it just fine, e.g., to choose one packet at random within a just started square wave?

[GF]: Yes

* "After one RTT it comes back"

   Is "it" the "single packet" of the previous sentence?

[GF]: Yes

* "and another packet is selected and set again to the opposite value of that period"

   But this other packet has to be in the next period of square wave. That is, the anomalous packet should be exactly one per square wave. Correct?

[GF]: Yes

* "By measuring the distance between these special packets, it is possible to measure the RTT in addition to packet loss."

   Isn't it sufficient to focus on the exact exchanges of special packets? How does the distance between such two exchanges play a role in measuring the RTT?

[GF]: Yes it is possible. It is called Delay Bit in draft-ietf-ippm-explicit-flow-measurements. But in this case the information is multiplexed with the Q bit.

* This overview of combined use of the two bits would benefit from a figure providing an example over time.

* "This mechanism uses a single bit that serves two purposes"

   And that should be the bit C introduced later. Correct?

[GF]: Yes

* "Indeed, the Delay bit is set only once per RTT and a single packet with the marked Delay bit bounces between a client and a server."

   Why "per RTT"? Shouldn't it say "per square wave" or "only for one RTT within each square wave"?

   Also, is the specific combination in Section 4 of this document enforced by considering the S bit rather than the D bit? That's what is suggested in Section 4 when introducing the bit C, but the S bit has a different meaning than the D bit.

[GF]: No, S bit and D bit have the same meaning.

* The last two paragraphs presents the C bit as something computable from the Q and D bits. This is the case in -explicit-flow-measurements.

   However, the D bit in itself is not part of the proposed approach, and later in Section 4 the C bit is used in the Pattern 1 (M = 0), in order to combine what you otherwise separately get from using the Q bit or the S bit.

   That said, why involving a D bit not directly used here, and presenting the C bit in one way here (as combining the Q bit and the D bit), and in another way later (as combining the Q bit and the S bit)?

[GF]: To clarify, let’s say that C bit =  Qbit XOR Dbit


[Section 3]

* "None of these properties is marked for the PM options."

   Actually, the property NoCacheKey is marked.

[GF]: This will change in the next version since the Option becomes Proxy Unsafe and Safe-to-Forward only in special cases with no-caching proxies.

* "Note that it could be possible to make use of one bit in the option to identify the mode. In this way two patterns can be defined."

   Why "could be" rather than "is"? Such a use is defined in Section 4.

   Also, it would be better to already give the intuition of "mode" and "pattern", that are otherwise introduced only later on in Section 4.

[GF]: Ok

* Although it is discussed more in detail later in Section 5.3, the definition of the PM Option in this section should already mention that the option is of class U and E in terms of OSCORE processing.

[GF]: Ok


[Section 4]

* This can just be moved into the current Section 3 as its subsection.

[GF]: Ok

* The caption of Figure 2 should actually refer to the value of the option.

[GF]: Ok

* "The Mode bit (M bit) can be set to 1 or 0 and it is used to identify whether the Option follows pattern 1 (M bit = 0) or pattern 2 (M bit = 1)."

   Any reason why not having pattern 0 (M bit = 0) or pattern 1 (M bit = 1) instead?

[GF]: Yes, it can be modified.

* "C bit is used in pattern 1. It is based on the enhancement of the Q bit signal with the S bit information. The two methods are described in [I-D.ietf-ippm-explicit-flow-measurements] and coupled as detailed in Section 2.2;"

   See comments above about Section 2.2 also referred here. While this bullet point talks about coupling the Q bit and the S bit, Section 2.2 talks about coupling the Q bit with the D bit.

[GF]: Yes, I will revise.

* The use of the Q bit and the S bit in pattern 2 is defined again here. When it comes to this document, can't their use be properly defined early in Section 2.1, without relying (again) on external references here in Section 4?

* "Event bits MAY encode additional ..."

   I think you mean "Event bit MAY be used to encode additional ...", and if that happens, as you say, they follow a well-defined encoding.

[GF]: Yes

* A lot of text in this section heavily relies on -explicit-flow-measurements and concepts defined therein, to the point that that document would need to become a normative reference.

   Is this actually necessary? If the Q/S/C bits and the related algorithms are well defined in this documents in a self-standing and self-contained way, references to -explicit-flow-measurements can indeed remain minimal and informative.

[GF]: We can consider this in a later version to avoid DOWNREF.

* "The Event bits can be divided into two parts, for instance: loss event bits and delay event bits."

   With "for instance", do you actually mean that other kind of information can be encoded? Would that require application-specific profiles to define such information and their encoding in the Event bits?

   Sticking to loss event bits and delay event bits, can the two types of information co-exist in the same option value or not? In either case, how do the event bits encode the information that they convey?

[GF]: Yes. The information encoding is already proposed but it is optional for now.

* "The CoAP PM Options described in this document can be used in both requests and responses. If a CoAP endpoint does not implement the measurement methodologies, it can simply leave the default value (all bits are zero). In this way the other CoAP endpoints become aware that the measurement cannot be executed in that case."

   How does the recipient endpoint distinguish between: i) the case where the sender endpoint does not support the measurement methodologies; and ii) the case where the sender endpoint is intentionally using Pattern 1 (M=0) with the C bit set to 0 and the Event bits all sets to 0 (hence to be ignored)?

[GF]: The C bit cannot be set to 0 all the time.

   Also, if the sender endpoint does not support the measurement methodologies, why would it include the option in an outgoing message?

[GF]: Yes, the option is not included in this case.

* "The fixed number of packets to create the Q bit (or C bit) signal is predefined and its value is configured from the beginning for all the CoAP endpoints."

   This is the length of the wave discussed in Section 2.2, correct? As to the pre-configuration of such a value, a pointer to the later Section 6 would help.

[GF]: Ok


[Section 5]

* What is the difference between "split measurement" and "on-path measurement"? Perhaps a "split measurement" can be an "on-path measurement" carried out by an external on-path probe as well as a measurement made by an intermediary such as a proxy? Either way, this taxonomy should be made clearer.

[GF]: It is the same. Maybe we can use only one term to avoid confusion.

* "Network Functions or Probes that must be able to see deep into application."

   What does this sentence mean? The application data is anyway hidden from intermediaries if OSCORE is used to protect communications end-to-end.

[GF]: Yes, if OSCORE is used.

* I can see gateways and proxies as intermediaries, but where are "network functions" located? Do they run on "probes"/"observers" entities other than proxies and intermediaries that simply listen to traffic in promiscuous mode? That seems to be the case, based on text later on in Section 5.1.

[GF]: I meant probes.

[Section 5.1]

* "The on-path network probes can read Q bit and S bit (or C bit) ..."

   This is possible only if: i) no security at all is used; or ii) only OSCORE is used and an outer PM Option is also added. Correct?

[GF]: Yes

* "indeed it allows RTT measurement for all the intermediate points."

   There are no proxies in this scenario, so what are the intermediate points? Are you thinking of the on-path probes?

[GF]: Yes

* "Additionally, with the Q bit and by applying [RFC8321], it is also possible to do hop-by-hop measurements for loss and delay and segment where possible ..."

   There are no proxies in this scenario, so what does hop-by-hop refer to? Perhaps this paragraph pertains to Section 5.2 instead?

[GF]: No, if you have more probes you can do hop-by-hop measurements between the probes.


[Section 5.2]

* "The CoAP PM Option can be applied end-to-end between client and server (or between Proxies) ..."

   What does "(or between Proxies)" exactly mean here? If it means "or end-to-end between proxies", that really suggests the use of the PM Option between two non-adjacent proxies.

   You probably mean hop-by-hop here, as holding between two adjacent proxies, between origin client and adjacent proxy, and between proxy and adjacent origin server.

[GF]: We will specify the possible sessions.

* "... and since it is Safe-to-Forward, it is intended to be safe for forwarding by a proxy that does not understand it."

   A feedback from discussion at the CoRE interim meeting on 2023-02-15 was to have the option not Safe-to-forward instead, and to define what a proxy is minimally supposed to understand for handling it.

[GF]: Yes, we will define it as Proxy Unsafe

* "It can also be possible to apply the CoAP PM Option between the collaborating Proxies ..."

   This set of measurement is possible to perform non exclusively (i.e., together with the end-to-end measurements between client and server) only if OSCORE is used and the PM Option is used both as inner and outer. Correct?

[GF]: No, because you have a separated session between the two Proxies. If you want to measure on a Probe you need outer option otherwise you can measure between the two proxies.

   Then you need to ensure (at least) integrity protection of the outer option, to be verifiable by the hop intended to consume it (i.e., the proxy acting as next hop). That is, in addition to using OSCORE end-to-end, on each pair of hops either you use (D)TLS or you apply a second layer of OSCORE as in draft-tiloca-core-oscore-capable-proxies

* "Since CoAP proxies hide the identity of the client and could also apply caching, on the server side the data would appear mixed in presence of more than one client doing the measurements."

   A feedback from discussion at the CoRE interim meeting on 2023-02-15 was to consider a single origin client involved in the measurements with a given server.

[GF]: Yes

* "The Server can distinguish the source client by using additional flow information such as the IP addresses."

   IP addresses are not a reliable source of identity. Also, in the presence of a proxy as in this section, the server would anyway see the address of the proxy, but not the address of the origin clients.

[GF]: This consideration will be omitted

* Thinking of the last four paragraphs, this seems written having in mind the case where no OSCORE-based security is used. It should be made clearer what changes and what becomes possible/impossible to do when OSCORE is used end-to-end between client and server.

[GF]: Yes


[Section 5.3]

* "Since an OSCORE message may contain both an Inner and an Outer instance of a certain CoAP message field"

   That applies specifically to CoAP Options defined accordingly in terms of OSCORE processing, not to "CoAP message fields". Consistently:

   s/Inner option message fields/Inner options

   s/Outer option message fields/Outer options

[GF]: Ok

* "(Class U or I) are used to support proxy operations"

   I suggest to replace "are used" with "are intended to be used".

[GF]: Ok

* "If the CoAP PM Option is sent as Outer Option, it allows both end-to-end ..."

   As per a comment above, a reliable and trusted hop-by-hop measurement would require the use the use of DTLS or OSCORE also on the communication leg with the intermediary at that hop.

[GF]: Maybe this is only necessary on the Internet.

* Is it intended to also admit the PM Option as only outer?

[GF]: I will revise to consider also the inner case

* Aligned with previous comments, note that what would be an outer option for the origin endpoint can be possible to protect with OSCORE for an intermediate hop, see draft-tiloca-core-oscore-capable-proxies

   That would ensure (at least) integrity protection of hop-by-hop measurements consumed and verifiable by a proxy.

[GF]: Ok

[Section 6]

* "There are several alternatives for the implementation but this is out of scope of this document."

   Can you at least name and point to some of the several alternatives?


[Section 7]

* "As specified in [RFC7252], clients (including proxies) MUST strictly limit"

   Proposed rephrasing: "As specified in Section 4.7 of [RFC7252], clients (including proxies) have to strictly limit"

   Besides providing a more specific pointer, this avoids using normative language in referring to something as-is from RFC 7252.

[GF]: Ok


[Section 8]

* "A CoAP endpoint can use the CoAP PM Options to affect the measures of a network into which it is making requests by maliciously modifying the value of the option."

   If this actually refers to the CoAP endpoint including the option in its outgoing message, it is more about "maliciously specify a wrong option value", rather than modifying it.

   If it is about a malicious modification on the wire by any entity other than the origin client and server, then it is about integrity-protecting the PM Option in such a way that the intended consumer can verify it upon reception (see also previous comments about this).

[GF]: OK I will revise

* "... a CoAP proxy that is located at the boundary of an administrative domain MAY be instructed to strip the payload or part of it before forwarding the message."

   If OSCORE is used end-to-end between the origin client and server, then stripping the payload is going to break things on the origin server later on.

* "When a client uses a proxy the session towards the proxy can be secured using DTLS and the same from there on.  In this case the separated sessions can still be measured."

   What "session" are you referring to? Since you say "secured using DTLS", you don't mean the DTLS session. Do you mean "leg-specific measurement execution"?

[GF]: With DTLS, you can measure the session between client and proxy.

   What does "the same from there on" mean? DTLS protection is hop-by-hop. The proxy may have a separate DTLS session with the (next hop towards the) origin server.

[GF]: it refers to the other sessions between the two proxies and between proxy and server.

* "... but it doesn't mean that the endpoints are not lying to the observer."

   Well, it doesn't mean that the endpoints are not lying in general. If the outer PM Option is not included at all or is further protected for a proxy, then a probe (i.e., an observer) would not even see it.

[GF]: Yes

* "... while it is more likely that an on-path observer is the attacker."

   Yes, which makes it desirable to (at least) integrity protect a PM Option left visible to probes (see previous comments for Sections 5.2 and 5.3).


[Nits]

* Section 1
- s/[RFC7252] define the CoAP Protocol. In CoAP, reliability/In the CoAP protocol [RFC7252], reliability

* Section 2, s/COAP/CoAP

* Section 2.1, s/by Q bit/by the Q bit

* Section 4
- s/COAP/CoAP
- s/end point/endpoint
- s/The CoAP PM Options/The CoAP PM Option

* Section 5.1
- s/if the CoAP PM Option/If the CoAP PM Option
- s/between client and the server/between client and server

* Section 5.2
- s/where it is applied the CoAP PM Option/where the CoAP PM Option is applied
- s/in presence of/in the presence of

* Section 5.3
- s/CoAP PM Option/The CoAP PM Option

* Section 6
- s/signal) It is/signal), it is

* Section 8
- s/someone tampered/someone tampered with the option value
- s/COAP/CoAP

[GF]: OK


--

Marco Tiloca

Ph.D., Senior Researcher



Phone: [phone]



RISE Research Institutes of Sweden AB

Box 1263

164 29 Kista (Sweden)



Division: Digital Systems

Department: Computer Science

Unit: Cybersecurity



https://www.ri.se