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

[Brian Dickson]

In-line reply, speaking only for myself (as an ordinary caucus member, of
course):

On Wed, Sep 7, 2016 at 5:26 PM, Terry Manderson <terry at terrym.net> wrote:

> Caucus,
>
> Speaking as just a caucus member,
>
> I am very concerned about section 3.3.7
>
> =-=-=-=-=-=-=
> 3.3.7 Address Registries
>
> The candidate operator’s address space SHOULD be registered in one of the
> Regional Internet Registry (RIR) public databases. The candidate SHOULD
> have entries in relevant public routing registries, and if possible Route
> Origin Authorization (ROA) objects in relevant Resource Public Key
> Infrastructure (RPKI) registries for their IPv4 and IPv6 address space.
> =-=-=-=-=-=-=
>
> I fully understand what RPKI (and BGPSEC) are meant to do, and I applaud
> that effort. However in this context My concern comes from two directions:
>

As I understand it, RPKI is also used by Origin Validation (OV) stuff. (I'm
not overly familiar with OV, beyond that it is used in some manner to
ensure the correct ASN appears to originate the route.)


>
> 1) Looking at the diversity principle, any thus by extension, we have
> currently exactly 5 regional internet registries (and no more on the
> horizon) for currently 12 operators. So in effect if all operators adopt
> the SHOULD we are reducing the attack vector diversity for a key component
> of operating a root server.
>

TL;DR: I disagree that recommending registration in RPKI is harmful, even
if it is not necessarily widespread or mature.

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.

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.

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.

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.

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.


>
> 2) The RPKI and BGPSEC is fairly well thought out, however I don't believe
> there is depth of experience there yet.
>
> 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?


>
> Cheers
> Terry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20160907/17ad72f3/attachment.html>