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

Michael Richardson <> Wed, 20 December 2017 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D40D126C89; Tue, 19 Dec 2017 17:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MEiL13cqtrEG; Tue, 19 Dec 2017 17:21:31 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id F057D1205F1; Tue, 19 Dec 2017 17:21:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2650D2008D; Tue, 19 Dec 2017 20:25:10 -0500 (EST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 33C3881AFF; Tue, 19 Dec 2017 20:21:29 -0500 (EST)
From: Michael Richardson <>
To: "Black\, David" <>
cc: Tero Kivinen <>, "patient\" <>, "saag\" <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <23096.60715.827133.4311> <>
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: <>
Archived-At: <>
X-Mailman-Approved-At: Wed, 20 Dec 2017 07:59:06 -0800
Subject: Re: [Patient] [saag] [EXT] Re: Internet Draft posted as requested -
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Dec 2017 01:21:33 -0000

Black, David <> 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 <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-