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

["Black, David" <[e-mail]>]

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:[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