Re: [sidr] Route Leaks and BGP Security

Danny McPherson <danny@tcb.net> Tue, 22 November 2011 11:00 UTC

Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E0E21F8D66 for <sidr@ietfa.amsl.com>; Tue, 22 Nov 2011 03:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.476
X-Spam-Level:
X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnRfTQW89NvE for <sidr@ietfa.amsl.com>; Tue, 22 Nov 2011 03:00:27 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 560BE21F8D47 for <sidr@ietf.org>; Tue, 22 Nov 2011 03:00:27 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id CEFFC268063; Tue, 22 Nov 2011 04:00:26 -0700 (MST)
Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 22 Nov 2011 04:00:26 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=49377; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAL9jLaaUzm1rM5YVj+QHZDzQ2JUjO19WbiaxmjmWStDfA5-_Gg@mail.gmail.com>
Date: Tue, 22 Nov 2011 06:00:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C290E9F1-FC40-4E84-97E1-BE38B1282FA3@tcb.net>
References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <CAL9jLaZvCe2U6Y=BbZxsfF+BDOqQuV18Ac6N_6Fxxc=Cpms1jg@mail.gmail.com> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> <CAL9jLaY9rNCuLqozgbD7r03U8ZHB_n6MLmFrpVziPM2NNAuqnw@mail.gmail.com> <C054161F-43D5-4292-8A0F-7B386C76BABF@terrym.net> <CAL9jLaYNWge-tEo9XQeLqgOid72C2osdTHZdEZJzRHD8+M-Gnw@mail.gmail.com> <C629001C-E424-4484-8081-6A4542CB120F@terrym.net> <CAL9jLaaUzm1rM5YVj+QHZDzQ2JUjO19WbiaxmjmWStDfA5-_Gg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Route Leaks and BGP Security
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2011 11:00:28 -0000

On Nov 22, 2011, at 1:09 AM, Christopher Morrow wrote:

>> Probably they are the closest it gets, but a line from the ENISA paper sticks with me:
>> 
>> "Unfortunately, the quality of the IRRs varies, which makes it difficult to rely on them"

Terry: I think this is in large part attributed to lack of formally verifiable IRR objects (i.e,. 
objects bootstrapped by some resource certification mechanism).  There are many other
reasons as well, I'm working with a few folks to try and capture some of these..

> For instance, ALT-DB blows as a source for as701 data... RADB has some
> for AS701...
> Neither has RPSL-Policy-Foo for AS701 :( ('accepts all routes from
> <list-o-customer-asns> && sends-all-routes to
> <everyone-except-SFP-peers>')
> 
> I got the impression that the culture in ripe-region essentially was
> that: "Everyone autogens filters from RIPE-IRR, so ... get that right
> or your internet is very small."

I like that culture, it provides accountability and puts the onus on each operator 
to maintain their information.

-danny