Re: [sidr] Burstiness of BGP updates

Eric Osterweil <eosterweil@verisign.com> Thu, 17 November 2011 03:07 UTC

Return-Path: <eosterweil@verisign.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 2BEE911E80DB for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 19:07:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level:
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 cpZlO4KQKvfK for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 19:07:53 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3133211E80CA for <sidr@ietf.org>; Wed, 16 Nov 2011 19:07:53 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKTsR6aCtnnD9tBY1168yBbYc1hXYpgIJi@postini.com; Wed, 16 Nov 2011 19:07:53 PST
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAH37JGM023984; Wed, 16 Nov 2011 22:07:20 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 22:07:18 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <m2ty634ie7.wl%randy@psg.com>
Date: Thu, 17 Nov 2011 11:07:08 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com>
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> <m2ty634ie7.wl%randy @psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 17 Nov 2011 03:07:19.0325 (UTC) FILETIME=[048DA4D0:01CCA4D6]
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 03:07:54 -0000

On Nov 17, 2011, at 10:01 AM, Randy Bush wrote:

> hi russ,
> 
>>>> Security compares what the state currently looks like to what the state
>>>> should look like.
>>> the problem is how does one know what the state of the system 'should'
>>> look like?
>> 
>> My understanding has always been that the point of any security system
>> is provide a secure and verifiable indication of what the system should
>> look like in order to compare current events against that standard.
> 
> you have been saying that for years.  and i understand your point.  what
> i have never understood is *how* you can tell how things 'should' be.
> 
> so the current sidr proposals are for what we *know how to do.*  they
> are not perfect, but they are a radical improvement on the current
> state.
> 
> i am very open to clue on how to rigorously define how things 'should'
> be, especially if it is rigorously testable given real world
> constraints.

Maybe this discussion could be viewed as a good motivation for revisiting the requirements draft.  It seems to me that these arguments (on both sides) could be viewed as the early stages of requirements analysis (RA).  If we can all get on the same page (or maybe into the same chapter) about what we want to protect, then we can talk about how to do it.  In the event we discover that we've carved out an unattainable requirement, we follow the exception back to RA and revisit the requirements.

Software engineering... :)

Eric