Attended IAB Retreat in Reykjavik
27 May 2019
(Note that this post represents a personal view, and not the consensus of the IAB)
The IAB has a curious remit. In principle, it provides "long-range technical direction for Internet development, ensuring the Internet continues to grow and evolve as a platform for global communication and innovation". That's certainly part of the role, in so far as it's possible to influence the direction of the herd of cats that is the IETF community, and to the extent that IETF standards still set the technical direction for Internet development. But many of the activities of the IAB are focussed on administration rather than architecture, to ensure the smooth running of the IETF, IRTF, and supporting organisations.
The agenda for the retreat reflected this. The first technical topic was on changes to the Internet Threat Model. Previously, the IETF has considered protocol security but ruled security of end systems out-of-scope. While it's clearly important to ensure that end systems are not compromised, doing so has to date been viewed as outside the scope of protocol specifications, and rather an issue to be considered by implementers of a protocol. The IETF certainly considers ease of secure implementation during protocol design, and warns against common mistakes that might affect security where appropriate, but we've not generally put effort into designing protocols that are secure against endpoint compromise. The question the IAB discussed was whether the threat model considered during protocol specification should be extended to include protocol robustness against compromised endpoints? The increasing success with ensuring communication security (e.g., by use of end-to-end encryption) focusses efforts of attackers onto other aspects of the ecosystem, so it may now be appropriate to broaden the efforts in this space. The input document to the discussion was draft-arkko-arch-internet-threat-model-00, but discussion went beyond this to consider issues of consolidation in the Internet ecosystem. Expect further reflection and proposals from the IAB in this space in future.
A related topic we discussed was how to maintain trust in the Internet infrastructure. Correct operation of the infrastructure that underpins the Internet, including routing, DNS, and the certificate authorities that support web security, relies on the combined services and cooperation of a global network of operators. For example, an ISP can provide Internet services to its customers because other ISPs accept its so-called "route advertisements" and cooperate to deliver its traffic. An ISP that loses the trust of other ISPs could quickly find itself unable to operate if they refused to accept its routes; with little hope of speedy or effective legal recompense due to the global nature of the network. Similar issues can be identified with other parts of the Internet infrastructure. A concern is that well-meaning regulation intended for a service running on the Internet (perhaps a social network website) could be applied to the infrastructure that comprises the Internet, forcing an operator to act in a manner that other operators find indistinguishable from a compromise or other security breach. To return to the routing example, a court order could be imagined that would compel an ISP to issue a route advertisement redirecting traffic intended for a certain destination to another network that's under law enforcement control. This would, however, appear to other ISPs—possibly far removed from the original, and so unaware of the legal constraints—like a security breach, where the ISP redirected traffic for malicious purposes. This could lead to a loss of trust, causing other ISPs to reject advertisements from the affected ISP, and making it difficult for it to conduct its legitimate business. Local regulation can have unintended consequences in a global network.
We discussed draft-arkko-iab-internet-consolidation, and reviewed the goals and agenda for the upcoming Workshop on Design Expectations vs. Deployment Reality in Protocol Development. The concern is around the extent to which the provision of Internet services is becoming concentrated on a small set of large operators, and the degree to which technical and market forces are driving this consolidation. The Internet community has long had a belief that diverse implementations and deployments are needed to ensure that the network is both technically robust and serves the needs of its diverse user population. On the other hand, market forces have tended to encourage centralised deployments based around a limited set of dominant implementations, with the inevitable concerns this raises around centralised control, freedom of expression, and so on. As noted in draft-nottingham-for-the-users, when we design the network and its services we should consider the diversity of users and their range of needs. The ongoing consolidation of the network and its services clearly benefits some of its users, but we should consider the costs and implications for all users, to ensure the benefits of a robust decentralised network, designed to support permissionless innovation, are not lost in the process.
The final technical topic we considered was protocol design and maintenance, and specifically the consequences of the robustness principle ("Be liberal in what you accept, and conservative in what you send") for implementations and the broader protocol ecosystem. This built on draft-iab-protocol-maintenance and an extensive extensive mailing list discussion. The concern focusses on how should protocol designers and implementers handle malformed protocol messages, and what are the consequences of the different approaches for the deployment of new implementations and the overall health of the ecosystem. The traditional approach ("Be liberal in what you accept...") initially encourages broad interoperability, but leads to divergence and a weakening of the protocol semantic over time, and the subsequent need for "bug compatibility" with popular implementations. Enforcing stricter adherence to the specifications, if done at the right point in the life-cycle of a protocol, can help the community settle onto a consistent interpretation of its specification, making it easier to deploy new implementations and protocol extensions. If poorly timed, or handled insensitively and with insufficient buy-in from the broad community, or if attempted in a community lacking the ability to effectively evolve implementations, such enforcement can hinder deployment efforts. There was no clear conclusion, other than perhaps to note that the traditional robustness principle is overly simplistic, and further study of alternative approaches is merited.
On the administrative side, the IAB considered openness and visibility of its discussions, content and scheduling of IETF technical plenaries, and the timing of its participation in, and review of, new work being brought into the IETF (i.e., the role of BoF shepherds). We reviewed the draft marking the first 50 years of the RFC series (draft-flanagan-fiftyyears) and, discussed the role of the RFC Series Editor and RSOC, and the scope of the IAB oversight role for the RFC series in the era of the IETF LLC.