[ksk-rollover] Starting discussion on acceptable criteria for proceeding with the root KSK roll

[Matt Larson]

> On Jan 5, 2018, at 1:25 PM, Paul Wouters <paul at nohats.ca> wrote:
> 
> At the time, there were no statistics to base and decision on. We have
> some now from Sep 2017. It would be nice to get more. I understand ICANN
> was also trying to find out more and hired people to do so. What
> happened to that effort? Do we have new data? Do we have new sources of
> bad behaviour (eg software versions, OS versions, other issues?). Have
> we ruled out any software design/deployment issues?

>From https://www.icann.org/news/blog/update-on-the-root-ksk-rollover-project (18 December 2017):

> Since then, we have attempted to contact the operators of 500 addresses that had reported a resolver configuration with only KSK-2010 instead of the correct configuration of both KSK-2010 and the new KSK, KSK-2017. Ideally, that investigation would have revealed a set of clear causes for the improper configuration, allowing further communication and actions to be targeted at addressing those specific issues. But in the end, the analysis was not as conclusive as we would have hoped.
> 
> In our initial attempt, we received a response from operators of approximately 20% of the 500 addresses. Of those addresses whose operators we could contact, 60% came from address ranges known to host devices with dynamic addresses, such as routers of home broadband users and ephemeral virtual machines, making these resolvers extremely difficult (if not impossible) to track down. About 25% of the addresses corresponded to a resolver forwarding on behalf of another resolver that was reporting only KSK-2010. Since the address of the device reporting the incorrect configuration was not the actual source resolver, it is extremely difficult (if not impossible) to identify the true source address of the resolver that was reporting only KSK-2010.

Not surprisingly, tracking down operators of individual IP addresses is hard and, of those we could contact, there is no smoking gun.

Your questions are reasonable and I'm realizing that we can and should publish the report of the contractor we engaged to try to reach those 500 addresses, which will show the unfortunate lack of smoke.

Now that we've gotten about as far as we can on our own with that line of investigation, we're starting to enlist the help of the ISPCP and RIRs, whom we've previously reached out to and who have expressed a willingness to help. We'll be sending them the specific IPs to see whom they can track down and what they can find.

I continue to believe what we reported back in September as the reason for the rollover postponement: we need to understand whatever signal there is in the RFC8145 trust anchor reports better to know how to proceed. But I'm open to suggestions: that's why we want to have this discussion. 

> If we are waiting on more data, lets finish with the data. If we are not
> gathering more data, then there isn't any point in waiting.

We're still gathering data. ICANN has RFC8145 data from eight root server letters now (with more hoped for). We're at this moment preparing an update of what we've seen since September and will have that within a couple weeks, hopefully sooner.

Matt