Hi Dino, Here are a couple of areas to consider:
(1) I don't see any confidentiality requirements. For this and other NVO3 security requirements, please see the security considerations section of RFC 7365 (NVO3 framework) and draft-ietf-nvo3-arch. The latter contains a new paragraph on sensitivity of performance and other monitoring data gathered by the control plane - that paragraph was added at the behest of both Security ADs: https://tools.ietf.org/html/rfc7365#section-5 https://tools.ietf.org/html/draft-ietf-nvo3-arch-08#section-16 (2) This item: > > 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. suggests that congestion control is also a consideration to protect the network. If an existing congestion-controlled transport protocol (e.g., TCP, SCTP, DCCP) is not used for control traffic, then see draft-ietf-tsvwg-rfc5405bis for discussion of applicable requirements: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/ Thanks, --David > -----Original Message----- > From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, September 21, 2016 6:51 PM > To: Dino Farinacci > Cc: b...@lispers.net; id...@ietf.org; LISP mailing list list; NVO3; LISPmob; > 5gan...@ietf.org; lisp-b...@external.cisco.com > Subject: Re: [nvo3] Mapping System Requirements and draft-padma-ideas- > problem-statement-00.txt > > Reposting since the cisco mailing lists are no longer in service. Please > respond to > this email. > > Thanks and sorry for inconvenience, > Dino > > > On Sep 21, 2016, at 2:12 PM, Dino Farinacci <farina...@gmail.com> wrote: > > > > 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. > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
