Re: [Model-t] ICN as an example (was: Re: (meta) Trust, and threat vs vulnerability models)

Robin Wilton <wilton@isoc.org> Mon, 17 February 2020 12:39 UTC

Return-Path: <wilton@isoc.org>
X-Original-To: model-t@ietfa.amsl.com
Delivered-To: model-t@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A76D1200DB for <model-t@ietfa.amsl.com>; Mon, 17 Feb 2020 04:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
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 oID3CQ8gdwtK for <model-t@ietfa.amsl.com>; Mon, 17 Feb 2020 04:39:15 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770053.outbound.protection.outlook.com [40.107.77.53]) (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 9A74012010F for <model-t@iab.org>; Mon, 17 Feb 2020 04:39:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SyciSEsbboSgPDmwDc4WBvJCVeVA9aUomtbSV7YVuT0gtr+IjchRocY8SbSLBKHYAS25leyGWvHZMIgN/pyM0KFa5spFEzDOT8zlDqD5cjLOcfVlVFJBXUiM720UeyNMLPPP0MGRiXwL/CEZxRMtDgdZj5/V9iWoYa/WjPIuHawc/r7AtPtVx+9+oqQhMwP5GdVogXegm9Zu5IEYqNR9u4j7SNg7LmikeASEMZ/GhEDnIgrNZDW9QdGmKK90vNoBpF6KDA/F8hx4KnXuNJVPADhpTta+um2DxT41boq8YOCMki3He0qFME7xOiQfF/qXSocnfyeNGxj/OWgyxBnlpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v2Gez0z3Syc1iG3lNbGfZJDppCoF2gPq1XvzrHD/Qog=; b=CB7fZy4ZyBvmjEDz9GUcB6NcCZHSo6T1Wyj5OWrn2T6SEteElKp72x34ReVyxPqXhkh28Mt/65zPfW+X/gauzGfXNCclNyxtjxMw3uecPTGkwDkzMWZhu1mLUcCYWLkscx8BR+tU8fgkxFblKfTuNd+cBzlLi8lireio+KE/HuzPOIph0RzBH7+R0THBkD+1sOzIDMXxYbBjpA2UxxbXDs/80vdWFl+DuQErqYaPFdMzA4kkLmhOIRMVGdluvHAujHahXFyfB7VRE1L5eI3V/A+edDdJd3AzS18n8ZUMMtHp/DxrGtF8NNZJDM7Mjr3RDjdhwwyFzdJAVW66vutxuQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v2Gez0z3Syc1iG3lNbGfZJDppCoF2gPq1XvzrHD/Qog=; b=fJJQt7gcRWenwL1TJJIje9lBjYLAwsDohmRYLfR6rMm0xTiQMfbmfLqtNTYci3L3MqzIr4+kA5xBjTi2+KhC4uXrAIyiUTv0KoGdOlWAZKMDdxuHhYKQq89mbaS9KBx4lJ3I2cbDHHFaDVui/Nb/f72QDnQ39zVaojcB03XNYWk=
Received: from BL0PR06MB4772.namprd06.prod.outlook.com (52.132.0.222) by BL0PR06MB5074.namprd06.prod.outlook.com (10.167.233.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.22; Mon, 17 Feb 2020 12:39:07 +0000
Received: from BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::f0d3:21c8:5720:a272]) by BL0PR06MB4772.namprd06.prod.outlook.com ([fe80::f0d3:21c8:5720:a272%3]) with mapi id 15.20.2707.035; Mon, 17 Feb 2020 12:39:07 +0000
From: Robin Wilton <wilton@isoc.org>
To: Benjamin Kaduk <kaduk@mit.edu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: "model-t@iab.org" <model-t@iab.org>
Thread-Topic: [Model-t] ICN as an example (was: Re: (meta) Trust, and threat vs vulnerability models)
Thread-Index: AQHV43Sc1YsPtG8WdUagsrkNiSvd3qgfUlkx
Date: Mon, 17 Feb 2020 12:39:07 +0000
Message-ID: <BL0PR06MB4772B78C2E158D31D1A62571BF160@BL0PR06MB4772.namprd06.prod.outlook.com>
References: <mailman.804.1581694262.25531.model-t@iab.org> <2571A4DB-05F7-477D-A244-B53193C15BD9@isoc.org> <894281a0-6319-3967-8482-2da860bf2963@cs.tcd.ie>, <20200214202313.GH43385@kduck.mit.edu>
In-Reply-To: <20200214202313.GH43385@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org;
x-originating-ip: [185.222.26.242]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 006fac7f-87d4-4746-5d5c-08d7b3a6614e
x-ms-traffictypediagnostic: BL0PR06MB5074:
x-microsoft-antispam-prvs: <BL0PR06MB5074291ED2AB5BB1CBD38183BF160@BL0PR06MB5074.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0316567485
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(39840400004)(396003)(376002)(199004)(189003)(110136005)(9686003)(2906002)(86362001)(316002)(33656002)(7696005)(8936002)(55016002)(4326008)(76116006)(5660300002)(6506007)(26005)(55236004)(8676002)(81166006)(91956017)(66556008)(64756008)(66476007)(66446008)(66946007)(52536014)(81156014)(53546011)(71200400001)(186003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB5074; H:BL0PR06MB4772.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TQZLZGloyVhTF/JjBo9YQE3/nHLQL+EOMA83Ac+CzDCAqe0qQNdq9xXH+3zUrLOETojF+QTruriVAcR2LfM67gxPghPeTUNVnNs11vjAhp2SIJ9PYseua8kpdWK0RKk4XBQYa4z8WriKPxnXSSHsp1fNZOsAI7nbMr4YR8vtsYJtp+wv/vBPnLULm/V7t6ZTy6MC31ANRYgmBvVVTimt83iuOcYzQCY3OKjSK7IfkhoOS1yEYYOQDsW4acLdTE6MUEmumLQIQKi6T80wSO2kIY0gFdvA7ZiqE3OQo+q3ONJMScY906ldA4IXNQUYT+3Y15JUPzR9CR+PDdksUfK6F1E4rvEEy1YcoMZ/u9XPSoknb77/GTjSR0BNQLaIFUEfeSpQalbSYPPNCWuzDFwqGgXAjfVaD9FdTQVfI53Xbq9Mw6NIqm1GU9iJSpgZUMzN
x-ms-exchange-antispam-messagedata: ZZGfQ0563w7Ys20trpsYkZSjyK0b5flFE2130wFomrnIjXRpJ7i7gRg2d7bSYjqWlAVJINrBfckZiV0g9R/Hv9QUUoMRiL0mUmZdNokOeu96C9af2LhLQpfPRpLvqkYYUbc/HBHikhkxSNTUq2hdLQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR06MB4772B78C2E158D31D1A62571BF160BL0PR06MB4772namp_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 006fac7f-87d4-4746-5d5c-08d7b3a6614e
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 12:39:07.4453 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7ScSHp4rHLOJOHxhGTnOLTMBsUk6J6s0hjzrfe/Yzth4c2IubHqdTfX33BXbPb/4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB5074
Archived-At: <https://mailarchive.ietf.org/arch/msg/model-t/oYfQZ4hz7LvP7kD5tinD6_yiLgc>
Subject: Re: [Model-t] ICN as an example (was: Re: (meta) Trust, and threat vs vulnerability models)
X-BeenThere: model-t@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions of changes in Internet deployment patterns and their impact on the Internet threat model <model-t.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/model-t>, <mailto:model-t-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/model-t/>
List-Post: <mailto:model-t@iab.org>
List-Help: <mailto:model-t-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/model-t>, <mailto:model-t-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2020 12:39:19 -0000

Thanks, both... just for clarity, my question/point wasn’t about ICN per se.
It was an attempt to find a (maybe poor) example of an innovation that changes the function of network nodes, increases the attack surface, and therefore potentially invalidates some of the reasons why I might previously have trusted the network to behave in a particular way.

Here’s the hypothetical I was trying to explore: maybe I previously trusted intermediate nodes not to prioritise other users’ traffic over mine, because those nodes were too dumb to do so. However, let’s suppose that an intermediate node now starts to make “reputational” judgements about the behaviour of other nodes, and starts to prioritise particular routes for some kinds of traffic. That potentially creates a situation in which an adversary could manipulate the “reputation” data so as to influence the node’s decisions about prioritisation, in ways that weren’t previously an option.

Like I say, this isn’t so much about whether ICN makes that possible (though I’ve heard something similar described as an R&D idea); it’s about whether increased functionality at intermediate nodes (as opposed to endpoints) materially changes the threat model.

Hope this helps,
Robin

________________________________
From: Benjamin Kaduk <kaduk@mit.edu>
Sent: Friday, February 14, 2020 8:23:13 PM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Robin Wilton <wilton@isoc.org>; model-t@iab.org <model-t@iab.org>
Subject: Re: [Model-t] ICN as an example (was: Re: (meta) Trust, and threat vs vulnerability models)

On Fri, Feb 14, 2020 at 08:18:28PM +0000, Stephen Farrell wrote:
>
> Hi Robin,
>
> I'm not sure I'm following your argument TBH, but that
> might be because I think the answer to:
>
> On 14/02/2020 17:52, Robin Wilton wrote:
> > "does a shift towards information-centric networking change the
> > reasons why I should or should not trust the network to behave as I
> > expect?"
>
> ...is fairly straightforwardly a "no."
>
> Without straying too far into ICN weeds (but I am a bit,
> hence the change to the subject line:-), ICN has no real
> conception of confidentiality nor access control that
> doesn't bring it right back to host-based networking (in
> terms of risks). I guess in future someone might figure
> out "pure" ICN-oriented solutions for such services, but
> afaik, they've not. I think the same is also still true
> for how any PKI might be used to support ICN, so even
> the signed-data doesn't really change many of the risks
> that much.
>
> So I'm not clear that consideration of ICN will be that
> enlightening for us.

I'm not super-versed in ICN, but it seems like it would be more of an
object security model than a connection-oriented one, so it might become
hard to know that you have received the latest information of a given kind.

-Ben