Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

[Robert Raszuk <[e-mail]>]

Hi Jakob,

> If we reprioritise BGPSec, we could make it work. Sugestion:
> during bringup, send routes without the BGPSec attribute.

I think there is a significant risk that this would cause unnecessary 
Internet wide churn.

I would propose and alternative approach. To send the routes with 
whatever attributes sender decides to send then with and do it only once.

Up-on reception if indeed inline CPU processing is an issue on given 
platform store the BGPSec related attributes without any processing then 
when CPU get's idle .. verify them.

Hoping that only small fraction of all routes could be considered 
invalid you may later withdraw them.

Of course this only attempts to fix inbound processing issue. You can 
not do the same when signing the routes outbound.

---

It keeps me puzzled  why sidr is so stuck on BGP inbound solution as 
opposed on number of proposals which deliver the same results using out 
of BGP bound control plane verification.

Cheers,
R.

> A router that implements BGPSec will *always* use more memory
> and more CPU that one that doesn't.
>
> CPU
> ---
> A router has a powerful CPU mainly to converge when it comes up
> and when a neighboring router comes up or goes down. During normal
> operation, it is largely unused.
>
> If we reprioritise BGPSec, we could make it work. Sugestion:
> during bringup, send routes without the BGPSec attribute.
> Once converged, during low CPU usage, send them again with
> the BGPSec attribute. Call this the first beacon.
> When receiving routes, delegate the BGPSec
> verification to a low priority task.
>
> Memory
> ------
> Because BGPSec operations do not affect convergence (we send
> without BGPSec attribute to achieve convergence), it can use
> slower, cheaper memory like a hard disk or flash disk.
>
> Downside
> --------
> There will be a few minutes after router bringup when unverified
> routes exist. Unverified routes can be given a lower preference.
>
> On Thursday, September 08, 2011 12:13 PM, George, Wesley<>  wrote:
>
>> -----Original Message-----
>> From: Sriram, Kotikalapudi [mailto:[e-mail]]
>> Sent: Wednesday, September 07, 2011 5:52 PM
>> To: George, Wesley; sidr wg list
>> Subject: RE: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
>>
>>>
>>> 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.
>>
>> Wes,
>>
>> Sorry for the belated response -- I was away in India on vacation :)
>> We had some discussion earlier on this list about
>> BGPSEC in conjunction with an RRG scalability solution (e.g., LISP).
>> (You might have seen these posts back in May, but just in case.)
>>
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02836.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02837.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg02847.html
>>
>> These posts relate only to the above noted comment from you
>> (but not directly to a different question you've raised
>> w.r.t. the concerns in 4984/6227).
>>
>> WEG] Sriram - thanks for the pointers, but all this really tells me
>>   is that I'm not the first one to point out a potential problem here.
>> The issue with making any assumption of a solution means that we're
>> essentially closing our eyes and hoping that someone else figures
>> this out before the world ends. My point is that we have to take a
>> more active role in bringing this back to the forefront of the
>> discussion in IETF because we stand to be impacted by delays in
>> finding a solution. If the timing is wrong, it ends up being gating
>> to deployment of BGPSec. If the timing is right, it probably requires
>> a lot of redesign work and additional investment, neither of which
>> are particularly optimal. I'd prefer that we document up-front that
>> there is a real concern here and that IETF needs to get moving on the
>> scale problem, in some way other than endless debate over options
>> within RRG. Even making a decision as to which direction to go (map
>> and encap vs L/I split) would move a long way to wards allowing other
>> things like BGPSec to optimize their designs accordingly.
>>
>> 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.
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
>