Warren Kumari
Warren Kumari is Director of Internet Standards.
He currently serves as an Internet Engineering Task Force (IETF) Operations and Management Area Director. He has previously chaired the CAPPORT, DPRIVE,DANE, OpsAWG and OpSec Working Groups in the IETF, and also co-chairs the Internet Engineering and Planning Group (IEPG). He is also active in ICANN, serving on the Security and Stability Advisory Committee (SSAC), Root Server System Advisory Committee (RSSAC) and also served as the IAB appointed representative to the ICANN Technical Liaison Group.
Authored Publications
Sort By
SAC123 - SSAC Report on the Evolution of Internet Name Resolution
Internet Corporation for Assigned Names and Numbers (ICANN) , ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2023), pp. 36
Preview abstract
New technologies are changing how name resolution happens on the Internet. The DNS remains the prominent, or default, naming system for the Internet, but alternative naming systems are in use as well. This is nothing particularly new, as there have always been naming systems besides the DNS in use throughout the Internet’s history. These alternative naming systems use the same syntax as the DNS, dot-separated labels. There are many motivations for copying this syntax, but the primary reason is because designers of these alternative naming systems wish to benefit from the existence of software applications built to receive DNS names as input.
This has the potential to create situations where the same name exists in DNS and in an
alternative system, potentially causing name collisions. However, there is only one domain
namespace and its referential integrity is important for Internet users and for the stability and
security of Internet names. Thus, as alternative naming systems increase in popularity their use
threatens to increase ambiguity in the shared single domain namespace. This increased ambiguity in Internet naming threatens to undermine the trust that users have in Internet identifiers and the services that rely on them.
Additionally, names are becoming less visible to Internet end users, yet they remain vital to the
security and stability of Internet infrastructure. Technologies such as QR codes and URL
shorteners offer great utility to Internet users while also obscuring the underlying domain names used and creating new opportunities for malicious behavior. Meanwhile, QR codes and URL shorteners use domain names to access the Internet resource, even if the human user does not see it.
These are the two main trends that the SSAC identifies in this report. The same name can resolve in different ways (ambiguous name resolution), and names of service endpoints are less visible (names are less conspicuous to end users). It is the combination of these two trends that fundamentally threatens to undermine confidence in services on the Internet.
View details
SAC122 - SSAC Report on Urgent Requests in the gTLD Registration Data Policy
Internet Corporation for Assigned Names and Numbers (ICANN) , ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2023), pp. 14
Preview abstract
This paper examines the process that led to the proposed language for Urgent Requests and
asserts the following questions should be asked if the same or similar requirements for
processing special requests are pursued in the future.
● What is known about the need for special requests? Is there documentation of the
frequency, urgency, source and outcomes of requests of this type?
● Is the rationale for creating a separate process for these special requests fully specified,
well defined, and accepted by all parties?
● Is the proposed special process fit for purpose? (i.e., Will the resulting policy or
implementation accomplish its stated purpose?)
This paper concludes with three recommendations. The first recommendation adds additional
structure so that Urgent Requests will be handled in an appropriately expedited fashion. The
second recommendation requests that the response time policy for Urgent Requests be fit for
purpose. Finally, the third recommendation requests ICANN org begin gathering data on Urgent
Requests and make it available to the community to inform future policy making efforts.
View details
Preview abstract
This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces.
View details
SAC121 - SSAC Briefing on Routing Security
Tim April
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2022), pp. 36
Preview abstract
Like all other Internet applications, the Domain Name System (DNS) depends on the Internet’s
routing system, which controls the data paths across the Internet’s more than 70,000
autonomously managed networks. A longstanding problem with the routing system is that its key protocol, the border gateway protocol (BGP), does not protect against incorrect routing
information. BGP was designed in the late 1980’s and early 1990’s when the Internet consisted
of only a few hundred networks that all trusted one another. As the Internet grew and the number of networks increased, the number of routing incidents increased and this implicit
trustworthiness waned. The routing system today is subject to a continuous stream of routing
anomalies that affect its integrity and that sometimes cause large DNS outages. For example, in April of 2018 attackers were able to “hijack” routes to Amazon’s Route53 DNS services, which
resulted in DNS traffic for domains hosted on this service ending up at a different destination
network where it was served by malicious DNS servers.
In this report, the SSAC discusses events like these and what impact similar incidents can have
on the DNS, surveys the pros and cons of various solutions, and discusses future security
extensions of the routing system (e.g., path validation). The main focus of this report is on the
security and stability implications for the DNS, although most of it also applies to other types of
Internet applications (e.g., email, web, media streaming).
This report provides a tutorial-style discussion accessible to non-technical members of the
ICANN community and elsewhere (e.g., policy makers and legal experts). It does not contain
any recommendations to the ICANN Board. Because this report is intended to be understandable to a non-technical audience, it sometimes simplifies technical details that are not relevant to the discussion.
View details
SAC118 - SSAC Comments on Initial Report of the EPDP on the Temporary Specification for gTLD Registration Data
Steve Crocker
Tara Whalen
Ben Butler
Greg Aaron
Benedict Addis
James Galvin
Robert Guerra
Julie Hammer
Merike Käo
John Levine
Danny McPherson
Rod Rasmussen
Mark Seiden
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN)(2021), pp. 11
Preview abstract
In this document the SSAC presents both general comments about the overall Expedited Policy
Development Process and specific comments on individual recommendations in the EPDP 2A
Initial Report.
View details
SAC117 - Report on Root Service Early Warning Systems
Joe Abley
Jaap Akkerhuis
Tim April
Patrik Fältström
James Galvin
Julie Hammer
Geoff Huston
Russ Mundy
Rod Rasmussen
Matthew Thomas
Suzanne Woolf
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN)(2021), pp. 22
Preview abstract
The concept of an early warning system for the root zone comes originally from the Root Scaling Study Team and TNO Reports, both published in 2009. Since then the concept has evolved away from an original intention of modelling the potential impact on the operation of the root service with the addition of
internationalized domain names (IDNs), IPv6, and new gTLDs to the root zone into a concept
that is intended to provide feedback about the operational stability of the root service as more
gTLDs are added to the root zone.
In reviewing these publications, the SSAC came to the conclusion that an early warning system
for the root zone is currently infeasible, as was also concluded by OCTO-15. The root zone
system is highly complex, and our current understanding of it does not allow us to predict
imminent failure within its conventional and conservative operational parameters. This however,
should not take away from efforts to better understand and gather data on the root server system,
which root server operators are collecting, as described in RSSAC002 and RSSAC047.
View details
RFC 9092 - Finding and Using Geofeed Data
Randy Bush
Massimo Candela
Russ Housley
IETF Request For Comments, RFC Editor(2021), pp. 21
Preview abstract
This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.
View details
SAC115 - SSAC Report on an Interoperable Approach to Addressing Abuse Handling in the DNS
Greg Aaron
Benedict Addis
Lyman Chapin
kc Claffy
John Levine
Mark Seiden
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, SSAC115(2021), pp. 39
Preview abstract
There are many ways to define the term “DNS Abuse” including, abuse of the protocol itself,
abuse of the DNS infrastructure, using the DNS as a supporting service for some other abuse,
and the use of domain names themselves in an abusive manner. In this report, the SSAC focuses
on cases where domain names themselves are used in an abusive manner. These are often
colloquially referred to within the ICANN community as “technical abuses”, which generally
refer to abuses spelled out in ICANN’s registry agreements in Specification 11.3 (b) and that have been the focus of many community discussions from 2018-2020.
In general, the term “DNS abuse” in this report refers to the use of domain names, or the DNS system, to perpetuate abusive activities. Abuse on the Internet continues to victimize millions annually,
reducing trust in the Internet, including the DNS, as a place to conduct commercial and non-commercial
activities. This erosion of trust negatively impacts all parties in the Internet ecosystem, from endusers to infrastructure service providers.
In this report, the SSAC proposes a general framework of best practices and processes to
streamline reporting DNS abuse and abuse on the Internet in general. This effort is focused on
determining approaches and methodologies that could ultimately reduce the severity and
duration of victimization for end-users. This report focuses on one specific area of the DNS
abuse lifecycle, namely abuse handling. Other topics in the space, including, but not limited to,
prevention, mitigation methods, and education may be explored in future SSAC work. This
report is intended to be of benefit to the victims of DNS abuse, reporters of DNS abuse, and to
those responsible for identifying and remediating DNS abuse.
View details
RSSAC056 - RSSAC Advisory on Rogue DNS Root Server Operators
Ken Renard
Abdulkarim Oloyede
Barbara Schleckser
Brad Verd
Di Ma
Duane Wessels
Fred Baker
Hiro Hotta
Jaap Akkerhuis
Jeff Osborn
Kazunori Fujiwara
Kevin Wright
Mallory Knodel
Marc Blanchet
Nicolas Antoniello
Paul Hoffman
Paul Muchene
Peter DeVries
Russ Mundy
Shinta Sato
Wes Hardaker
Yazid Akanho
ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN)(2021), pp. 8
Preview abstract
In this report, the ICANN Root Server System Advisory Committee (RSSAC) examines both measurable and subjective activities of a root server operator (RSO) that could be considered rogue to inform future Root Server System (RSS) governance bodies. Future RSS governance bodies may use this document to develop a more complete definition of rogue RSO actions and will ultimately be the authority in determining subjective factors such as intent, when judging the actions of a RSO. The audience of this report is the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN), future root server system governance bodies, and, more broadly, the Internet community
View details
SAC114 - SSAC Comments on the GNSO New gTLD Subsequent Procedures Draft Final Report
Lyman Chapin
KC Claffy
James Galvin
Julie Hammer
Geoff Huston
Merike Kaeo
Barry Leiba
Ram Mohan
Rod Rasmussen
Suzanne Woolf
ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2021), pp. 31
Preview abstract
The SSAC makes the following comments and recommendations. For the full and
official recommendations see Section 4 of this publication.
● First, the SSAC believes that the introduction of more gTLDs to the root namespace is
not consistent with ICANN’s mission and commitment to keep the Internet secure, stable,
and interoperable. The fundamental question from the SSAC’s security and stability
perspective is whether adding more generic top-level domains (gTLDs) to the root
namespace should remain a primary response to furthering the overall objectives of
ICANN, namely “keeping the Internet secure, stable and interoperable. [ICANN]
promotes competition and develops policy on the Internet's unique identifiers.”2 This
comment is not a criticism of the Final Report or the community effort, but the SSAC
thinks now is a good time for the ICANN Board to address this question.
The SSAC recommends that the ICANN Board initiate a fundamental review to
determine whether continuing to increase the number of gTLDs is consistent with
ICANN’s strategic objective to “evolve the unique identifier systems in coordination and
collaboration with relevant parties to continue to serve the needs of the global Internet
user base.”3 This review should be considered an input towards updating ICANN’s
strategic goals in conjunction with implementing the CCT Review Team’s
recommendations (see Recommendation 1).
● Second, given a general intent to proceed with this program in any case, there is a clear
need to add greater levels of not only process oversight, but also a systemic consideration
of the program’s impact, attendant risks and appropriate mitigations to the DNS itself.
The systemic considerations would include addressing, monitoring and mitigating
impacts on the entire DNS resolution chain (e.g., root servers, DNS recursive resolver
performance) and services that provide and/or are dependent upon it.
In addition, numerous items relating to risks, outcomes, and impacts of increasing the
gTLD namespace need to be measured and analyzed to better understand some of the
fundamental questions considered by the Working Group as well as areas it did not
explore. The SSAC agrees with the measurements proposed by the Working Group
Recommendations 7.1 - 7.5 and suggests additional goals and measurements.
The SSAC recommends that, as part of the process for creating new gTLDs, ICANN
develop and adopt a protocol for measuring progress against stated goals of the program
and thresholds, which if crossed, may require mitigation actions. Such measurements and
actions should consider the entirety of the DNS ecosystem (see Recommendation 2).
● Third, on the issue of DNS abuse, while the SSAC agrees that a holistic approach to DNS
abuse issues has merit, we note that security threats and attendant abuse of the DNS
remain a constant and rapidly evolving challenge, and that ICANN recognizes “Domain
name abuse continues to grow” as a Strategic Risk to the achievement of its Strategic
Objectives. Waiting until efforts to mitigate DNS abuse can be equally applied to all
existing and new gTLDs effectively cedes the ground to malicious actors who can depend
upon a long policy development process to hinder meaningful anti-abuse measures.
The SSAC recommends that the ICANN Board, prior to launching the next round of new
gTLDs, commission a study of the causes of, responses to, and best practices for the
mitigation of the domain name abuse that proliferates in the new gTLDs from the 2012
round. This activity should be done in conjunction with implementing the CCT Review
Team’s relevant recommendations. The best practices should be incorporated into
enforced requirements, as appropriate, for at least all future rounds (see Recommendation
3).
View details
