RE: Request for Authenticated but not Encrypted Traffic

[Antoine FRESSANCOURT <[e-mail]>]

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 <[e-mail]> On Behalf Of Randy Armstrong (OPC)
Sent: samedi 1 octobre 2022 03:21
To: Phillip Hallam-Baker <[e-mail]>; Christian Huitema <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, October 1, 2022 10:18 AM
To: Christian Huitema <[e-mail]<mailto:[e-mail]>>
Cc: Randy Armstrong (OPC) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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