Hello, Since the beginning of the discussion, I am really wondering why you want to use QUIC while it seems (in my view) that you “just” need to use an authentication header with IPv6, or change DTLS the way you changed TLS to provide only authentication without encryption.
But again, I might be completely misunderstanding your requirements Best, Antoine From: QUIC <[email protected]> On Behalf Of Randy Armstrong (OPC) Sent: samedi 1 octobre 2022 03:21 To: Phillip Hallam-Baker <[email protected]>; Christian Huitema <[email protected]> Cc: [email protected] Subject: RE: Request for Authenticated but not Encrypted Traffic * That is pretty much the only model we have been using but it isn't the only model and it is a straightjacket. We have other protocols for publish-subscribe patterns (including multicast). We would not want to use QUIC for those use cases. QUIC only makes sense for request-response. From: Phillip Hallam-Baker <[email protected]<mailto:[email protected]>> Sent: Saturday, October 1, 2022 10:18 AM To: Christian Huitema <[email protected]<mailto:[email protected]>> Cc: Randy Armstrong (OPC) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: Request for Authenticated but not Encrypted Traffic Both of you are assuming a request/response paradigm. That is pretty much the only model we have been using but it isn't the only model and it is a straightjacket. On Fri, Sep 30, 2022 at 7:44 PM Christian Huitema <[email protected]<mailto:[email protected]>> wrote: On 9/30/2022 4:30 PM, Randy Armstrong (OPC) wrote: > * Sure, we could design a presentation layer on top of QUIC. I think it > is better to design a transport/presentation layer for the problem space and > then see how we might make use of QUIC. > > Not quite sure why you make a big deal about this. OPC UA supports the kinds > of operations you described but the complex operations are broken into > multiple request-response pairs for transport. All OPC UA needs is a full > duplex channel that allows responses to be returned in any order. I would > imagine that any other protocol built on QUIC would do the same. That's exactly the way DNS over QUIC is designed. Full duplex channel (QUIC connection) allowing for series of transactions. Each transaction request (from the client) is mapped to a new duplex stream stream; response come back on the reverse part of that stream; responses to transactions arrive in any order. > The important question is: does QUIC have any inherent limitations that would > make it difficult to implement complex operations over top of QUIC? No. You have to pay attention to the management of connections, how to resume connections after they break, etc. But that's pretty standard when designing a distributed application. -- Christian Huitema
