Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -

Tero Kivinen <kivinen@iki.fi> Tue, 19 December 2017 21:07 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117AA1270A0; Tue, 19 Dec 2017 13:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 ds5XgwQfeTTP; Tue, 19 Dec 2017 13:07:22 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 C8AB9124239; Tue, 19 Dec 2017 13:07:21 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vBJL75vc026599 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Dec 2017 23:07:09 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vBJL6xpf014208; Tue, 19 Dec 2017 23:06:59 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23097.32627.710293.414741@fireball.acr.fi>
Date: Tue, 19 Dec 2017 23:06:59 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Black, David" <David.Black@dell.com>
Cc: "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FE218DC@MX307CL04.corp.emc.com>
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com> <dfdb52ca-81ae-50b7-cd5f-e256b5cb047d@cs.tcd.ie> <AF4C62E0-61AB-45DB-B3E6-56AB67A1070A@telefonica.com> <d47e82af-5c6f-9be5-4226-4d6713701148@cs.tcd.ie> <MWHPR16MB14889F9F1671437D969B83D8930E0@MWHPR16MB1488.namprd16.prod.outlook.com> <23096.60715.827133.431108@fireball.acr.fi> <CE03DB3D7B45C245BCA0D243277949362FE218DC@MX307CL04.corp.emc.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 20 min
X-Total-Time: 20 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/STpIyEE1o85ohZ_Yyg4DQI2_dXU>
Subject: Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Dec 2017 21:07:24 -0000

Black, David writes:
> Some of the people on this list are among the fraction of 1% of
> Internet users who can configure a firewall.

True. On the other hand most of the network access devices (ADSL
modems, LTE modems etc) already have firewall built in and the default
configuration quite commonly is, outbound traffic allowed, inbound
traffic forbidden.

This already protects quite a lot of devices...

On the other hand as that configuration is so common, lots of IoT
devices have "call home" protocol, i.e., they will periodically
connect to some home server and ask if there is anything they need to
do, and this allows attack vector for attacking those devices. 

> However, that's probably more of an argument for ISP/ISV/IHV
> firewall management as a security service that may or may not be
> bundled with other services than an argument for encrypted traffic
> access. 

Yep. Offloading firewall configuration to security service vendor
makes lots of sense, as they can then change configuration quickly
when some kind of new attack is found out.

> That's not as simple as one might like.   I recently had to request
> opening up the corporate firewall to allow a web conferencing
> service (name of service omitted to protect the innocent ... and the
> guilty).  That request involved two TCP ports (in addition to 443)
> plus a large UDP port range (for RTP) across seven IPv4 address
> blocks whose size ranges from /26 to /21.   That's quite a bit more
> than "two locations," and this is something that an IoT web
> conferencing system could require.

What, no /48 networks? Bad, bad system, you should require proper
software that actually works on the internet instead of those old
legacy systems :-)

> That suggests separation of those two classes of use cases in
> discussion and design applicability.  The above line of reasoning
> also appears to assume that it's acceptable to prohibit P2P
> functionality (i.e., "talk[ing] to random devices in the Internet")
> in IoT devices.  I'm not sure about that. 

Yes. They are different use cases. But even then there is multiple
different use cases in the IoT too.

IoT is quite often used to mean devices that do machine to machine
communications, i.e., where there is no user or user interface on the
device. I.e., the thermostat sending temperature, or fetching the
configuration from the cloud or local server.

For those devices connecting random IP-address in the world is not
usually needed. They only communicate with the machines they are
configured to communicate with and thats it. These devices have also
long lifetime, i.e., they might be installed once and assumed to work
for next decade or two. For those devices there might also be long
term support for them, including firmware updates.

Another class of IoT, is the cheap devices connected to the internet
doing something. Those devices can include toys, webcams etc. Those
devices might actually want to do peer to peer or similar systems as
they might want to create network of other people using same devices
etc. Protecting them is going to very difficult as their behavior can
be very random or unpredictable, thus making rules for them in
firewall etc can be hard.

Also those are quite often throw-away devices, meaning that if they
are broken, they are thrown away, and there is no point of repairing
them. Updating the firmware can be considered as repairing it, thus
vendors might even not make them so they can be updated, if something
goes wrong they just say throw it away and buy new one... 
-- 
kivinen@iki.fi