Re: [sidr] Burstiness of BGP updates

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 17 November 2011 02:04 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 0516821F8663 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 18:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.491
X-Spam-Level:
X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 XTiV8VgWlYzH for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 18:04:48 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0745921F86FF for <sidr@ietf.org>; Wed, 16 Nov 2011 18:04:47 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so1590733bkb.31 for <sidr@ietf.org>; Wed, 16 Nov 2011 18:04:47 -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=ZjCoCaQCi9XZe/+RoACSzDUPZUGbT0FoVy5xS/1EKAE=; b=Dcyo0Z9pUIRalUmHQIGmqiSFa2rFvwmQLIN7FLUI1EZ+SmWWz3+IQTM9KvPShtG/u4 GUC6L7ygWNH4SW6HANLvDehVM6ExyLALnLZIjLCwbzfz6nZZx0dZYVhAv8gQeXV8X6tG AiOnUQdK7U3L20lldyX801ksgw/Ncu7zQ5a28=
MIME-Version: 1.0
Received: by 10.205.119.207 with SMTP id fv15mr31518925bkc.100.1321495487108; Wed, 16 Nov 2011 18:04:47 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Wed, 16 Nov 2011 18:04:46 -0800 (PST)
In-Reply-To: <4EC46A16.7010109@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <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> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <E2D346C7800D704DB41ED19D90434DA6320C15DF93@ESESSCMS0358.eemea.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <CAL9jLabyymUZJRk44Z00UeQsxinN5D-05-7_htmRanYwi7ysvQ@mail.gmail.com> <4EC462E9.7090103@riw.us> <m2wraz4j68.wl%randy@psg.com> <4EC4684B.3030204@riw.us> <4EC46A16.7010109@raszuk.net>
Date: Wed, 16 Nov 2011 21:04:46 -0500
Message-ID: <CAH1iCirfziYJ+nCUH3VzeuO8neSMq36AxJLpjcfEY8MyHiuF3g@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset="ISO-8859-1"
Cc: sidr wg list <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: Thu, 17 Nov 2011 02:04:49 -0000

On Wed, Nov 16, 2011 at 8:57 PM, Robert Raszuk <robert@raszuk.net> wrote:
> Hi Russ,
>
> I think the current intention is to secure the network on the basis of
> giving each prefix a badge and just check it at entrance door readers to
> each AS.
>
> If it is allowed in it enters if it is determined by the security back-end
> to be evil it is denied.

That analogy works for packets. It doesn't work for routes.

Routing sucks. Routes attract traffic.

I would instead say, it's like a work order to install a window or door.

That someone with a work order got as far as they did, is either proof
that they are supposed to be there, or a security vulnerability, or
maybe both.

Signed work orders suggest that a window or door was requisitioned. It
doesn't necessarily confirm which wall it should go in - the one to
the next suite, the one to the vault, or the one to the street?

But, chasing analogies to their breaking point isn't necessarily constructive.

Yes, knowing what is intended is necessary if we want to provide
security, as opposed to merely vague assurance.

Given the amount of work expended thus far, taking the extra step
(which may not be large) is both advisable, and something IMNSHO
should be considered in-scope....

Brian