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
RFC 9632 - Finding and Using Geofeed Data
RFC Editor, RFC Editor(2024), pp. 23
Preview abstract
This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092.
View details
SAC126 - DNSSEC Delegation Signer (DS) Record Automation
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2024), pp. 39
Preview abstract
The deployment of Domain Name System (DNS) Security Extensions (DNSSEC) has been
hindered by a number of obstacles. This report focuses on one: the management of Delegation
Signer (DS) records, which connect a child zone’s DNSSEC public key and signatures to the
chain of trust provided by its parent zone (e.g., a zone corresponding to a top-level domain).
DNSSEC is not simply enabled by signing a delegated domain’s DNS zone with DNSSEC
signatures. It is also necessary to configure (and later maintain) appropriate DS records, which
involves coordinated actions by the DNS operator, registrant, registrar, and registry.
In the case where the domain’s DNS service is operated by the registrar, this process can be
reduced to a simple internal operation by the registrar. If the functions are separated, this is not
possible. This report is therefore focused on when the domain’s DNS service is not operated by
the registrar, but by a third-party DNS operator.
In such a scenario, current practice holds the registrant responsible for coordinating DS
maintenance. The registrant (or someone appointed by them) needs to first obtain DNSSEC
public key parameters from the DNS operator, and convey these parameters to the registrar
(potentially via a reseller). The registrar will then need to relay these DNSSEC public key
parameters to the registry, who will use them to create and publish the DS record in the parent
zone. This process often involves idiosyncratic interfaces for each combination of DNS operator
and registrar, requiring a level of engagement and time investment, awareness, and
understanding that often do not match with what the registrant knows or expects. The complexity of the process further introduces opportunity for error.
This can be alleviated by employing automation for the data exchanges required for DS
maintenance so that, when the domain’s DNS service is operated by a third party, registries or
registrars can, without human involvement, obtain all information needed for keeping DS records up to date. Various approaches to achieve this are possible, such as a scheme where the registry or registrar actively contacts the Child DNS operator, or vice versa. The different approaches come with different challenges with respect to authentication, timing, and efficiency.
The IETF has standardized specifications around the first approach, where the parent pulls
information from the Child DNS operator, and operational experience has been gained over
recent years. However, some standardization gaps remain (such as to improve efficiency and
error handling). In addition, the industry could benefit from further development of best practices in deploying the technology.
The SSAC believes that automated DS maintenance should be a goal for the domain name
industry. To make this a reality, the SSAC makes several recommendations with the goal to spur
industry players and ICANN towards an industry best practice for DNSSEC DS automation.
View details
SAC125 - SSAC Report on Registrar Nameserver Management
Gautam Akiwate
Tim April
kc claffy
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2024), pp. 56
Preview abstract
During domain registration, a minimum of two nameservers are typically required, and this
remains a requirement for any future updates to the domain. Often, domains are delegated to
nameservers that are subordinate to some other domains, creating inter-domain dependencies.
This network of dependencies creates a scenario where the functionality of a domain depends
on the operational status of another domain. This setup lacks contractual or procedural
safeguards against disruption or misuse, especially when the nameserver parent domain expires.
Most registries forbid deleting an expired domain if other domains depend on it for name
resolution. These constraints aim to prevent disruptions in DNS resolution for the dependent
domains. However, this also means that the expired domain remains in a liminal state, neither
fully operational nor completely removed. When registrars cannot delete expired domains with
dependents, they are forced to bear the burden of sponsoring the domain without remuneration
from the registrant. A peer-reviewed study, "Risky BIZness: Risks derived from Registrar Name
Management," observed that some registrars have found and utilized a loophole to these
constraints by renaming the host objects that are subordinate to the expiring domain.1 Once
renamed, the host objects are what Akiwate et al.—and subsequently the SSAC—refers to as
sacrificial nameservers.
This report focuses on a specific type of sacrificial nameserver where the parent domains of the renamed host objects are considered to be unsafe because they are registrable. Registrable
parent domains of sacrificial nameservers introduce a new attack surface for domain resolution
hijacking, as malicious actors can exploit unsafe sacrificial nameservers to gain unauthorized
control over the dependent domains, leading to manipulation or disruption. Unlike traditional
domain hijacking techniques that exploit compromised account credentials or manipulate the
resolution protocol, this report focuses on this unforeseen risk arising from a longstanding
practice employed by some registrars.
In this report, the SSAC explores potential solutions to remediate exposed domains and prevent
the creation of new unsafe sacrificial nameservers. The SSAC examines each proposed solution for its feasibility, effectiveness, and potential to reduce the attack surface without introducing undue complexity or new vulnerabilities into the DNS ecosystem.
View details
SAC124 - SSAC Advice on Name Collision Analysis
Internet Corporation for Assigned Names and Numbers (ICANN), ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories(2024), pp. 15
Preview abstract
In this document the Security and Stability Advisory Committee (SSAC) provides its analysis of
the findings and recommendations presented within the Name Collision Analysis Project
(NCAP) Study Two and the proposed Name Collision Risk Assessment Framework. The SSAC
also provides additional commentary on several aspects of the NCAP Study Two Report and
makes recommendations to the ICANN Board.
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
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
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
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 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
