Subject: [sidr] beacons and bgpsec

From: Danny McPherson <[email-masked]>
Date: Tue, 9 Aug 2011 21:06:34 -0400

The discussion of "Beacons" at the last meeting reminds of of EIGRP's 'triggered updates" v. RIP's "periodic updates" (i.e., cousin of beacons)...

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.  

With the lifetime of the average phishing site being only ~55 hours (for many reasons, I know), and an inclination to believe that infrastructure threats are likely to be even more temporal, and I'm inclined to recommend that beacons be removed altogether in their current incarnation of bgpsec, as there are plenty of other scale issues to focus on. 

Further study on alternatives, downstream purging issues, and clock skew for network elements might be useful in this context.  I saw something on the DANE list from PHB about vast skew across end systems, wondering if anyone has measured this?

Thoughts?

-danny

---

From: George Michaelson <[email-masked]>
Date: Wed, 10 Aug 2011 11:15:09 +1000

> Further study on alternatives, downstream purging issues, and clock skew for network elements might be useful in this context.  I saw something on the DANE list from PHB about vast skew across end…

Forgive a peanut gallery observation, but are we defining things as useless which we cannot understand in RPKI, because to admit that we don't understand them in RPKI means making RPKI more complex?

-G

---

From: Danny McPherson <[email-masked]>
Date: Tue, 9 Aug 2011 21:19:17 -0400

> Forgive a peanut gallery observation, but are we defining things as useless which we cannot understand in RPKI, because to admit that we don't understand them in RPKI means making RPKI more complex?

I'm not talking about RPKI, I'm talking about BGPSEC.  

I don't understand your question...

-danny

---

From: George Michaelson <[email-masked]>
Date: Wed, 10 Aug 2011 11:23:46 +1000

> I'm not talking about RPKI, I'm talking about BGPSEC.  

Ok. S/RPKI/BGPSEC/

> I don't understand your question...

You seemed to be saying "some people are saying beacons wont work"

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.

Its very probably an unfair question. Thats why I called it the peanut gallery.

-G

---

From: Danny McPherson <[email-masked]>
Date: Tue, 9 Aug 2011 21:34:16 -0400

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

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

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

-danny

---

From: George Michaelson <[email-masked]>
Date: Wed, 10 Aug 2011 11:42:01 +1000

> 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

> 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 s…

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)

> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Aug 2011 10:43:49 +0900

all in all, as my preso is being a bit mis-remembered, i think rereading
my preso may be helpful

    http://archive.psg.com/110728.sidr-replay.pdf

randy

---

From: Danny McPherson <[email-masked]>
Date: Tue, 9 Aug 2011 21:54:18 -0400

On Aug 9, 2011, at 9:42 PM, George Michaelson wrote:
> 
> Also, "newly designed" seems a bit strong. This is BGP + signing chains isn't it? Its not re-entering from the top clean state.

A BGPSEC-enabled routing system looks a lot different than BGP...

But let's say "new functionality" for periodic v. triggered updates, you ok with that?  :-)

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

That's orthogonal, perhaps you should have a look at Doug's slides and mailing list discussion related to pCNT, which has it's own set of issues.

> 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 abo…

Again, adding periodic updates to BGP is far from a trivial change from where we are today, and simply to "reduce the vulnerability window for replay attacks" I'm not convinced we can get to any frequency where such a fundamental architectural element is worth the investment.

-danny

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Aug 2011 18:56:02 -0700

>    http://archive.psg.com/110728.sidr-replay.pdf

+1. I don't see anything in my notes on Randy's presentation about "are pretty much useless and add considerable churn and complexity with little return from a practical attack surface perspective". The closest I see in my notes is "Doesn't gain anything against attack where an attacker could just do a withdraw".

--Paul Hoffman

---

From: Danny McPherson <[email-masked]>
Date: Tue, 9 Aug 2011 22:03:04 -0400

> +1. I don't see anything in my notes on Randy's presentation about "are pretty much useless and add considerable churn and complexity with little return from a practical attack surface perspective"…

My comment in the initial message:

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

I didn't quite Randy or his slides there, but I stand by my conclusions.

