[rssac-caucus] Best Practices for the Distribution of Anycast Instances of the Root Name Service WP Conclusion

[Fred Baker]

On Feb 5, 2018, at 5:29 PM, Terry Manderson <terry at terrym.net> wrote:
> I have some concerns about "Recommendation 3: RSOs should consider the value of certifying their resources through the RPKI, as a potential way to assure route origin authenticity in the future"
> 
> I believe it is premature for the RSSAC to recommend that the RSOs consider the future use of RPKI. I think the RSSAC caucus itself should first consider if the RPKI is at a maturity level for use by root server operators in so much as evaluating the standards maturity, operational processes and resiliency of RPKI operators, diversity of RPKI repositories, and diversity of certification organisations in so far as having all resources of all root server operators vested with (currently) 3 RIR organisations.

I gather you're not a true believer :-)

I would comment that there are two sides to RPKI deployment from the perspective of someone implementing it (and a third at the RIR). One is signing one's advertisements with a key registered with one's favorite RIR; the other is deciding whether or not to believe routes that are not signed, or are incorrectly signed.

I would suggest that creating and registering a suitably-signed key (not self-signed; I would think it needs to be signed at least by the RIR it is registered with and by the organization that will be advertising it, and in a perfect world, I would hope it's also signed by each of the companies it is to be advertised to), and then signing advertisements as they are sent, is something every BGP-speaker can and should do today. RPKI makes no sense unless it is highly probable that a party can receive advertisements and verify them in fact receives them, which implies that they have been sent. Thinking in terms of a rant chart, if every completion point on the chart is gated by an initial event, moving this initial event moves the entire thing, and "it's not yet good enough" is a self-fulfilling prophecy.

Over time, and this is not necessarily instant, the BGP speaker that is signing its advertisements needs to also be verifying the advertisements it receives. Again, "it's not yet good enough" will be a self-fulfilling prophecy if nobody is checking whether it's delivering the data needed.

The final step is the introduction of a policy on the part of the individual organization that it will treat advertisements differently and perhaps ignore them depending on whether they are correctly signed. That, I would argue, is down the road a way.

I might suggest a modified policy, however. This is more complex, but it may in the end be more manageable. I would suggest that each advertisement an organization receives is either not signed, signed but incorrectly (wrong key, invalid, or something), or correctly signed. When any BGP speaker starts advertising their signed route, I suspect that there will be fits and starts - it is signed, there is a fault, it is changed, la-de-da, and finally it stabilizes. A signed advertisement is only useful for policy once it has stabilized. So...

I might suggest that there be a per-advertisement state machine. Advertisements have never been correctly signed, they are somewhere in the process of stabilizing, or they are stable. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and it is not correctly signed, I apply the same policy I do today. If I receive an advertisement that I consider to be in the first state (never been correctly signed) and receive a correctly-signed advertisement (which includes accessing the PKI and verifying the signature), I move it to the second state (stabilizing) and continue to apply the policy I do today. In the second state, though, I note what the sender appears to do - they might come and go, change the key, fumble, or other things, and I note the timestamp and the event. At a point at which the provider has decided to trust RPKI for some subset of its routing AND the given advertisement has been consistently correctly signed for mumble time units, and <LOCAL POLICY> says to do so, the advertisement is moved to the third state - stable.

When the advertisement has been deemed to be stable, I trust validly signed advertisements, both positive and negative, and I ignore anything else.

What I might be interested to hear from the caucus is, first, whether they would recommend a similar approach, or whether they have a better idea, and second, whether the software that implements that it stable and usable. In the event of a "yes", I might expect a recommended game plan, which might be a link to a web page.