Re: [sidr] Burstiness of BGP updates

Brian Dickson <> Wed, 16 November 2011 05:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72E601F0D1C for <>; Tue, 15 Nov 2011 21:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.483
X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d-xVak8BY1VR for <>; Tue, 15 Nov 2011 21:56:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 66EB01F0D1A for <>; Tue, 15 Nov 2011 21:56:25 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so147361bkb.31 for <>; Tue, 15 Nov 2011 21:56:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UZpRVjdhcPEy5WhqsVOFNuFefuOggU02/SxstTMmRkQ=; b=SbXWlyMzJ34yNJ73K336fzrlEGYEmu05qHRDF8X2V4irkcHvzED7SUA4iLeDS6hAhL 0ti/84AUaOd11YqQ9rTeiBqmcziHWxdsKQH6hIH3tAEKgHTgxLLDlIslvh+qFddmQUWC cdoZUL9NdXgnJFVjdZLd/u76FU5JEl4ewpwFs=
MIME-Version: 1.0
Received: by with SMTP id iq17mr19563703bkc.118.1321422984394; Tue, 15 Nov 2011 21:56:24 -0800 (PST)
Received: by with HTTP; Tue, 15 Nov 2011 21:56:24 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 16 Nov 2011 00:56:24 -0500
Message-ID: <>
From: Brian Dickson <>
To: Christopher Morrow <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [sidr] Burstiness of BGP updates
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Nov 2011 05:56:26 -0000

On Wed, Nov 16, 2011 at 12:35 AM, Christopher Morrow
<> wrote:
> On Wed, Nov 16, 2011 at 12:29 AM, Brian Dickson
>> Does this illustrate the importance of not only validating origins,
>> but also only using signed prefixes if you are participating in
>> BGPsec?
> sure, but if your customer forgets to pay a bill, calls you up and
> (post proper 'this is the customer' authentication) says: "Hey, srsly,
> I forgot, checks in the mail to ARIN, can you accept our route pls?"

I was using "only" in contrast to Jakob, who was suggesting having the same
prefix and as-path, both signed and unsigned, be used, and in fact the
unsigned used prior to validating the signatures.

Basically, if you have BGPsec enabled with a given peer, you might get
a combination of signed and unsigned from that peer - but for a given prefix,
you MUST only get one or the other. Invalid-sig != unsigned.

Accepting unsigned as a "fast" short-cut is insane, frankly.

Signed prefix processing actually needs to "block" until the signature
result is received.
On a per-prefix basis, of course.

This is why having your cache very close is important, as are any
possible implementation
optimizations or design considerations that improve signature

> you may be willing to do same, you may also be willing to do this in
> the case of internal services routes that you don't actually want
> externally visible.

Sure - and locally significant signatures/trust-anchors are very
important for just such an occasion.
(For any convenient value of "local", it should be noted. City, zip
code, province, continent, building, whatever.)

> re-announcement is 'harder' since it's not clear if NTT is supposed to
> be passing cogent aol's routes or not, is it?

Agreed - I can't be specific on exactly when, but expect me to present something
"real soon now" on a nuts-and-bolts level of how to do this. Maybe a
month, maybe two.