Re: [sidr] beacons and bgpsec

"Montgomery, Douglas" <dougm@nist.gov> Wed, 10 August 2011 13:35 UTC

Return-Path: <dougm@nist.gov>
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 F384A21F89BA for <sidr@ietfa.amsl.com>; Wed, 10 Aug 2011 06:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.343
X-Spam-Level:
X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 74qE3+WFD649 for <sidr@ietfa.amsl.com>; Wed, 10 Aug 2011 06:35:07 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 332E821F899F for <sidr@ietf.org>; Wed, 10 Aug 2011 06:35:07 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Wed, 10 Aug 2011 09:35:03 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 10 Aug 2011 09:35:37 -0400
From: "Montgomery, Douglas" <dougm@nist.gov>
To: George Michaelson <ggm@pobox.com>, Danny McPherson <danny@tcb.net>
Date: Wed, 10 Aug 2011 09:35:35 -0400
Thread-Topic: [sidr] beacons and bgpsec
Thread-Index: AcxXYk2MitxN+/w7RbiKD7HXQ9Y0fw==
Message-ID: <CA67FEA7.5D697%dougm@nist.gov>
In-Reply-To: <4DA5E29E-7B05-4986-B993-3EDF2BDB847D@pobox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] beacons and bgpsec
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: Wed, 10 Aug 2011 13:35:08 -0000

On 8/9/11 9:42 PM, "George Michaelson" <ggm@pobox.com> 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
>