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

"Smith, Donald" <Donald.Smith@CenturyLink.com> Wed, 07 September 2011 20:18 UTC

Return-Path: <Donald.Smith@CenturyLink.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 2182821F8B4F for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2011 13:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9vjrTFUMAUGj for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2011 13:18:01 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB721F8B4E for <sidr@ietf.org>; Wed, 7 Sep 2011 13:18:01 -0700 (PDT)
Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p87KJjgr008004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 15:19:45 -0500 (CDT)
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 26A2B1E0060; Wed, 7 Sep 2011 14:19:40 -0600 (MDT)
Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0251A1E005B; Wed, 7 Sep 2011 14:19:39 -0600 (MDT)
Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p87KJdvY027501; Wed, 7 Sep 2011 15:19:39 -0500 (CDT)
Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p87KJdJJ027491 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 7 Sep 2011 15:19:39 -0500 (CDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 7 Sep 2011 14:19:37 -0600
From: "Smith, Donald" <Donald.Smith@CenturyLink.com>
To: 'Jakob Heitz' <jakob.heitz@ericsson.com>, 'Rob Shakir' <rjs@rob.sh>
Date: Wed, 07 Sep 2011 14:19:35 -0600
Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Thread-Index: AcxtX9RRciuxpYOPRTmM125yD16/7AAOrrjg
Message-ID: <B01905DA0C7CDC478F42870679DF0F1010B0E6F99A@qtdenexmbm24.AD.QINTRA.COM>
References: <A37CADA4-F16D-4C01-8D9C-D01001C4EFE4@tcb.net> <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <B92913D1-AB82-4D9F-B8A9-F8F4F99713D6@tcb.net> <p06240803ca685bff5443@[128.89.89.43]> <D6D12861-412E-4A65-B626-B627449981B8@tcb.net> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com>
In-Reply-To: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: 'sidr wg list' <sidr@ietf.org>
Subject: Re: [sidr] BGPSec scaling (was RE: 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, 07 Sep 2011 20:18:02 -0000

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.
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
Donald.Smith@CenturyLink.com


> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] 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" <rjs@rob.sh> 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
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> 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.