IETF Logo Mail Archive

Re: [sidr] Burstiness of BGP updates

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 16 November 2011 05:29 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AAA1F0CA7 for <sidr@ietfa.amsl.com>; Tue, 15 Nov 2011 21:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.48
X-Spam-Level:
X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6tP1knzyo3l for <sidr@ietfa.amsl.com>; Tue, 15 Nov 2011 21:29:31 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50E001F0C95 for <sidr@ietf.org>; Tue, 15 Nov 2011 21:29:31 -0800 (PST)
Received: by faap16 with SMTP id p16so1293022faa.31 for <sidr@ietf.org>; Tue, 15 Nov 2011 21:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CAQIYDacn96xyKOrTka1bc+xmFzMw+ADYvt8+peiIqE=; b=NpuO/YSMt/tP5JdSTnARcsNH8pHZf9da9KEOnXwTONr0eO7nvOAazTLDosH3MU3Rzo 3Q7WVm2maFCLOtWpNf1w0ylw8Nu09RfAE8o31cXqygfx3oQnEBR5FpWWq6e752Mklyya oMc1gRx7k2fi9X/Gn1qAMYF8mN4ZGl+fXuKcc=
MIME-Version: 1.0
Received: by 10.204.133.216 with SMTP id g24mr19639721bkt.82.1321421369345; Tue, 15 Nov 2011 21:29:29 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Tue, 15 Nov 2011 21:29:29 -0800 (PST)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <m2fwhqeq5i.wl%randy@psg.com> <CCE759E6-BEA6-433B-957A-6559C67BAD52@ericsson.com> <DCC302FAA9FE5F4BBA4DCAD4656937791452387941@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se>
Date: Wed, 16 Nov 2011 00:29:29 -0500
Message-ID: <CAH1iCiqFq7reoMrCBAUOk-PdmZDYoed+ii37xQbgX0nopNgDEw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 05:29:37 -0000

Understanding the "real" threats, and worked, real-world examples, is important.

I cannot believe anyone in this WG would be ignorant of things like this:

http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

Does this illustrate the importance of not only validating origins,
but also only using signed prefixes if you are participating in
BGPsec?

And the importance of minimizing or eliminating the ability of someone
currently off-axis, from becoming on-axis?

Preferably eliminating exploitation of lack of proper trust boundaries
WRT leakage (reannouncement permissions)?

(It is difficult to change from off-axis to on-axis without "leaking"
- the only time "leaking" isn't strictly required, is when already
on-axis.)

Jakob, please view the whole presentation above. It was more than 3
years ago... You should have heard of it by now.

Brian

v2.23.0 | Report a Bug | By Email