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

["t.petch" <[e-mail]>]

----- Original Message -----
From: "Smith, Donald" <[e-mail]>
To: "'Jakob Heitz'" <[e-mail]>; "'Rob Shakir'" <[e-mail]>
Cc: "'sidr wg list'" <[e-mail]>
Sent: Wednesday, September 07, 2011 10:19 PM

I would guess you would get a very low take rate on "secure bgp" even if you
gave it away (no premium).
It would be interesting to see how many customers implemented MD5 for bgp
peering sessions when it became freely available.

<tp>
None, when first I became involved in BGP but then, 18 months later, it was
widely deployed as a result of a 'disaster' of the kind I alluded to in my
previous post.  I never
did hear directly what happened, and it may be an European affair that did not
impact America.  I think that I learnt most about it via the RIPE Routing group
but it was several years ago, and my memory of it is now quite vague.  But
it was a good example of nothing being done with the available technology until
the disaster happened, and then it was all hands to the pumps.

Tom Petch

</tp>








It wasn't very widely deployed the last time I heard.
It got a ton of push back on the NANOG list when I recommended it.


Ignorance is Bliss. "Bliss (Basic Language for Implementation of System
Software) was a
systems programming language originally for the PDP-10 and DECsystem-20 written
at CMU." Kevin Oberman RTD
[e-mail]


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Jakob Heitz
> Sent: Wednesday, September 07, 2011 7:13 AM
> To: Rob Shakir
> Cc: sidr wg list
> Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
>
> While a router that performs BGPSEC may not be more expensive in 5
> years than one that does not today, that is not relevant. A router that
> performs BGPSEC in 5 years will most definitely cost more to produce as
> well as cost more to run than a router that does not perform BGPSEC in
> 5 years.
>
> So, a question for you Rob. Will your customers pay the premium for BGP
> security?
>
> --
> Jakob Heitz.
>
>
> On Sep 7, 2011, at 5:05 AM, "Rob Shakir" <[e-mail]> wrote:
>
> > On 11 Aug 2011, at 22:40, George, Wesley wrote:
> >
> >> 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.
> >>
> >
> > Hi All,
> >
> > Wes' point here is really important I think, and it's a bit of a
> shame it hasn't got more focus. I stood up and mentioned scaling in
> Prague, then found myself making a very similar point again in Québec.
> As with Wes, I would prefer that this is not interpreted as a criticism
> of the goals of bgpsec, but rather is an operational perspective on the
> assumptions that are made for deployment of the protocols being
> developed in sidr.
> >
> > The root assumption that we seem to be taking as read throughout such
> discussions is that at the point where routing infrastructure is
> expected to support the computational load that is demanded of it by
> bgpsec, there will have been sufficient growth in both the
> computational and memory resources that are available to these systems.
> Whilst I appreciate that cryptographic validation of the validity of a
> route can be performed on the edge system(s), I think there are two
> very key concerns here.
> >
> > - Historically, do we see Internet routing systems matching the rate
> of general computational resource availability? My view on this is that
> we do not - there are plenty of edge systems out there that are
> relatively modern (and capable of routing tens of gigabits of traffic)
> that do not have a control-plane that is as powerful as some of the
> software devices that existed prior to it - as such, this means either
> this was a lower priority to deliver (which may well be true), or that
> it was not practical to do so. With increasing demands on control-plane
> resources of IP systems (be they Internet edge or otherwise) - there is
> surely some query as to whether having a large amount of memory or
> crypto offload hardware will be a priority over other features. The
> question Wes raised as to whether we, as a working-group, are happy
> with the assumption that this is the case, is very valid. It would seem
> to me that we are being somewhat prescriptive with prioritising what
> hardware vendors' solutions should look like, and what operator's
> scaling approaches will look like - without necessarily explicitly
> discussing why this is reasonable to do so.
> >
> > - Are the assumptions that we are making regarding how those
> autonomous systems delivering an "Internet" product set are architected
> valid? There is some assumption (AIUI, please feel free to correct me)
> that we are looking at networks where we have explicit edge devices
> which can scale to meet the validation workload that we're putting on
> it. This would seem (again, to me) to be based around assumption that
> there are a relatively high number of less-dense edge devices. I would
> be interested whether it's the feeling of the WG that my reading of
> what we're assuming is correct - and if so, whether the WG feels that
> we can be prescriptive like this for how one should architect an
> Internet network.
> >
> > I'm again very supportive of what problems bgpsec is trying to solve
> - and do not want to put a dampener on any of the excellent efforts
> that have gone into it - but think that we cannot wholly abstract
> ourselves away from the actual deployability of the solutions that are
> being developed. After all, we will not solve the problems that the WG
> is chartered to solve if the fruits of the labours herein are not
> actually deployed.
> >
> > I am not sure of exactly how we progress discussing the scalability
> of the solution - but with Sriram's analysis, is it possible to discuss
> within this forum, and perhaps others concerned with the general
> scaling of IP routing elements, why the scaling
> considerations/assumptions of bgpsec are valid, and where a departure
> is made from the longer term view of scalability that is presented in
> existing IETF documents.
> >
> > Thanks for reading this - and your consideration!
> > r.
> >
> >
> >
> >
> >
> > _______________________________________________
> > sidr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr

This communication is the property of CenturyLink and may contain confidential
or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr