Re: [RPSEC] BGP Security Requirements v08

Curtis Villamizar <curtis@occnc.com> Wed, 18 July 2007 15:44 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 1IBBhO-0007nV-M9; Wed, 18 Jul 2007 11:44:22 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBBhN-0007nM-7w for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 11:44:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBhM-0007nE-Tv for rpsec@ietf.org; Wed, 18 Jul 2007 11:44:20 -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 1IBBhL-0004ks-Hs for rpsec@ietf.org; Wed, 18 Jul 2007 11:44:20 -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 l6IFiMLG025817; Wed, 18 Jul 2007 11:44:22 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com)
Message-Id: <200707181544.l6IFiMLG025817@harbor.brookfield.occnc.com>
To: Stephen Kent <kent@bbn.com>
From: Curtis Villamizar <curtis@occnc.com>
Subject: Re: [RPSEC] BGP Security Requirements v08
In-reply-to: Your message of "Tue, 17 Jul 2007 11:09:48 EDT." <p0624051cc2c286f29523@[128.89.89.71]>
Date: Wed, 18 Jul 2007 11:44:22 -0400
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: rpsec@ietf.org, Russ White <riw@cisco.com>
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 <p0624051cc2c286f29523@[128.89.89.71]>
Stephen Kent writes:
>  
> As a "security guy" I would not agree with your opening statement. 
> We usually worry that mixing unverified info with verified info, in 
> any context, is a recipe for trouble, as it encourages folks to 
> accept the mixed info and treat it as verified.  You give an example 
> of ISPs wanting to " ... distinguish their services as having 
> somewhat more reliable routing due to the use of authentication ..." 
> That is precisely the sort of claim most security folks would worry 
> about :-).


As a security guy, you could think of it as a different kind of (not
very good) security across a known reliable ISP or a small set of
known reliable ISPs.  A provider may peer with one or more ISPs who
they know have excellent security practices and whose routing is known
to be fairly robust.  An set of AS with those AS numbers only plus
a set of authenticated AS would be more likely to deliver packets than
an AS Path through unauthenticated AS of unknown reliability.

What we are talking about here is prevention of DOS, not protection of
secrets.  Choosing a path that is extremely likely to be reliable but
not guarenteed to be reliable in practice is clearly an improvement
over choosing any available path.  It is the sole basis of most policy
routing decisions today.

My view on this is we can strive for perfection and get nothing at all
or try to improve the current situation and get the work implemented
with limited deployment in ISPs and due to being implemented the
security community has it and can use it as they please.  My concern
is that with no interest from ISPs it will be hard to get vendors to
implement and it will never get PS status for lack of implementation.

It would be nice to hear from ISPs since I'm not at one.  If memory
serves me, we had two opinions voiced.  One was that some sort of
transitive property across non-authenticated AS was a necessary
feature.  The other was that the storage overhead needed to be
reasonable or ISPs who did not use the authentication would simply
drop the attributes at their peerings.

Curtis


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