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
- [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] [EXT] Internet Draft posted as requ… Mingliang Pei
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] Internet Draft posted as requested … Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as req… Peter Gutmann
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] Internet Draft posted as requested - Paul Wouters
- Re: [Patient] [EXT] Re: Internet Draft posted as … Brian Witten
- Re: [Patient] Internet Draft posted as requested - Black, David
- Re: [Patient] [EXT] RE: Internet Draft posted as … Brian Witten
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as req… Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as req… Black, David
- Re: [Patient] [saag] Internet Draft posted as req… Stephen Farrell
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Brian Witten
- Re: [Patient] [saag] Internet Draft posted as req… Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as req… Melinda Shore
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Brian Witten
- Re: [Patient] [saag] Internet Draft posted as req… Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as req… Bret Jordan
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Mark Kennedy
- Re: [Patient] [saag] Internet Draft posted as req… Melinda Shore
- Re: [Patient] [saag] Internet Draft posted as req… Roland Zink
- Re: [Patient] Internet Draft posted as requested - Roland Zink
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Tero Kivinen
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Black, David
- Re: [Patient] [saag] Internet Draft posted as req… Bret Jordan
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Tero Kivinen
- Re: [Patient] [EXT] Re: [saag] Internet Draft pos… Stephen Farrell
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Peter Gutmann
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Michael Richardson
- Re: [Patient] [saag] [EXT] Re: Internet Draft pos… Michael Richardson
- [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] the IETF participant choice Ted Lemon
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] the IETF participant choice Ted Lemon
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Brian Witten
- Re: [Patient] the IETF participant choice Benjamin Kaduk
- Re: [Patient] the IETF participant choice Eggert, Lars
- Re: [Patient] the IETF participant choice Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant choi… Brian Witten
- Re: [Patient] the IETF participant choice Kathleen Moriarty