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), 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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
