Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System
Dino Farinacci <farinacci@gmail.com> Sat, 29 October 2016 17:27 UTC
Return-Path: <farinacci@gmail.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 358951294F3;
Sat, 29 Oct 2016 10:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=gmail.com
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 TXSPjIfR-CW2; Sat, 29 Oct 2016 10:27:54 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com
[IPv6:2607:f8b0:400e:c00::233])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 09608129421;
Sat, 29 Oct 2016 10:27:54 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id s8so53850215pfj.2;
Sat, 29 Oct 2016 10:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=iEoGu2hJ5HqOBkFV+MXCD2x/hmfQdTOgZ57wH8ctYJg=;
b=bvDc/irTnAMFZLgOYnewKhUCSi1pB5E67yTJBfLTqMjDZ7A/bqSj1VF0oOCzzPEBVZ
M+LK9soksrP9X78e+kJOytMbNIanq6RbYsutg9Yo9yZ7YeztG+xRYv8YVxbytJO6IeAF
Rolax+q2ajDXm5QvqGIIgbeQM9kHKm+0ZqDPP8DLbqZ1gpUj+uPZdz/cS6wzRmmClQXU
614ytXG/Gl5v3qAH6eUY0D25UsvcpfvoLMcOxQ7kymyv5RdIEuVhHjtJ1XBgqs4ociBk
Wz2Dj185Yein3chvCvJYRFkz1d28r1gMX3WZ5Sea96fBB1qSZxQOjmHzGAkQ0zZGszww
cpPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=iEoGu2hJ5HqOBkFV+MXCD2x/hmfQdTOgZ57wH8ctYJg=;
b=eNJwWvSZPz1vg3p0lHMpy9ttxsj3dBVj682m4CsErDl3Bc2H6XfEIsmxcuiM0sTc7v
IP0f34yx8xcihuZKOQjAXSTZVqz6qZVJ9P+BC8Hr4tR0sdTnMJdLEDaYVJo1lUSjvrJc
Q8CVoB9ISr+31jS3oUTgwIZ9567wwVz9SGAQq7CZPHUYL+c9PYSLw5Tc7VoWwdcxXT6Q
8dIkCZFp397fVL5fD4WQQMvM4s/TawunQrlZxTheFlKYNG6MsoUYXfzmve4n2l774I5/
Vi6HFRnULJRVc2p4i5WQrh2nO7LrAox11VZ4OyEktwZMKks/sWH7+d0YyW4HLr/qqE3h
JpxA==
X-Gm-Message-State: ABUngvehxWvfENfFyRb+DsajhlQYLwgzvah26A2QK7G0AQMTbySAX/yjGw7OaHJqQwMa7Q==
X-Received: by 10.99.55.66 with SMTP id g2mr28703074pgn.65.1477762073594;
Sat, 29 Oct 2016 10:27:53 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net.
[173.11.119.245])
by smtp.gmail.com with ESMTPSA id ak3sm26412641pad.19.2016.10.29.10.27.50
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 29 Oct 2016 10:27:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <9147701f-8395-7b2e-d370-111200ce2656@joelhalpern.com>
Date: Sat, 29 Oct 2016 10:27:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EEDC8239-3906-4879-9BF0-69B5A0C5C7F8@gmail.com>
References: <EC7A99B9A59C1B4695037EEB5036666B012C63D0@dfweml501-mbb>
<85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com>
<CAG-CQxr8gXiQi_D1PNN6HMk7NVc6P62kPsZicLdm1PgfL41prA@mail.gmail.com>
<9147701f-8395-7b2e-d370-111200ce2656@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/MiKxTbtXsNO6r8RwLn73WfcwxWc>
Cc: Padma Pillay-Esnault <padma.ietf@gmail.com>,
"ideas@ietf.org" <ideas@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [Ideas] [lisp] 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: Sat, 29 Oct 2016 17:27:55 -0000
> Also, it seems to me that if all you want to do is break a single MR, then rate limiting is irrelevant. In the absence of limits on who can query a specific MR, you can bombard it with more queries than it can handle and you will take it out of service. So a rate limit helps the system while harming the MR capability only slightly. This is why it is important to anycast most of the MRs that will be deployed. So the attack sources are naturally sending, in spread out fashion, to a very large cluster-set of MRs. Only with a concentration of sources in the relatively same topoglical area with lots of bandwidth can be successful at a many-to-1 attack. > Trying to infer whether an entity is allowed to undertake specific operations without authentication, using information such as the IP address, seems fraught with failure. Trying to classify all entities into types (onotology?) seems unlikely to produce correct results, as classes are not cleanly defined. And remember by doing signature verification or decryption, the problem gets worse for the MR. Because it has to use more resources when most of the packets are from unauthorized sources. And white-listing 1 billion users to provide a public service minus the 1,000,000 attackers is a white-list management nightmare/challenge. > As I said, I look forward to the technical presentation at the IETF meeting to see if they have any ideas that can help. Yes, there is work to be done. Putting authorization into the identity seems to be asking for trouble. Definitely. Dino
- [Ideas] FW: Technical plenary: Attacks against th… Padmadevi Pillay Esnault
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Joel M. Halpern
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Padma Pillay-Esnault
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Joel M. Halpern
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Dino Farinacci
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Dino Farinacci
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Padma Pillay-Esnault
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Templin, Fred L
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Dino Farinacci
- Re: [Ideas] [lisp] FW: Technical plenary: Attacks… Padmadevi Pillay Esnault