Re: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
Robert Raszuk <robert@raszuk.net> Tue, 27 September 2016 23:13 UTC
Return-Path: <rraszuk@gmail.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 7408312B01C;
Tue, 27 Sep 2016 16:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=gmail.com
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 vOcFdi_gjhtT; Tue, 27 Sep 2016 16:13:41 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com
[IPv6:2a00:1450:400c:c09::22d])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 4631C12B4B8;
Tue, 27 Sep 2016 16:13:40 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id w84so203746583wmg.1;
Tue, 27 Sep 2016 16:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=hBSFtnUIhGUP9WTkjlpdJkyBLr9e2J+9GL28hSfp5rE=;
b=HSmbR6+4guyvoZdW2KB9E///b0Gd8aTVgZ0ar3DKk4Dg7y3WjioRjnrBIkb84Ckuh8
sXvL9CQsCAxbfiFVopzFuAjbtt1drH8IdtadDL0FQBs9cJES4Y3mgN+Vq8n++rVrtYtc
wJLqRRxqZuOlAEPjRoSi3jOJ8hVD+7PKUn0m4gggWbTETA5Fb7tibmYmXqtFfx/pn0/q
6OsdnOEDcslxiNLkJt7VaJ5gjRVQ5JlNIhLF0FUFtHKi4DaJ4Am32sfbovaVqbcIJyKH
+79vqKHv4I1SjSPxQkbPcY6mc00lWsOq40ZJRol1atmjJSh1Wl88yNYCXBlZ2yQT5HXn
HMTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=hBSFtnUIhGUP9WTkjlpdJkyBLr9e2J+9GL28hSfp5rE=;
b=TNM31pLCTyHUmLjcEA34Bl89WjrL8lQxiun7j2BigYz9N7nU7yZpAy4OyZvcnmkIQb
S8cSfwrJmBj5JEotzakgylT9BmiY3Md4d7WJg4AOD+yymb3D6hsbL/CKIsZvujgvpZEh
WJDCDYtxkbur0x02n2eH4po1rTNkyoA6cUs7Cn8jH+GLQomST54Nd1E4r+X6ap5oteaH
V/Q7PPqc0nOfLWBMT/4C3fPkvEZ6eI06bLw4sOb77KLOFV4MG/OcKJT5qRWaAaO/+Tgp
zL6/1zBtZl+4z9BCZF9E4Nd6xlyLUfoHeK/gM/QSjreBhn6zQTTfwjmsokDEmEAtRR0R
/7sg==
X-Gm-Message-State: AA6/9Rkj4EYBdV3QVGPyEaezpSFKHaYdv0VIXe5x6uH8ba1s6CLkjaqCxZEj7Xzpj09aqXlBE9u5hsWN5aSksA==
X-Received: by 10.28.35.68 with SMTP id j65mr4814453wmj.61.1475018018739; Tue,
27 Sep 2016 16:13:38 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.153.44 with HTTP; Tue, 27 Sep 2016 16:13:37 -0700 (PDT)
In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com>
References: <32C28142-350A-4242-A9C6-9E32D9966601@gmail.com>
<1D30AF33624CDD4A99E8C395069A2A162A600B3E@SJCEML701-CHM.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 28 Sep 2016 01:13:37 +0200
X-Google-Sender-Auth: tJ4zCPyuB-cB0v7XVEaFOi-TvGc
Message-ID: <CA+b+ER=JhWHkDWgJhwpxUs8MWHr_yuRvqSeWgMuaJofkX_5QVg@mail.gmail.com>
To: Lin Han <Lin.Han@huawei.com>
Content-Type: multipart/alternative; boundary=001a113e9a340b5db2053d856545
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/3pApOG13Gh-kPsM4iLDRG1Jt0ek>
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>,
Dino Farinacci <farinacci@gmail.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: Tue, 27 Sep 2016 23:13:44 -0000
Dear Lin, You bring interesting news to the table with your insight ... IMHO any global mapping plane should be fully distributed with no root under any specific gov. Look at BGP protocol ... it does not require a root .. yet it allows to dynamically interconnect quite a few of global databases. Of course from 30 years back we now know much more modern ways to share information then via distance vector protocol. But none of those should be based on any politics controlling "the root" of it no matter which side it is on. /* Side comment .... */ When I spoke to some of the 5G folks this was clearly the direction and in fact Dino's LISP was one of the strongest candidates there as control plane. Best, Robert. On Wed, Sep 28, 2016 at 1:06 AM, Lin Han <Lin.Han@huawei.com> wrote: > Hi, Dino > > Should we consider the security of sovereignty for the mapping system? > This question is probably too early. > > As you know, DNS tree architecture introduced a lot debate historically > for the ownership and operation of root DNS. Due to pressure from industry > and other countries, USA government plans to hand over the operation of > root DNS to IANA next month even there is a lot opposing voice from > congress. It could change back again. > > 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. > > This is related to both technology and politics. Without the support of > other countries, mapping server deployment globally will be in question. > > > Regards > > Lin > > > > -----Original Message----- > From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, September 21, 2016 2:13 PM > To: ideas@ietf.org > Cc: beta@lispers.net; LISP mailing list list; NVO3; > lisp-alpha@external.cisco.com; LISPmob; 5gangip@ietf.org; > lisp-ops@external.cisco.com > Subject: [Ideas] Mapping System Requirements and draft-padma-ideas-problem- > statement-00.txt > > Hello folks. In draft-padma-ideas-problem-statement-00.txt, we have a > section on mapping system requirements for map-n-encap and translation > based loc/id split protocols. Rather than having you go into the document > in detail (we wish you would and comment though), I will provide the short > list below to attempt a discussion on requirements. > > I have copied the possible WGs that may want to use the mapping system > technology. And I have also copied the LISP working group who can shed > expertise on the subject as well as some beta lists that have some > operational experiences with mapping database deployment and management. > > The requirements below have a security and robustness twist to it but I > think that is the best place to start and to consider security “up front”. > > Thanks in advance, > Dino > > ---- > > 6.4. Mapping System Security > > The secure mapping system must have the following requirements: > > 1. The components of the mapping system need to be robust against > direct and indirect attacks. If any component is attacked, the > rest of the system should act with integrity and scale and only > the information associated with the compromised component is made > unavailable. > > 2. The addition and removal of components of the mapping system must > be performed in a secure matter so as to not violate the > integrity and operation of the system and service it provides. > > 3. The information returned by components of the mapping system > needs to be authenticated as to detect spoofing from > masqueraders. > > 4. Information registered (by publishers) to the mapping system must > be authenticated so the registering entity or the information is > not spoofed. > > 5. The mapping system must allow request access (for subscribers) to > be open and public. However, it is optional to provide > confidentiality and authentication of the requesters and the > information they are requesting. > > 6. Any information provided by components of the mapping system must > be cryptographically signed by the provider and verified by the > consumer. > > 7. Message rate-limiting and other heuristics must be part of the > foundational support of the mapping system to protect the system > from invalid overloaded conditions. > > 8. The mapping system should support some form of provisioned > policy. Either internal to the system or via mechanisms for > users of the system to describe policy rules. Access control > should not use traditional granular-based access lists since they > do not scale and are hard to manage. By the use of token- or > key- based authentication methods as well as deploying multiple > instances of the mapping system will allow acceptable policy > profiles. Machine learning techniques could automate these > mechanisms. > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas >
- [Ideas] Mapping System Requirements and draft-pad… Dino Farinacci
- Re: [Ideas] Mapping System Requirements and draft… Dino Farinacci
- Re: [Ideas] [nvo3] Mapping System Requirements an… Black, David
- Re: [Ideas] [nvo3] Mapping System Requirements an… Michael Menth
- Re: [Ideas] [nvo3] Mapping System Requirements an… Dino Farinacci
- Re: [Ideas] [nvo3] Mapping System Requirements an… Padma Pillay-Esnault
- Re: [Ideas] [nvo3] Mapping System Requirements an… Dino Farinacci
- Re: [Ideas] Mapping System Requirements and draft… Lin Han
- Re: [Ideas] Mapping System Requirements and draft… Dino Farinacci
- Re: [Ideas] [lisp] Mapping System Requirements an… Richard Li
- Re: [Ideas] [lisp] Mapping System Requirements an… Dino Farinacci
- Re: [Ideas] [lisp] Mapping System Requirements an… Padmadevi Pillay Esnault
- Re: [Ideas] Mapping System Requirements and draft… Lin Han
- Re: [Ideas] [lisp] Mapping System Requirements an… Lin Han
- Re: [Ideas] [lisp] Mapping System Requirements an… Dino Farinacci
- Re: [Ideas] [5gangip] Mapping System Requirements… Padmadevi Pillay Esnault
- Re: [Ideas] [5gangip] Mapping System Requirements… Tom Herbert
- Re: [Ideas] Mapping System Requirements and draft… Robert Raszuk
- Re: [Ideas] Mapping System Requirements and draft… Dino Farinacci
- Re: [Ideas] [lisp] Mapping System Requirements an… Michael Menth
- Re: [Ideas] Mapping System Requirements and draft… Michael Menth
- Re: [Ideas] Mapping System Requirements and draft… Dino Farinacci
- Re: [Ideas] [lisp] Mapping System Requirements an… Dino Farinacci
- Re: [Ideas] [lisp] Mapping System Requirements an… Sharon
- Re: [Ideas] [5gangip] Mapping System Requirements… Padmadevi Pillay Esnault