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