Re: [sidr] beacons and bgpsec

Jakob Heitz <> Wed, 10 August 2011 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC40321F84FE for <>; Wed, 10 Aug 2011 08:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.986
X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 30WrfZFA8nI4 for <>; Wed, 10 Aug 2011 08:24:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0799C21F84F4 for <>; Wed, 10 Aug 2011 08:24:42 -0700 (PDT)
Received: from ([]) by (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p7AFP8Qp001814; Wed, 10 Aug 2011 10:25:09 -0500
Received: from ([]) by ([]) with mapi; Wed, 10 Aug 2011 11:25:08 -0400
From: Jakob Heitz <>
To: "Montgomery, Douglas" <>
Date: Wed, 10 Aug 2011 11:25:32 -0400
Thread-Topic: [sidr] beacons and bgpsec
Thread-Index: AcxXca/4vxiDP9EMR6yBC/tlIwomgQ==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sidr wg list <>, George Michaelson <>
Subject: Re: [sidr] beacons and bgpsec
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, 10 Aug 2011 15:24:44 -0000

Sorry, where did the 2% load come from?
Does that mean that every prefix in the Internet is already being advertised 50 times every day?
Then, one more advertisement per day would make it 2% extra load.

Also, note that a beacon every day means a timeout of 3 days. Previous suggestions were a timeout of ~24 hours and a beacon of ~8 hours.

An alternative to beaconing is a push model instead of pull. That is, every router registers it's interest with the repository instead of querying it periodically. Then the repository would tell all registered parties when a change occurred rather than waiting for them to ask.

Jakob Heitz.

On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" <> wrote:

> On 8/9/11 9:42 PM, "George Michaelson" <> wrote:
>> On 10/08/2011, at 11:34 AM, Danny McPherson wrote:
>>> On Aug 9, 2011, at 9:23 PM, George Michaelson wrote:
>>>> You seemed to be saying "some people are saying beacons wont work"
>>> No, that's precisely why I referenced Randy's presentation, if you
>>> didn't see it you should have a look at the proceedings...
>> Will look
>>>> when you said: "I think Randy successfully convinced me during his
>>>> talk at the Quebec City WG session that "beacons" at a frequency of 24
>>>> hours (or anything in the "hours" range) are pretty much useless and
>>>> add considerable churn and complexity with little return from a
>>>> practical attack surface perspective.  "
>>>> So, I am asking, are we removing support for beacons in BGPSEC because
>>>> we don't understand their impact on BGPSEC and they add complexity
>>>> which makes BGPSEC harder to push uphill.
>>> I was contemplating the ROI for a newly designed protocol (bgpsec) and
>>> why they were put there in the first place (replay attacks [and more
>>> frequent wedgie oscillation :)]) and considering attack surface and
>>> practical implications, realizing that from an engineering tradeoff
>>> perspective they're quite likely not worth the effort.  Hence my broken
>>> attempt at a corollary with phishing site lifetime and RIPv1 scaling
>>> properties, because I don't have quantitative empirical data handy of
>>> routing hijack duration, nor could I possibly predict what it might
>>> entail in a bgpsec-enabled world, but I do suspect 24 hours is, umm...
>>> quite a while.
>> Popup announcements for spamming might well lie under 24h lifetime. I
>> think some people have notes on that. You can inject a humongous amount
>> of store-and-forward from far far less than 24h of routing.
> I think it important to remember that BGPSEC and Origin Validation are
> basically preventative, not reactionary/response mechanisms.   That is
> infrastructure that is manipulated in human time scales (e.g., ROAs,
> AS/router Certs) that prevent future false announcements.   I think it is
> the assumption that having ROAs in place will address most pop-up spam
> false announcements.
> The issue of expire time and beacons - and reducing the vulnerability
> window of "stale" BGPSEC signed announcements - is a bit more of a
> reactionary measure.   The idea of expire time exists to address an BGPSEC
> signed update that *was a valid signed path* at one time but is no longer.
>  Given the assumption that the RPKI is a fairly stable and slowly
> reacting infrastructure (and one that requires administrative actions to
> change) it was seemed better to just bound the useful lifetime of a
> BGPSSEC signed update, than to propose to churn the RPKI to invalidate
> previously valid paths.
> At the 24hour + range, our estimates are that it adds 1-2% load of
> announcements.
> Dougm
> _______________________________________________
> sidr mailing list