This is probably a little late, but I support this plan. Sharon
On Tue, Dec 17, 2013 at 11:17 AM, Murphy, Sandra <[email protected]>wrote: > No replies, so the authors should proceed as suggested. > > --Sandy, speaking as co-chair > ------------------------------ > *From:* sidr [[email protected]] on behalf of Murphy, Sandra [ > [email protected]] > *Sent:* Thursday, December 05, 2013 8:05 PM > *To:* Roque Gagliano (rogaglia); sidr wg list > *Subject:* [sidr] a new direction for > draft-ietf-sidr-multiple-publication-points > > 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]> > 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] > https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
