Re: [sidr] beacons and bgpsec

Sandra Murphy <Sandra.Murphy@sparta.com> Wed, 10 August 2011 19:46 UTC

Return-Path: <Sandra.Murphy@cobham.com>
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 A004721F8B7A for <sidr@ietfa.amsl.com>; Wed, 10 Aug 2011 12:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.227
X-Spam-Level:
X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 lFMNKywYAKkP for <sidr@ietfa.amsl.com>; Wed, 10 Aug 2011 12:46:41 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D456721F86D0 for <sidr@ietf.org>; Wed, 10 Aug 2011 12:46:40 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p7AJl7Lq031712; Wed, 10 Aug 2011 14:47:07 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p7AJkwDA027202; Wed, 10 Aug 2011 14:46:58 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.128]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 15:46:54 -0400
Date: Wed, 10 Aug 2011 15:46:54 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-Reply-To: <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com>
Message-ID: <Pine.WNT.4.64.1108101518080.8688@SMURPHY-LT.columbia.ads.sparta.com>
References: <CA67FEA7.5D697%dougm@nist.gov> <57F4C7B1-F1C7-4B95-8C6F-A15544C2715D@ericsson.com>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 10 Aug 2011 19:46:54.0440 (UTC) FILETIME=[419CAE80:01CC5796]
Cc: George Michaelson <ggm@pobox.com>, 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 19:46:41 -0000

Speaking as a regular ol' member

On Wed, 10 Aug 2011, Jakob Heitz wrote:

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

I'm not sure I understand your suggestion that the repository push 
changes, as the bgpsec protocol (where beaconing occurs) is not a 
repository based system.

The bgpsec protocol draft describes an in-band system, where protections 
for bgp routes get transmitted synchronously with the bgp routes.  Trying 
to couple transmission (whether push or pull) of protections of the bgp 
routes via a repository system would present difficulties in getting the 
protections to the recipients at the right time.

OTOH, the RPKI *is* a repository system, and that works for the types of 
data stored in the RPKI because it changes infrequently (or infrequently 
compared to the rate of change in BGP routes), changes can be anticipated 
and uploaded ahead of time, etc.  For the RPKI, one could imagine a 
service that would push changes out to RPKI customers, as you suggest.

--Sandy


> --
> Jakob Heitz.
>
>
> On Aug 10, 2011, at 6:35 AM, "Montgomery, Douglas" <dougm@nist.gov> wrote:
>
>>
>> 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
>>>
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>