[Sidr] other means of trusting announcements
Joe Abley <jabley@ca.afilias.info> Thu, 21 June 2007 02:07 UTC
Return-path: <sidr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1C5I-0004Rq-B7; Wed, 20 Jun 2007 22:07:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1C5G-0004Rk-He for sidr@ietf.org; Wed, 20 Jun 2007 22:07:42 -0400
Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1C5E-0008MU-G2 for sidr@ietf.org; Wed, 20 Jun 2007 22:07:42 -0400
Received: from yxu1a22.hopcount.ca ([199.212.90.22]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>) id 1I1C7k-000Fv0-JC for sidr@ietf.org; Thu, 21 Jun 2007 02:10:19 +0000
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <B2E2362D-049B-44D1-8712-1C20F39C923C@ca.afilias.info>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
To: sidr@ietf.org
From: Joe Abley <jabley@ca.afilias.info>
Date: Wed, 20 Jun 2007 22:07:27 -0400
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Subject: [Sidr] other means of trusting announcements
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
Errors-To: sidr-bounces@ietf.org
Hi all, I made a comment during the wg meeting in Prague in response to a question from the floor (I forget who asked the question; someone from Easynet, I think). Sandy and Steve asked me to repeat it on the list. The problem at the time, if I remember correctly, was one of context. For many operators in the RIPE region, there is established practice for building filters automatically for use as import filters on BGP sessions which is common to many operators. In that context, the SIDR approach as described in the face-to-face meeting is perplexing. It may well be that the documents could benefit from some accommodation of this context in the interests of rapid comprehension by operators in that region (operators who, I think, have shown the most interest in applying import filters to peers and customers). The RPSL repository operated by the RIPE NCC (the "RIPE database") on behalf of RIPE members (and others) incorporates a feature which I believe is not available in corresponding services offered by other RIRs. The assignment/allocation data from the RIR (in the form of RPSL inetnum, aut-num, etc objects) is linked for the purposes of authentication with routing data (e.g. route, route6, etc objects). This linkage is provided by RPSS (Routing Policy System Security). RPSS is documented in RFC 2725, but I do not know how accurate that document is with respect to the code which is actually running today in Amsterdam. In broad terms (and apologies to those who know the details of this, and who are now cringing) it is not possible to register a route object in the RIPE database if you are not authorised to manipulate the corresponding (covering) inetnum object. This means that the presence of a route object with a particular origin attribute implies reasonable confidence that the AS specified in the origin is authorised to originate the route in question. [The big hole in this trust dynamic is that for addresses assigned by other RIRs, no such linkage exists; in practice anybody can install route objects for addresses they have no business announcing in the RIPE database so long as those route objects don't already exist, and so long as the addresses concerned are not taken from one of the RIPE NCC's pools.] The key point is that it is possible to build a prefix filter based on policy expressed in an aut-num or as-set RPSL object using the RIPE database and have a reasonable degree of confidence that the resulting prefix filter is probably a reasonable one, at least if the peers you mainly deal with are European, and acquired their addresses from the RIPE NCC. For an operator in Europe who mainly deals with other European networks, it may well appear that confidence in the origination of a particular route from a particular AS is a problem which is largely solved. In this context, the need for the X.509 approach developed in this working group seems unclear, and the practical process by which a prefix filter could be constructed with reference to a certificate chain is non-obvious. For operators elsewhere there is no such context, and the idea of a solution to the problem "how do I trust this new customer when he says he is allowed to announce route X through me" that doesn't involve photoshopped letterheads and fax machines is no doubt much more obviously attractive. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr
- [Sidr] other means of trusting announcements Joe Abley
- Re: [Sidr] other means of trusting announcements Sandy Murphy
- Re: [Sidr] other means of trusting announcements Joe Abley