This is my third contribution to The IETF Journal as chair of the Internet Architecture Board (IAB). Pervasive monitoring and Internet governance were discussed in many sessions.
IAB Statement on Pervasive Monitoring
At IETF 88 in Vancouver, the IAB held a technical plenary in which pervasive monitoring was discussed. The IAB, like many others who attended the session, believes that pervasive monitoring represents an attack on the Internet. Their view is supported by the fact that during such monitoring large amounts of information that is intended to be confidential is gathered and aggregated by third parties. Such broad-scale attacks undermine public confidence in the Internet infrastructure, no matter the intent of those collecting the information.
In response, the IAB encourages individuals to take practical measures to limit pervasive monitoring within their environments.
Strengthening the Internet (STRINT) Workshop
The IAB and World Wide Web Consortium (W3C) held a workshop called Strengthening the Internet Against Pervasive Monitoring (STRINT)[1] in London on 28 February 2014. The workshop assembled 100 participants and was supported by the EU FP7 STREWS project[2]. Discussions covered terminology, the role of user interfaces, classes of attack mitigation, specific use cases, and transition strategies. The workshop ended with a few high-level recommendations outlined in the report at https://datatracker.ietf.org/doc/draft-iab-strint-report.
Sessions at IETF 89
During IETF 89, the IAB hosted two sessions. The first, rfcform, gathered input from the community for the RFC Series Editor on the proposed publication of RFCs in formats other than plain text. The second,igovupdate, gathered input from the community on the evolution of the IANA protocol parameter registries.
First-hand comments confirm that ICANN’s administration of the protocol parameter registry functions works well for both the Internet and the IETF. We are pleased with the publication and maintenance of the protocol parameter registries and with the coordination of the evaluation of registration requests through the IANA function provided by ICANN.
Session discussions led to the following guiding principles for IAB efforts that impact IANA protocol parameter registries. These principles must be taken together; their order is not significant.
- The IETF protocol parameter registry function has been and continues to be capably provided by the Internet technical community.
The strength and stability of the function and its foundation within the Internet technical community are both important given how critical protocol parameters are to the proper functioning of IETF protocols.
We think the structures that sustain the protocol parameter registry function needs be strong enough that they can be offered independently by the Internet technical community, without the need for backing from external parties. And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made.
- The protocol parameter registry function requires openness, transparency, and accountability.
Existing documentation of how the function is administered and overseen is good [RFC2860,RFC6220]. Further articulation and clarity may be beneficial. It is important that the whole Internet community can understand how the function works, and that the processes for registering parameters and holding those who oversee the protocol parameter function accountable for following those processes are understood by all interested parties. We are committed to making improvements here if necessary.
- Any contemplated changes to the protocol parameter registry function should respect existing Internet community agreements.
The protocol parameter registry is working well. The existing Memorandum of Understanding [RFC2860] defines “the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force.” Any modifications to the protocol parameter registry function should be made using the IETF process to update RFC 6220 and other relevant RFCs. Put quite simply: evolution, not revolution.
- The Internet architecture requires and receives capable service by Internet registries.
The stability of the Internet depends on capable provision of not just IETF protocol parameters, but IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in standards development, architectural guidance, and allocation of certain name/number parameters to continue. IP multicast addresses and special-use DNS names are two examples where close coordination is needed. The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. We fully understand the need to work together.
- The IETF will continue management of the protocol parameter registry function as an integral component of the IETF standards process and the use of resulting protocols.
RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. The IAB, on behalf of the IETF, has the responsibility to define and manage the relationship with the protocol registry operator role. This responsibility includes the selection and management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation.
- The protocol parameters registries are provided as a public service.
Directions for the creation of protocol parameter registries and the policies for subsequent additions and updates are specified in RFCs. The protocol parameters registries are available to everyone, and they are published in a form that allows their contents to be included in other works without further permission. These works include, but are not limited to, implementations of Internet protocols and their associated documentation.
Highlights since IETF 89
The IAB published RFC 7101,[3] “List of Internet Official Protocol Standards: Replaced by a Web Page.”
The IAB published RFC 7094,[4] “Architectural Considerations of IP Anycast.”
The IAB appointed two people to the ICANN Technical Liaison Group: Warren Kumari for a two-year term and Daniel Migault for a one-year term.
References
- https://www.w3.org/2014/strint/
- http://www.strews.eu/
- http://www.rfc-editor.org/rfc/rfc7101.txt
- http://www.rfc-editor.org/rfc/rfc7094.txt