On Thu, Sep 29, 2022 at 4:42 PM Randy Armstrong (OPC) < [email protected]> wrote:
> At this point we have not determined that QUIC will actually be better > than TCP for OT applications. That said, we see the potential because there > is a need for UDP based protocols on some embedded devices because the OS > does not support TCP and QUIC offers the potential for prioritizing traffic > with multiple streams. > > > > There is also some effort to deploy 5G networks within factories which > would mean the lower latency recovering after IP address changes could be a > benefit. > > > > One risk for QUIC in this setting comes from the memory consumption needed > to handle out of order/repeated messages. TCP has had decades to optimize > this problem which means it could be more efficient. > > > > If the WG already knows that QUIC will not work so well on low end > embedded devices then we would like to learn more about the issues. > > > Hi Randy, I read the above. I think that TCP for IoT has been researched a lot and now we have some stripped down versions of TCP that are being used. Not sure or not familiar with anything similar for Quic. Quic is not like TCP, i.e. as far as I know, for Quic there is only one sender, that is HTTP. So you may be opening a can of worms with this proposal. Good luck, Behcet > *From:* Roberto Peon <[email protected]> > *Sent:* Friday, September 30, 2022 6:19 AM > *To:* Randy Armstrong (OPC) <[email protected]>; Paul > Vixie <[email protected]> > *Cc:* [email protected] > *Subject:* Re: Request for Authenticated but not Encrypted Traffic > > > > So I understand the background here: > > Why do we need/want QUIC in this setting instead of TCP? > > > -=R > > *From: *QUIC <[email protected]> on behalf of Randy Armstrong (OPC) < > [email protected]> > *Date: *Thursday, September 29, 2022 at 1:13 PM > *To: *Paul Vixie <[email protected]> > *Cc: *[email protected] <[email protected]> > *Subject: *RE: Request for Authenticated but not Encrypted Traffic > > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > Hi Paul, > > Thanks for the support. > > I think it is important to note: we already have our own TCP based > protocol that supports authentication only. If QUIC cannot meet our > requirements we may not recommend the use of QUIC at all. > > Also note that factory owners sometimes owners disable security entirely > if they have s/w that uses TLS/HTTPS with no sign only option. IOW, forcing > people to use encryption when they have a compelling business justification > to turn it off can result in more security risks - not less. > > Regards, > > Randy > > -----Original Message----- > From: Paul Vixie <[email protected]> > Sent: Friday, September 30, 2022 4:31 AM > To: Randy Armstrong (OPC) <[email protected]> > Cc: [email protected] > Subject: Re: Request for Authenticated but not Encrypted Traffic > > i understand this ask and i resonate positively to it. however, i predict > it will be seen as controversial in this community, based on my prior > experience trying to get ssh/scp to support clear text for use inside a > campus, datacenter, VPC, or VM server. i've also been trying to get an SMTP > library's author team to have an option to ignore STARTTLS when talking to > my own localhost. in each case i was told that the risk of accidental > nonencryption across a wide area network was too great. > so, good luck with this use case. --vixie > > re: > > Randy Armstrong (OPC) wrote on 2022-09-29 05:31: > > The OPC Foundation is looking at deploying QUIC within factories as > > means for different OT devices to communicate with each other. In this > > environment, factory owners often wish to monitor traffic to check for > > anomalies. Encryption prevents this. > > > > For this reason, an authentication only option is essential to making > > QUIC a viable choice for communication within factories. > > > > Regards, > > > > Randy Armstrong > > > > OPC UA Security WG Chair > > > > > -- > P Vixie >
