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

Russ White <russw@riw.us> Fri, 09 September 2011 16:40 UTC

Return-Path: <russw@riw.us>
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 0A7CF21F8802 for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2011 09:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level:
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 lRORPUwTXww2 for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2011 09:40:53 -0700 (PDT)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 796EB21F86DE for <sidr@ietf.org>; Fri, 9 Sep 2011 09:40:53 -0700 (PDT)
Received: from cpe-065-190-157-197.nc.res.rr.com ([65.190.157.197] helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1R24AA-0004md-Px; Fri, 09 Sep 2011 12:42:46 -0400
Message-ID: <4E6A420C.1020203@riw.us>
Date: Fri, 09 Sep 2011 12:42:52 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@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> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <m2ipp4qxs5.wl%randy@psg.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <D4059E53-6EEC-4F66-9E1E-B96675182F22@rob.sh> <m2wrdhvjpe.wl%randy@psg.com> <4E6A2CD0.1010305@riw.us> <m2pqj9vgc8.wl%randy@psg.com> <4E6A3D30.9030605@riw.us> <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com>
In-Reply-To: <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
Cc: "sidr@ietf.org" <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: Fri, 09 Sep 2011 16:40:54 -0000

> By doing "converge first verify later", the router can be made cheaper.

I'm not certain I'd agree with this assessment... I'd guess you can make
convergence faster this way, but the memory and other costs on the
router are going to be the same. You could make it cheaper by moving
specific things off the router and onto auxiliary boxes, but the point
of inline authentication is _not_ to move anything onto boxes outside
the router (or even onto line cards within the router) --this is the
reason all overlay proposals were rejected up front.

> However, there is still the cost of the RPKI and the cost of running/maintaining it.
> My guess is that will bury the cost of the routers.

I would guess this, as well --and I would guess that the cost of the
extra memory and processing to perform what BGPsec is asking for will
never be buried. IMHO, there will always be a cost differential between
a device capable of what BGPsec requires, and a device that's not capable.

Security will always cost something, no matter how you slice it. The
more "perfect" you try to make it, the more it will cost. SIDR seems to
have started out with "let's engineer the most perfect security we can
imagine," end of the stick --something most engineers (including myself)
tend to do a lot.

Russ