RE: [RPSEC] Re: draft-convery-bgpattack-00

Stephen Kent <kent@bbn.com> Fri, 08 November 2002 15:36 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23384 for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 10:36:34 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Fcab04077 for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 10:38:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Fcav04074 for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 10:38:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23346 for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 10:36:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8FcHv04051; Fri, 8 Nov 2002 10:38:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8FbGv03723 for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 10:37:16 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23198 for <rpsec@ietf.org>; Fri, 8 Nov 2002 10:34:43 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21394; Fri, 8 Nov 2002 10:37:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100306b9f1866d9d36@[128.89.88.34]>
In-Reply-To: <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
References: <20021106171433.J58530-100000@sequoia.muada.com> <20021106171433.J58530-100000@sequoia.muada.com> <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
Date: Fri, 08 Nov 2002 10:35:20 -0500
To: "Joel M. Halpern" <joel@stevecrocker.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>

Joel,

>What I see in S-BGP and this discussion is:
>
>1) An approach that attempts to comprehensively provide security for BGP

yes

>2) An approach that for deployment probably requires significant 
>enhancements in the actual routing hardware (storage, increased 
>memory, crypto hardware).

in the long run yes, but maybe not for initial, incremental 
deployment because, by definition, there are fewer entries with RAs 
and thus less space is required in RIBs and fewer sigs to generate or 
check, etc.

>It seems this overlooks several things:
>A) The indications are that operators are not interested in (or 
>possibly even capable of) deploying solutions with this complexity

agreed, but at least in the U.S. there is an increased focus on 
infrastructure security, and Richard Clark has hinted that if ISPs do 
not do a better job, the Government may "help"

>B) We could probably get a lot of coverage (but not as complete) 
>with a much simpler solution or set of solutions.

Do you have a specific example in mind? So far we have few, if any 
proposals that have been well analyzed re the security they provide, 
so I find it a bit hard to understand how you can confidently make 
this statement. Also, one needs to have a metric by which you can 
characterize the extent of "coverage" in order to compare two 
security proposals. What metric do you envision?

>C) Securing BGP this carefully when the rest of the infrastructure 
>is completely insecure seems almost counter-productive.

What "rest of the infrastructure" do you have in mind? Routing is 
separate from DNS, for example, in terms of what attacks can do, so 
it is justifiable to pursue securing these independently. Also, the 
design of S-BGP is such that it protects the set of ISPs who use it 
from false advertisements about the parts of the address space by the 
ISPs who do not use it. So, it offers incremental benefits even 
without full deployment.

>Note that currently many operators do not deploy source address 
>filtering, or even martian address filtering with their customers. 
>And that is only the tip of the iceberg of simple things that need 
>to be done.  It would seem that whatever energy it would take to 
>even begin serious development and deployment of S-BGP could be much 
>better spent getting some of the simple steps that are necessary 
>deployed.  Then we could examine again to determine what makes sense 
>to do next based on that experience.

There is a difference between approaches to security that rely on 
other ISPs to do the right thing, and approaches that let you know if 
other ISPs are doing the right thing. S-BGP falls into the latter 
category and thus is more resistant to benign failures and attacks 
against internal ISP route management components or procedures, vs. 
schemes that rely on ISPs doing local source address filtering, for 
example. Yes, there are other things ISPs could be doing to make life 
better, but these measures are not very resistant to many forms of 
attacks and they represent considerable management burdens for ISPs. 
So in part the question is whether one should devote effort to 
halfway measures, or devote more effort to more comprehensive 
measures.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec