Subject: [lisp] 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: Robert Raszuk <[email-masked]>
Date: Wed, 28 Sep 2016 01:13:37 +0200

Dear Lin,

You bring interesting news to the table with your insight ...

IMHO any global mapping plane should be fully distributed with no root
under any specific gov.

Look at BGP protocol ... it does not require a root .. yet it allows to
dynamically interconnect quite a few of global databases. Of course from 30
years back we now know much more modern ways to share information then via
distance vector protocol. But none of those should be based on any politics
controlling "the root" of it no matter which side it is on.

/* Side comment .... */

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.

Best,
Robert.

On Wed, Sep 28, 2016 at 1:06 AM, Lin Han <[email-masked]> wrote:

> 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
>
>
>
> Cc: [email-masked]; LISP mailing list list; NVO3;
> [email-masked]; LISPmob; [email-masked];
> [email-masked]
> 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.
>
> 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
>
> ----
>

---

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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Sep 2016 20:02:03 -0700

> 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

---

From: Michael Menth <[email-masked]>
Date: Wed, 28 Sep 2016 08:50:54 +0200

Hi Dino,

> 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…
What do you mean by that exactly? What's the problem with DNS and what's
the advantage of LISP-DDT?

Michael

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

---

From: Michael Menth <[email-masked]>
Date: Wed, 28 Sep 2016 08:50:40 +0200

Hi Dino,

> 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 serv…
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
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
IDs can register, the mapping system provider needs to authenticate the
mapping owner. Can you elaborate the problem you are tackling and the
solution in more detail?

Michael

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Sep 2016 13:24:31 -0700

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

> 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

I was solely asking if the messaging to the mapping system should be confidential.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Sep 2016 13:30:04 -0700

> 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

---

From: Sharon <[email-masked]>
Date: Thu, 29 Sep 2016 11:19:43 -0700

Can add that we don't want to scale a mapping service like dns or x500. rather take full advantage of no-sql tech that wasn't available at the time to create a flat pub-nub like service for overlays, scaled based on underlay regular IP. No bootstrap loop.

The effect on mobile can be dramatic, any packet coming up from the base-station, no matter the address space or transience can be considered Gi. No need for a whole different sets of framework for network functions pre Gi and post Gi. There's the RAN and there's virtual IP (NVO3). Or rather (flat ) directory-assisted virtual IP. traffic going back and forth:
                            
                            Mapping 
                       |                        |
RAN <> NVO3 <> IP <> NVO3 <> Internet 
                     |                            |
             Functions            Functions 
           (scheduling)          (peering)

--szb