Re: [sidr] Burstiness of BGP updates

Robert Raszuk <robert@raszuk.net> Thu, 17 November 2011 01:57 UTC

Return-Path: <robert@raszuk.net>
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 BC3511F0C6D for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 17:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.157
X-Spam-Level:
X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, 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 C6JjiNfsQy2D for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 17:57:43 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 09CBA1F0C64 for <sidr@ietf.org>; Wed, 16 Nov 2011 17:57:43 -0800 (PST)
Received: (qmail 22831 invoked by uid 399); 17 Nov 2011 01:57:42 -0000
Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 01:57:42 -0000
X-Originating-IP: 130.129.19.9
Message-ID: <4EC46A16.7010109@raszuk.net>
Date: Thu, 17 Nov 2011 02:57:42 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Russ White <russw@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>
In-Reply-To: <4EC4684B.3030204@riw.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
Reply-To: robert@raszuk.net
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:57:43 -0000

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.

I am not sure if you actually need to know who should be in or not at 
any given time if the backend provides the correct rules based on the 
badge readings. Of course the assumption is that HR distributed the 
badges correctly in the first place ;)

R.


>>> 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
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>