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

[Lin Han <[e-mail]>]

Hi, Robert

Agree that the distributed mapping system will not have the root DNS location/ownership/operation issues which brought a lot of debating before.
As a basic protocol for internet, BGP has been very successful in this area.
But if we want to use BGP for this mapping system, I guess BGP’s current performance/security may not satisfy the requirement of mobility hand over unless we change it a lot. Sure this might be a direction to investigate for the architecture of mapping server.

Rgds

Lin

From: [e-mail] [mailto:[e-mail]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 27, 2016 4:14 PM
To: Lin Han
Cc: Dino Farinacci; [e-mail]; [e-mail]; LISP mailing list list; NVO3; [e-mail]; LISPmob; [e-mail]; [e-mail]
Subject: Re: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Dino Farinacci
Sent: Wednesday, September 21, 2016 2:13 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; LISP mailing list list; NVO3; [e-mail]<mailto:[e-mail]>; LISPmob; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ideas