Re: QUIC for IoT embeddeds system

[Mikkel Fahnøe Jørgensen <[e-mail]>]

See inline

On 18 August 2019 at 13.55.27, JH ([e-mail]) wrote:

Are there any IETF QUIC open sources for clearly separation? Ideally,
a QUIC git source should only contain QUIC core functionality, the
moment you added HTTP, WebRTC, Web sockets to mix with the QUIC
source, there will never be a clear separation.

https://github.com/quicwg/base-drafts

The invariants is what never change - it is very small document.

The transport document is the core QUIC document - with supporting TLS and
retransmission docs. The HTTP and QPACK are separate from that but still
part of the eventual QUIC v1 delivery.


> The intention for IoT, as I undertand it, is for “someone” to pick up the
> ball and specify a new QUIC version aimed for constrained devices. QUIC is

> designed to handle such protocol variations.

If the QUIC spec can define core functions mandatory, variations and
options can be added or removed for specific platforms or
applications, that will make it easier to be adapted and adopted. For
IoT embedded system, the size is critical for many small devices.

I personally don’t think modular plug and play is a good thing here.
Different QUIC versions with limited functionality is better - it keeps
things simple and reduces interop complexities and attack vectors. As to
encryption, I could imagine a version that doesn’t use TLS at all, but
simply settles for simplified ChaCha/Poly handshake with ED25519 key
exchange, and optional AES-GCM. Such a version would use many primitives
from TLS but with reduced overhead. The downside is if the crypto
vulnerability is discovered, but that can be fixed in a new QUIC version.

A QUIC version could be modular in the sence that you have multiple
versions that each flag in one or more features from a base version such as
QUIC v1 but then there might be say 4 different profiles or versions,
rather than infinitely many combinations.

QUIC versioning and fallback attack protection isn’t fully designed yet but
will likely be a priority just after v1 release.


> Another aspect could be transport over non-UDP, non-IP fabric.

The IP is the Internet, same as UDP or TCP, I don't see any non-IP,
non-UDP or non-TCP can be succeeded.

IoT isn’t necessarily running on the internet. You can have mesh networks
for power metering or in-car electronics.

That said, at least one IoT version would likely be UDP centric.