POSTS TAGGED: icann

IANA 2.0: Ensuring ICANN Accountability and Transparency for the Future

Keith Drazek | Jun 25, 2014

The National Telecommunications and Information Administration’s (NTIA) March 14, 2014, announcement proposing the transition of its legacy Internet Assigned Numbers Authority (IANA) stewardship role has presented the Internet Corporation for Assigned Names and Numbers (ICANN) multi-stakeholder community equal amounts of opportunity and responsibility. We have been handed a singular opportunity to define the terms of any stewardship transition and the fundamental responsibility to get it right.

Getting it right means ensuring, through a bottom-up, multi-stakeholder process, the reform of ICANN’s accountability structures to protect the community and the multi-stakeholder model prior to NTIA’s disengagement from its oversight and stewardship role. It also means acting quickly and efficiently so our window of opportunity is not missed.

At ICANN’s 50th meeting taking place in London this week, some have suggested that there are “elements” or “forces” among us who oppose the IANA stewardship transition and that calls for accountability reform are tantamount to delay tactics. I have found the opposite to be true. There is significant community support for NTIA’s announcement. There is significant support for NTIA’s four key principles. There is universal support for initiating a bottom-up, multi-stakeholder process to develop a recommended transition plan for NTIA’s consideration. The community also recognizes our limited time to get the work done and the need to propose concrete and implementable enhancements. And, perhaps most importantly, there’s a rapidly growing and strong consensus that ICANN’s accountability reform is a key dependency for any successful IANA stewardship.

On March 24, 2014, at the 49th ICANN meeting in Singapore, Verisign’s Pat Kane, senior vice president of Naming and Directory Services, made the following statements in support of the NTIA announcement, accountability and the multi-stakeholder process:

  • Verisign recognizes that it is probably the right time to transition the IANA functions and stewardship of those functions away from the United States government.
  • Verisign further recognizes that the ICANN community is ready to begin the conversation and its multi-stakeholder, bottom‐up structures have matured and will be the means by which a proposed solution for the transition is developed for continued operations of the IANA functions.
  • We support ICANN as the convener of this process as we find solutions for the clerical, authorizing, and technical operations of IANA which are all tied to accountability to the community.
  • The accountability regime that replaces the NTIA's stewardship should ensure enforceable and auditable transparency and accountability mechanisms. The DNS community and the global business and user communities deserve no less as such mechanisms are critical to the functioning of an open and secure Internet for everyone.
  • We look forward to contributing to the process and the proposed solution.
Those comments were made almost exactly three months ago.  To eliminate any uncertainty around Verisign’s position on the issues of IANA Stewardship Transition and ICANN Accountability, I will take this opportunity to dispel any question or misinformation and reaffirm our views:

  • Verisign supports NTIA’s March 14, 2014, announcement;
  • Verisign supports NTIA’s four key principles;
  • Verisign supports the bottom-up, multi-stakeholder process now under way;
  • Verisign supports the target date of September 2015 for transition;
  • PROVIDED the multi-stakeholder community recommendations for ICANN’s accountability reform are accepted by NTIA before the final transition and sufficiently implemented by ICANN subject to measurable deliverables.
Read more

The Real Uneven Playing Field of Name Collisions

Burt Kaliski | May 06, 2014

Recent comments on the name collisions issue in the new gTLD program raise a question about the differences between established and new gTLDs with respect to name collisions, and whether they’re on an even playing field with one another.

Verisign’s latest public comments on ICANN’s “Mitigating the Risk of DNS Namespace Collisions” Phase One Report, in answering the question, suggest that the playing field the industry should be concerned about is actually in a different place. The following points are excerpted from the comments submitted April 21.

In a previous comment, Eric Osterweil summarized key differences between established and new gTLDs as they affect name collision risks.  Namespaces associated with established TLDs, he observed, represent “well known and measurable real estate” that system administrators can plan for.  In contrast, namespaces associated with applied-for strings including new gTLDs, Osterweil continued, “inherently have no well-known policies and structure” – other than the assumption that they weren’t expected to be delegated in the future foreseeable to system administrators.

Osterweil’s points are important to keep in mind, because they apply just as much to one of the comments in this public review period as they did to comments in the previous period.

A better understanding of the situation starts with clear definitions.  A name collision occurs when one system assumes that a name is in one name space, another system assumes that the name is in another name space, and the two systems interact unaware of their difference in assumptions.  One of the reasons they may not be aware is that the assumptions of both systems were historically the same, and then the assumptions of one of the systems changed.

ICANN’s Security and Stability Advisory Committee (SSAC) expresses the definition as follows in SAC062:

