Will the Internet fragment? Professor Mueller gave a talk about his book “Will the Internet Fragment?” at Clemson University (his talk starts around 4:30). He says the network effects of global compatibility are powerful enough to defeat a technical fracturing of the web. The real threat comes from governments’ attempts to align information flows with their territorial boundaries. A power struggle may loom over the future of national sovereignty in the digital world.
ICANN is a California nonprofit headquartered in the United States. ICANN’s accountability reforms included a discussion of how U.S. jurisdiction affects ICANN’s accountability and domain name users. Not satisfied with ending U.S. control over the DNS root, a few stakeholders wanted to get ICANN out of the U.S. altogether. It is now pretty clear that there is no viable or superior alternative to U.S. jurisdiction. But there are some problems and issues associated with U.S. jurisdiction that ICANN needs to address.
In the last few months, the Workstream 2 Jurisdiction subgroup circulated a questionnaire about how ICANN jurisdiction affects Domain Name System customers and users. It called for identifying problems associated with U.S. jurisdiction. The group has finished analyzing the responses to the questionnaire. During this process, IGP put forward some issues that demonstrated how ICANN jurisdiction can hamper access to DNS. In this blog post we provide a more general overview of those problems and explain how they can be solved without changing ICANN’s basis in California law. The key jurisdiction issues stem from U.S. sanctions and ICANN’s ccTLD delegation process. Continue reading
As this blog post shows, ICANN’s management is now thinking about how to comply with the European General Data Protection Regulation (GDPR). They’d better be. Everyone knows ICANN’s Whois policies, which require registries and registrars to provide indiscriminate public access to personal data about domain name registrants, violate European privacy laws. In the past, this didn’t matter much, because the data protection laws didn’t have much teeth when it came to ICANN and the domain name industry. But under the GDPR, such violations will result in fines of up to 4% of an organization’s revenue. Not only registries and registrars, but ICANN itself, could be subject to these serious penalties. Real money is on the table.
But even with this huge threat looming over it, ICANN still can’t handle the data protection issue wisely and fairly. All of its efforts to prepare for the crisis reveal the same bias that got it into the problem to begin with. ICANN’s internal efforts involve only registries and registrars – the supply side of the industry – and not registrants. The aforementioned blog says that ICANN has formed an internal task force “comprised of senior leaders and subject matter experts” to focus on this important matter. Who is on this task force? Just contracted parties (registries and registrars), other registries and ICANN staff. There has been no effort to include privacy advocates or noncommercial users in this internal task force. Continue reading
As part of its effort to improve the security of inter-domain routing traffic exchange, NIST has issued a request for comments on a proposed project to test RPKI and Route Origin Validation (ROV), a process by which route advertisements can be authenticated as originating from an expected Autonomous System (AS). The project’s results will feed into the development of a NIST Special Publication (SP 800-189 – in preparation) that will provide security recommendations for the use of inter-domain protocols and routing technologies.
Soliciting comments on the NANOG list, the project’s manager noted:
The objective of the project is to examine and demonstrate the state of the RPKI and BGP Origin Validation technologies in realistic scenarios and to address identified concerns with their deployment and use (e.g., security, robustness, management / monitoring, multi-vendor inter-operation)…This request is for industry input on the the proposed project plan. In particular we seek input from both network operators and enterprises on practical issues and barriers to adoption and suggestions for how these could be addressed in the project.
The project will explore two scenarios for ROV, “Hosted RPKI for ROV” and “Delegated RPKI for ROV”. Hosted RPKI is pretty much a turn-key deployment for address holders, relying heavily on the Regional Internet Registry (RIR) to generate and host key material used in ROV and the creation of Route Origin Authorizations (ROAs), i.e., the digitally signed information linking an AS and prefix(es). Under the delegated RPKI, a more operator-controlled approach, the RIR is not required to host the private key of an AS’s delegated RPKI key pair. In this scenario, the address holder can host and delegate RPKI services to its customers who participate in BGP. Despite the relative independence that the address holder maintains under the delegated arrangement, the draft project description lays out certain requirements (lines 264-268):
To participate, the organization must have IPv4 or IPv6 prefixes that are obtained from an RIR. It also needs to have signed a Registration Services Agreement (RSA) to cover all resources (or ROAs) it needs to certify. The organization must have an account with its RIR to manage the resources it plans to certify.
One explanation for the requirements is that the RIRs operate the RPKI systems available to test, they also maintain registry information for address resources. However, these policy-like requirements also seem to prevent a large portion of address holders in the ARIN region from participating in the project. Continue reading