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
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Joachim Jensen
- RE: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- [RPSEC] draft-convery-bgpattack-00 Sean Convery
- Re: [RPSEC] draft-convery-bgpattack-00 Damir Rajnovic
- [RPSEC] Re: draft-convery-bgpattack-00 David G. Boney
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] draft-convery-bgpattack-00 Christopher Lonvick
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Birger Toedtmann
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Randy Bush
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Michael Richardson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Birger Toedtmann
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- [RPSEC] prefix origin authentication (was Re: dra… Michael Richardson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Michael Richardson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Tony Tauber
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Danny McPherson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Michael Richardson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Sean Convery
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Sean Convery
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Larry J. Blunk
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Barry Raveendran Greene
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Michael Richardson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Michael Richardson
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Barry Raveendran Greene
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- RE: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Randy Bush
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Jeffrey Haas
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Charles Lynn
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Susan Hares
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- Re: [RPSEC] Re: draft-convery-bgpattack-00 sandy
- Aggregation in S-BGP was RE: [RPSEC] Re: draft-co… Charles Lynn
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Joel M. Halpern
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Randy Bush
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Iljitsch van Beijnum
- [RPSEC] Potential requirements Charles Lynn
- Re: [RPSEC] Potential requirements Iljitsch van Beijnum
- RE: [RPSEC] Re: draft-convery-bgpattack-00 Stephen Kent
- Re: [RPSEC] Potential requirements Tony Tauber
- Re: [RPSEC] Potential requirements Steve Suehring
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Sean Convery
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Sean Convery
- Re: [RPSEC] Re: draft-convery-bgpattack-00 Michael Richardson