Re: [sidr] Burstiness of BGP updates

Russ White <russw@riw.us> Thu, 17 November 2011 01:50 UTC

Return-Path: <russw@riw.us>
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 1ABA21F0C57 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 17:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599]
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 Fz9YtXmBtInS for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 17:50:07 -0800 (PST)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 868741F0C56 for <sidr@ietf.org>; Wed, 16 Nov 2011 17:50:07 -0800 (PST)
Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:50848 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RQr77-0002aT-Ng; Wed, 16 Nov 2011 20:50:05 -0500
Message-ID: <4EC4684B.3030204@riw.us>
Date: Wed, 16 Nov 2011 20:50:03 -0500
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Randy Bush <randy@psg.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>
In-Reply-To: <m2wraz4j68.wl%randy@psg.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
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 01:50:08 -0000

>> 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. For
instance, could you secure an airport without some idea of who should be
where and when they should be there? Or your house?

How do you detect "attack traffic," in your network? By seeing things
that shouldn't be there. If you don't know what it's supposed to look
like, how can you tell what's not supposed to be there? In the same way,
how can you "secure" the routing system without knowing what routes
should be where --in other words, without knowing what everyone intended
to advertise? Saying "it's okay if we know what it was supposed to look
like a week ago," doesn't, IMHO, solve the problem at hand.

:-)

Russ