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

[Dino Farinacci]

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

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

[Padma Pillay-Esnault]

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



On Wed, Sep 21, 2016 at 4:19 PM, Black, David  wrote:

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

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

[Dino Farinacci]

> 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

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

[Michael Menth]

Hi David,


   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.

> 
> (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:me...@uni-tuebingen.de
http://kn.inf.uni-tuebingen.de

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

[Black, David]

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: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  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
> n...@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3