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

Stephen Kent <kent@bbn.com> Fri, 08 November 2002 23:25 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 SAA22091 for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 18:25:08 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8NRFQ08154 for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 18:27:15 -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 gA8NRFv08151 for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 18:27:15 -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 SAA22077 for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 18:24:37 -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 gA8NR1v08103; Fri, 8 Nov 2002 18:27:01 -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 gA8NQ8v08034 for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 18:26:08 -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 SAA22003 for <rpsec@ietf.org>; Fri, 8 Nov 2002 18:23:31 -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 SAA06092; Fri, 8 Nov 2002 18:26:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100318b9f1f596bb3d@[128.89.88.34]>
In-Reply-To: <20021108235307.C62928-100000@sequoia.muada.com>
References: <20021108235307.C62928-100000@sequoia.muada.com>
Date: Fri, 08 Nov 2002 18:21:51 -0500
To: Iljitsch van Beijnum <iljitsch@muada.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>

At 11:55 PM +0100 11/8/02, Iljitsch van Beijnum wrote:
>On Fri, 8 Nov 2002, Stephen Kent wrote:
>
>>  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.
>
>Source address filtering can be done in other places than just the
>customer edge. It is possible to do this on peering interfaces as well,
>if done with care. Unfortunately, it can't be done on transit
>interfaces. So the tier-1 ISPs (who get all their traffic from peering)
>should step up to the plate and start doing this to protect the rest of
>us.

I realize that one can filter other than at the edge, but it gets 
harder to do it the further one goes away from the edge, with transit 
interfaces being the agreed upon limiting case. Your last sentence 
conflicts with my observation about the undesirability of relying on 
others to protect you, as far as security goes.

Its somewhat analogous to living in an apartment building; you can 
lock your own door to keep out unwanted visitors, or you can rely on 
all your fellow apartment dwellers to not loose their keys and to not 
buzz in bad visitors.

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