Re: [LISPmob-users] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
> 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 Farinacciwrote: >>> >>> 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
Re: [LISPmob-users] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
Hi David Thanks for your comments. I take note of your comment (2) and pointer. Here is a pointer to the draft https://www.ietf.org/internet-drafts/draft-padma-ideas-probl em-statement-00.txt Padma On Wed, Sep 21, 2016 at 4:19 PM, Black, Davidwrote: > 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 > >
Re: [LISPmob-users] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
> The optional requirement for confidentiality was added for potential use > cases where only some users are allowed to access information about > others. Motivation: snooping mapping system informatation may be a way > to track the behavior of other users. Especially if GPS coordinates were part of the RLOC-records. Dino
Re: [LISPmob-users] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
Hi David, 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. > > (1) I don't see any confidentiality requirements. The optional requirement for confidentiality was added for potential use cases where only some users are allowed to access information about others. Motivation: snooping mapping system informatation may be a way to track the behavior of other users. Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:me...@uni-tuebingen.de http://kn.inf.uni-tuebingen.de
Re: [LISPmob-users] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
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 Farinacciwrote: > > > > 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