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

Eliot Lear <lear@cisco.com> Tue, 21 January 2020 14:14 UTC

Return-Path: <lear@cisco.com>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD86120090 for <t2trg@ietfa.amsl.com>; Tue, 21 Jan 2020 06:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 2oWNy5mSCjWU for <t2trg@ietfa.amsl.com>; Tue, 21 Jan 2020 06:13:59 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCFE120091 for <t2trg@irtf.org>; Tue, 21 Jan 2020 06:13:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9211; q=dns/txt; s=iport; t=1579616039; x=1580825639; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=rYG2vABftrV+UjNl3K3Kk/In2NlbzfyhzNiLUBJTqYQ=; b=ajSwKNEwasWgmKoH7WvCqlRXhspy2pPs8s8i4JHXgF9NY/2gbKZkHdph b7ZWWDXMBpXkcqKs+tSKpKG3lrA8kiCHUra2lYm1jhX3lt8uzT3bmbQno EfcrMSSV8TnUjAoVC+4cCAO+qRLn/Lgd4NLDxkqBpnIgnPc8YMi/rkOYH o=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DoAQABBide/xbLJq1bChwBAQEBAQcBAREBBAQBAYFqBAEBCwGBJAGBA0d5ASASKoQSiQOIJYc9i2+ICwIHAQEBCQMBAS8BAYRAAoI2NwYOAgMNAQEEAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsYKgICVwYTgyYBglsgrH91gTKFSoRbEIE4AYFSiluCAIERJyCCHi4+hB6DOzKCLASNODqJQJgggkOCSYEckkwbmnemN4MtAgQGBQIVgWgjgVgzGggbFWUBgkE+EhgNVpVyQAMwAo4PAQE
X-IronPort-AV: E=Sophos;i="5.70,346,1574121600"; d="asc'?scan'208,217";a="22319798"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 14:13:57 +0000
Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 00LEDumw005346 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 14:13:56 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <51D05107-DD21-4B5D-BBCE-6281285B36A3@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3BDFC81F-FEBC-4EE3-BEA4-A2D7B1BFE408"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 21 Jan 2020 15:13:55 +0100
In-Reply-To: <D0D33A4C-DA5D-4C2D-86C4-F938C4D8521F@orandom.net>
Cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, Lars Eggert <lars@eggert.org>, Василий Долматов <vdolmatov@gmail.com>, lwip@ietf.org, t2trg@irtf.org
To: "David R. Oran" <daveoran@orandom.net>
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> <D0D33A4C-DA5D-4C2D-86C4-F938C4D8521F@orandom.net>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Outbound-SMTP-Client: 10.61.103.205, dhcp-10-61-103-205.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/XE3BliC14QP_DeeGUkaA_fiwZAw>
Subject: Re: [T2TRG] [Lwip] QUIC on IoT boards
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2020 14:14:05 -0000


> On 21 Jan 2020, at 14:49, David R. Oran <daveoran@orandom.net> wrote:
> 
> 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?
> 

Certainly not with TLS 1.3, and that is by design.  With TLS 1.2 it’s possible, but then we end up with divergent code bases, and I would like to avoid that.

> Indeed Dad may want an agent that blocks certain
> 
> I can see two related reasons why this might be important:
> 
> 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.
> 
> 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
> 
Wellll…. It depends.  Again, I’m reminded of Hitchhiker’s Guide to the Galaxy: “Space,” it says, “is big. Really big.”  Same with IoT.  If we’re talking about a digital twin strategy or some cloud-based service, the chances are ACLs are good enough, so long as you can identify the correct ACLs.

But… if the threat here really is the device itself in its fully functional form without any malware, then you need a full scale ALG to defend against it.  That’s something that we need to be thinking about.

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

It’s a matter of who you want making the claim.  If it’s the device, then STUN or another half dozen protocols can do the job.  If it’s the manufacturer who designed the thing, then MUD is the right tool.