This workshop discussed some of the internet governance-related issues raised by the adoption of Resource Public Key Infrastructure (RPKI), a technology developed by the Internet Engineering Task Force (IETF) to validate the registration of Internet number resources, including IP addresses (IPv4 and IPv6). RPKI is intended to help ensure the long-term stability of Internet routing by preventing route hijacking and leaking, resulting in a safer online environment for Internet users. The Regional Internet Registries (RIRs) are taking the lead role in deploying this technology to their members, in consultation with the multi-stakeholder Internet community.
The session was moderated by Hisham Ibrahim of AFRINIC.
Geoff Huston, of APNIC, gave a technical description of the Internet routing system and the role that RPKI, also known as Internet resource certification, can play in making this system more secure. He outlined the activities that the Internet Engineering Task Force (IETF) and the Regional Internet Registries (RIRs) have been undertaking to develop and deploy a global system of RPKI.
Heather Dryden, of the Canadian Government, outlined the interest of government, particularly the Canadian government, in the development of RPKI. She noted that this is clearly an area being led by the technical community, but noted the interest the public sector has in seeing a more secure routing system (including the financial cost incurred by bad routing incidents). She also noted the assistance that government could provide, in terms of encouraging uptake by vendors and other relevant stakeholders.
Malcolm Hutty, of LINX (the London Internet Exchange), raised the issue of overlap between policy and technical development. He suggested that the RPKI system may have unintended consequences that actually detract from the defined goals. Specifically, he noted that with widespread adoption of the system (and people basing their routing decisions on RPKI information), revocation of a certificate could equate to disconnecting the resource holder from the Internet. This would mark a significant change, as RIRs currently have no ability to reclaim the number resources that they have allocated, and there are questions about whether the RIRs should have this power. RIRs are organisations that operate in specific national jurisdictions, which means that the power to revoke certificates would be dependent on that national legal system and its authorities. Malcolm argued that policymaking in this area therefore needs to consider not only existing law, but laws that may yet be made.
Sebastian Bellagamba, of the Internet Society (ISOC), approached the issue from a freedom of expression perspective, and noted that he comes from a region (South America) which has a history of instability in terms of legal systems. However, he argued that the risks associated with the deployment of RPKI would be outweighed by the benefits that it would bestow.
Paul Wilson expanded on the problems already being caused by insecure routing, including the squatting of unused addresses, which are then used to facilitate problematic activities such as "mail bombing" and phishing. He also noted that APNIC already revokes address space, which means removing records from the whois database and routing registry. More often they use the threat of revocation to ensure policy compliance. He suggested that RPKI would primarily result in a more automated process for doing this. He also agreed with Malcolm that the issues Malcolm had raised would only present themselves with wide adoption, and this remains a very long way off. Paul suggested it will be a long time before network operators are willing to trust their routing decisions to an RPKI system, but in the meantime RPKI will serve a useful role in triggering alerts for uncertified space etc.
Marco Hogewoning and Chris Buckridge of the RIPE NCC clarified the situation noted by Malcolm regarding the RIPE NCC's interaction with Dutch authorities and a recent legal request to freeze certain resource registrations in the RIPE Database. They also noted the importance of involvement by law authorities in multi-stakeholder discussions in this area.
Dmitry Kohmanyuk, of .UA (Ukraine) asked about the APNIC transition to five trust anchors. Paul Wilson clarified that while a single, interim trust anchor had initially been deployed, this has now been replaced with a different strategy, with each RIR deploying their own trust anchor. He noted that this reflects what each RIR community wanted to see, but it also means some more complexity.
Adiel Akplogan, of AFRINIC, argued that RPKI should not be seen as giving any more power to the RIRs than they already have, and argued that the issue must be considered objectively on its merits.
Alain Bidron, of FT/Orange, asked about the provision of RPKI for legacy IPv4 address space. Paul Wilson noted that the legacy space has transferred to respective RIRs, based on the original registrant, and could therefore be certified by those RIRS, according to the relevant policies. Brenden Kuerbis, of the Internet Governance Project, sought clarification in this point, and it was confirmed that the RIRs are not certifying those resources registered only in the IANA database.
Baher Esmat, of ICANN, asked if RPKI would require additional expertise or additional cost for operators. Marco Hogewooning noted that there may be a cost involved, as with any new technology, but in terms of specific deployment costs, RPKI is becoming a standard feature in routers produced by many vendors.
Paul Wilson and Adiel Akplogan noted examples of when both APNIC and AFRINIC have had to revoke number resources. This generally occurs when the RIR loses its business relationship with the address holder, but has also been done, in some cases, on the basis of requests from legal authorities due to legitimate cases of misuse.
Malcolm Hutty made a concluding statement, expressing his belief that we should widen the technical scope of the problem and address or mitigate the concerns he raised. Sebastian Bellagamba agreed, arguing that this is the best solution so far, but it is important to keep investigating and be aware of the problems that remain or are raised by RPKI.
