Re: [Lwip] [T2TRG] QUIC on IoT boards

[Lars Eggert <[e-mail]>]

Hi,

On 2020-1-20, at 16:52, Eliot Lear <[e-mail]> wrote:
> 	• I only want that device speaking protocols it was designed to speak.
> 
> It’s that last one that has me worried from a long term perspective with QUIC.

I don't quite follow. Surely if someone ships an IoT device that uses QWUIC for communication, that *is* a device "designed to speak" QUIC?

>  If the stack hides means to determine directionality, as it does, and applications, as it does, we should take a pause to determine how we would detect whether it has services running on it that aren’t intended, as has happened all too often.[1]. These are use cases that QUIC was not designed to address.

So [1] is a case where the firmware web server had an embarrassing bug - it's not an example where someone hacked in and ran another service in addition to (or instead of) the manufacturer one. So that's not a fitting example for the point you are trying to raise.

We can certainly debate whether more encryption and/or obfuscation makes network-based threat detection harder or not. It might even be the case that there are wrinkles in the IoT space that aren't there in the broader web space, in terms of appropriateness or trade-offs. But in general, I think this issue is a general one, and not IoT-specific.

> On the other hand, we do want the IoT community to leverage the best that the Web community has delivered, if and when it is appropriate, and even when the whole package is not, it is best that they adopt the components that are, so that they don’t end up having to repeat old mistakes.

Exactly. Given the ever increasing amount of engineering cycles that are being poured into QUIC, the IoT community should absolutely try to leverage that to the max, where it can.

Thanks,
Lars