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

Jakob Heitz <jakob.heitz@ericsson.com> Wed, 07 September 2011 13:11 UTC

Return-Path: <jakob.heitz@ericsson.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 B93CE21F8C58 for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2011 06:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.289
X-Spam-Level:
X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 pffKwWZI+UR3 for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2011 06:10:59 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9172921F8C55 for <sidr@ietf.org>; Wed, 7 Sep 2011 06:10:59 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p87DCjrv020163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Sep 2011 08:12:46 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 7 Sep 2011 09:12:44 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Rob Shakir <rjs@rob.sh>
Date: Wed, 07 Sep 2011 09:12:41 -0400
Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Thread-Index: AcxtX9RRciuxpYOPRTmM125yD16/7A==
Message-ID: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.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>
In-Reply-To: <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 13:11:00 -0000

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