> Hi Dino, Thanks so much David for the reply. The pointers you provided will be useful.
> 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 I can see this for east-west traffic patterns. Assuming the mapping database would be managed internal to a data center where there would not be regisrations from any VTEPs/xTRs outside of the data center. But what if there was an overlay among CPE routers, access-points, and top-of-rack data center switches. Then the registration and requesting of mappings may travel outside of a secured physical area. Any reaction to this? > 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 For multi-tenancy, there can be an instance of a mapping system that runs for each tennant or a single mapping system run by the multi-tennant provider. In any case, encrypting Map-Registers and Map-Requests COULD be desirable. Not sure. Again, this requirement we have stated would be for private mapping systems and not a global mapping system that would be a public service much like DNS is. > https://tools.ietf.org/html/draft-ietf-nvo3-arch-08#section-16 Since the draft-padma-ideas-problem-statement-00.txt is focusing on control-plane, there would be no mention of data-plane security but there are mechanisms for doing this. For the control-plane reference in section 16, there is plans to have authentication and it could also be done with AE (Authenticated Encryption) mechanisms. > > (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. Yes. > 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: We were thinking not just high-rate due to speed mismatches but more importantly DoS attacks from rogue sources. Thanks again, Dino > 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 >> n...@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3
