Re: [RPSEC] FW: AS 8437 announced a quarter of the net for half ofan hour

Curtis Villamizar <curtis@occnc.com> Wed, 16 August 2006 12:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKyy-0002Iw-PO; Wed, 16 Aug 2006 08:58:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDKyx-0002Gt-MV for rpsec@ietf.org; Wed, 16 Aug 2006 08:58:51 -0400
Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDKyw-0007br-Bm for rpsec@ietf.org; Wed, 16 Aug 2006 08:58:51 -0400
Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k7GD53L5058305; Wed, 16 Aug 2006 09:05:03 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com)
Message-Id: <200608161305.k7GD53L5058305@workhorse.brookfield.occnc.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [RPSEC] FW: AS 8437 announced a quarter of the net for half ofan hour
In-reply-to: Your message of "Wed, 16 Aug 2006 11:22:53 +0200." <D533B682-2B41-4A39-83A8-36E6977868D0@muada.com>
Date: Wed, 16 Aug 2006 09:05:02 -0400
From: Curtis Villamizar <curtis@occnc.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: rpsec@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rpsec>
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>
Errors-To: rpsec-bounces@ietf.org

In message <D533B682-2B41-4A39-83A8-36E6977868D0@muada.com>
Iljitsch van Beijnum writes:
>  
> On 15-aug-2006, at 20:47, Curtis Villamizar wrote:
>  
> > I agree that the solution has to be simple to administer, better yet
> > trivial.
>  
> I disagree. This is a race to the bottom you can't win: business will  
> just hire less skilled people and you'll have the same problems as  
> before.

Much of the current problems were solved problems in the early 1990s.
To get to most of the Internet you had to go through the NSFNET.  To
get anything through the NSFNET you had to register routes.  The
NSFNET didn't have the types of problems we are now seeing.  The
commercial providers of the time did.

When the NSFNET was decommissioned the requirement to register routes
to get anywhere gradually diminished.  The IRR became ineffective
because certain providers didn't make use of the IRR and so they
refused to register routes.  They regarded use of the IRR as a
competitive advantage for their competitors and they were not going to
do something that helped their competitor.  The big offenders were
Sprintlink and UUNET.

Many providers still resist any form of route registration.  That is
why I made the comment that any administrative cost should be put on
those who benefit because they have the incentive to do the work.  For
example, that might mean building routing databases with both
registered and observed routes rather than just registered routes.

> The problem with idr administration isn't making it run 99% of the  
> time, but doing something during 99% of the time that minimizes the  
> trouble during the remaining 1% of the time.

Trust me.  I get it.

> > The way filters are set today is rather ad-hoc and coverage
> > is incomplete.
>  
> Right; the above is not to say that there isn't room for improvement  
> in current implementations.

There is lots of room for improvement.  In terms of routing security
most major US corporate users of the Internet (but not all, only 65%
of the fortune 500 were directly connected to the NSFNET when it was
decommissioned in 1995) were better off a decade ago than now.

I'm trying to be realistic given the historic level of cooperation
among Internet providers towards solving this.

Regards,

Curtis

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