-danny

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 10 Aug 2011 09:35:35 -0400

On 8/9/11 9:42 PM, "George Michaelson" <[email-masked]> wrote:

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

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 10 Aug 2011 11:25:32 -0400

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" <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 12:04:06 -0400

Danny,

My recollection of Randy's presentation was not what you suggest.

I think he said that having each AS along a path associated a 
lifetime with the sig it applied to an update was a bad idea.  He 
also said that a beacon rate of about 24 hours, at the origin AS, 
seemed potentially useful, and would not result in excessive routing 
churn.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 12:06:21 -0400

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

AS_SET is hard to do, but the principle reason for deprecating it in 
IDR was because nobody appears to use it (properly).  Measurement 
indicate a very, very tiny number of updates made use of AS_SET, and 
further examination of those
indicated a likely misunderstanding of the "feature" by the ASes in question.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 10 Aug 2011 12:21:08 -0400 (Eastern Daylight Time)

>>> You seemed to be saying "some people are saying beacons wont work"

<snip>

> 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 t…

Speaking of my view of the discussion, AS_SETs presented difficulties in 
origin validation, without consideration of path validation.  The topic 
has come up many times in the wg.  In 2010, and in the Beijing meeting in 
particular, we (energetically) discussed various aspects of validating an 
origin for AS_SETs. The eventual decision was to abandon determining the 
origin AS for AS_SETs.

--Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 10 Aug 2011 13:44:00 -0400 (Eastern Daylight Time)

Speaking as a regular ol' member

<snip>

> the assumption that having ROAs in place will address most pop-up spam

