Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt

[Thomas Fossati <[e-mail]>]

Hi Christian, Giuseppe, Mauro, Massimo, Fabio,

On Tue, Nov 9, 2021 at 5:11 PM Christian Amsüss <[e-mail]> wrote:
>
> Hello Giuseppe,
>
> On Mon, Nov 08, 2021 at 08:50:49AM +0000, Giuseppe Fioccola wrote:
> > [GF]: The derived values (RTT, losses) can be useful for an operator
> > or an enterprise that is managing a constrained, low-power and lossy
> > network. As IoT and M2M keep growing, a mechanism to measure the
> > performance can become useful to meet the operational requirements.
> > Also, it should be a simple mechanism to be developed on constrained
> > nodes.
>
> OK, so this sounds more like a "characterization" (to demonstrate
> meeting some requirements?) than "feeding these values into the protocol
> again", is that correct? Or is concrete action to be taken based on
> these? (If so, I'd imagine it would need to be more fine-grained than
> across all involved proxies).
>
> > [GF]: The intermediaries or on-path observers could also be network
> > gateway or probes, that can see deep into application and read the
> > measurements. This information can be used to monitor the network in
> > order to check the operational performance and to employ further
> > network optimization. The measurements can be end-to-end between
> > Client and Server or can be split. If CoAP Proxies are used, the
> > measurements can be done between the Proxies or between the Proxy and
> > the Client. The Server can distinguish the source client, for example
> > by using additional flow information such as the IP addresses. It
> > could also possible to bundle different clients if they are mixed. I
> > think we have to clarify the different scenarios in the next version
> > of the draft.
>
> Let me illustrate what I mean here by describing a use case like those
> I'd expect to see it around this document (not necessarily in a document
> update -- OK if that helps, but for initial steps this thread may
> suffice):
>
> 1 -- 2 -- 3 -- 4 -(Internet)- 5
>
> 1. Devices: Sensors with 6LoWPAN connectivity, operated by A.
> 2. Gateway: Proxy (eg. running on a cellular-to-6lowpan router) shipped
>    with the sensors and operated by A.
> 3. Uplink: provided by B.
> 4. Probe: passive monitoring device operated by B.
> 5. Backend: Data center operated by A.
>
> If this protocol is run between 1 and 5 (across intermediaries), the
> values read at 4 would be total round-trip times over the 6LoPAN, the
> cellular network and the remaining Internet. I wouldn't know what to do
> with those values; given that 2 is acting as a proxy, they are not the
> relevant parameters to tune their CoAP stack, and wouldn't tell anyone
> where to add capacity.
>
> (Moreover, data at 4 would look like garbage -- different clients at 1
> would send uncoordinated PM values, and at 4 the clients are not
> distinguishable any more by design).
>
> If, to set up a similar but different scenario, 4 was also a CoAP proxy,
> the PM option were hop-by-hop, and the protocol would be performed
> between 2 and 4, then this would result in a characterization of the
> cellular uplink, and (in my vastly oversimplifying imagination) might be
> used to place additional cell towers there.
>
> The operator situation here does raise an additional concern: If 2 is
> operated by A and 4 by B, wouldn't this be prone to A forcing B to take
> action (for example) by maliciously flipping the square bit every 62nd
> message, giving B the impression that there is message loss? I'm not
> asking for security considerations here at this point (I would later,
> and privacy on top of that), more about the assumptions underlying this
> work.


Yep, it looks like the ideal scenario is one where the new CoAP
options are clear-text and integrity protected end-to-end by OSCORE.
Then A and/or B can put their measurement boxes (or functions) in one
or more places to break down the different RTT contributions where it
makes sense (e.g., at the ingress/egress of their respective network
segments).  If we can't assume integrity protection we'd need to take
cheating inventives, trust relationships and all those things into
consideration, which tend to make the analysis much more complicated.

cheers!

>
> BR
> Christian
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>   -- Bene Gesserit axiom
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core


-- 
Thomas