[NCAP-Discuss] Current Status of the NCAP Project

[James Galvin]

As a reminder, the Recommendations section of the document is incomplete.  That said, I appreciate your helpful suggestions on how to improve what’s there.  Of course, it would be great if you, and any DG member, would contribute text to help us get this done sooner.

Just a few comments inline to your suggestions.



On 4 Nov 2022, at 12:27, Jeff Schmidt via NCAP-Discuss wrote:

> Team:
>
> I have reviewed the current draft and one thing really jumps out:
>
> From this section:
>
>> 6.4 Recommendation X - ICANN should replace the existing Name Collision
>> Management Framework [Merged with 6.X Recommendation X - ICANN
>> should adopt the following name collision process.] “with the recommended
>> Name Collision Risk Assessment Workflow”?
>
> The following sentence, which appears to be the sole justification for the most significant recommendation:
>
>> The findings from the various study reports and the input from responses to the Board
>> questions make it clear that a broader set of actions including PCA and, potentially,
>> ACA are necessary to acquire the Critical Diagnostic Measurements necessary to inform
>> a risk assessment.
>
> In reading the previous 60 pages, this isn't (at all) clear. What is clear is that there are many trade-offs and many competing objectives and opinions. There is no perfect solution.

The DG agrees there is no perfect solution.  What our analysis did was affirm the analyses that were done around the 2012 round and it is why we have adopted the controlled interruption framework that was designed for the 2012 round.  I’m saying framework because the DG has proposed some evolutionary enhancements to the prescribed controlled interruption to achieve at least three objectives.

1. To be responsive to the changes in the DNS infrastructure over the last 10 years.

2. To enhance the notification mechanism based on the fact that the existing mechanism did not achieve its desired objective.

3. To include support for IPv6.


> There is no chance that a reader of this document will be left convinced that "it is clear" that we must do all of these complex, expensive, high-risk, and never before done things like PCA, ACA, etc... especially since our own NCAP Study 1 says exactly the opposite! Casey's latest document highlights the reality of difficult trade-offs and competing objectives.
>
> This is leap not (at all) supported by data, logic, rigorous scientific process, or past experience.

I don’t understand “competing objectives”.  Would you please say more about the objectives you believe are in competition with each other?

>
> In general, I cannot support the current draft that recommends multiple root delegations and honeypots for every applied-for string. I find this approach plainly unnecessary and high-risk to the point of reckless. The risks associated with this path far outweigh the benefits.
>
> (1) Delegating each string to the TRT (presumably a contractor or ICANN itself) *doubles* the number of delegations/root change activities as compared to the previous round. In 2012, .foo was delegated once - to the new .foo registry. This was deliberate to reduce risk and root zone changes. We considered an intermediate delegation (CI being handled by a third party) but intentionally chose against this approach to reduce (re-)delegations. In the currently envisioned process, .foo would be delegated once to the TRT then again to the new .foo registry.
>
> The IANA-Verisign root management process is a low volume process and most requests span calendar weeks. IANA-Verisign processes to do what is envisioned here somehow in "bulk" don't currently exist, so we'd be asking IANA-Verisign to create new processes. Recall from the 2012 round the various "root scaling" research pieces (including one from SSAC and one from RSAC) stated that the "size" of the root zone was less of a concern than the rate of change. The currently envisioned process would *double* the number of root changes. Root zone changes are not zero cost and not zero risk. We better have a darn good reason to *double* the number of changes.

Your criticisms are correct and appropriate for one particular implementation choice of the principles we seek to describe, which is why I, speaking personally, wouldn’t implement it that way.  If I were implementing it I would do one delegation (DNS delegation) to conduct PCA and ACA, and one grant (change of administrative information at IANA) after a “successful” collision assessment.  Thus, the delegation step is the same as it was in the 2012 round and the grant step is an ordinary IANA task as well as being the same as it was in the 2012 round.  Both steps always had to be done; this proposal just does them separately as opposed to together.

Would you be willing to write some text for implementation notes to foster a more efficient choice when it’s time to implement the principles we’re proposing?


>
> (2) Both TLD honeypots of the envisioned variety and the "passive" data collection scheme (delegate and serve a skeleton zone) create enormous risk and uncertainty.

Would you please elaborate on the “enormous risk and uncertainty”?  The proposed workflow uses the same framework as was used in the 2012 round, evolved expressly to have two reduced risk steps before getting to the enormous risk and uncertainty of controlled interruption and equally ACA.



> These things have never been done before (Casey notes SiteFinder is the closest historical analog - and that created massive unintended consequences).

I do not understand what you mean when you say “this has never been done before”.  It’s been said many times before and now three times in this message that we are doing exactly what was done in the 2012 round, only better (as explained elsewhere).

It would help me to understand if you could identify specifically how what is being proposed this time is fundamentally different than what has been done before.  I honestly do not understand.


