Re: [Ideas] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

[Dino Farinacci <[e-mail]>]

> 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:[e-mail]] On Behalf Of Dino Farinacci
>> Sent: Wednesday, September 21, 2016 6:51 PM
>> To: Dino Farinacci
>> Cc: [e-mail]; [e-mail]; LISP mailing list list; NVO3; LISPmob;
>> [e-mail]; [e-mail]
>> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3