Re: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Michael Menth <menth@uni-tuebingen.de> Wed, 28 September 2016 06:57 UTC

Return-Path: <menth@uni-tuebingen.de>
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 3E9FC12B337; Tue, 27 Sep 2016 23:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level:
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=unavailable 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 zTMgBJYqBiAF; Tue, 27 Sep 2016 23:57:53 -0700 (PDT)
Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (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 5A27B12B38D; Tue, 27 Sep 2016 23:50:43 -0700 (PDT)
Received: from [192.168.1.100] (hsi-kbw-109-192-128-060.hsi6.kabel-badenwuerttemberg.de [109.192.128.60]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 5CC2BE5117; Wed, 28 Sep 2016 08:50:41 +0200 (CEST)
To: Dino Farinacci <farinacci@gmail.com>, Lin Han <Lin.Han@huawei.com>
References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com> <ADE71A46-ABEC-4043-B740-6FEF3ACBE035@gmail.com>
From: Michael Menth <menth@uni-tuebingen.de>
X-Enigmail-Draft-Status: N1110
Message-ID: <57EB6840.1070808@uni-tuebingen.de>
Date: Wed, 28 Sep 2016 08:50:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <ADE71A46-ABEC-4043-B740-6FEF3ACBE035@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/GkbTaxptDH8XEgTcddVJONC_dto>
X-Mailman-Approved-At: Thu, 29 Sep 2016 15:46:55 -0700
Cc: "beta@lispers.net" <beta@lispers.net>, "ideas@ietf.org" <ideas@ietf.org>, LISP mailing list list <lisp@ietf.org>, NVO3 <nvo3@ietf.org>, "lisp-alpha@external.cisco.com" <lisp-alpha@external.cisco.com>, LISPmob <users@lispmob.org>, "5gangip@ietf.org" <5gangip@ietf.org>, "lisp-ops@external.cisco.com" <lisp-ops@external.cisco.com>
Subject: Re: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 28 Sep 2016 06:57:54 -0000

Hi Dino,

Am 28.09.2016 um 04:59 schrieb Dino Farinacci:
>> One side is that the national security of US prefer the government operates the root DNS, another side is that other countries don’t like US to completely control the DNS.
> I see this hierarchy run by commercial companies that have monetary incentive to run a production level service. So for example, I could use a pair of roots from say a Verisign. Or a different pair of roots offered by an AT&T, or a possible a third-party that calls themselves a Mapping Service Provider (MSP).
>
> It is these roots at the top of the tree that need to connect to common parts in the middle and to the leaf map-servers of the tree.
>
>> This is related to both technology and politics. Without the support of other countries, mapping server deployment globally will be in question.
> If registrations and requests are encrypted, then anyone could run the roots and the what goes in and out of the mapping system stays private. But there needs to be competition so the level of service stays at a high-quality production level.
What is your vision? How much of the mapping data can be encrypted and
how much information about the mapping owner can be hidden from the
mapping system operator? The ID cannot be encrypted as it is used as
retrieval key. When we want to make sure that only rightful owners of
IDs can register, the mapping system provider needs to authenticate the
mapping owner. Can you elaborate the problem you are tackling and the
solution in more detail?

Michael