Re: [RPSEC] BGP Security Requirements v08

Curtis Villamizar <curtis@occnc.com> Wed, 18 July 2007 21:00 UTC

Return-path: <rpsec-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGdC-0007Rd-DM; Wed, 18 Jul 2007 17:00:22 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBGdA-0007PU-3T for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 17:00:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGd8-0007MK-24 for rpsec@ietf.org; Wed, 18 Jul 2007 17:00:19 -0400
Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBGd6-0005vN-Le for rpsec@ietf.org; Wed, 18 Jul 2007 17:00:18 -0400
Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IL172W031766; Wed, 18 Jul 2007 17:01:08 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com)
Message-Id: <200707182101.l6IL172W031766@harbor.brookfield.occnc.com>
To: sandy@tislabs.com (Sandy Murphy)
From: Curtis Villamizar <curtis@occnc.com>
Subject: Re: [RPSEC] BGP Security Requirements v08
In-reply-to: Your message of "Wed, 18 Jul 2007 15:45:58 EDT." <20070718194558.D2FBB3F43C@pecan.tislabs.com>
Date: Wed, 18 Jul 2007 17:01:07 -0400
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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 <20070718194558.D2FBB3F43C@pecan.tislabs.com>
Sandy Murphy writes:
>  
> >The major ISPs have important major customers and peer.  For example
> >they would not want their routing corrupted by a bad route to a major
> >content provider.  Therefore many major providers will only accept
> >these major customer and peer routes from a very limited set of ISPs.
>  
> I hear you about the Internet mostly just works.
>  
> But we seem to have p-l-e-n-t-y of publically discussed examples of
> cases where the trust structure did not not serve us well.
>  
> Furthermore, from what major ISP have said, what is said by others
> about major ISPs and from the analyses of public data of some incidents,
> it seems the case that some major ISPs (Spring comes to mind?) do not
> filter well enough to prevent some noticable traffic redirection.
> These have been accidents so far, but provide worked examples of
> how bad the problem can get.
>  
> Relying on the ISP trust and policies is mostly good enough for
> mostly just works.


This has been true for over a decade.

Back in the mid-1990s ANS days two very major incidents occurred.  One
was the intentional advertisement of very specific routes into PSI for
every DNS TLD servier.  This took out DNS for anyone who beleived
those routes.  It did not affect ANS due to IRR policy.  Another was
announding critical subnets of AOL.  Again that did not affect ANS
since they had specific filters to protect their direct customers and
any peer that wished to register in the IRR.

Even earlier, Sprint, UUNET, and PSI default routed to the NSFNET.
Someone got a 56K circuit to ANS at a university in the middle east
and announced the NSFNET address.  Sprint, UUNET and PSI were a mess
for 10 hours.  NSFNET customers were fine (then it was the PRDB).

There are ways to protect routing today.  Not everyone makes use of
them.  That's been the case for a very long time.  And they are far
from perfect.


> >Add some authentication and you may have further improviment in the
> >reliability of routing information.  Don't allow that to cross the
> >major ISPs and the authenticaion is of very little use for ISPs.
>  
> I agree with you here!  But I don't think anyone is talking about
> not allowing auth info to cross major ISPs.  We're mostly arguing
> how strong a requirement to make the ability to transit un-upgraded
> ISPs: MUST, SHOULD, or MAY.
>  
> --Sandy


Some providers may never upgrade.  Some mechanism to still pass routes
through them is needed, albiet placing less trust in those routes.

Curtis


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