Subject: [5gangip] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Sep 2016 14:12:57 -0700

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.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Sep 2016 15:51:07 -0700

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 <[email-masked]> wrote:
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 21 Sep 2016 23:19:00 +0000

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

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

---

From: Michael Menth <[email-masked]>
Date: Thu, 22 Sep 2016 08:48:35 +0200

Hi David,

> 
> (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:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Sep 2016 11:08:50 -0700

> to track the behavior of other users.

Especially if GPS coordinates were part of the RLOC-records.

Dino

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 22 Sep 2016 22:17:18 -0700

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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Sep 2016 15:43:38 -0700

> Hi Dino,

Thanks so much David for the reply. The pointers you provided will be useful.

> 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?

> 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.

> suggests that congestion control is also a consideration to protect the network.

Yes.

> 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

---

From: Lin Han <[email-masked]>
Date: Tue, 27 Sep 2016 23:06:00 +0000

Hi, Dino

Should we consider the security of sovereignty for the mapping system? This question is probably too 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.

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.

This is related to both technology and politics. Without the support of other countries, mapping server deployment globally will be in question.

Regards

Lin

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Wednesday, September 21, 2016 2:13 PM
To: [email-masked]
Cc: [email-masked]; LISP mailing list list; NVO3; [email-masked]; LISPmob; [email-masked]; [email-masked]
Subject: [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Thanks in advance,
Dino

----

Ideas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ideas

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Sep 2016 19:59:33 -0700

> 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…

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&T, 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