Re: [sidr] beacons and bgpsec

"Montgomery, Douglas" <> Wed, 10 August 2011 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F384A21F89BA for <>; Wed, 10 Aug 2011 06:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.343
X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 74qE3+WFD649 for <>; Wed, 10 Aug 2011 06:35:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 332E821F899F for <>; Wed, 10 Aug 2011 06:35:07 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.0; Wed, 10 Aug 2011 09:35:03 -0400
Received: from ([fe80::d479:3188:aec0:cb66]) by ([]) with mapi; Wed, 10 Aug 2011 09:35:37 -0400
From: "Montgomery, Douglas" <>
To: George Michaelson <>, Danny McPherson <>
Date: Wed, 10 Aug 2011 09:35:35 -0400
Thread-Topic: [sidr] beacons and bgpsec
Thread-Index: AcxXYk2MitxN+/w7RbiKD7HXQ9Y0fw==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: sidr wg list <>
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 13:35:08 -0000

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