Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

Alexander Clemm <alexander.clemm@huawei.com> Mon, 09 October 2017 21:15 UTC

Return-Path: <alexander.clemm@huawei.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BFD134218; Mon, 9 Oct 2017 14:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 JFIK1sQvbTNG; Mon, 9 Oct 2017 14:15:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C74132D51; Mon, 9 Oct 2017 14:15:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF32139; Mon, 09 Oct 2017 21:15:00 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 22:14:59 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 14:14:48 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Tom Herbert <tom@herbertland.com>, Uma Chunduri <uma.chunduri@huawei.com>
CC: "ideas@ietf.org" <ideas@ietf.org>, Padma Pillay-Esnault <padma.ietf@gmail.com>, S Moonesamy <sm+ietf@elandsys.com>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTOT4HtvaRdsDDgEqucGYSnlXKNaLZOf32gAESvhGAAHpWAP//jtH5gAHxDwCAAAaigP//wyFw
Date: Mon, 9 Oct 2017 21:14:48 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA8500@sjceml521-mbx.china.huawei.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <CAG-CQxpnHKtov+pj6YFL0wxnO3YX7mbLUA9uHUkVQbHqE3A1rQ@mail.gmail.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <CAG-CQxpEb8Lcjy0M5445K4Ob+nQW15WeEooggcxpb=hToB4HZw@mail.gmail.com> <6.2.5.6.2.20171008112206.1100fa88@elandnews.com> <25B4902B1192E84696414485F572685401A87E81@SJCEML701-CHM.china.huawei.com> <CALx6S342Zq15nvoxWxsAbeW=mb==QKcpOnbmEVmc_i-oEwBNRw@mail.gmail.com>
In-Reply-To: <CALx6S342Zq15nvoxWxsAbeW=mb==QKcpOnbmEVmc_i-oEwBNRw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.78]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59DBE6D4.01CD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/5mQKG5jTUGwKndpXHlvfLzJf0Y4>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Oct 2017 21:15:05 -0000

> 
> I don't believe that is true. There are many examples of deployments that
> have a private mapping system which is not accessible by just anyone, For
> instance, in multi tenant virtualization it is imperative that tenants are not
> able to access the mapping system-- if they were then the whole concept of
> virtual network isolation starts to breaks done. Mapping systems are already
> by protected using ACLs, authentication, network isolation, etc.
> 
> Tom
> 

I thought one concern raised here wasn't that the information couldn't be secured, but that the owner or operator of the mapping system could collude with dark forces to turn its information against you, in which case all bets are off. 

Assuming for a moment that we have an operator who does not collude with dark forces and does want to secure access to the mapping system and information, one question concerns how the access is controlled - just to the mapping system as a whole, or at the level of individual records.  Is this level of differentiation provided (which can be important if I want to protect e.g. my locator information from some, but not all users)? 

--- Alex