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

Padmadevi Pillay Esnault <padma@huawei.com> Fri, 28 October 2016 23:40 UTC

Return-Path: <padma@huawei.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9C129638; Fri, 28 Oct 2016 16:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3xDk55AsZmx; Fri, 28 Oct 2016 16:40:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65924129429; Fri, 28 Oct 2016 16:40:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZG08931; Fri, 28 Oct 2016 23:40:04 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 29 Oct 2016 00:40:03 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Fri, 28 Oct 2016 16:39:53 -0700
From: Padmadevi Pillay Esnault <padma@huawei.com>
To: "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: Technical plenary: Attacks against the architecture - implications for the Network Mapping System
Thread-Index: AQHSMTdVE6o3cYrLi025ADZM5w7QIaC+f2AA
Date: Fri, 28 Oct 2016 23:39:52 +0000
Message-ID: <EC7A99B9A59C1B4695037EEB5036666B012C63D0@dfweml501-mbb>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.218]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5813E1D4.011B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a923a50355e87759d9a3cbaa3b166bd1
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/eIy4voCqEf1xB-U0LllVPDoWTC0>
Cc: Padmadevi Pillay Esnault <padma@huawei.com>, "lisp@ietf.org" <lisp@ietf.org>
Subject: [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 23:40:09 -0000

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