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

Stephen Kent <kent@bbn.com> Mon, 11 November 2002 15:26 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 KAA22171 for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 10:26:36 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gABFSfa16651 for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 10:28:41 -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 gABFSfv16648 for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 10:28:41 -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 KAA22116 for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 10:26:05 -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 gABFSLv16580; Mon, 11 Nov 2002 10:28:21 -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 gABF9Pv15713 for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 10:09:25 -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 KAA21316 for <rpsec@ietf.org>; Mon, 11 Nov 2002 10:06:49 -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 KAA04231; Mon, 11 Nov 2002 10:09:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100302b9f577408a9b@[128.89.88.34]>
In-Reply-To: <20021109175850.Q62928-100000@sequoia.muada.com>
References: <20021109175850.Q62928-100000@sequoia.muada.com>
Date: Mon, 11 Nov 2002 10:06:30 -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 6:04 PM +0100 11/9/02, Iljitsch van Beijnum wrote:
>On Fri, 8 Nov 2002, Stephen Kent wrote:
>
>>  >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.
>
>You should be able to rely on the door man to keep people out who are
>recognizable as undesirable elements. After all, that's what you pay
>for.
>
>We all (directly or indirectly) pay the tier-1 networks so it is
>reasonable to ask them to do anti-spoofing filtering on their peering
>interfaces, for the exact reason you mention: expecting all ISPs to
>filter their customers is the short road to disappointment.

Amsterdam must be a more civilized place than most major U.S. cities :-)

Most apartment complexes here do not have doormen. The "undesirable 
elements" can and do gain entrance by "buzzing" apartments randomly 
in hopes someone will let them in, or by following in legitimate 
residents (tailgating), showing up dressed as a delivery person, etc. 
So, we have adopted a more defensive posture and assume the need to 
secure entrance to individual apartments as the responsibility of the 
residents.

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