Re: [sidr] a new direction for draft-ietf-sidr-multiple-publication-points

[Sharon Goldberg <[e-mail]>]

This is probably a little late, but I support this plan.

Sharon


On Tue, Dec 17, 2013 at 11:17 AM, Murphy, Sandra
<[e-mail]>wrote:

>  No replies, so the authors should proceed as suggested.
>
>  --Sandy, speaking as co-chair
>  ------------------------------
> *From:* sidr [[e-mail]] on behalf of Murphy, Sandra [
> [e-mail]]
> *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:* [e-mail] [[e-mail]] on behalf of Roque
> Gagliano (rogaglia) [[e-mail]]
> *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) <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>
>


-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe