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

Iljitsch van Beijnum <iljitsch@muada.com> Sat, 09 November 2002 17:12 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 MAA21714 for <rpsec-archive@odin.ietf.org>; Sat, 9 Nov 2002 12:12:38 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA9HEgt03971 for rpsec-archive@odin.ietf.org; Sat, 9 Nov 2002 12:14:42 -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 gA9HEgv03968 for <rpsec-web-archive@optimus.ietf.org>; Sat, 9 Nov 2002 12:14:42 -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 MAA21702 for <rpsec-web-archive@ietf.org>; Sat, 9 Nov 2002 12:12:07 -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 gA9HE8v03927; Sat, 9 Nov 2002 12:14:08 -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 gA9H4kv02747 for <rpsec@optimus.ietf.org>; Sat, 9 Nov 2002 12:04:46 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21566 for <rpsec@ietf.org>; Sat, 9 Nov 2002 12:02:11 -0500 (EST)
Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA9H43M68144; Sat, 9 Nov 2002 18:04:03 +0100 (CET) (envelope-from iljitsch@muada.com)
Date: Sat, 09 Nov 2002 18:04:03 +0100
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <p05100318b9f1f596bb3d@[128.89.88.34]>
Message-ID: <20021109175850.Q62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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>

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.

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