Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

Eric Osterweil <eosterweil@verisign.com> Fri, 04 November 2011 15:57 UTC

Return-Path: <eosterweil@verisign.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 F232721F8B8F for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 08:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.486
X-Spam-Level:
X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
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 4dzBvFXfnUXr for <sidr@ietfa.amsl.com>; Fri, 4 Nov 2011 08:57:10 -0700 (PDT)
Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E121F8B49 for <sidr@ietf.org>; Fri, 4 Nov 2011 08:57:10 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Nov 2011 08:57:10 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pA4Fv3AR000371; Fri, 4 Nov 2011 11:57:03 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 11:57:02 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <p06240804cad81a9e4485@[193.0.26.186]>
Date: Fri, 04 Nov 2011 11:57:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com>
References: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com> <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <p06240808cad5c4d268eb@[193.0.26.186]> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <p06240804cad81a9e4485@[193.0.26.186]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 04 Nov 2011 15:57:02.0562 (UTC) FILETIME=[64899C20:01CC9B0A]
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
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, 04 Nov 2011 15:57:11 -0000

On Nov 3, 2011, at 11:59 AM, Stephen Kent wrote:

> At 9:32 PM -0400 11/2/11, Danny McPherson wrote:
>> On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote:
> 

<snip>

>> More specifically, if I have perform a cost/benefit analysis it's not at all clear to me
>> that tightening exposure windows to the frequency (hours/days) you're suggesting
>> is worth the investment and fundamental shift from the stateful BGP model we know
>> today, particularly given the drive-by and targeted nature we see in all other aspects
>> of security today (e.g., APT, phishing, etc..).
> 
> I presume that your statement "fundamental shift from the stateful BGP model..." refers to beaconing. Beaconing does create a new basis for propagating a route, but an AS could cause the same impact on the routing system by changing other route parameters at the same frequency, consistent with the BGP spec. I'd prefer a better solution, but I don't have one to offer at this time.

ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today?  Specifically, the comment above, "an AS could cause the same impact on the routing system by changing other route parameters at the same frequency" seems to miss the point I think I see in the objection: what if _every_ AS must do this all the time (not just a rogue, or select few).  How much extra overhead would ensue if (say) someone took the current set of all ASes and prefixes and simulated the extra update traffic needed in (say) a day?  Maybe if we saw some numbers that told us how many additional updates and how much additional bandwidth this approach would require in a routing system like today's we could understand another aspect of much of a shift we are talking about?

Eric