> Hi, Dino > > Should we consider the security of sovereignty for the mapping system? This > question is probably too early.
Yes, you bring up a very real question that needs to be answered this 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. Architecturally we need root nodes as a mechanism but they do not have to be run by any one party or spread across government/continental boundaries. Any root could be run independently and point to the same next level children leading to map-servers. > 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. Dino > > > Regards > > Lin > > > > -----Original Message----- > From: Ideas [mailto:ideas-boun...@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, September 21, 2016 2:13 PM > To: id...@ietf.org > Cc: b...@lispers.net; LISP mailing list list; NVO3; > lisp-al...@external.cisco.com; LISPmob; 5gan...@ietf.org; > lisp-...@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 > id...@ietf.org > https://www.ietf.org/mailman/listinfo/ideas _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
