Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

There are some preliminary thoughts on overload issues in the security 
considerations of draft-ietf-lisp-introduction.

I will also be curious to see what the presentations at the technical 
plenary in Seoul have to suggest on the issue, if anything.

There probably is more with considering.

Yours,
Joel

On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote:
> The recent Denial-of-service attacks is a scenario we should have in mind when building robustness in the network mapping system.
> In draft-padma-ideas-problem-statement-00.txt, there is a section on mapping system security requirements that specifically cover
> this case.
>
> One of the questions that comes to mind is whether the robustness of such a mapping system should drop/throttle responses when it is
> Overloaded or should we expect it always to handle the load no matter what?
> While we do propose to rate-limit the messages in the problem statement, isn't this playing into the hands of the attackers?
>
> Requesting feedback from the list and ccing wg with expertise in the area or interest in mapping system technology.
>
> Thanks in advance
> Padma
>
> Below an excerpt from the draft
> 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.
>
>
> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Chair
> Sent: Friday, October 28, 2016 9:21 AM
> To: IETF Announcement List
> Cc: ietf@ietf.org
> Subject: Technical plenary: Attacks against the architecture
>
> The technical plenary in Seoul will be about the recent Denial-of-Service
> attacks involving the use of compromised or misconfigured nodes or
> “things”, and the architectural issues associated with the network
> being vulnerable to these attacks.
>
> See
>
>   https://www.ietf.org/blog/2016/10/attack-against-the-architecture/
>
> and join us for the discussion on Wednesday 16:40-19:10, November 16,
> 2016 either in person or remotely. You can register for the meeting here:
>
>   https://www.ietf.org/meeting/97/index.html
>
> Jari Arkko, IETF Chair
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>