I agree that the RPKI is an infrastructure whose contents change in human 
time scales, with the examples you mention.  But the bgpsec protocol 
operates in-line and at bgp time scales.  (Whether that is human scale or 
not, I'll leave to the operators.)

Certainly ROAs would make the pop-up spammers work harder, but I don't 
know that ROAs could be said to address them completely. Danny has pointed 
out many times that origin validation does not prevent a bad actor from 
attaching the valid origin to a bogus path.  That was a motivation for 
doing path validation.  I would think pop-up spammers might be determined 
enough to go to the effort of doing the attach-valid-to-bogus step.  They 
seem to be determined enough to take steps to thwart any other measure 
thrown in their path.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Aug 2011 15:12:01 -0400

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

I think your characterization is accurate, i.e., a TTL of 24 hours which
implies a more frequent beacon rate, to avoid a signed route from expiring.

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

Every AS that does not rely on default routes is potentially "interested" in
the freshness of every origin's route announcement. So I don't see how
a registration approach to trigger pushes will help.  Also, a motivation for
pushing the route freshness info via updates is because this reduces 
the need for frequent access to the repository system. The downside 
is that it creates
the need to "refresh" a route that might otherwise not need to be announced.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Wed, 10 Aug 2011 15:38:21 -0400

> My recollection of Randy's presentation was not what you suggest.

Again, I don't recall putting any words in Randy's mouth, if I did, it was unintentional.  However...

> I think he said that having each AS along a path associated a lifetime with the sig it applied to an update was a bad idea.  He also said that a beacon rate of about 24 hours, at the origin AS, seemed potentially useful, and would not result in excessive routing churn.

Periodic updates of the entire routing table *with much larger and more updates* seems undesirable at best to me, particularly to ""reduce the vulnerability window for replay attacks" to "days".

I suggest we stick with the current triggered updates operation or take this to IDR, it's a fundamental change from where we are today, and one's perspective of "excessive routing churn" seems to be relative.

-danny

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 10 Aug 2011 15:45:06 -0400

Beaconing 3,600,000 paths (from RIB size preso) every 8 hours
is 125 updates per second on average. More than a few percent extra load.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Danny McPherson
> Sent: Wednesday, August 10, 2011 12:38 PM
> To: sidr wg list
> Subject: Re: [sidr] beacons and bgpsec
> 
> 
> > I think he said that having each AS along a path associated 
> a lifetime with the sig it applied to an update was a bad 
> idea.  He also said that a beacon rate of about 24 hours, at 
> the origin AS, seemed potentially useful, and would not 
> result in excessive routing churn.
> 
> Periodic updates of the entire routing table *with much 
> larger and more updates* seems undesirable at best to me, 
> particularly to ""reduce the vulnerability window for replay 
> attacks" to "days".
> 
> I suggest we stick with the current triggered updates 
> operation or take this to IDR, it's a fundamental change from 
> where we are today, and one's perspective of "excessive 
> routing churn" seems to be relative.
> 
> -danny

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 10 Aug 2011 15:46:54 -0400 (Eastern Daylight Time)

> 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 al…

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

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 10 Aug 2011 15:55:17 -0400

A push model is just an idea.
It is highly likely to have lots of problems.
I haven't thought much about it.
Has it come up before and was it discredited?
Is it worth developing?

--
Jakob Heitz.

> From: Sandra Murphy [mailto:[email-masked]] 
> Sent: Wednesday, August 10, 2011 12:47 PM
> To: Jakob Heitz
> Cc: Montgomery, Douglas; sidr wg list; George Michaelson
> > 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.
> >
>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 11 Aug 2011 13:41:10 +1000

> At the 24hour + range, our estimates are that it adds 1-2% load of

Doug,

Thats a fascinating claim Doug, and I just don't accept it.

Are you seriously suggesting that you are basing this on a measurement of a eBGP location that has an update load such that adding some 370,000 additional updates would add 1 - 2 % to the existing load? i.e. an eBGP location that currently experiences some 18,500,000 - 37,000,00 updates per day. Really? Where is this location?

The data I have collected at AS2.0 on BGP update loads over a baseline of many years suggests that adding 370,000 announcements every day to a base eBGP average workload of some 100,000 announcements a day is not exactly a 2% increase. Nowhere close. So where did your "adds 1-2% load" estimates come from?

Geoff

---

From: "George, Wesley" <[email-masked]>
Date: Thu, 11 Aug 2011 17:40:33 -0400

Danny said,
"Periodic updates of the entire routing table *with much larger and more updates* seems undesirable at best to me, particularly to 'reduce the vulnerability window for replay attacks' to 'days'."
---------------------------------------------------------
I think that this is a small part of a much larger issue that has been bugging me since our meeting in Quebec City.
After looking at Sriram's estimates around the necessary amount of memory, etc for the different algorithms, I'm bothered by what is being asked of the routing system in support of BGPSec.

For ~5 years, IETF via 4984, & 6227 has said that simply relying on Moore's law to cover the impacts of the growth of the routing table is not sustainable. Yet here we are doing exactly that, while also doing something that will tilt the curve of the memory footprint, processing requirements, etc for the RIB significantly in the wrong direction. When scale comes up, mostly I've heard "well, this isn't going to be deployable for 5 years because you have to ask YFV to build hardware that can support it, but by then it'll be fine, mumble mumble cheap RAM mumble crypto acceleration..."
I guess you could say that I'm having a bit of a philosophical crisis over the taste of the Kool-aid here in terms of the benefits vs the potential costs.

Don't get me wrong, I very much support SIDR's work and goals, but I think we shouldn't downplay the overall scaling considerations. If it's no longer a concern, or won't be in 5 years, we need to articulate (in a broader forum) the reasons why the concerns and assumptions in 4984/6227 are no longer valid or not applicable to this case.

Assuming that the situation hasn't fundamentally changed and those concerns are still valid, the supposed 5-year event horizon for BGPSec adoption makes it somewhat more likely that between now and serious deployment, we will be seriously considering some design changes (whether outputs from RRG or something new) to improve the scalability of the global routing system, and I fear that we will end up with a lovely protocol suite from this WG that would end up in need of radical changes because we've since fundamentally altered the function of the routing system to make it scale better.

As far as where this leaves BGPSec, I don't know. Perhaps a solution comes in the form of some of us starting to champion the necessary work to move one or more of the better ideas from RRG into implementation so that the underlying scaling problem is being addressed in parallel. It should be quite possible to incorporate improvements to route security into whatever must already be done to improve scale, and even if not, these are two things that both share a barrier to deployment, especially incrementally, and would certainly benefit from being designed  and deployed in concert instead of in separate silos.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.