From nobody Mon Dec 1 15:35:31 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CC1A9133 for ; Mon, 1 Dec 2014 15:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7VnnPitqTre for ; Mon, 1 Dec 2014 15:35:27 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8671A89AF for ; Mon, 1 Dec 2014 15:35:26 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XvaV3-000pht-0q>; Tue, 02 Dec 2014 00:35:25 +0100 Received: from g231225173.adsl.alicedsl.de ([92.231.225.173] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XvaV2-003F66-SM>; Tue, 02 Dec 2014 00:35:25 +0100 Date: Tue, 2 Dec 2014 00:35:05 +0100 From: Matthias Waehlisch To: Tim Bruijnzeels In-Reply-To: <3849CC4E-C34D-49EF-8F81-047FFD7DF599@ripe.net> Message-ID: References: <3849CC4E-C34D-49EF-8F81-047FFD7DF599@ripe.net> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="120093956-21014-1417476095=:4952" Content-ID: X-Originating-IP: 92.231.225.173 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/HxEKp_R2Mm60ekK6-rin-MnVOTI Cc: sidr@ietf.org Subject: Re: [sidr] Call for input: RPKI Browser X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 23:35:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --120093956-21014-1417476095=:4952 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7 Content-Transfer-Encoding: 8BIT Content-ID: Hi Tim, On Fri, 28 Nov 2014, Tim Bruijnzeels wrote: > We have been thinking of building a similar graphical UI for browsing > the RPKI tree into our validator, but we haven˘t had the time to work > on it so-far, and we have quite a few other things to work on as well. > What is your future plan with this? Are you planning to provide this > as a service, or do you envision this is a tool that people can run > locally? Is it open source? > both, we will release the source code such that people can run it locally, and also provide public access to a running server. From our side, we want build a more elaborated system for monitoring and inspection of RPKI objects. The browser is one component. We are very open for collaboration, and would like to extend the browser to a state where people enjoy using it. > I like the initiative and I think it˘s a useful concept. I played with > the filter to search for a resource, and I would like to suggest that > if I search for example for a prefix that maybe I should also see more > specific matches. For example if I now search for 84.205.80.0/19 I see > the certificate issued to RIPE NCC operations, but it doesn˘t show the > ROA for 84.205.80.0/24. > OK. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net --120093956-21014-1417476095=:4952-- From nobody Thu Dec 4 09:24:55 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5295B1A3BA0; Thu, 4 Dec 2014 09:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOyx9T5e_vBl; Thu, 4 Dec 2014 09:24:51 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6C1A889F; Thu, 4 Dec 2014 09:24:51 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C0D91181CDC; Thu, 4 Dec 2014 09:24:16 -0800 (PST) To: turners@ieca.com, gih@apnic.net, ggm@apnic.net, robertl@apnic.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20141204172416.C0D91181CDC@rfc-editor.org> Date: Thu, 4 Dec 2014 09:24:16 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/G5u_8SKlE_MGLwzq61pj93sK20c Cc: rfc-editor@rfc-editor.org, akatlas@juniper.net, iesg@ietf.org, sidr@ietf.org Subject: [sidr] [Errata Verified] RFC6487 (4080) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 17:24:53 -0000 The following errata report has been verified for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=4080 -------------------------------------- Status: Verified Type: Technical Reported by: Sean Turner Date Reported: 2014-08-12 Verified by: Alia Atlas (IESG) Section: 6.1.1 Original Text ------------- This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances. Corrected Text -------------- This field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances. Notes ----- Submitted after consultation with the responsible AD and WG chairs. The subject field included in the PKCS#10 request can't be omitted because the ASN.1 in RFC 2986 doesn’t allow subject to be omitted - there’s no “OPTIONAL” in the ASN.1: CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} } In other words, four fields are included in every certificate request. If there’s no subject field it’s a NULL (see RFC5280 for omitting subjects) and if there’s no attributes it’s an empty sequence. version and subjectPKInfo (subject public key information) are always present. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Dec 12 14:10:09 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD51ACFFC; Fri, 12 Dec 2014 14:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZEiln8q26vs; Fri, 12 Dec 2014 14:10:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 100961A0264; Fri, 12 Dec 2014 14:10:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: mlepinski@bbn.com,kent@bbn.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212221005.3917.60557.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 14:10:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/cDXY9kbGaZxscHCt4b6pH1HF2Ss Cc: sidr@ietf.org, morrowc@ops-netman.net, sandy@tislabs.com, ipr-announce@ietf.org Subject: [sidr] IPR Disclosure: IPR Declaration for RFC 7382 - Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 22:10:07 -0000 Dear Matt Lepinski, Dr. Stephen T. Kent: An IPR disclosure that pertains to your RFC entitled "An Infrastructure to Support Secure Internet Routing" (RFC6480) was submitted to the IETF Secretariat on 2014-12-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2498/). The title of the IPR disclosure is "IPR Declaration for RFC 7382 - Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI).""); The IETF Secretariat From nobody Fri Dec 12 15:56:10 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB61A03AA; Fri, 12 Dec 2014 15:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtZ8RPXVhX5z; Fri, 12 Dec 2014 15:56:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF4E1A07BD; Fri, 12 Dec 2014 15:56:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: kseo@bbn.com,skent@bbn.com,dkong@bbn.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212235605.11893.92369.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 15:56:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/sOHYrUHXcXd8lBYHn9CD121B50k Cc: sidr@ietf.org, morrowc@ops-netman.net, sandy@tislabs.com, ipr-announce@ietf.org Subject: [sidr] IPR Disclosure: Karen S. Seo's Statement about IPR related to draft-ietf-sidr-cps-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 23:56:08 -0000 Dear Karen Seo, Stephen Kent, Derrick Kong: An IPR disclosure that pertains to your Internet-Draft entitled "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)" (draft-ietf- sidr-cps) was submitted to the IETF Secretariat on 2014-12-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2499/). The title of the IPR disclosure is "Karen S. Seo's Statement about IPR related to draft-ietf-sidr-cps-04.""); The IETF Secretariat From nobody Thu Dec 18 15:26:38 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6331A9142 for ; Thu, 18 Dec 2014 15:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjaxd1TWV2RX for ; Thu, 18 Dec 2014 15:26:31 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18FF1A913B for ; Thu, 18 Dec 2014 15:26:30 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 2138028B0017 for ; Thu, 18 Dec 2014 18:26:30 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D4BDF1F8036; Thu, 18 Dec 2014 18:26:29 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_9E869268-ACF9-4BD5-881C-D5F46E9164AB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 18 Dec 2014 18:26:29 -0500 Message-Id: <921B6730-A6C3-4567-80F8-7CFB47CB4390@tislabs.com> To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/IB32hQFXqiYnnxndfEEZOOjEhso Cc: Sandra Murphy Subject: [sidr] minutes for IETF 91 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 23:26:35 -0000 --Apple-Mail=_9E869268-ACF9-4BD5-881C-D5F46E9164AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii MInutes uploaded as pdf and below as text. Changes, additions, corrections due by 05-Jan-2015. Apologies, I got these week before last. I could have sworn I uploaded = them then, but no. --Sandy Wes Hardaker as minutes taker Table of Contents _________________ 1 WG status of the various documents 2 BGPSEC protocol .. 2.1 BGPSEC-10 (Matthew Lepinski (ML)) ..... 2.1.1 Open issues ..... 2.1.2 Next steps 3 Considerations on RPKI overclaiming (John Curran (JC)) .. 3.1 Smaller subordinate certificates are sometimes needed ..... 3.1.1 weird things happen when parent and children CAs disagree 4 RPKI Retrieval Delta Protocol Tim Brujnzee .. 4.1 Rsync and new replacement protocol discussions 5 Proposal for signaling consent with whacked RPKI objects .. 5.1 main points .. 5.2 APNIC does publish manifests .. 5.3 discussion 1 WG status of the various documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + recap of various states 2 BGPSEC protocol =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.1 BGPSEC-10 (Matthew Lepinski (ML)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + origin validation is decoupled from BGPSEC validation + BGPSEC and RPKI results are independent + Wes George (WG): has anyone given a thought to the race condition when one is valid and the other isn't? this strikes me as something that is going to bite us if we don't think about how this is going to work. + Matt L (ML): I think you're right that it might be wise to include an example policy or something that said "this is one example policy of how to deal with these different results". + Added reference to AS-migration + should be complimentary and not in conflict now 2.1.1 Open issues ----------------- + Only outstanding issues are editorial + Is the text describing how the BGPsec_Path attribute is used in place of AS_Path sufficient and clear? 2.1.2 Next steps ---------------- + discuss with IDR + push -11 with editorial changes + Sriram, Kotikalapudi NIST (SR): + Went through document + Have some editorial comments + Matt: can you give them to me quickly so I can spin the document with them? + With section 5, found a couple of technical errors + BGPSEC update is valid and invalid + Need to say "origin validation or path validation is valid or invalid", because some sentences still indicate both + Negotiating EBGP peers is establishing a relationship. When you establish a new connection during algorithm + ML: you don't agree on algorithms in the capabilities exchange; I just send all algorithm sigs and you ignore what you don't understand + SR: ok, but on page 24/25ish then if I receive alg 2 when I only understand alg 1 then i should treat this as an unsigned update. If i'm processing the sig block and I don't find alg 1 and I find a sig block with alg 2, is this an attack point and I should treat it as a protocol error or should I treat it as unsigned. i think we should carefully thing that. + ML: I'd be happy to entertain comments on the mic or on the list about it. I think we hope the way the transition will work is that we continue to do both until all our peers plenty of time to support both algorithms. + SR: when I don't recognize the algorithm number, i think i should treat that as an error + Rob Austine (RA): I believe we discussed this. It's a slow algorithm transition. We agreed a long time ago that not understanding the algorithm is equivelent to an unsigned update. + ML: lets discuss that more on the list 3 Considerations on RPKI overclaiming (John Curran (JC)) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D + JC gives presentation 3.1 Smaller subordinate certificates are sometimes needed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.1.1 weird things happen when parent and children CAs disagree --------------------------------------------------------------- + overlaps happen when a child is using a larger CA + sometimes validation states end up in bad statesup, including "invalid" + Ruediger Volk (RV): make before break is required if we want to use this operationally. We better design our stuff so we can fully rely on it. We need to be careful until we have perfect implementations. It's not a good idea to consider something "not completely reliable". + RV: We do have any procedures for describing what a proper transfer procedure is? + JC: I think the RIRs need to contribute this. It's not a RIR only topic though. Moving from one ISP to another requires coordination between your old ISP and my new one. + RV: how can I, as an ISP, do the right thing when I don't understand what my parent does. + WG: there is a definite need for consistency here. Even just RIR to RIR transfer. How prescriptive do we need to be? Some is just operational. We need to be prescriptive because if we do it wrong we'll break stuff. + Sandy Murphy (no hat; SMNH): One thing has always confused me about actions that are planned and ones known about ahead of time vs ones that happen without any planning. The second accidental case includes power outages, crypotgraphic failures, etc. Do we need a solution that applies to all of them or just some of them? + JC: the transfer is the foreseen case; those occur when people move organizations but also happen when people move between regions. We can mitigate for those if we document some of them. There are some instructions from a court that says to do something you don't have a choice about what to do. These unforeseen resource changes are very hard to mitigate against. + SMNH: I admit there are exmaples of those (I'm not sure the court case is one). The question remains: do we need a solution that covers all the examples? Is there one more than other that needs to be addressed. + JC: I'm not sure we need to change, we just all need to understand the ramifications. + ?? to SMNH: There is a set of events that can make this happen + SMNH: what I was asking for was a description of cases where it is possible, because I don't believe it is. I don't see that it's possible for an RIR to have an overclaiming certificate, but I don't see RIRs able to do that. + JC: only if you have a global trust anchor + SMNH: I still don't see it. + JC: I'm more concerned about ISPs having overclaiming certs + SMNH: I don't see when RIRs overclaim and when it can happen? + JC: right now it can't happen + Tim Brujnzee (TB) RIPE NCC: there is a lot of benefit of looking at foreseen cases. EG, transfers, reclaims, etc. I think there is stuff to do that we can make stuff better. There are also always a possibility that things break. You're right we need to review. Another problem can be that if you allow for this on one hand you increase the resiliance against mistakes but you also increase the risks that holes can be punched from the top with surgical precision (the validation reconsidered mechanism). Which is the bigger problem, accidental failures vs hole-punches from the top? + RA: the design of the provisioning protocol tried to deal with this by trying not to do revokes when possible, but when you have a shrink you don't have a choice. Picture Alice->Bob->Carol tree; If Bob didn't get a notification that carol's resources got yanked, then Bob has to re-issue everything once it sees things happen. If Carol sees this later, then there are certificates that are invalid because they don't match the current resource allocations. If someone has a failure in the communication chain, then are failure modes in the big distributed database that contains errors. + SMNH: Alice will reduce bob's cert; carol has cert from bob and has a mix of retained and removed. Bob will eventually give carol new certificates for those retained, but alice can actually issue that certificate itself. In the RIPE database it says you're responsible for the entire address database below you even if you have delegated some of it. I always thought that's the way this world thought; they had the responsbility and the authority. + RA: I don't know where alice can get carol's [public] key from. I don't think that is possible. + SMNH: Alice would need to get carol's key to fix this + JC: there may need to be a mitigation step. I just don't think we've exlpored them and documeentd them. + TB: We need a signaling mechanism. In the case of a foreseen shrink there is a lot we can do there. 4 RPKI Retrieval Delta Protocol Tim Brujnzee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 4.1 Rsync and new replacement protocol discussions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + WG: why can't we just start testing this? + tim: we have existing deployment and we can't just change from one thing to the next; I do have confidence this will work though. + RA: This is a change and I'm quite sure my validation code won't work with the new OIDs, so we can't just drop it in without talking to people first + WG: Just to clarify, I wasn't saying flip the switch without telling anyone, I'm just saying lets roll it out soon. + RA: this is similar to zone transfers with AXFR and IXFR. This is a new application of an old technology. + ML: I like this approach. Where is this documented? + TB: it's outdated; I haven't asked for a WG document yet. + ML: just want it in the minutes + [editor: It is!] + TB: it is outdated, so I'll try to update it within the next 2 weeks + Andy Newton (AN): can we adopt it now? + AN: how do you make sure the file is complete before serving it + TB: have you operated a CDN? You could run your own. The cheap solution would be to write it to a disk + RA: there are standard unix tricks for this + AN: how do we know when we can delete the deltas? + Tim; that's a good question. We need to have a discussion about that + RA: Handle it the same way DNS does; keep stuff around till you're tired of maintaining it. + WG: it's less work to pull the whole file sometimes; it's probably better to start from scratch if you need to pull more than N deltas + Tim; we can actually keep some stats to work on this as well. we may be able to determine how long to keep them + Terry M (TM): has there been any security review of the file itself? + TB: no review, but we have object security so it is no different than rsync + RA: we've thought about this, are there any benefits to channel security? + TB: and how do you achieve it (HTTPS), but then that becomes a point of trust. + TM: perhaps consider just to stop the man in the middle attack. Use it to stop the man in the middle preventing an update. + Jeff: The notification file itself needs an integrety check on top of it. I think the caching mechanisms are needed, and the object security mechanisms as well. + RA: I'm not sure that https brings anything. It doesn't stop anything. Part of what we were trying to do is going light weight. I'm not convienced there is a case for https yet. + Tim: maybe serving over https would be heplful; we'll have to check. + AN: I think I agree with Terry about https. Ghost buster files have PII, and those might need to be encrypted with https. + Tim; but it's a public database + AN: you just have to call it out as a privacy issue + ML: if anyone is putting something in a distributed repository that they're uncomfortable with the entire world seeing, then we have a problem. + SM with hats (SM): The WG discussed this in the past, this is someone putting stuff in the database for publication. + AN: there are other groups that have issues with this, and we will too because it's a vcard. + TB: https doesn't solve this problem; you can still get the data. + Ellie: we should do what's right for the security pieces, yes privacy is concerned. Don't worry about the IESG; we'll talk. Do the right thing for a public database. + Chris (no hats); CNH: there is a lot of direction for focus on caching. + Wes Hardaker (WH): caching should just be stated as possible, but point to the transport documents about how to do it (eg, http) + RA: we're looking for a way to steal a mechanism to help with both redundancy and caching and many exist. We wanted a system to allow for current off the shelf tools to be used. + TB: want to minimize the load on the server side and put the load on the clients. 5 Proposal for signaling consent with whacked RPKI objects =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 5.1 main points ~~~~~~~~~~~~~~~ + People that hold ROAs that are going to be whacked must approve the whacking. 5.2 APNIC does publish manifests ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + George: Slide said that APNIC doesn't publish manifests, this is incorrect because we do publish it but we do make the statement that there are operational aspects of it. The MANIFEST may not contain files because they shouldn't be included even if they're still on disk because of the publication timeline. It's an exclusion check, not a catalog. We made the public statement that a manifest, during publication timeframe, may not perfectly match the files. 5.3 discussion ~~~~~~~~~~~~~~ + Terry: a court order won't talk to the defendant to tell them to sign a .dead file + WH: what happens with a signer which truly is dead (company or key loss) and can't sign the .dead? + the alarms would go off; whether something happens automatically in determining if a route is accepted automatically or requires human intervention is not known at this time + ML: this is a problem to be solved and + ??: is the .dead a mandatory or optional feature? This allows people to be able to make local choices. + Doug Montgomery (DM): is there a garbage collection mechanism + yes; it's later in the slides + TB: sadly, sometimes, consent is sometimes optional. Relying parties will have a lot of burden to make decisions about each case as they come forward. + DM: I'm worried about the tons-of-alarms problems. Normal business operations will likely produce thousands of alarms, how would we deal with these? We've talked to a lot of people that love the idea of the RPKI because they can invalidate the people underneath them and get the addresses back. + The key must be held by the provider in that case so they can invalidate the child without the child's consent. + Jeff: It is useful to be able to tell if something happened that you didn't see. Most users will only care about the most current state. + Jeff: Any number of problems in the real world need to be accounted for in the proposal, such as system crashes, key losses, etc. + RV: Can we figure out who did the revocation? + partial answer: it's coming later in the slides + DM: This seems tailored at rare events. RPs may make different decisions. I worry about global synchronicity about looking at the RPKI, which is currently loose. Different people will have very different time-notions of the state of the world. + ??: This is base on the premise that this problem needs to be solved for deployment of the RPKI; I think this decreases the deployability of the RPKI because it adds complexity. + I think it's important to signal when something is suspicious and I think that increases the trust in the system + DM: the discussion of whacking always interests me. There are forced revocation of resources that most people would agree is necessary. + You would need to prove the internet community that what you're doing is right + DM: how? + Out of band. + DM: don't some orders come sealed? + Chris: yes, many cases state you can't tell the client that you're doing this + TB: There are reasons we take back resources. And the parties doesn't agree. How does this scale, because if you have to evaluate each case and that puts a lot of burden on operators. I agree there is a problem, but this might be better for a 3rd-party auditor case that can tell you when things are going wrong [other than having each operator do it]. + ML: I don't believe it was a design goal to allow for revocations. It may be used to remove bad people from the internet, but it wasn't designed for that and i'm not sure we have working group consensus about it. + RV: certain parties may interfere, but now maybe they'll think twice about it. + WG: responding to take down not a design goal: while true, in practice, there is a whole set of things that we don't concern ourselves about, such as legal implications, etc. But we do have to be thinking about them none-the-less. We don't take the position about what is evil, but we do have to think about how that interacts with our systems. + SMNH: What was a design goal was that the prefix allocation system has a particular structure and the RPKI is designed to enforce that structure. I can only allocate from what I currently have. That's the allocation system, and the RPKI models that system. Every contract says "if you mess up we get to take the allocation back". Any time there is a structure that permits enforcement, the same structure allows you to do new things that aren't good. + WH: The thing about situations like this is that I can see the future where every parent requires the revocation keys from the children. And I also worry about grandparents being the one told to remove a grandchild. + DM: the original goal was to ensure authorized holders of networked resources that they could announce them. It was short sighted to believe that they wouldn't need to change. --Apple-Mail=_9E869268-ACF9-4BD5-881C-D5F46E9164AB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUk2KlAAoJEHplpQeet0IZ/uIQALdl15tn/hAoJLI5E9ThUTWF 1LMyymwDxEXMXsKrLG6KJAgXw/4mOpH+08+Otq/yKnJneikaKZDm2ZIlnpAW/N1l ZyLxEPEuVZ5JdkD5Pk9uCJ271c9rSn7c4wg0XjqDyWe0vi3ggDTRE6YC7iJKBRn/ GEbC9NN+LzHZN7dgkbXOPUAa6dba2IpowMxuy46H0uYF6S/v29qwqrVnxhNjlgf3 AhJGmwuV4BQ5H1hkTPaPhqxiCbSyn3EdHrYM3P+Z6ch8zrRkRfwxKNBCmWnv7S19 YJEpZ8UnMOgtIUSr1nO9klBSiQ132RGZ/1vtodNHOYpMSiz95odOllYlFe2Wuw2a CB6myZAW+PFbQjh637aAzStDCGawrDuPVVed31BUdK6cgZ+B8ONEx0+4alHInzum EgwlE5mIh8k3W7rPo4+FGIM0JzLyytCIgmrzBjmGF0ng3PTT+Gv+YTLkQ6v6dVZ9 DnzbJIO7qI+Ng+bXz9c+zC7Gpf+R2v+xHzde7O+VJHcl8vcZAo82+wUNIOeFL0c/ Os6yzXst+zxvtgEaoc8EQZq7tPbBFYx1OSOiMQCKU4nJ8DgUIcFI6t6cW8NDlgVn qMOiP24CYFsu0LAGivkMZF08d3dBz2pK7CaWrQam95ozPrHUez0F6T0LehQ3N2A+ 54f3E9d4QH59g6sK2tJq =alE2 -----END PGP SIGNATURE----- --Apple-Mail=_9E869268-ACF9-4BD5-881C-D5F46E9164AB-- From nobody Mon Dec 22 03:55:35 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D601A8A61 for ; Mon, 22 Dec 2014 03:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zadWk_T_jHE4 for ; Mon, 22 Dec 2014 03:55:32 -0800 (PST) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CAF1A036C for ; Mon, 22 Dec 2014 03:55:32 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1Y31a9-0000xt-7b; Mon, 22 Dec 2014 12:55:26 +0100 Received: from tel-sslvpn-1.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e8] helo=[IPv6:2001:67c:2e8:5009::40]) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Y31a9-0005lA-4O; Mon, 22 Dec 2014 12:55:25 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_97FB1CFA-3ED9-4293-A78E-73EC0FED0C15" From: Tim Bruijnzeels In-Reply-To: Date: Mon, 22 Dec 2014 12:55:22 +0100 Message-Id: <6DD59BFC-7E1D-4186-AE7E-472203B3E1B2@ripe.net> References: To: sidr wg list X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071995f2a5d0afb4e2e366e239337fa9397d Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/wEhuF-gQvycoZOFSmgI70jGeAXQ Cc: Sandra Murphy Subject: Re: [sidr] this is possibly Tim Bruijnzeels delta protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 11:55:34 -0000 --Apple-Mail=_97FB1CFA-3ED9-4293-A78E-73EC0FED0C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, On 14 Nov 2014, at 21:38, Tim Bruijnzeels wrote: > ...and I hope to post it to the wg within two weeks... A little later than I was hoping for, but I just uploaded a revised = version: http://www.ietf.org/id/draft-tbruijnzeels-sidr-delta-protocol-03.txt I would like to ask the working group to read this version and I would = like to ask the chairs for a formal call for adoption of this work. This version of the document is quite different from previous versions = that you may have read. The basic principle is unchanged. The format of = the protocol messages has been simplified quite a bit and reflects proof = of concept implementations that Rob Austein and I have worked on, and = tested interoperability on, over the last months. The supporting text = (reasoning and text on usage of the protocol etc) has also been revised. = Some elements of that text are definitely still up for discussion: e.g. = when talking about how *long* a notification file may be cached. We = tried to outline these discussions clearly in the document. Regards, Tim Bruijnzeels= --Apple-Mail=_97FB1CFA-3ED9-4293-A78E-73EC0FED0C15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = all,

On 14 Nov 2014, at 21:38, Tim Bruijnzeels <tim@ripe.net> = wrote:
...and I hope to post it to the wg within two = weeks...

A little later than I = was hoping for, but I just uploaded a revised version:





<= /div>
Tim Bruijnzeels
= --Apple-Mail=_97FB1CFA-3ED9-4293-A78E-73EC0FED0C15-- From nobody Tue Dec 23 14:42:03 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E111A6FF6 for ; Tue, 23 Dec 2014 14:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.175 X-Spam-Level: * X-Spam-Status: No, score=1.175 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_XBL=0.375] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gf29n7p3HQw for ; Tue, 23 Dec 2014 14:42:00 -0800 (PST) Received: from nm23-vm8.access.bullet.mail.bf1.yahoo.com (nm23-vm8.access.bullet.mail.bf1.yahoo.com [216.109.115.167]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0591A6FEA for ; Tue, 23 Dec 2014 14:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419374519; bh=djDtxtuTsRIJ1X9ytAjLroTgvpNSEc29K5EsYra50j8=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=FLl77O5HwEhx0ps0qDI4KOqU0a0bUe1trvinurThcEGPPlECjaF2xoz10foF+3d84V9tpbnUd8+B/r7yQa4N2VIatFV4OgLmWVS/w1oQDoS0/yVPXpKcoJX0BU7CTW+tYwlanLgslzEcIOoE0J4Zl8te1B4xp/Pdei+726fUFC3PUIQ5hi0aDWmKN4WWcvi5j1GWdWsek9qmj05QJDcvP4c8ecbcsoOwnWNt5XuOlyXHwELXxsFA3eUImcTjoG2ZhBBa7ikSaJ8Wkcci/KsJj/AChY6pBGOzoHBW8hrKK6Jy69hd+pNFp0y/hJqh8PY6Ch/OeXgTPMaKxe/SuCiiYg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=Ym62O9gAPllaFzpqrAawjlSWsAfFizlmccB2tqBR5EfajNTd2HBYyrLuo36OgFWwgvQNpenqbBtcleoqfTJCVAky1faGp6oeci4OxRy8OFi+dKBO+ZnTrHADg2+XH98mzaYc7m+T4w7XDJEMhgJIUeqklwL/4JwrzZVCLHbD7QLn0OSCoBbVZhY163lKbcGZkPC26/IWIHDJhJslm9PK1Zf13kf5jEwhcba6cQXuBAJIZHfYaGJd2HKjRwONme7ptYQUO0HIdJXkd0pQMtX1e1NNavvPMSSRfSHZ91oCP70YJ5hLniDJsMcOivjRyIDq7RjiUZUUewkmVbRgcdUS8g==; Received: from [66.196.81.159] by nm23.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Dec 2014 22:41:59 -0000 Received: from [98.138.104.100] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 23 Dec 2014 22:41:58 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 23 Dec 2014 22:41:58 -0000 X-Yahoo-Newman-Id: 840440.77350.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ..fP4OAVM1kiBXdOItwpBPm6MlLD1NN2LPLkelLhH_HxJlu s_w5g4_DkH77XOmHahfIHkWHPKEUnozr5D6dvw1ukbZonUBdrJNRmj6PA.LW ejtqz6OEUJ34MoWvk3pTTUcNyO0ukkP5.myt6MPHzYZxoz0GL3OLucjeDFkh .zGn3l7EXqQeHxhx6qtqpgI3Qze0JP7gHS4g8YBXtsvjpTEIp3YM.PCZz6fd C.hxNwVyrJd3JqryYcBA17wMi3AQlGAW2EdDcTacJ0avJ2NKAcTKzKp9m25l tIMuwicVract6lu.TYJdn43AS3epkDYveEM5cqmOJUdtCUvwiD3pZSrJGb5j M403Fnyzcdqq.Fo.CrPH3KgA.U_F0hC9hO2lHikV0mNgcboM1P5v6a86IgAV tbONV_vp81wQT8c8FLVaXFetEn8rErHw6OGnheg837W90vko17xdhFUg7dOV VsSD.COD4x2yP8cvrmox3Xb6JaB58D6ToVzTbdOGa00NiJm408qDM79NWhYn zUIj2QLDdkSOq_fPHWrBSOBZq34H29MbHI2kjzm8Zp9MtuoM6xlgByIvv_er haShRB76BwkTcyp9semfQLQFUOdE833wz0rwKjo.Hl2NT0rNJlw-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id AB19512001 for ; Tue, 23 Dec 2014 17:41:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 23 Dec 2014 17:41:57 -0500 From: David Mandelberg To: In-Reply-To: <6DD59BFC-7E1D-4186-AE7E-472203B3E1B2@ripe.net> References: <6DD59BFC-7E1D-4186-AE7E-472203B3E1B2@ripe.net> Message-ID: <1c396f957caaf91732e5d30deb17936c@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/lZElb8dTDwjnXjhxoPqQp_pBXPg Subject: Re: [sidr] this is possibly Tim Bruijnzeels delta protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:42:01 -0000 Yes, I know I'm an author, but I'm going to review this anyway. Section 3.2.3: "The serial attribute must be an unbounded, unsigned positive integer indicating the current version of the repository." On the relying party side, unbounded integers make me a bit nervous. If the serial number is terabytes long, I'd really prefer to reject the entire file. Can we instead restrict the serial attribute to fit in a 64-bit unsigned integer? Changing sessions once every 2^64-1 serials doesn't seem like a significant burden. (nit) Section 3.2.4 uses the term "version" when I think it means "serial". In section 3.2.5, "A new delta file MUST be generated", but "The [notification] file SHOULD also include available delta files for this and previous updates". Is there any point to generating a delta file and not listing it in the notification file? I'd recommend changing both to MUST or both to SHOULD. Section 3.4.3: "Including the hashes in this manner allows relying parties to identify specific objects by their hash rather than the URI where they are found." If some RPs use just the URI and some use just the hash, it might be possible for a cooperating CA and repository to cause the two types of RP to see two completely different views of the RPKI. A paranoid RP could check both the hashes and the URIs to make sure that never happens, but that defeats the purpose of having both identifiers. Is the flexibility here worth the potential risk? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Mon Dec 29 12:12:18 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBDF1AC3CB; Mon, 29 Dec 2014 12:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcbsy_LX1rub; Mon, 29 Dec 2014 12:12:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1A1AC3E1; Mon, 29 Dec 2014 12:12:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229201210.4105.11992.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 12:12:10 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/eg0KW5m3N0voKWH4c5iSNYvnKmk Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 20:12:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI Local Trust Anchor Use Cases Author : Randy Bush Filename : draft-ietf-sidr-lta-use-cases-02.txt Pages : 5 Date : 2014-12-29 Abstract: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-lta-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-lta-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-lta-use-cases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 29 17:21:03 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9705B1ACEB7 for ; Mon, 29 Dec 2014 17:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoaz4VITy7f7 for ; Mon, 29 Dec 2014 17:21:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781711ACEB6 for ; Mon, 29 Dec 2014 17:21:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Y5lUY-0006hW-AT for sidr@ietf.org; Tue, 30 Dec 2014 01:20:58 +0000 Date: Tue, 30 Dec 2014 10:20:57 +0900 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20141229201210.4105.11992.idtracker@ietfa.amsl.com> References: <20141229201210.4105.11992.idtracker@ietfa.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/YdDLvr9LeFzawBeBl04r713y38Y Subject: Re: [sidr] I-D Action: draft-ietf-sidr-lta-use-cases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 01:21:01 -0000 just a six month refresh. nothing to see. keep moving. randy From nobody Tue Dec 30 08:29:56 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76041A000F for ; Tue, 30 Dec 2014 08:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmjHJ66U0Xm5 for ; Tue, 30 Dec 2014 08:29:53 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3B11A000D for ; Tue, 30 Dec 2014 08:29:52 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1Y5zg3-0006iM-98; Tue, 30 Dec 2014 17:29:48 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-44.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Y5zg3-0007cv-69; Tue, 30 Dec 2014 17:29:47 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Tim Bruijnzeels In-Reply-To: <1c396f957caaf91732e5d30deb17936c@mail.mandelberg.org> Date: Tue, 30 Dec 2014 17:29:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9023661A-B0F9-4BF1-B7DE-7979DAFEB6E1@ripe.net> References: <6DD59BFC-7E1D-4186-AE7E-472203B3E1B2@ripe.net> <1c396f957caaf91732e5d30deb17936c@mail.mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.1878.6) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719123779cd2083d77fd5d25065740fcc58 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/fNvx-lnLk9mn_pU14sLUZcGQaz0 Cc: sidr@ietf.org Subject: Re: [sidr] this is possibly Tim Bruijnzeels delta protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 16:29:55 -0000 On 23 Dec 2014, at 23:41, David Mandelberg wrote: > Yes, I know I'm an author, but I'm going to review this anyway. >=20 > Section 3.2.3: "The serial attribute must be an unbounded, unsigned = positive integer indicating the current version of the repository." On = the relying party side, unbounded integers make me a bit nervous. If the = serial number is terabytes long, I'd really prefer to reject the entire = file. Can we instead restrict the serial attribute to fit in a 64-bit = unsigned integer? Changing sessions once every 2^64-1 serials doesn't = seem like a significant burden. I believe we have unbounded numbers elsewhere, like manifest serial = numbers. But if this makes you nervous. If there is an update every = second, it takes more than 500 billion years to hit 2^64. So for all = practical purposes I am fine with restricting this. I think server = implementations can get away with not checking this during our lifetime = though ;) As for clients rejecting a number that=92s too long. Maybe we should = specify a reasonable maximum size for this file instead? HTTP 1.1 does = not support an "if-size-smaller-than" header as far as I know, but = careful RPs could do a head request to figure out the "Content-Length" = and "Last-Modified", and then decide to proceed or reject. > (nit) Section 3.2.4 uses the term "version" when I think it means = "serial". ack >=20 > In section 3.2.5, "A new delta file MUST be generated", but "The = [notification] file SHOULD also include available delta files for this = and previous updates". Is there any point to generating a delta file and = not listing it in the notification file? I'd recommend changing both to = MUST or both to SHOULD. sorry, significant typo here.. the first sentence should be: "A new = *snapshot* file MUST be generated." In theory this protocol can be used with only snapshots. Long term this = may not be so useful, so if the WG would want to change this to "MUST = support deltas" we could of course. Shorter term I think a "SHOULD" = allows for a more incremental uptake of this. I can imagine a poor man's implementation where a CA just writes its = stuff to disk (like it might do today for rsync), and kicks of a process = that scans the subfolders to construct a single snapshot file, without = keeping track of what actually changed between versions. This would = force RPs to retrieve the full snapshot file whenever an update happens. = Then again.. even with this scenario comparing your snapshot files = server side to figure out what the delta is after the fact should not be = too difficult either. Oh and the first serial would typically not have a delta. There is no = previous serial to update from. We could insist that a delta is included = that's effectively the same as the first snapshot, but that seems a bit = artificial to me. > Section 3.4.3: "Including the hashes in this manner allows relying = parties to identify specific objects by their hash rather than the URI = where they are found." If some RPs use just the URI and some use just = the hash, it might be possible for a cooperating CA and repository to = cause the two types of RP to see two completely different views of the = RPKI. A paranoid RP could check both the hashes and the URIs to make = sure that never happens, but that defeats the purpose of having both = identifiers. Is the flexibility here worth the potential risk? Note that we have similar trust problems with rsync. Going forward section 4.2 has text about treating "object updates and = withdraws with some skepticism". I think it may be useful to include = URIs and hashes in withdraw messages and updates (publish with hash = attribute for old), as hints, or in case of deltas because it's just = convenient to include all publish and withdraws received in a single = update from a CA in a single delta. But RPs should not blindly trust = them. I don't think there is only one clear strategy to achieve this = though, which is why the remaining text of 4.2 is rather informal. We can really benefit from RP implementation experience here. My idea = would actually be to keep a map of all relevant objects by their hash, = ignore withdraws completely - only use the protocol to learn about new = objects. URIs are just hints as well. I would rely fully on hashes in = validated manifests to retrieve objects. I would delete these objects = only because of space and efficiency concerns, and only if they have = expired, or I see a new *valid* manifest where the object is removed. I = am not convinced yet though about all the details - so I would like to = have an implementation first. And even then I am not convinced that this = is the only way to do it..=20 In short: I think we can find a way to implement this securely in the = RIPE NCC validator. I would be happy to document the exact details in an = informative draft for scrutiny and reference of that implementation. But = I don't think we can mandate how to do this in general, and even if we = could this delta document is probably not the place to do it. Tim >=20 > --=20 > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr