Re: [LISPmob-users] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
> 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. The IETF’s LISP-DDT borrows ideas from DNS but does not need to be structured like the DNS deployed today. There is hierarchy for scale with iterative lookups, but we don’t have to allow it to get out of hand with too many levels of hierarchy. Dino
Re: [LISPmob-users] [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
> Am 28.09.2016 um 05:02 schrieb Dino Farinacci: >>> 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. >> The IETF’s LISP-DDT borrows ideas from DNS but does not need to be >> structured like the DNS deployed today. There is hierarchy for scale with >> iterative lookups, but we don’t have to allow it to get out of hand with too >> many levels of hierarchy. > What do you mean by that exactly? What's the problem with DNS and what's > the advantage of LISP-DDT? These were the main reasons we didn’t consider DNS as a mapping system back in the RRG days when we were designing the mapping system for LISP: (1) DNS didn’t work easily on bit boundaries. So delegation would have to be on byte boundaries and that restricts the flexibility of how EID address allocation occurs on the LISP-DDT hierarchy. (2) DNS doesn’t have a pub/sub model. LISP needed notification support so old RLOCs new when an EID has moved to a new set of RLOCs. (3) Architecturally, we didn’t want routing information to be in an applicaiton Directory. Since DNS depends on routing, we didn’t want routing to depend on DNS and cause a circular dependency to be created. (4) And we thought it would be too hard to get IETF to allow network layer information to be stored in what is really a application level database. So the architectural definition of a LISP EID would be in the DNS pointed to by names and the dynamic binding of EIDs to RLOCs would be in a new network layer database, which we refer to as the LISP Mapping System. Dino > > Michael > >> >> Dino >> >> ___ >> lisp mailing list >> l...@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp
Re: [LISPmob-users] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
>> 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. > What is your vision? How much of the mapping data can be encrypted and > how much information about the mapping owner can be hidden from the Well I think we can encrypt the transport of messages from LISP sites to the mapping system. As to encrypting the stored state at the map-servers could also be done but here are some caveats: (1) If the MSP is providing proxy-reply services it has to return Map-Replies to ITRs/PITRs. It can do so with lisp-sec for security. But the information needs to be stored in plaintext. (2) All the map-servers need to know when they are not proxy-replying is to know the RLOCs of the ETRs of the site that registered the information (and not so much all of the RLOC-records that were registered) so the map-servers can forward Map-Requests to the ETRs so they can Map-Reply. > mapping system operator? The ID cannot be encrypted as it is used as > retrieval key. When we want to make sure that only rightful owners of Right. At a minimum, the amount of plaintext that is stored in the map-servers are EID-prefix and the RLOCs in the RLOC-set (for case (2) above). > IDs can register, the mapping system provider needs to authenticate the That is done today with a Map-Register that contains an authentication hash across the entire Map-Register message. > mapping owner. Can you elaborate the problem you are tackling and the > solution in more detail? I was solely asking if the messaging to the mapping system should be confidential. Dino
Re: [LISPmob-users] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt
> 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, 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 sh
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 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
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
[LISPmob-users] 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.
Re: [LISPmob-users] 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.
