Re: [sidr] Burstiness of BGP updates

Stephen Kent <kent@bbn.com> Thu, 17 November 2011 03:26 UTC

Return-Path: <kent@bbn.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 1089F1F0CC5 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 19:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.537
X-Spam-Level:
X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 TYSjvu6Tr8n5 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 19:26:27 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 86C491F0CA5 for <sidr@ietf.org>; Wed, 16 Nov 2011 19:26:27 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:53555 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RQscL-000Nxa-HX; Wed, 16 Nov 2011 22:26:26 -0500
Mime-Version: 1.0
Message-Id: <p0624080dcaea2dd3301a@[172.20.1.65]>
In-Reply-To: <4EC4684B.3030204@riw.us>
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>
Date: Wed, 16 Nov 2011 22:25:31 -0500
To: Russ White <russw@riw.us>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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:26:28 -0000

At 8:50 PM -0500 11/16/11, Russ White wrote:
>  >> 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.

The usual characterization of a secruity system is a set of mechanisms that
are intended to enforce a secruity policy. Only if the policy 
articulates what the system "should look like" would your definition 
be congruent.

Most security policies focus on aspects of system operation that are 
perceived as "secruity critical."  The WG charter articulates a 
security policy, focusing on origin validation and path authenticity. 
These aspects of routing security are visible and this avoid the more 
problematic question of what the system "should look like."

Steve