Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 20 December 2017 01:21 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 2D40D126C89;
Tue, 19 Dec 2017 17:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]
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 MEiL13cqtrEG; Tue, 19 Dec 2017 17:21:31 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca
[IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id F057D1205F1;
Tue, 19 Dec 2017 17:21:30 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21])
by tuna.sandelman.ca (Postfix) with ESMTP id 2650D2008D;
Tue, 19 Dec 2017 20:25:10 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1])
by sandelman.ca (Postfix) with ESMTP id 33C3881AFF;
Tue, 19 Dec 2017 20:21:29 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Black\, David" <David.Black@dell.com>
cc: Tero Kivinen <kivinen@iki.fi>, "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.4311 08@fireball.acr.fi>
<CE03DB3D7B45C245BCA0D243277949362FE218DC@MX307CL04.corp.emc.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;
<'$9xN5Ub#
z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 19 Dec 2017 20:21:29 -0500
Message-ID: <6704.1513732889@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/JCCNCohnG6D-tTr4kBwW8ZDgszA>
X-Mailman-Approved-At: Wed, 20 Dec 2017 07:59:06 -0800
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: Wed, 20 Dec 2017 01:21:33 -0000
Black, David <David.Black@dell.com> wrote: > I have a few reactions to Tero's message, which may not be coherent or > consistent taken as a whole. I've excerpted the text of interest. >> If my IoT device crashes when someone makes some new remote attack to >> it, I will change configuration of my local "thing" called firewall >> and block all access to IoT device, except to those few addresses it >> will need to connect to. > Some of the people on this list are among the fraction of 1% of > Internet users who can configure a firewall. But, MUD will let us automate it this configuration. > 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. Agreed. We don't need to see the traffic to authorize it. If we had some better home-router/desktop/phone integration, end users could get requests and might authorize things sensibly. Or not, but at least, they would realize what's going on. Again, MUD. >> IoT devices usually only require connection to the one of two >> locations, i.e., their own cloud service, or to my local home are IoT >> gateway. In both cases protecting the IoT device is best done by >> limiting access to device using normal firewall rules. Installing >> firewall rules does not require seeing the traffic inside the >> encrypted flow. > 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. It would be interesting if applications could emit a cooked (JSON or maybe XML format) file that users could forward to corporate IT that made the request precise and exact. Well, really we could reuse MUD format for that, along with the signature format, it's just that the statement would come out of a browser rather than via https from MUD URL. >> > Some people in this discussion have proposed narrowing the scope so >> > that endpoints only trust a set of well-known, manually >> > pre-configured set of such appliances, but still tackle challenges >> > like end2end integrity. >> >> I think set of well-known pre-configured set of device is good idea >> for most of the IoT devices. IoT devices usually do not want to talk >> to random devices in the internet, they will need to talk to the few >> things pre-configured to them. And for that filtering basic firewall >> is usually enough. >> >> This does not work for laptops or similar, but works for most of the >> IoT devices. > 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. Given that we have no real technical definition of IoT (I've proposed some, btw), it's hard to make categories. 95% of devices that currently are called IoT are really in my definition, "Web Connected Devices", because they never talk to anything other than the "cloud", and sometimes they want to open a port-80 equivalent. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Patient] Internet Draft posted as requested - Brian Witten
- Re: [Patient] [EXT] Internet Draft posted as re... Mingliang Pei
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] Internet Draft posted as requeste... Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as r... Peter Gutmann
- Re: [Patient] [saag] Internet Draft posted as r... 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 a... Brian Witten
- Re: [Patient] Internet Draft posted as requested - Black, David
- Re: [Patient] [EXT] RE: Internet Draft posted a... Brian Witten
- Re: [Patient] Internet Draft posted as requested - Bret Jordan
- Re: [Patient] [saag] Internet Draft posted as r... Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as r... Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as r... Stephen Farrell
- Re: [Patient] [saag] Internet Draft posted as r... Black, David
- Re: [Patient] [saag] Internet Draft posted as r... Stephen Farrell
- Re: [Patient] [EXT] Re: [saag] Internet Draft p... Brian Witten
- Re: [Patient] [saag] Internet Draft posted as r... Paul Wouters
- Re: [Patient] [saag] Internet Draft posted as r... Melinda Shore
- Re: [Patient] [EXT] Re: [saag] Internet Draft p... Brian Witten
- Re: [Patient] [saag] Internet Draft posted as r... Diego R. Lopez
- Re: [Patient] [saag] Internet Draft posted as r... Bret Jordan
- Re: [Patient] [EXT] Re: [saag] Internet Draft p... Mark Kennedy
- Re: [Patient] [saag] Internet Draft posted as r... Melinda Shore
- Re: [Patient] [saag] Internet Draft posted as r... Roland Zink
- Re: [Patient] Internet Draft posted as requested - Roland Zink
- Re: [Patient] [saag] [EXT] Re: Internet Draft p... Tero Kivinen
- Re: [Patient] [saag] [EXT] Re: Internet Draft p... Black, David
- Re: [Patient] [saag] Internet Draft posted as r... Bret Jordan
- Re: [Patient] [saag] [EXT] Re: Internet Draft p... Tero Kivinen
- Re: [Patient] [EXT] Re: [saag] Internet Draft p... Stephen Farrell
- Re: [Patient] [saag] [EXT] Re: Internet Draft p... Peter Gutmann
- Re: [Patient] [saag] [EXT] Re: Internet Draft p... Michael Richardson
- Re: [Patient] [saag] [EXT] Re: Internet Draft p... 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 ch... 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 ch... Tony Rutkowski
- Re: [Patient] [EXT] Re: the IETF participant ch... Brian Witten
- Re: [Patient] the IETF participant choice Kathleen Moriarty