On 9/30/2022 12:38 PM, Phillip Hallam-Baker wrote:
On Fri, Sep 30, 2022 at 3:04 PM Christian Huitema<[email protected]>
wrote:
See RFC 9250 for an example of transaction based application using QUIC.
-- Christian Huitema
DNS is an example of an information retrieval service which is the class of
services that HTTP works for.
What I am looking at are transactions of the form:
Post <EncyclopediaBritannica>
Analyze <HardProblem>
Stream <temperatureProbe>
The problem with HTTP for the first is that the receiver doesn't get to
know how big the data is until the buffer is filled unless Content-Length
is specified. And that has to be an exact length which kinda makes
streaming compression hard.
RFC 9250 does not use HTTP. It uses a simple RPC-style interface,
mapping each RPC transaction to a QUIC stream.
The content length requirement that you cite is entirely an application
issue. If an application defines its own application level protocol on
top of QUIC, it can specify messages any which way, including requiring
explicit message length up front, or in advance.
Of course, this has nothing to do with the claimed requirement to expose
messages from individual devices to third parties. On that part, the use
of a Wireshark-style solution appears the most practical, as Martin and
Lucas pointed out already.
And yes, solutions in which the device being monitored cooperates with
the monitor don't work if the device does not cooperate. That's a
generic problem. A compromised device might claim to cooperate, and then
use some form of steganography to infiltrate or exfiltrate information.
It could do that even if the transmissions were in clear text.
Monitoring, in practice, requires cooperation from the monitored device.
-- Christian Huitema
