Subject: QUIC for IoT embeddeds system

From: JH <[email-masked]>
Date: Sun, 18 Aug 2019 10:02:47 +1000

Hi,

I am new to QUIC and just joined the mailing list, it seems to me that
QUIC working groups focus on HTTP and Web applications. Are there any
WG working for small socket level QUIC client server for embedded
system? The requirements for embedded system QUIC is very much
different to large size of QUIC for HTTP, using small size socket
level QUIC in embedded system is long overdue, I will be very
interested in involving the embedded system QUIC development,
appreciate more information about IETF WG agenda and clarification.

Thank you.

Kind regards,

- Jupiter

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 18 Aug 2019 01:57:38 -0400

I believe the QUIC WG has its hand full just getting version 1 out of the
door.
The focus is not limited to HTTP although it is the only defined
application protocol for the time being. There is a fairly strict
separation between the transport layer (QUIC) and the application layer
(HTTP etc. over QUIC). Game application etc. may also be relevant and there
is separate ongoing work on WebRTC, Websockets, etc. in a new form over
QUIC - the WebTransport work may cover some or all of this.

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.

In the simplest form such a specification might do away with Retry,
migration, have a lighter initial packet, and support a only subset of
crypto algorithms. Note that a lighter initial packet is open to
amplification attacks so there might be some concerns about IP whitelisting.

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

That would not directly address HTTP/3 or other application protocols but
it would be a precondition.

I for one would like to see MQTT over a lighter version of QUIC.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 18 August 2019 at 02.03.06, JH ([email-masked]) wrote:

Hi,

Thank you.

Kind regards,

- Jupiter

---

From: JH <[email-masked]>
Date: Sun, 18 Aug 2019 21:55:26 +1000

> QUIC - the WebTransport work may cover some or all of this.

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.

> 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.

> amplification attacks so there might be some concerns about IP

That details should be handled by implementation if it is capable of
plugging different fmodules or cryto algorithms.

> 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.

> I for one would like to see MQTT over a lighter version of QUIC.

Applications and high level protocols can come and go, QUIC should
follow in UDP/TCP/IP footstep. I am not clear if IETF has already got
an experiment of QUIC open source or if it is going to develop one,
appreciate your advice.

Thanks Mikkel,

- jupiter

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 18 Aug 2019 08:08:39 -0400

See inline

On 18 August 2019 at 13.55.27, JH ([email-masked]) wrote:

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.

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.

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.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 18 Aug 2019 08:16:50 -0400

Well, technically it is by definition the internet as IoT means "Internet
of Things”, but taken in a broader context, many non-trivial embedded and
constrained devices will run at the perimeter of the Internet with
aggregators/gateways doing the actual Internet thing.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Aug 2019 18:13:55 +0800

Hi,

On 2019-8-18, at 8:02, JH <[email-masked]> wrote:
> Are there any
> system?

my implementation (https://github.com/NTAP/quant) can be compiled for the particle.io platform and currently weighs in at around 90KB code size. It would probably be possible to shave off another few KB by making it client-only. Additional savings would require changing some key data structures and are therefore more painful.

Lars

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 19 Aug 2019 03:17:36 -0700

Is that size including the TLS implementation?

Mikkel

On 19 August 2019 at 12.14.29, Lars Eggert ([email-masked]) wrote:

Hi,

> WG working for small socket level QUIC client server for embedded

my implementation (https://github.com/NTAP/quant) can be compiled for the
particle.io platform and currently weighs in at around 90KB code size. It
would probably be possible to shave off another few KB by making it
client-only. Additional savings would require changing some key data
structures and are therefore more painful.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Aug 2019 18:47:48 +0800

> Is that size including the TLS implementation?

Yes. But there is no H3.

Lars