Jump to Content
Warren Kumari

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
Google Publications
Other Publications
Sort By
  • Title
  • Title, desc
  • Year
  • Year, desc
    RFC 9476 - The .alt Special-Use Top-Level Domain
    Paul Hoffman
    IETF Request For Comments, RFC Editor (2023), pp. 7
    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) , vol. 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) , vol. 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
    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
    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, vol. 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
    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
    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 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
    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
    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
    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
    RFC 8767 - Serving Stale Data to Improve DNS Resiliency
    Puneet Sood
    D. Lawrence
    IETF RFCs, RFC Editor (2020), pp. 12
    Preview abstract This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. View details
    RSSAC047 - RSSAC Advisory on Metrics for the DNS Root Servers and the Root Server System
    Russ Mundy
    Duane Wessels
    Alejandro Acosta
    Jaap Akkerhuis
    Fred Baker
    Ray Bellis
    Kazunori Fujiwara
    Paul Hoffman
    Kevin L. Jones
    Akira Kato
    Matt Larson
    Daniel Migault
    Ken Renard
    Shinta Sato
    Ryan Stephenson
    Robert Story
    Kevin Wright
    Zhiwei Yan
    Internet Corporation for Assigned Names and Numbers (ICANN) (2020), pp. 31
    Preview abstract In this report, the RSSAC: • Defines measurements, metrics, and thresholds that root server operators (RSOs) meet to provide a minimum level of performance. The thresholds are based on technical metrics designed to assess the performance, availability, and quality of service that each root server identifier (RSI) provides. The thresholds and the metrics on which they are based are included as the RSSAC’s input to a yet-to-be defined evaluation process for future RSOs. • Defines system-wide, externally verifiable metrics and thresholds which demonstrate that the root server system (RSS) as a whole is online and serving correct and timely responses. The metrics described in this report are based on the current awareness of, experience with, and understanding of the root servers and RSS. In the future, different metrics may be required to better understand the RSS and quantify performance, availability, and quality of service. As the metrics and this document are revised, current and future RSOs may have to adapt their architectures over time to meet the changing needs of the RSS. View details
    SAC109 - The Implications of DNS over HTTPS and DNS over TLS
    Barry Leiba
    Suzanne Woolf
    Joe Abley
    Tim April
    Paul Ebersman
    Ondrej Filip
    Geoff Huston
    Jacques Latour
    John Levine
    Chris Roosenraad
    Tara Whalen
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2020), pp. 34
    Preview abstract Encrypted DNS technologies, including DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT), are recent protocols developed for the primary purpose of enhancing user privacy. They accomplish this in several ways, including encrypting their traffic in transit and permitting DNS resolver selection and resolution in applications. Major browser vendors, Internet Service Providers (ISPs), and others are deploying support for these technologies. Their deployment brings a number of possible implications, both positive and negative, to the ICANN community, operators and users of the DNS, and Internet users. This report analyzes the initial effects of these technologies by identifying some groups whose online experiences around privacy could change with the deployment of these technologies. Detailed analysis of effects will have to wait for more widespread deployment and measurement. This report discusses implications occurring now, and raises some longer-term questions for the future. This report frames the issues from the perspectives of interested parties, with the understanding that the issues are nuanced, and that readers coming from different perspectives will have different sensitivities: readers from two different perspectives are likely to view a single issue in two different ways. The intended audience for this report is both the ICANN community and the greater Internet community. This includes network operators, DNS software implementers, policy makers, and concerned Internet users. View details
    RSSAC026v2 - RSSAC Lexicon
    Fred Baker
    Wes Hardaker
    Paul Hoffman
    Lars-Johan Liman
    Daniel Migault
    Russ Mundy
    Karl Reuss
    Brad Verd
    Paul Vixie
    Duane Wessels
    ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories (2020), pp. 9
    Preview abstract The precise technical language often found in Internet Engineering Task Force (IETF) Request for Comments (RFCs), while often providing consistency and clarity to technical communities, can sometimes be incomprehensible or misleading when used in a non-technical setting. The purpose of this document is to increase the understanding of terms used commonly when discussing the root server system to the broader ICANN community. It is not to redefine or provide guidance to any technical communities on the correct use of these terms. This document and its terms should be useful to anyone discussing the DNS root server system. This includes the ICANN community, ICANN staff, RSSAC Caucus members and the RSSAC itself. It will be updated by the RSSAC as the vocabulary used to discuss the root server system evolves. Definitions for other DNS terms can be found in RFC 8499, DNS Terminology. View details
    RSSAC002v4 - Advisory on Measurements of the Root Server System.
    Alejandro Acosta
    Duane Wessels
    Jaap Akkerhuis
    John Bond
    John Heidemann
    Ken Renard
    Ondřej Surý
    Paul Hoffman
    Paul Vixie
    Ray Bellis
    Shinta Sato
    Zhiwei Yan
    ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories (2020), pp. 19
    Preview abstract In this Advisory, the RSSAC identifies and recommends a set of parameters that would be useful for monitoring and establishing baseline trends of the root server system. In response to a desire voiced by the ICANN Board, the RSSAC made a commitment to prepare for an implementation of an early warning system that shall assist in detecting and mitigating any effects (or the absence of such effects) which might challenge the scaling and/or normal performance of the Internet's DNS root server system (RSS) caused by growth of the DNS root zone itself or changes in client behavior from a larger root zone file. As a first step, the RSSAC has begun work to determine a list of metrics that define the desired service trends for the RSS. These metrics include the measured latency in the publication of the root zone, number of queries and responses, distribution of response types, distribution of message sizes, and the number of sources seen. With knowledge of these metrics in hand, the RSSAC can then seek to produce estimates of acceptable root zone size dynamics to ensure the overall system works within a set of parameters. The future work to define these parameters will involve RSSAC working closely with the root server operators (RSOs) to gather best practice estimates for the size and update frequency of the root zone. It must be well understood that the measurements described in this document are a response to the current awareness, experience, and understanding of the RSS. As time progresses more, fewer, or entirely different metrics may be required to investigate new concerns or defined problem statements. View details
    RFC 8914 - Extended DNS Errors
    Evan Hunt
    Roy Arends
    Wes Hardaker
    David C Lawrence
    IETF Request For Comments, RFC Editor (2020), pp. 13
    Preview abstract This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. View details
    SAC108 - SSAC Comments on the IANA Proposal for Future Root Zone KSK Rollovers
    Joe Abley
    Jaap Akkerhuis
    Tim April
    KC Claffy
    Patrik Fältström
    James Galvin
    Geoff Huston
    Andrei Kolesnikov
    Jacques Latour
    Barry Leiba
    Danny McPherson
    Ram Mohan
    Russ Mundy
    Rod Rasmussen
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2020), pp. 10
    Preview abstract The DNS root zone was first signed with DNSSEC in 2010. On October 11, 2018 the DNSSEC Key Signing Key (KSK) was first rolled in the root zone. Having now completed that first roll, the Internet Assigned Numbers Authority (IANA) has asked the ICANN Community to respond to its plan for subsequent KSK rollovers. The SSAC would like to thank ICANN, and specifically IANA, for engaging with the technical community on planning related to KSK rollovers, and for incorporating past advice from the technical community into its current work. This comment represents the SSAC's full input to IANA on its Proposal for Future Root Zone KSK Rollovers, which will henceforth be referred to in this document as the Proposal. The SSAC has previously commented on root zone KSK rollovers in SAC063, SAC073 and SAC102. This comment specifically addresses concerns relating to future KSK rolls, and focuses on items in the Proposal where the SSAC has concerns. In general, the SSAC is confident that the Proposal as written is an adequate and viable high-level plan and does not believe that further delay in planning for subsequent KSK rollovers is merited. View details
    SAC113 - SSAC Advisory on Private-Use TLDs
    Greg Aaron
    Joe Abley
    Jaap Akkerhuis
    Tim April
    Lyman Chapin
    kc claffy
    Patrik Fältström
    James Galvin
    Cristian Hesselman
    Geoff Huston
    Merike Kaeo
    Barry Leiba
    John Levine
    Danny McPherson
    Russ Mundy
    Rod Rasmussen
    Mark Seiden
    Suzanne Woolf
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2020), pp. 27
    Preview abstract In this document, the SSAC recommends the reservation of a DNS label that does not (and cannot) correspond to any current or future delegation from the root zone of the global DNS. This label can then serve as the top-level domain name (TLD) of a privately resolvable namespace that will not collide with the resolution of names delegated from the root zone. In order for this to work properly, this reserved private-use TLD must never be delegated in the global DNS root. Currently, many enterprises and device vendors make ad hoc use of TLDs that are not present in the root zone when they intend the name for private use only. This usage is uncoordinated and can cause harm to Internet users. The DNS has no explicit provision for internally-scoped names, and current advice is for the vendors or service providers to use a sub-domain of a public domain name for internal, or private use. Using sub-domains of registered public domain names is still the best practice to name internal resources. The SSAC concurs with this best practice, and encourages enterprises, device vendors, and others who require internally-scoped names to use sub-domains of registered public domain names whenever possible. However, this is not always feasible and there are legitimate use cases for private-use TLDs. The need for private-use identifiers is not unique for domain names, and a useful analogy can be drawn between the uses of private IP address space and those of a private-use TLD. Network operators use private IP address space to number resources not intended to be externally accessible, and private-use TLDs are used by network operators in a similar fashion. This document proposes reserving a string in a manner similar to the current use of private IP address space. A similar rationale can be used to reserve more strings in case the need arises. This document does not recommend a specific string for reservation. Instead, criteria are provided in Section 4.1 to guide the decision on which string to choose and assist the ICANN Board in making its determination. Four criteria are provided to help guide this decision and reasoning is provided for each. This advisory takes a pragmatic approach to an issue that the DNS allows by its design. Because of the decentralized nature of the DNS, there is no way to prevent ad hoc use of a TLD, rather than use of an explicitly reserved private string as this advisory recommends. Nevertheless, the SSAC believes that the reservation of a private string will help to reduce the ad hoc usage, provide greater predictability for network administrators and equipment vendors, and, over time, reduce erroneous queries to root servers. View details
    RFC 8886 - Secure Device Install
    Colin Doyle
    IETF RFC, RFC Editor (2020), pp. 16
    Preview abstract Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support. In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration. This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device. View details
    RFC 8805 - A Format for Self-Published IP Geolocation Feeds
    Erik Kline
    Krzysztof Duleba
    Zoltan Szamonek
    Stefan Moser
    IETF RFCs, RFC Editor (2020), pp. 23
    Preview abstract This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. View details
    RFC 8806 - Running a Root Server Local to a Resolver
    Paul Hoffman
    IETF RFCs, RFC Editor (2020), pp. 12
    Preview abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round- trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706. View details
    Preview abstract In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions. This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document. This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679. View details
    SAC105 - The DNS and the Internet of Things: Opportunities, Risks, and Challenges
    Tim April
    Lyman Chapin
    Cristian Hesselman
    Merike Kaeo
    Jacques Latour
    Danny McPherson
    Dave Piscitello
    Rod Rasmussen
    Mark Seiden
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories (2019), pp. 29
    Preview abstract The Internet of Things (IoT) promises to enhance our daily lives by seamlessly and autonomously sensing and acting upon our physical environment through tens of billions of connected devices. While this makes the IoT vastly different from traditional Internet applications like email and web browsing, we expect that a significant number of IoT deployments will use the DNS to locate remote services that they need, for instance to enable telemetry data transmission and collection for monitoring and analysis of sensor data. In this report, the SSAC provides a discussion on the interplay between the DNS and the IoT, arguing that the IoT represents both an opportunity and a risk to the DNS. It is an opportunity because the DNS provides functions and data that can help make the IoT more secure, stable, and transparent, which is critical given the IoT's interaction with the physical world. It is a risk because various measurement studies suggest that IoT devices may stress the DNS, for instance, because of complex DDoS attacks carried out by botnets that grow to hundreds of thousands or in the future millions of infected IoT devices within hours. We also identify and discuss five challenges for the DNS and IoT industries (e.g., DNS and IoT operators and software developers) to address these opportunities and risks, for instance by making the DNS’s security functions (e.g., response verification and encryption) available on popular IoT operating systems and by developing a shared system that allows different DNS operators to automatically and continually exchange data on IoT botnet activity. View details
    SAC106 - SSAC Comments on Evolving the Governance of the Root Server System
    Joe Abley
    Geoff Huston
    Danny McPherson
    Ram Mohan
    Russ Mundy
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN - Internet Corporation for Assigned Names and Numbers (2019), pp. 9
    Preview abstract This publication represents the full SSAC input to the Evolving the Governance of the Root Server System ICANN Public Comment Proceeding. The primary motivation of the SSAC during the review of the proposed Root Server System (RSS) evolution was to ensure that the RSS was adequately positioned for long term sustainability as the RSS is critical to the security and stability of the Domain Name System. The SSAC reviewed the proposed framework in order to assure itself, and others, that the proposed governance structures are capable of identifying issues and responding to them as they arise, including but not limited to issues of technology, policy, operations, or security. View details
    SAC101- SSAC Advisory Regarding Access to Domain Name Registration Data
    Greg Aaron
    Joe Abley
    Benedict Addis
    Jaap Akkerhuis
    Jeff Bedser
    Don Blumenthal
    Ben Butler
    kc claffy
    Jay Daley
    James Galvin
    Robert Guerra
    Julie Hammer
    Geoff Huston
    Merike Kaeo
    John Levine
    Carlos Martinez
    Danny McPherson
    Ram Mohan
    Russ Mundy
    Rod Rasmussen
    Doron Shikmoni
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN - Internet Corporation for Assigned Names and Numbers (2018), pp. 29
    Preview abstract Reliable, consistent, and predictable access to domain name registration data (via Registration Data Directory Services, or RDDS) is essential for a variety of legitimate purposes, especially the identification and mitigation of various types of Internet abuse and technical problems. In recent years, access to the data by those who have a legitimate need for it has been diminished, and availability is more constrained and more restricted than ever. This has happened for two main reasons: new legal and policy developments, and an operational practice known as rate limiting. These developments represent a shift in the abuse detection and mitigation landscape. The ability of security practitioners and law enforcement to detect and mitigate cybercrime and DNS abuse has been negatively affected, and the current situation is imposing greater operational and administrative burdens on those defenders. This in turn impairs the general usability and trustworthiness of the Domain Name System (DNS) and the Internet. This document describes the results of SSAC’s extended deliberation on RDDS access issues and offers recommendations for how to move forward. View details
    RFC 8374 - BGPsec Design Choices
    Chris Morrow
    Rob Austein
    Steven Bellovin
    Russ Housley
    Stephen Kent
    Matt Lepinski
    Kotikalapudi Sriram
    Request for Comments, RFC Editor (2018), pp. 50
    Preview abstract This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes. View details
    SAC102 - SSAC Comment on the Updated Plan for Continuing the Root KSK Rollover
    Benedict Addis
    Jaap Akkerhuis
    Lyman Chapin
    Jay Daley
    Patrik Fältström
    Paul Ebersman
    James Galvin
    Geoff Huston
    Barry Leiba
    John Levine
    Danny McPherson
    Ram Mohan
    Russ Mundy
    Suzanne Woolf
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (2018), pp. 4
    Preview
    RFC 8509 - A Root Key Trust Anchor Sentinel for DNSSEC
    Geoff Huston
    Joao Silva Damas
    RFC Editor, RFC Editor (2018), pp. 19
    Preview abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. View details
    RSSAC040 - Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis
    Jaap Akkerhuis
    Ray Bellis
    John Bond
    Joao Damas
    Brian Dickson
    John Heidemann
    Paul Hoffman
    Geoff Huston
    Akira Kato
    Lars-Johan Liman
    Robert Story
    Brad Verd
    Paul Vixie
    Duane Wessels
    Internet Corporation for Assigned Names and Numbers (ICANN) (2018), pp. 19
    Preview abstract DNS operators, in particular Root Server Operators (RSOs), are periodically requested to collect query data and submit it to a central storage location where it is accessible for future research. The typical example is the yearly Day In The Life of the Internet (DITL) collections undertaken by the DNS Operations Analysis and Research Center (DNS-OARC). Some operators are uncomfortable sharing IP addresses of the query sources and some are even legally prevented from doing so. In those cases, the compromise has been for the RSO in question to anonymize the source IP addresses of the queries. View details
    Preview abstract This memo describes Opportunistic Wireless Encryption (OWE) -- a mode of opportunistic security [RFC7435] for IEEE Std 802.11 that provides encryption of the wireless medium but no authentication. View details
    RFC 8244 - Special-Use Domain Names Problem Statement
    Ted Lemon
    Ralph Droms
    Internet Engineering Task Force (IETF) (2017)
    Preview abstract The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names. This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names. View details
    RFC 8145 - Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
    Duane Wessels, Verisign
    Paul Hoffman, ICANN
    Internet Engineering Task Force (IETF), IETF (2017)
    Preview abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. View details
    RFC 8205 - BGPsec Protocol Specification
    Rob Austein
    Steven Bellovin
    Russ Housley
    Stephen Kent
    Doug Montgomery
    Chris Morrow
    Sandy Murphy
    Keyur Patel
    John Scudder
    Samuel Weiler
    Matthew Lepinski
    Kotikalapudi Sriram
    IETF RFCs, RFC Editor (2017), pp. 45
    Preview abstract This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. View details
    RSSAC028 - Technical Analysis of the Naming Scheme Used For Individual Root Servers
    Joe Abley
    John Bond
    Brian Dickson
    Paul Hoffman
    Suresh Krishnaswamy
    Matt Larson
    Declan Ma
    Bill Manning
    Jim Martin
    Robert Martin-Legene
    Daniel Migault
    Shinta Sato
    Arturo Servin
    Davey Song
    William Sotomayor
    Paul Vixie
    Wesley Wang
    Suzanne Woolf
    ICANN Root Server System Advisory Committee (RSSAC) Reports and Advisories (2017)
    Preview abstract The Domain Name System (DNS) is supported by root servers that serve the root zone. Individual root servers were named under the “root-servers.net” domain in 1995. The root-servers.net zone is delegated to the root servers. This naming scheme has worked well for root servers and the Internet community at large for over two decades. However, given today’s Internet environment, the RSSAC has studied the naming scheme used for individual root servers and considered the consequences of making changes. The study documents a risk analysis of different alternative naming schemes. This analysis includes: Where the names reside in the DNS hierarchy Who administers the zone in which the names reside How different naming schemes affect DNSSEC validation of priming responses The size of priming responses From the risk analysis, the document aims at providing: Recommendation to root server operators, root zone management partners, and ICANN on whether changes should be made, and what those changes should be Recommendations on signing the addresses associated with the root servers Recommendation on the naming scheme for the root servers View details
    RFC 8198 - Aggressive Use of DNSSEC-Validated Cache
    Kazunori Fujiwara
    Akira Kato
    Internet Engineering Task Force (IETF) (2017)
    Preview abstract The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. View details
    SAC090 - SSAC Advisory on the Stability of the Domain Namespace
    Joe Abley
    Jaap Akkerhuis
    Don Blumenthal
    Lyman Chapin
    Patrik Fältström
    Jim Galvin
    Geoff Huston
    John Levine
    Danny McPherson
    Ram Mohan
    Russ Mundy
    Rod Rasmussen
    Doron Shikmoni
    Suzanne Woolf
    ICANN, ICANN (2016), pp. 14
    Preview abstract This advisory is concerned only with the risks to security and stability that arise from ambiguity in the use of the domain namespace. Because no one owns (or can own) the domain namespace, and programmers and network managers cannot be prevented from creating their own names and naming scopes, these risks arise regardless of how policy debates about authority or oversight are resolved. Therefore, the observations and recommendations in this advisory are directed at mitigating clearly identified risks and developing policies that provide practical guidance to software and system developers, rather than debating whether or not private network operators should use the domain namespace, or who (if anyone) should have the authority to declare and enforce exclusive uses for specific individual domain name labels or categories of labels. View details
    RSSAC024 - Key Technical Elements of Potential Root Operators
    Wes Hardaker
    Paul Hoffman
    Shane Kerr
    Russ Mundy
    Internet Corporation for Assigned Names and Numbers (ICANN) (2016)
    Preview abstract In this document the RSSAC defines key technical elements of potential new root operators that would be a critical part of any potential root server operator designation process. RSSAC001 (“Service Expectations of Root Servers”) and RFC 7720 (“DNS Root Name Service Protocol and Deployment Requirements”) are considered as starting points; alone, they are insufficient to evaluate potential operators. Non-technical aspects, such as trustworthiness, ethos, funding, business models, openness, community participation and politics are out of scope for this document. The RSSAC believes these non-technical aspects to be important, and although this document does not address them, we expect them to be part of the overall evaluation. The elements defined in this document are designed to be: • Technical in nature • As specific as possible • Provable, documentable, and/or measurable View details
    SAC078 - SSAC Advisory on Uses of the Shared Global Domain Name Space
    Geoff Huston
    Lyman Chapin
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2016), pp. 6
    Preview abstract It is widely known that the Domain Name System (DNS) includes both a set of rules for constructing syntactically valid domain names (the “domain name space”) and a protocol for associating domain names with data such as IP addresses (“domain name resolution”). It is less widely understood, however, that DNS name resolution coexists with other name resolution systems that also use domain names. In many cases these other name resolution systems deliberately use domain names, rather than some other naming scheme, for compatibility with the widely deployed infrastructure of the DNS. They depend on the ability of DNS name resolution protocols and interface conventions to recognize their domain names but treat them in some special way. ... The SSAC wishes to ensure that the ICANN Board and ICANN community are aware of discussions and ongoing work in multiple venues to more fully define what a namespace is, and how to avoid potential side effects, including name collisions, across the broad set of name resolution systems and expectations for their use. View details
    RFC 7871 - Client Subnet in DNS Queries
    Carlo Contavalli
    Wilmer van der Gaast
    David C Lawrence
    IETF, IETF (2016)
    Preview abstract This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. View details
    RSSAC002v2 - RSSAC Advisory on Measurements of the Root Server System
    Duane Wessels
    Shumon Huque
    John Bond
    Ray Bellis
    ICANN (2016)
    Preview abstract RSSAC has begun work to determine a list of parameters that define the desired service trends for the root zone system. These parameters include the measured latency in the distribution of the root zone, the frequency of the updates, and their size. With knowledge of these parameters in hand, RSSAC can then seek to produce estimates of acceptable root zone size dynamics to ensure the overall system works within a set of parameters. The future work to define these parameters will involve RSSAC working closely with the root server operators to gather best practice estimates for the size and update frequency of the root zone. View details
    SAC079 - SSAC Advisory on the Changing Nature of IPv4 Address Semantics
    Don Blumenthal
    Russ Mundy
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2016), pp. 17
    Preview abstract In this advisory, the SSAC considers the changing role of Internet Protocol Version 4 (IPv4) addresses caused by the increasing scarcity, and subsequent exhaustion, of IPv4 addresses. The exhaustion of the IPv4 address supply has been predicted since the end of the 1980s. However, the large scale adoption of mobile devices and their associated IPv4 addressing needs accelerated the exhaustion timetable, and placed increased pressure on network operators to conserve IPv4 addresses. This pressure has resulted in a marked increase in the use of Network Address Translation (NAT) technologies, altering the attributability characteristics of IPv4 addresses, and requiring changes to their interpretation by parties wishing to use them as endpoint identifiers. View details
    SAC073 - SSAC Comments on Root Zone Key Signing Key Rollover Plan
    Patrik Fältström
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2016), pp. 41
    Preview abstract SSAC Comments on the Design Teams Draft Report on the Root Zone Key Signing Key Rollover Plan. View details
    SAC070 - ICANN SSAC Advisory on the Use of Static TLD / Suffix Lists
    Jaap Akkerhuis
    Patrik Fältström
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2015), pp. 32
    Preview abstract This advisory investigates the security and stability needs surrounding the growing use of public suffix lists on the Internet. For the purposes of this Advisory, a public suffix is defined as “a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains.” Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com". There is no programmatic way to determine the boundary where a Domain Name System (DNS) label changes stewardship from a public suffix, yet tracking the boundary accurately is critically important for security, privacy, and usability issues in many modern systems and applications, such as web browsers. One method of determining this boundary is by use of public suffix lists (PSLs), which are static files listing the known public suffixes. View details
    RFC 7535 - AS112 Redirection Using DNAME
    Joe Abley
    Brian Dickson
    George Michaelson
    IETF RFCs, Internet Engineering Task Force (2015), pp. 16
    Preview abstract AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records. This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure. View details
    RFC 7607 - Codification of AS 0 Processing
    Randy Bush
    Heather Schiller
    Keyur Patel
    IETF RFCs, Internet Engineering Task Force (2015), pp. 5
    Preview abstract This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message. View details
    RSSAC003 - RSSAC Report on Root Zone TTLs
    ICANN Root Server System Advisory Committee ( RSSAC ) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2015), pp. 35
    Preview abstract Root zone TTLs have not changed since 1999. In this report, the RSSAC Caucus studies the extent to which the current root zone TTLs are still appropriate for today’s Internet environment. Selecting a TTL for a given resource record involves finding the right balance between a few tradeoffs. Intuitively, shorter TTLs are beneficial for data that changes frequently, whereas longer TTLs are beneficial for data that is relatively stable. Related to this, longer TTLs provide robustness in the event of operational failures. All other things being equal, and assuming software involved in queries and responses follow the DNS protocol standards, shorter TTLs generally result in higher query rates, and longer TTLs result in lower query rates. View details
    RFC 7710 - Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
    Olafur Gudmundsson
    IETF RFC, Internet Engineering Task Force (2015), pp. 8
    Preview abstract In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document. View details
    RFC 7646 -Definition and Use of DNSSEC Negative Trust Anchors
    Jason Livingood
    Chris Griffiths
    IETF RFCs, Internet Engineering Task Force (2015), pp. 15
    Preview abstract DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains. View details
    RFC 7706 - Decreasing Access Time to Root Servers by Running One on Loopback
    Paul Hoffman
    IETF RFCs, Internet Engineering Task Force (2015), pp. 12
    Preview abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. View details
    RSSAC002 - RSSAC Advisory on Measurements of the Root Server System
    ICANN Root Server System Advisory Committee ( RSSAC ) Reports and Advisories, Internet Corporation for Assigned Names and Numbers (ICANN) (2015), pp. 15
    Preview abstract RSSAC has begun work to determine a list of parameters that define the desired service trends for the root zone system. These parameters include the measured latency in the distribution of the root zone, the frequency of the updates, and their size. With knowledge of these parameters in hand, RSSAC can then seek to produce estimates of acceptable root zone size dynamics to ensure the overall system works within a set of parameters. The future work to define these parameters will involve RSSAC working closely with the root server operators to gather best practice estimates for the size and update frequency of the root zone. It must be well understood that the measurements described in this document are a response to the current awareness, experience, and understanding of the Root Zone System. As time progresses more, less, or entirely different metrics may be required to investigate new concerns or defined problem statements. View details
    Preview abstract This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments. View details
    SAC064 - ICANN SSAC Advisory on Search List Processing
    Jaap Akkerhuis
    Don Blumenthal
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2014), pp. 17
    Preview abstract This advisory examines how current operating systems and applications process search lists. It outlines the issues related to the current search list behavior, and proposes both a strawman to improve search list processing in the long term and mitigation options for the Internet Corporation for Assigned Names and Numbers (ICANN) and the Internet community to consider in the short term. The purpose of these proposals is to help introduce new generic Top Level Domains (gTLDs) in a secure and stable manner with minimum disruptions to currently deployed systems. View details
    Preview abstract This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. View details
    RFC 7304 - A Method for Mitigating Namespace Collisions
    IETF RFCs, Internet Engineering Task Force (2014)
    Preview abstract This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict. View details
    SAC062 - ICANN SSAC Advisory Concerning the Mitigation of Name Collision Risk
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2013)
    Preview abstract 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. The circumstances that may cause this can be accidental or malicious. In the context of Top Level Domains (TLDs), the conflicting namespaces are the DNS namespace defined in the root zone as published by the root management partners (ICANN, U.S. Dept. of Commerce National Telecommunications Information Administration (NTIA), and VeriSign) and any privately defined namespace, whether that namespace is defined only for the Domain Name System (DNS) or is also intended to “work” for other namespaces such as Active Directory View details
    SAC057 - ICANN SSAC Advisory on Internal Name Certificates
    Steve Crocker
    Patrik Fältström
    Ondrej Filip
    James Galvin
    Danny McPherson
    Ram Mohan
    Doron Shikmoni
    ICANN SSAC Reports and Advisories, ICANN (Internet Corporation for Assigned Names and Numbers) (2013)
    Preview abstract The SSAC has identified a Certificate Authority (CA) practice that, if widely exploited, could pose a significant risk to the privacy and integrity of secure Internet communications. This CA practice could impact the new gTLD program. The SSAC thus advises ICANN take immediate steps to mitigate the risks. View details
    SAC063 - SSAC Advisory on DNSSEC Key Rollover in the Root Zone
    Russ Mundy
    Matt Larson
    Jaap Akkerhuis
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (2013)
    Preview abstract There is consensus in the security and domain name system (DNS) communities that the root zone DNS Security Extensions (DNSSEC) system poses unique challenges for standard DNSSEC practices. While there is agreement that an eventual root zone Key-Signing Key (KSK) rollover is inevitable regardless of whether that rollover is caused by a key compromise or other factors, there is no solid consensus in the technical community regarding the frequency of routine, scheduled KSK rollovers. In this Advisory the SSAC addresses the following topics: * Terminology and definitions relating to DNSSEC key rollover in the root zone; * Key management in the root zone; * Motivations for root zone KSK rollover; * Risks associated with root zone KSK rollover; * Available mechanisms for root zone KSK rollover; * DNS response size considerations; * Quantifying the risk of failed trust anchor update; and * DNS response size considerations View details
    SAC056 - ICANN SSAC Advisory on Impacts of Content Blocking via the Domain Name System
    Alain Aina
    Jaap Akkerhuis
    Don Blumenthal
    KC Claffy
    David Conrad
    Patrik Fältström
    James Galvin
    Jason Livingood
    Danny McPherson
    Ram Mohan
    Paul Vixie
    ICANN Security and Stability Advisory Committee (SSAC) Reports and Advisories, ICANN (Internet Corporation for Assigned Names and Numbers) (2012)
    Preview abstract The use of Domain Name System (DNS) blocking to limit access to resources on the Internet has become a topic of interest in numerousInternet governance venues. Several governments around the world, whether by law, treaty, court order, law enforcement action, or other actions or agreements, have either implemented DNS blocking or are actively considering doing so. However, due to the Internet’s architecture, blocking by domain name can be easily bypassed by end users and is thus likely to be largely ineffective in the long term and fraught with unanticipated consequences in the near term. In addition, DNS blocking can present conflicts with the adoption of DNS Security Extensions(DNSSEC) and could promote balkanization of the Internet into a country-by-country view of the Internet’s name space. View details
    RFC 6583 - Operational Neighbor Discovery Problems
    Igor Gashinsky, Yahoo!
    Joel Jaeggli, Zynga
    IETF RFCs, Internet Engineering Task Force (2012)
    Preview abstract In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. View details
    Preview abstract This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. View details
    Preview abstract Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. View details
    No Results Found