IETF Logo Mail Archive

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

"David R. Oran" <daveoran@orandom.net> Tue, 21 January 2020 13:50 UTC

Return-Path: <daveoran@orandom.net>
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 D386A1200E5; Tue, 21 Jan 2020 05:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wuRz9n494h9d; Tue, 21 Jan 2020 05:50:17 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A1C120090; Tue, 21 Jan 2020 05:50:17 -0800 (PST)
Received: from [192.168.2.1] ([IPv6:2601:184:407f:80ce:349f:2df:2bdc:d2ac]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 00LDnmpP004758 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 05:49:50 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: Eliot Lear <lear@cisco.com>
Cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, Lars Eggert <lars@eggert.org>, Василий Долматов <vdolmatov@gmail.com>, lwip@ietf.org, t2trg@irtf.org
Date: Tue, 21 Jan 2020 08:49:42 -0500
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <D0D33A4C-DA5D-4C2D-86C4-F938C4D8521F@orandom.net>
In-Reply-To: <37818CA3-93F3-43BC-A9F5-3CCAEC4C99A7@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> <247FD52A-D90D-498E-AD79-9DADA8653EB2@eggert.org> <C210C02A-B6E3-46E4-A3FC-6534490783B5@cisco.com> <08fa9838-bfa3-2b91-c7ba-9631a73da264@ericsson.com> <37818CA3-93F3-43BC-A9F5-3CCAEC4C99A7@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_C2772D24-9ED1-4D90-9D4C-2533A4D4D5FF_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/SyiWAW0WnVqbtW_Hub1Tpyb-d2I>
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: Tue, 21 Jan 2020 13:50:22 -0000

On 21 Jan 2020, at 5:24, Eliot Lear wrote:

> Hi Mohit
>
>> On 21 Jan 2020, at 11:07, Mohit Sethi M <mohit.m.sethi@ericsson.com> wrote:
>>
>> Hi Eliot,
>>
>> I find your example rather disturbing. I am sure a dad does not want everyone else on the Internet to see what his daughters toy is exfiltrating. You would need encryption for that?
>>
>
> Yes, you would!  But Dad might want to be able to have an agent to decrypt.
Sure, which is why key sharing is probably appropriate and having standards for doing that safely are important. Do we have a good way to maintain PFS in those scenarios?

> Indeed Dad may want an agent that blocks certain
I can see two related reasons why this might be important:

1. To prevent “packet of death” scenarios where either bugs or malware can be exploited by a single crafted packet making it through to a vulnerable device.

2. To mitigate DoS attacks against devices that are not prepared to discard traffic effectively, either due to processing or energy considerations.

#1 is quite difficult to achieve without full middle-box functionality, in which case I’d argue that rather than ACL-like blockage based on things like ports, you want a full application proxy that acts as an “agent” fronting the device. In this case the intermediary is trusted and already should have the necessary keys.

#2 could be done with ACLs based on information in things like MUD profiles, but I’d argue a better approach is something similar to STUN, but whose purpose is for the device to install filtering or rate-limiting state in a cooperating device “upstream of it”.

My 2¢, FWIW…

>
>>
>> I am totally with you on the need for knowing what's inside the device and how is the device behaving. RFC 8576 identifies this in Section 5.6 'Verifying Device Behavior':https://tools.ietf.org/html/rfc8576#section-5.6 <https://tools.ietf.org/html/rfc8576#section-5.6>
>
> Well indeed.  But I do think we should be considering what the first class objects are in these cases.
>
> Eliot



DaveO

v2.23.0 | Report a Bug | By Email