“The term ‘name collision’ refers to the situation in which a name that is properly defined in one operational domain or naming scope may appear in another domain (in which it is also syntactically valid), where users, software, or other functions in that domain may misinterpret it as if it correctly belonged there.”

With this definition in mind, it’s useful to highlight two situations that are not the same as name collisions.

Read more

Verisign’s Preliminary Comments on ICANN’s Name Collisions Phase One Report

Burt Kaliski | Apr 16, 2014

Verisign posted preliminary public comments on the "Mitigating the Risk of DNS Namespace Collisions" Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS.  However, there is still much work to be done.

Below, I have outlined the four main observations from ICANN’s "Mitigating the Risk of DNS Namespace Collisions" Phase One Report discussed in Verisign’s public comment along with recommendations:

Read more

Proceedings of Name Collisions Workshop Available

Burt Kaliski | Mar 26, 2014

Presentations, papers and video recordings from the name collisions workshop held earlier this month in London are now available at the workshop web site, namecollisions.net.

The goal for the workshop, described in my “colloquium on collisions” post, was that researchers and practitioners would “speak together” to keep name spaces from “striking together.”  The program committee put together an excellent set of talks toward this purpose, providing a strong, objective technical foundation for dialogue.  I’m grateful to the committee, speakers, attendees and organizers for their contributions to a successful two-day event, which I am hopeful will have benefit toward the security and stability of Internet naming for many days to come.

Keynote speaker, and noted security industry commentator, Bruce Schneier (Co3 Systems ) set the tone for the two days with a discussion on how humans name things and the shortcomings of computers in doing the same.  Names require context, he observed, and “computers are really bad at this” because “everything defaults to global.”  Referring to the potential that new gTLDs could conflict with internal names in installed systems, he commented, “It would be great if we could go back 20 years and say ‘Don’t do that’,” but concluded that policymakers have to work with DNS the way it is today.  

Bruce said he remains optimistic about long-term prospects as name collisions and other naming challenges are resolved:  “I truly expect computers to adapt to us as humans,” to provide the same kind of trustworthy interactions that humans have developed in their communications with one another.

Read more

Uncontrolled Interruption? Dozens of “Blocked” Domains in New gTLDs Actually Delegated

Burt Kaliski | Feb 26, 2014

The Mitigating the Risk of DNS Namespace Collisions report, just published by JAS Global Advisors, under contract to ICANN, centers on the technique of “controlled interruption,” initially described in a public preview shared by Jeff Schmidt last month.

With that technique, domain names that are currently on one of ICANN’s second-level domain (SLD) block lists can be registered and delegated for regular use, provided that they first go through a trial period where they’re mapped to a designated “test” address.  The staged introduction of new SLDs is intended to provide operators of installed systems the opportunity to assess the potential impact of an impending name collision on their own, before any external operators have an opportunity to exploit it.

The new technique is subject to a public comment period before being adopted (including discussion at the upcoming Name Collisions Workshop).  However, if this technique (or any other) were adopted, it would stand to reason the staged introduction would need to be monitored carefully.  Someone would need to check that SLDs on the block lists actually did go through the trial period, and were not put into regular use without the appropriate opportunity for assessment by operators of installed systems.

(Note that Verisign isn’t endorsing the technique; we are reviewing the just-published Mitigating the Risk of DNS Namespace Collisions report, and we’ve already expressed reservations about the statistical invalidity of SLD block lists as an indicator of name collision risk.  That being said, the point still remains that if such a technique were adopted, it would need to be monitored to ensure correct implementation.)

Given the anticipation of “controlled” interruption, it’s ironic that while ICANN specifically precludes the delegation of domain names on the SLD block lists, dozens of them were actually registered and delegated!

That fact was recently duly noted by one of Verisign’s researchers who has been analyzing the daily progress of new gTLDs.  As it turns out, nearly all delegated SLDs that should have been blocked were cancelled over the past weekend after independent reports citing the existence of inappropriate delegations began to circulate.

That the delegations of SLDs on the block lists could have caused name collisions with installed systems is not our primary concern.  (And, as noted above, we don’t consider the block lists – which are based solely on query frequency at specific points in time – to be the final word on which delegations might or might not cause name collisions.  As our chief security officer Danny McPherson has well explained in one of his blog posts, “Query frequency data without query context isn’t enough.”)

Our concern, rather, is that domain names on the SLD block lists were delegated at all, given ICANN’s clear direction to the contrary.  As Pat Kane and I have noted in a broader-ranging letter to NTIA on operational miscues in the new gTLD delegation process, a policy that’s unenforced is worse than no policy at all.

If this is the state of affairs when the answer is “no” – effectively, a state of “uncontrolled interruption” – what happens when the answer changes to “wait 120 days”?