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

Iljitsch van Beijnum <iljitsch@muada.com> Fri, 08 November 2002 22:52 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 RAA20828 for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 17:52:49 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA8Msuu05973 for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 17:54:56 -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 gA8Msuv05970 for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 17:54:56 -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 RAA20777 for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 17:52:18 -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 gA8MsNv05950; Fri, 8 Nov 2002 17:54:23 -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 gA8Mr1v05901 for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 17:53:01 -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 RAA20724 for <rpsec@ietf.org>; Fri, 8 Nov 2002 17:50:24 -0500 (EST)
Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA8MqN563832; Fri, 8 Nov 2002 23:52:23 +0100 (CET) (envelope-from iljitsch@muada.com)
Date: Fri, 08 Nov 2002 23:52:23 +0100
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>
cc: rpsec@ietf.org
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
Message-ID: <20021108233801.C62928-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 Thu, 7 Nov 2002, Joel M. Halpern wrote:

> 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

Good point. Also, this is very much a double edged sword: on the one
hand, the expensive crypto checks validate that what's in the routing
tables is good, but on the other hand they'll keep out stuff, and
certainly not all of what they'll keep out will be bad. If I look at the
way routing registry entries are maintained today, I expect the first
few networks that implement this will suffer from noticably degraded
connectivity to the rest of the world.

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

Agree. I think soBGP is much better than S-BGP in this regard, but both
of them are stuck on a track that I think is wrong for this: the source
provides information to the router, and the router validates this
information using cryptographic means. This is a good approach if the
information the source will be providing can't be checked by other
means. However, that is not the case here: it is possible to collect the
information about what the source may be announcing beforehand, and then
simply check the actual announcement against this information. This way
the routers don't need to do any crypto.

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

> Note that currently many operators do not deploy source address filtering,

Which is indeed a big problem as it makes very hard to trace DoS attacks
possible. These happen every day, and many ISPs don't do very little to
stop it. Routing attacks are rare enough that I've never heard anyone
say they encountered one. I don't doubt Randy's remark that there have
been some, but the fact that the victims don't want to talk about it
makes me assume the attacks could probably have stopped using today's
technology.

However, just because there is problem A doesn't mean you shouldn't do
anything about problem B. It's not like work on routing security will
take away time from installing anti-spoofing filters.

> or even martian address filtering with their customers.

Martian filters aren't a good idea as they remove some symptoms but not
the cause. If someone doesn't filter, I like seeing those packets from
192.168.0.0/16 to inform me of this fact.

Iljitsch

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