Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points

From: Sharon Goldberg <[email-masked]>
Date: Tue, 1 Oct 2013 17:12:56 -0400

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?

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 2 Oct 2013 07:58:28 +0000

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.
> (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>

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 14 Oct 2013 19:41:12 +0000

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-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Oct 2013 13:40:01 -0400

Roque,

I support your proposal to revise the doc to address only the TAL case.

Steve

---

From: Arturo Servin <[email-masked]>
Date: Tue, 15 Oct 2013 17:05:09 -0200

Sounds like a good way forward.

/as