Re: [sidr] Burstiness of BGP updates

Russ White <russw@riw.us> Thu, 17 November 2011 04:32 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 491C811E80C2 for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 20:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 KVf60TGg7j0s for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 20:32:38 -0800 (PST)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id C659111E80B0 for <sidr@ietf.org>; Wed, 16 Nov 2011 20:32:38 -0800 (PST)
Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:53228 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1RQteM-0005Gi-WD; Wed, 16 Nov 2011 23:32:35 -0500
Message-ID: <4EC48E5E.4060203@riw.us>
Date: Wed, 16 Nov 2011 23:32:30 -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: robert@raszuk.net
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <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>
In-Reply-To: <4EC46A16.7010109@raszuk.net>
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 04:32:39 -0000

> 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.

Don't treat routing updates as packets. Routing protocols are
distributed near real time databases, not applications that send and
receive packets.

> 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 ;)

But you see, that's intent.

What we're trying to do is infer undefined intent (because we won't
admit it's intent), from a rather loose and messy signature on the
packet, combined with some timers that are set so far away from real
time as to be almost useless (because it's too hard to secure route
removal in a signed packet system).

:-)

Russ