> Not only do we have the "but for" issue that will subject the operator and ICANN to liability under every conceivable global privacy and cybersecurity framework, there is good reason to worry about the cure being worse than the disease operationally to those impacted.

On the issue of privacy:

It may very well be that there is liability to ICANN or an operator depending on the implementation choice.  Fortunately, we are focused on technical issues and principles.  Nonetheless, speaking personally, as I am quite familiar with privacy regulations around the world I can say with a high degree of confidence there are implementation choices to be made depending on the desired risk appetite.  Again, fortunately, this is an analysis that ICANN legal in cooperation with ICANN technical staff are exceptionally well qualified to evaluate.

In addition, the DG has been quite sensitive to privacy concerns throughout this process.  If you could identify a specific technical choice that’s been made that you believe is contradictory to privacy requirements as you understand them that would certainly inform our discussions further.

On the issue of cybersecurity framework:

Would you please elaborate on what element of which cybersecurity framework (as you know, like privacy, there are quite a few to choice from around the world) you believe is being overlooked in the current proposal?  Speaking personally I’m quite familiar with several and I’m not aware of any fundamental issues.  I’d certainly like to make sure we’re not missing anything.


> Not only would we be causing those impacted to exfiltrate data (what Verisign calls "controlled exfiltration"), we would also change their operational dynamics in ways we don't understand and have zero experience.

It would be helpful if you identify specifically what operational dynamics have been overlooked.  Even better, please contribute text to the document to explain the concerns.  The writing team will be covering the issues that have been discussed as it develops the text and it could use the help.

And, as a factual matter, we do have some experience.  If you could identify the specific element being proposed for which you believe there is “zero experience” that would certainly inform our discussions.



> This is a concern shared by OCTO and some in the DNS-OARC community: "As you discuss in the proposal, all the configurations would represent a change from the current behavior (the root sending authoritative NXDOMAIN replies). Changing this behavior could potentially cause disruption to some systems, so the benefit of this new behavior has to be weighed against the risk of disruption. We note that some in the DNS-OARC technical community have brought up similar issues in their Mattermost discussion system." (OCTO to Matt Thomas, email to NACP List 8/1/2022). Again, we better have a darn good reason to do these things.

I’m sorry but i don’t understand the point you’re making here.  As far as I know we are not doing anything that hasn’t been done before.  Please be specific about what we are overlooking.



>
> Monkeying with the root zone is deadly serious. Verisign has a term I love - they refer to the root as being "unnaturally perfect." When we invented Controlled Interruption, we considered all of this very carefully and ultimately took the absolutely most conservative approach we could think of and tested it extensively. Why 127.0.53.53 and not 127.53.53.53? We found some older Cisco router firmware improperly defaulted localhost to 127/16 instead of 127/8. Why did we specifically recommend against an IPv6 address? We tested everything we could think of: 0::ffff:7f:/104 usually dumped to a default route or tunnel. FC00::/7 and FE80::/10 were unevenly implemented, particularly in Juniper (based on BSD) implementations, and occasionally dumped to a default route. We were extremely, extremely, extremely conservative. We wanted to be *sure* that we wouldn't cause data to leave the host that would not have otherwise.

I am in complete agreement with you.  This is why we are not doing anything that has not been done before.  If would help if you could be specific about what we are overlooking.


>
> I can tell 'ya I was personally nervous to the point of nausea during the first few CI implementations in the 2012 round. There was real risk of something going sideways. We spent months testing everything we could think of. We talked to all the major vendors that would talk to us. We had every imaginable piece of gear in our labs, offices, and basements. We were ready with EBERO-like procedures in case the worst happened; it was a nail-biting experience. Fortunately, it seems to have worked out by any reasonable definition of worked out. We are now at the point where we have a decade and a thousand strings of operational experience with the 2012 procedures; prudence dictates that the bar must be exceedingly high to conjure-up something different.

All of this is still true today.  And it’s why we are not “conjuring up something different”.  It would help if you could be more specific about what element in what is being proposed that is giving you such concern.


Thanks,

Jim


>
> Four years and 100 meetings later, NCAP hasn't come-up with anything that is demonstrably and objectively better. NCAP's own Study 1 says that.
>
> What NCAP has come-up with are a bunch of ideas (most previously considered, exhaustively) and a few folks hoping real hard that these ideas will somehow be better. For an unclear definition of better. In fact, the things being considered have real risk of making things worse both procedurally (by creating quagmire and controversy) and technical/operational impacts to the root, root management processes, and to those end-systems experiencing collisions. I get the real sense that some in this group simply don't recognize the diligence applied a decade ago. There were really good reasons we did the things we did in 2012 and no evidence has emerged warranting the types of dangerous schemes being considered.
>
> Makes zero sense to me. I will likely be submitting a dissenting opinion to be published within NCAP's final work product. Folks interested in contributing to the dissenting opinion please contact me offline.
>
> Thanks,
> Jeff
>
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.