[rssac-caucus] FOR REVIEW: Elements of Potential Root Operators

[Terry Manderson]

Hi Brian,

> On 8 Sep 2016, at 12:08 PM, Brian Dickson <brian.peter.dickson at gmail.com> wrote:
> 
> 
> TL;DR: I disagree that recommending registration in RPKI is harmful, even if it is not necessarily widespread or mature.
> 

Please re-read my email. I'm not saying it is harmful. I'm saying it is premature to place it in the "SHOULD" category without further and thorough analysis.

> I think this needs a bit of pro/con analysis, on what attack vectors exist, what protections are available, and what the uptake is on those protections. 
> The deployment states of both DNSSEC and of RPKI are moving targets, so the pro/con might change over time.
> I am pretty sure that already, they are respectively moving in directions that doesn't affect the following analysis...
> 
> Basically, the choices on the table are RPKI or no-RPKI.

Actually there are several more states than just RPKI or no-RPKI. Those two only represent the ideal (RPKI ubiquitous) world.

> 
> The "target" is, IMHO, anything that can DOS one or more root servers, or anything that can hijack the IP of one or more root servers.

Such as an RIR and their RPKI database and the RPKI repository state? which might then allow an entity to assert a competing ROA that then allows any number of vectors? 

I'm certainly not being all inclusive, my point is that this is not yet well understood in the context of the root server system.

> 
> The value of "hijack" is largely in the ability to do one of two things for DNS traffic: (a) MITM vs DNSSEC-protected traffic, or (b) forge responses vs non-DNSSEC-protected traffic.
> The MITM is only of value for staying in the loop of resolution, until a given resolver passes from signed to unsigned in the DNS tree.
> At the point where all DNS is DNSSEC, hijacking is of no value, vs validating resolvers.
> 

In a world where all resolvers validate and all stub<->resolver exchanges are encrypted (DPRIVE) the option for a MiTM is decreased. One might then say that the routing state is irrelevant so long as the answer that is received is validated. But that is for a later discussion.

> Non-validating resolvers are the low-hanging fruit, as are unsigned zones. This makes hijacking high-value.
> 
> The value of "DOS" (other than nuisance DOS) is hijackers trying to tip the odds in their favor.
> 
> Now consider the actual RPKI content, with respect to root server addresses. 
> Of all the addresses on the Internet, those are likely to be the most stable, in terms of ownership and origin ASN.
> In addition, their single-purpose nature means they are likely to be handled very carefully, if/when any RPKI change for them is necessary.

By its very nature, using RPKI places a significant level of responsibility for the routing/RPKI state of root operators into at most 5 third parties. I'm not saying that is good or bad either way, but I think we need to be honest and critical of that new relationship. What is the agreement structure? What are the remediation and compliance states. Are there grounding service commitments in place?

> 
> Anyone doing OV is likely to cache RPKI, and given the stable nature of root server ROAs, the caches can survive significant RPKI transferral DOS traffic for great lengths of time.
> 
> OV caching increases the "availability surface" (the inverse of "attack surface") by many orders of magnitude. 
> The decentralized nature of caching means that DOS vs the 5 RPKI central repos would only impact RPKI updates, rather than the usability of RPKI itself.
> OV itself, as I understand it, from cache to router, is pretty close to a closed system, assuming any given network operator is doing sensible things.
> 
> RPKI caches are independent, and this is their strength.
> 
> BGP, on the other hand, is inherently dependent; a hijacked route will propagate base on not only topology, but also based on the nature of BGP peering links. (qv route leaks.)
> 
> The failure modes of OV, if they do occur, are likely to look like "damage" to the infrastructure; the route won't pass through the impacted network operator's network. Unless the viewpoint of a given resolver is basically "single homed beneath this network operator", there will be alternate announcements at the ASN level, of the affected root server.
> 
> Combine this with the 13 root servers, and their multitude of anycast instances, and my calculations give the following result:
> 
> The risk (and impact) of hijacking one or more root server addresses, far exceeds the chance of any significant risk of DOS vs RPKI-based OV.
>  

[..]

> 
> For both of these reasons, I believe it is premature for RSSAC to make RPKI an element of a potential root operator without a deeper investigation into the benefits and risks (and scenarios of attack) of RPKI in the context of the root server system and the resiliency expected.
> 
> Is the above analysis sufficient to sway your opinion?
>  

No. Because, and despite your talent, I think this needs a more thorough review before I would see that paragraph pass.

Cheers
Terry