The authors made a suggestion (see below) for a new course of action for the draft draft-ietf-sidr-multiple-publication-points, splitting the draft into two work items.
And there have been nearly two months of mostly silence on the point. (Thanks to Steve and Arturo for their replies.). If the working group does not reject the approach the authors suggest by 13 Dec 2013, the authors should proceed with submission of a new version of draft-ietf-sidr-multiple-publication-points that meets the first proposal: - A "6490-bis" document that obsoletes RFC 6490 with the addition of multiple operators in section 3 of the current document. and submission of an individual draft for consideration of the working group that meets the second proposal: - A new BCP/Informational document on best practices when RPKI certificates include multiple repository operators for the same materials. --Sandy, speaking as wg co-chair ________________________________ From: [email protected] [[email protected]] on behalf of Roque Gagliano (rogaglia) [[email protected]] Sent: Monday, October 14, 2013 3:41 PM To: sidr wg list Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points Dear Working Group: The co-authors of the multi-publication points document would like to propose a new course of action to the WG referring to this document. Since its initial submission, the document addresses two problems related to the support of multiple operators in RPKI: i)- Multiple Operators support in TAL files (Section 3 of current document) ii)- Multiple Operators support in Certificates (Section 4 of current document) Today, we believe that the two problems are very different. On one side point i) could be quickly solved by the WG by updating or obsoleting RFC 6490 with the changes proposed in Section 3 of the document. We have shown in Berlin that changes to RPs should be very small and that "some" (and I say so because in some cases it was accidental) backward compatibility exists with most popular RPs. However the second point ii) while it does not require changes to existing standard document but rather a "BCP" document, it does require much more research. While we go down to the RPKI hierarchy, we need to understand how multiple operators may create transient states and how RPs will typically react to these. Some of the questions to answer were raised at the meeting and recently in the WG mailing list. Our proposal to the group is to split the current content in the document in two documents: - A "6490-bis" document that obsoletes RFC 6490 with the addition of multiple operators in section 3 of the current document. - A new BCP/Informational document on best practices when RPKI certificates include multiple repository operators for the same materials. We look forward to hearing from you, Regards, Roque + Carlos + Terry On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) <[email protected]<mailto:[email protected]>> wrote: Thanks Sharon for your email and analysis. These points are some of the points raised during our last meeting. I personally believe that the non-TAL work requires more research activity and I guess from your email that you have an interest in this area :-). Regards, Roque Hi Roque, As you work on this, I wanted share some observations made by my colleague here at BU, Ethan Heilman. He read the draft in detail and had a two suggestions and one question, see below. Sharon Suggestion 1: Section 4.1 of the draft says: “If the connection to the preferred URI fails, the RP SHOULD fetch the repository objects from the next URI of preference." We suggest that the failover logic be extended to include validation failures as well as connection failures (similar to the logic for TALs). That is, when RPKI-validation generates a warning, an RP should fail over to another publication point. These warnings could be generated by stale manifests, manifest errors (http://tools.ietf.org/html/rfc6486<https://urldefense.proofpoint.com/v1/url?u=http://tools.ietf.org/html/rfc6486&k=ppNirDwWpcp60F64Pj2f9Q%3D%3D%0A&r=1r2Unu%2Fc6gYAwDNJlKNsbPY52jaSAOPXvi3DGzGJXQo%3D%0A&m=k9moRHdBcKv1YVn%2B05d4Q%2F6SBxF5N2hhQ4CzsG%2BvGYI%3D%0A&s=f91c1c4f76c7ab2d139669df30dfad9fb53ecdf7bb5b6dc47a66534f07054718>), expired certs, missing ROAs, and other validation failures. We call this failover mode FO-Corrupt (Failover On Corruption) as opposed to the current failover mode FO-Connect (Failover On Connection failure) in the draft. Here’s why we suggest FO-Corrupt: 1) Multiple publication points using the FO-Connect policy increase the attack surface, while multiple publication points using the FO-Corrupt policy decrease the attack surface. With FO-Connect, corruption failures in a given publication point will directly affect RPs that select that publication point. Meanwhile, under FO-Corrupt, a corruption failure must occur on all publication points before it affects RPs; each additional publication point adds an additional barrier to an attacker that seeks to corrupt objects. This also allows operators to raise the cost of an attack by adding publication points using diverse software and operating systems. Importantly, missing or corrupted RPKI objects can cause routes to become classified as invalid, and therefore be less preferred -- I provide examples of this happening in the attached PDF – so if some of the publication points contain uncorrupted objects, it’s important to ensure that RP’s fetch them. 2) The differences in behavior between TAL failover and RPKI object failover could cause confusion. FO-Corrupt would provide a more consistent policy. Compare the quote from Section 4.1 above with the following from Section 3.2: “If the connection to the preferred URI fails or the fetched certificate public key does not match the TAL public key, the RP SHOULD fetch the TA certificate from the next URI of preference.” Suggestion 2: Section 3.2 and 4.1 of the draft suggest three rules to select the URI of the publication point: (1). Provided order, "the order provided in the correspondent certificate" ---- my reading is that this would be consistent across all RPs. (2). Random order (selecting randomly from the available list) (3). RP prioritized order, "a prioritized list of URIs based on RP specific parameters such as connection establishment delay", this may or may not be consistent across some subset of RPs. We see the value of giving RP’s the flexibility to choosing publications points based on their own concerns (delay, jurisdiction, etc.). But rule (3) seems problematic because it could be exploited by attackers to predict the order which an RP would fail over from one publication point to the next. For example: i. An attacker could target the first publication point of the list to distribute bad or missing objects, causing all RPs to get bad information. ii. An attacker who happened to compromise a publication point that was not the first element of the list, could e.g. DOS publication points at the top of the list to ensure that RPs would use the attacker’s publication point. iii. An attacker which could predict the fail over order could perform a rolling DOS attack attacking the first element, then the second and so on. Question: Finally, there has been lots of work on fault-tolerant distributed database systems that allow RPs to resolve inconsistencies between replicas of a database. We’re not experts on these systems, but given that RPs will download RPKI data relatively infrequently, is this something that could be considered here? <examples.pdf> _______________________________________________ sidr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
