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

Lars Eggert <lars@eggert.org> Mon, 20 January 2020 15:09 UTC

Return-Path: <lars@eggert.org>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC38A12008C for <lwip@ietfa.amsl.com>; Mon, 20 Jan 2020 07:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlK0a79HDK3W for <lwip@ietfa.amsl.com>; Mon, 20 Jan 2020 07:09:48 -0800 (PST)
Received: from vs20.mail.saunalahti.fi (vs20.mail.saunalahti.fi [62.142.117.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5743E12007A for <lwip@ietf.org>; Mon, 20 Jan 2020 07:09:48 -0800 (PST)
Received: from vs20.mail.saunalahti.fi (localhost [127.0.0.1]) by vs20.mail.saunalahti.fi (Postfix) with ESMTP id 2C8FD205F9; Mon, 20 Jan 2020 17:09:46 +0200 (EET)
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs20.mail.saunalahti.fi (Postfix) with ESMTP id 17681205E2; Mon, 20 Jan 2020 17:09:46 +0200 (EET)
Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw03.mail.saunalahti.fi (Postfix) with ESMTPSA id 9804620066; Mon, 20 Jan 2020 17:09:40 +0200 (EET)
Received: from stickers.eggert.org (stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id E23651B0845; Mon, 20 Jan 2020 17:08:58 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <247FD52A-D90D-498E-AD79-9DADA8653EB2@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_E7A0ABDE-4931-4FE0-9A01-16FA23615A57"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 20 Jan 2020 17:08:58 +0200
In-Reply-To: <4528ED27-E3B6-43C4-99A5-715DE1B79A09@cisco.com>
Cc: Василий Долматов <vdolmatov@gmail.com>, "t2trg@irtf.org" <t2trg@irtf.org>, Dave Oran <daveoran@orandom.net>, "lwip@ietf.org" <lwip@ietf.org>
To: Eliot Lear <lear@cisco.com>
References: <6CB4D459-4AAA-4313-B95C-05DF22C9A9DD@eggert.org> <E7C38177-DD0B-4D92-AE0E-EB457691E493@cisco.com> <6B9FFEF5-CDC9-4703-BB10-616DBEDE80AB@gmail.com> <4528ED27-E3B6-43C4-99A5-715DE1B79A09@cisco.com>
X-MailScanner-ID: E23651B0845.A4C65
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/HtpLxE2OPCXKv9_FPHHFoBJ25Wk>
Subject: Re: [Lwip] [T2TRG] QUIC on IoT boards
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2020 15:09:54 -0000

Hi,

On 2020-1-20, at 16:52, Eliot Lear <lear@cisco.com> 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