From danny@tcb.net Fri Feb 12 06:32:56 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C253A76DC for ; Fri, 12 Feb 2010 06:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO2nbVmzLIsE for ; Fri, 12 Feb 2010 06:32:55 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7F2223A76C7 for ; Fri, 12 Feb 2010 06:32:55 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 28BE226866F; Fri, 12 Feb 2010 07:34:14 -0700 (MST) Received: from [192.168.1.64] (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Fri, 12 Feb 2010 07:34:13 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=50741; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 12 Feb 2010 07:34:13 -0700 References: <20100212105543.A162228C161@core3.amsl.com> To: sidr@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [sidr] Fwd: IAB statement on the RPKI. X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 14:32:56 -0000 Suspect folks here might be interested in this.. -danny Begin forwarded message: > From: IAB Chair > Date: February 12, 2010 3:55:43 AM MST > To: IETF Announcement list > Cc: iab@iab.org > Subject: IAB statement on the RPKI. > Reply-To: iab@iab.org > > > > IAB statement on the RPKI. > > = RPKI as a prerequisite for improving the security of the global > routing system. > > To date, the Internet has operated without a secure means to certify > the allocation of Internet number resources, particularly Autonomous > System (AS) numbers and IP addresses. The pending exhaustion of the > IPv4 address space, coupled with a pressing need to improve the > security of the global Internet routing system, has given impetus to > the development of a resource certification infrastructure for the > Internet. A consistent shared view around the world of which number > resources are allocated to whom is essential for the reliable > operation of the Internet as it continues to grow. The IETF Secure > Inter-domain Routing (SIDR) Working Group (WG) has been working with > the various stakeholders to specify a Resource Public Key > Infrastructure (RPKI) system that can be used to certify these > resource allocations in order to substantially improve the security > of the routing system. > > The IAB considers a properly designed and deployed RPKI to be an > absolute prerequisite to having a secure global routing system, > which is in turn a prerequisite to having a reliable worldwide > Internet. In its absence, there is no formally verifiable > authoritative source to determine the allocation for any > Internet number resource. Consequently, before originating, > propagating, or accepting an IP address prefix, each routing domain > must individually assess the consistency of that prefix with > whatever information can be obtained about actual allocations. This > loose "routing by rumor" approach provides considerable flexibility > to each routing domain, but the negative consequences are severe. > The global routing system is vulnerable to large-scale disruptions > through both misconfiguration and malice. These vulnerabilities can > be substantially reduced through the use of an RPKI. Through proper > design and wide-scale deployment, an RPKI enables network operators > to generate their routing policies from securely verifiable > allocation data, providing much higher confidence in the > authenticity of routing information. > > = Technical considerations with respect to the design of the PKI > > For any PKI, a certification hierarchy must exist that allows > parties to ascertain the validity of a given certificate. The SIDR > architecture uses a certification hierarchy, and relying parties > must explicitly place trust in the top-level of the hierarchy, > commonly called a trust anchor. The SIDR architecture and protocols > have been designed to support a single trust anchor as well as > multiple trust anchors. The IAB however, is in strong agreement with > the Number Resource Organization (NRO) (made up of the five > Regional Internet Registries (RIRs)) regarding the number of trust > anchors as well as what and whom they represent: > > 1. the RPKI should have a single authoritative trust anchor > > 2. this trust anchor should be aligned with the registry of the root > of the allocation hierarchy > > The reasoning is of a technological nature and is as follows. A > single root for the certification hierarchy significantly reduces > the risk of two or more parties accidentally (or maliciously) > issuing conflicting certifications for the same address block, > because a single authoritative entity at the top-level of the > allocation hierarchy is authoritative for both (a) the allocation of > the address block and (b) the cryptographic certification of the > fact that it did indeed allocate that address block. > > Thus, the IAB strongly recommends a single root aligned with the > root of the address allocation hierarchy (now part of the IANA > function). Doing so will minimize unnecessary complexity in the > system, in particular virtually eliminating the possibility of > resource conflicts in the system, reducing substantially the > likelihood of errors as the allocation and certificate generation > can be done together by the same operator. > > = Implementation considerations > > The notion of having a certification hierarchy with multiple equally > trusted roots may be appealing from a social and political perspective > because of 'fairness' and 'equality' arguments. But that notion > allows different organizations to make inconsistent and conflicting > assertions about to whom a particular address block has been > allocated. In the case of conflicting assertions, the conflict would > need to be solved by each relying party, requiring each relying party > to have their own security policy and the associated increased > complexity. Such an approach does not provide any guarantee that the > outcome would lead to a globally coherent view of which resources > have been allocated to whom. > > It should be noted that mistakes in and attacks on the allocation > process are possible, and that sensible caution and fallback plans > still remain necessary. Therefore, architecturally, the set of trust > anchors employed by a relying party application remains strictly a > local matter. In practice relying parties will likely employ local > policy files (e.g., for local address spaces such as RFC 1918 spaces > used internally) and trust anchors that reflect local security > decisions. Therefore the existence of a single root for the > certification hierarchy does not give that root unilateral control > over the Internet. Individual network operators choose to trust the > information given by that root, based on operational experience that > the information given by that root is trustworthy. If they find > it to be untrustworthy, they are free to ignore it and instead > enforce policy based on what they believe to be more appropriate > data. The fact that the relying parties choose to trust the root > only so long as it proves itself to be trustworthy gives the > organization operating the root a strong incentive to ensure that > the information they give is accurate and correct, thereby making it > rare for network operators to have any reason to distrust it. > > Mechanisms to support local decisions about trust anchors, while > still maintaining compatibility with RFC 3779 certificate > processing, are currently being considered by the SIDR working > group. This statement is not to be interpreted as in conflict with > these goals; rather, it is concerned solely with the structure of > the RPKI certification hierarchy, as represented in the public > repository system and aligned with the Internet number resource > allocation hierarchy. > > = Concluding remarks > > The IAB commends the RIRs for their investment and leadership > in developing an RPKI system that can be used for digital > certification of Internet number resources, as well as enabling a > foundation upon which a secure Internet routing system can be > developed. > > > > IAB, Jan 27, 2010 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From randy@psg.com Fri Feb 12 13:49:07 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B3528C287 for ; Fri, 12 Feb 2010 13:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yTRsvKl86MP for ; Fri, 12 Feb 2010 13:49:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 3650B28C285 for ; Fri, 12 Feb 2010 13:49:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ng3P5-0004cF-BD; Fri, 12 Feb 2010 21:50:23 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 37D942D9F225; Sat, 13 Feb 2010 05:50:22 +0800 (SGT) Date: Sat, 13 Feb 2010 05:50:22 +0800 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: References: <20100212105543.A162228C161@core3.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Fwd: IAB statement on the RPKI. X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 21:49:07 -0000 > Suspect folks here might be interested in this.. >> Subject: IAB statement on the RPKI. deep thanks to you and the many others who moved this forward randy From achi@bbn.com Tue Feb 16 13:20:43 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B7A3A722A for ; Tue, 16 Feb 2010 13:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOplWmMOQkP5 for ; Tue, 16 Feb 2010 13:20:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id EDFA93A6CED for ; Tue, 16 Feb 2010 13:20:41 -0800 (PST) Received: from dhcp89-089-053.bbn.com ([128.89.89.53] helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NhUs5-0003KU-A9 for sidr@ietf.org; Tue, 16 Feb 2010 16:22:17 -0500 Message-ID: <4B7B0C95.9090607@bbn.com> Date: Tue, 16 Feb 2010 16:22:29 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] draft-ietf-sidr-ta-02: comment on ETA EE revocation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 21:20:43 -0000 While implementing the "compound trust anchor structure" described in draft-ietf-sidr-ta-02, we noticed that some semantics were not explicitly stated, so a couple of us implementers were not 100% certain of the correct behavior. This following is clear. The compound TA structure consists of: 1. An ETA ("external TA") CA cert without RFC 3779 extensions. 2. A single ETA EE cert without RFC 3779 extensions. 3. A CRL for revoking the ETA EE cert. 4. An RTA ("RPKI TA") cert with RFC 3779 extensions, which is contained inside a CMS blob signed by the ETA EE cert. The clearly stated intent is to allow the RTA to be replaced relatively frequently due to changes in the resource holdings encoded into the RTA's 3779 extensions. The ETA CA cert can remain the long-term trust anchor. I believe the following was also intended (but it was not 100% clear): if either the ETA CA cert expires or the ETA EE cert is revoked, then the RTA must also be considered invalid. That is, the relationship between the ETA EE certificate and the RTA is a full "issuer-subject" relationship, not simply a secure delivery mechanism. If that's true, could a sentence be added that states it explicitly? Thanks, Andrew Chi BBN