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
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
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
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
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
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
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
RFC 9098 - Operational Implications of IPv6 Packets with Extension Headers
Fernando Gont
Nick Hilliard
Gert Doering
Geoff Huston
Will (Shucheng) Liu
IETF Request For Comments, RFC Editor(2021), pp. 17
Preview abstract
This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension
headers are often dropped in the public Internet.
View details
RFC 8976 - Message Digest for DNS Zones
Duane Wessels
Piet Barber
Matt Weinberg
Wes Hardaker
IETF Request For Comments, RFC Editor(2021), pp. 31
Preview abstract
This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.
As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.
View details
RFC 9119 - Multicast Considerations over IEEE 802 Wireless Media
Charles E. Perkins
Mike McBride
Dorothy Stanley
Juan Carlos Zúñiga
IETF Request For Comments, RFC Editor(2021), pp. 22
Preview abstract
Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi)
and other local-area wireless environments. This document describes the known limitations of
wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement
features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some
operational choices that can be made to improve the performance of the network. Finally, some
recommendations are provided about the usage and combination of these features and
operational choices.
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
