Re: [sidr] beacons and bgpsec

[George Michaelson <[e-mail]>]

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.

But from the 1 week captures we did for the runout of IPv4, over a duration of a week we saw some frankly long lived, and widespread assumptions about routability of the spaces. Very probably not consciously in the wide, which goes to Randy's observations about the extent of default route propagating un-expectedly.

Also, "newly designed" seems a bit strong. This is BGP + signing chains isn't it? Its not re-entering from the top clean state..

I said it in part, because AS_SET has gone, precisely because its just too hard to do in BGPSEC, as I understand it. The justification is "its not useful" but its removed because of its impact on the emerging protocol modifications.

I am still struggling to understand how Path prepend is going to work. What I heard suggests its going to have to be administratively constrained to be sign-able. At the edge its more in the hands of the origin AS but beyond that where does the permission to play with the path come from?

(again, I may have misunderstood)

> 
>> Its very probably an unfair question. Thats why I called it the peanut gallery.
> 
> If it makes any difference, I think Randy both proposed beacons, and made a compelling case for removing them.

I guess I live in a margin where they are  research TOOL and you sometimes remove TOOLS. If they were added for another purpose, what I get from them (which is not much btw, but they get talked about in my hearing) is not the core motivation.

What they seem to do, is help confirm people are seeing BGP state. So they add something to the question "do I see the same kind(s) of BGP you see". Maybe thats not enough justifier.

-G