RFC 8980

Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development

📅 published February 2021, from ietf

Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development 💅

RFC 8980 🎀

  • Who wrote it: J. Arkko and T. Hardie, on behalf of the Internet Architecture Board (IAB) 👑
  • Category: Informational, so it's for the permanent record and not a standard 📚
  • Date: February 2021 🗓️
  • ISSN: 2070-1721
  • Obsoletes or updates: the title block doesn't list anything this one obsoletes or updates 🫶

Abstract 🌸

Okay so, the Design Expectations vs. Deployment Reality in Protocol Development Workshop was hosted by the Internet Architecture Board (IAB) in June 2019. This report sums up the big talking points from the workshop and flags topics that may be worth looking at more closely 🔍

Quick heads up: this is a write-up of what happened at the workshop. The views and positions in here belong to the workshop participants and don't necessarily match the IAB's own views and positions 💜

Status of This Memo 🧾

This document is not an Internet Standards Track specification. It's published for informational purposes 📖

This document is a product of the Internet Architecture Board (IAB). The IAB decided it's valuable enough to keep on permanent record, and it reflects the consensus of the IAB. Documents the IAB approves for publication are not candidates for any level of Internet Standard, so see Section 2 of RFC 7841 for the details 🙈

For info on the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8980 🔗

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents 🗂️

   1.  Introduction
   2.  Workshop Agenda
   3.  Position Papers
   4.  Discussions
     4.1.  Past Experiences
     4.2.  Principles
     4.3.  Centralized Deployment Models
     4.4.  Security
     4.5.  Future
   5.  Conclusions
     5.1.  Summary of Discussions
     5.2.  Actions
       5.2.1.  Potential Architecture Actions and Outputs
       5.2.2.  Other Potential Actions
     5.3.  Other Publications
     5.4.  Feedback
   6.  Security Considerations
   7.  Informative References
   Appendix A.  Participant List
   IAB Members at the Time of Approval
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

The IAB runs occasional workshops to think about long-term issues and strategies for the Internet, and to suggest where the Internet architecture should head next 🧭 This long-term planning is a complement to the ongoing engineering work that IETF working groups are doing, so it's like the big-picture friend to their day-to-day grind 💖

The Design Expectations vs. Deployment Reality in Protocol Development Workshop was hosted by the IAB in June 2019. This report recaps the workshop's major discussion points and points out topics that may deserve more thought 🎀

So the backstory is this: while a bunch of protocols were being built and early elaborated, the designers were assuming specific ways they'd get deployed. Real life, though, kept going against those early expectations. Economies of scale, DDoS attack resilience, market consolidation, and other factors kept showing up and messing things up, and the end result is often a deployed reality that's super concentrated 🙃

Okay this is a big deal for the Internet, bestie. Concentrated, centralized deployment models put user choice, privacy, and future protocol evolution at risk 😭

Sometimes the gap between the original expectations and reality showed up almost right away. Other times it didn't show up until a lot of time had passed since the protocol was first developed ⏳

Here are some examples 👇

  • Email: Email standards were built assuming lots of providers running in a mostly uncoordinated way. Instead, there's been huge market consolidation, and there's also a real need for coordination to fight spam and other attacks. Coordinated and centralized defenses scale better for big entities, and that has fueled even more consolidation 📧
  • The Domain Name System (DNS): DNS was designed around deep hierarchies, but it's often deployed as large, flat zones. That's made the nameservers for those zones into critical infrastructure. In the future, DNS might concentrate through globally available common resolver services, which evolve quickly and can offer better security. Plot twist: funneling queries into a few services creates brand new security and privacy concerns 🤯
  • The Web: The Web is built on a fundamentally decentralized design, but it's now often delivered with help from Content Delivery Networks (CDNs). Those services handle scaling, distribution, and denial-of-service prevention in ways that new entrants and smaller system operators would struggle to copy. Truly small services and truly large services can each run on only their own infrastructure, but a lot of everyone else's only practical choice is a globally available commercial service 🌐

Similar things may happen with future technologies and services. For example, the growing use of Machine Learning makes it hard to distribute an effective implementation of a service across a pool of many different providers 🤖

Some background from earlier IAB work: [RFC5218] looked at what makes a protocol successful, and [RFC8170] covered how to handle protocol transitions 📚 This workshop was about digging into cases where the original system design assumptions turned out to be wrong. The goal was to spot patterns in what made those assumptions fail (for example, concentration due to DDoS resilience), and to look at how those failures affect the security, privacy, and manageability of the deployments that came out of them 🕵️‍♀️

The eventual goals might include proposing common fixes for specific cases where protocol expectations got confounded. But this workshop, and so this report, focused on finding patterns first 💅

The workshop call for papers invited position papers that would:

  • Describe specific cases where system assumptions during protocol development were confounded by later deployment conditions.
  • Survey a set of cases to identify common factors in these confounded expectations.
  • Explore remediations that foster user privacy, security, and provider diversity in the face of these changes.

In total, 21 position papers were received, and they're listed in Section 3. There were 30 participants, on site or remote, and they're listed in Appendix A 🎉

2. Workshop Agenda 🗓️

After the opening and a chat about the goals for the workshop, the discussion focused on five main topics 👀

  • Past experiences. What have we learned?
  • Principles. What forces apply to deployment? What principles should we take into account in design?
  • Centralized deployment models. The good and the bad of centralization. Can centralization be avoided? How?
  • Security. Are we addressing the right threats? What should we prepare ourselves for?
  • Future. What can we do? Should we get better at predicting, or should we do different things?

3. Position Papers 📄

These position papers were submitted to the workshop. They're listed below by the people who submitted them, in alphabetical order 💜

  • Jari Arkko. "Changes in the Internet Threat Model" [Arkko2019]
  • Vittorio Bertola. "How the Internet Was Won and Where It Got Us" [Bertola2019]
  • Carsten Bormann and Jan-Frederik Rieckers. "WiFi authentication: Some deployment observations from eduroam" [Bormann2019]
  • Stéphane Bortzmeyer. "Encouraging better deployments" [Bortzmeyer2019]
  • Brian Carpenter and Bing Liu. "Limited Domains and Internet Protocols" [Carpenter2019]
  • Alissa Cooper. "Don't Forget the Access Network" [Cooper2019]
  • Stephen Farrell. "We're gonna need a bigger threat model" [Farrell2019]
  • Phillip Hallam-Baker. "The Devil is in the Deployment" [HallamBaker2019]
  • Ted Hardie. "Instant Messaging and Presence: A Cautionary Tale" [Hardie2019]
  • Paul Hoffman. "Realities in DNSSEC Deployment" [Hoffman2019]
  • Christian Huitema. "Concentration is a business model" [Huitema2019]
  • Geoff Huston. "The Border Gateway Protocol, 25 years on" [Huston2019]
  • Dirk Kutscher. "Great Expectations: Protocol Design and Socioeconomic Realities" [Kutscher2019]
  • Julien Maisonneuve. "DNS, side effects and concentration" [Maisonneuve2019]
  • John Mattsson. "Consolidation, Privacy, Jurisdiction, and the Health of the Internet" [Mattsson2019]
  • Moritz Müller. "Rolling Forward: An Outlook on Future Root Rollovers" [Muller2019]
  • Jörg Ott. "Protocol Design Assumptions and PEPs" [Ott2019]
  • Lucas Pardue. "Some challenges with IP multicast deployment" [Pardue2019]
  • Jim Reid. "Where/Why has DNS gone wrong?" [Reid2019]
  • Mohit Sethi and Tuomas Aura. "IoT Security and the role of Manufacturers: A Story of Unrealistic Design Expectations" [Sethi2019]
  • Andrew Sullivan. "Three kinds of concentration in open protocols" [Sullivan2019]

You can grab these papers from the IAB website [CFP] [POS] 🦋

4. Discussions 💬

Part 1 is done, bestie 🎀 Part 2 is where the Discussions get juicy, so keep scrolling and don't miss it 👑

4.1. Past Experiences ✨

okay so this section is where the workshop people dished on real deployment stories 🍓 they looked at certificate authorities for web connections (WebPKI) 🔐, DNS Security (DNSSEC) 🛡️, the Border Gateway Protocol (BGP) 🌐 and Network Address Translators (NATs), DNS resolvers and CDNs 💻, and Internet of Things (IoT) systems all the way over to instant messaging and social media apps 📱. bestie, the drama is real 😭

so in a lot of these cases, (1) something surprised everyone about how the tech actually got deployed 😳, (2) it just didn't get enough adoption 💔, or (3) the business models behind the chosen tech were NOT vibing with broader interoperability 🙃

ngl the protocol designers can't really control market forces 💅 they have to work within them. but there are often competing technical approaches or features built for one specific deployment pattern 🦋. sometimes you actually get to pick: support a clear need for an established business 💼, a feature meant to help smaller players collaborate 🤝, or some kind of disruption with a more speculative new feature or technology ⚡. main character choices, honestly 👑

here's the lessons-learned list, and it's giving humble pie 🥧:

  • feedback from the people who deploy usually shows up way too late 😩
  • building blocks get repurposed in totally unexpected ways 🧩
  • user communities also come in too late 🙈
  • the Web is getting more centralized, and pushing back on that is hard 💀 it's not totally clear which technical path leads to distributed markets and decentralized architectures, for instance 🌸
  • there are also a bunch of forces that make centralized models easier to pursue than other models 🧲. like, deployment is often simpler when it's centralized 🚀, and business and regulatory processes love working with a small, well-defined set of entities that can talk to each other 🗂️. so regulators can end up preferring a handful of entities they can call, instead of a diverse set of providers 📞
  • it's important but also hard to figure out how useful new protocols actually are 🤔
  • it's difficult for the IETF community to chat with other communities, e.g., specific business sectors that need new tech (like aviation ✈️ or healthcare 🏥) or regulators 🎀

4.2. Principles 🧠

okay so a few underlying principles showed up across the example cases 🔍 deployment failures tend to happen when interdependencies make progress hard and there's no major advantage to deploying early 🙃. and even when the tech already in use has persistent problems, it gets really hard for the ecosystem to switch to something better 😤. for instance, BGP [RFC4271] is lacking in a number of areas, but there's only been limited success deploying big improvements, like in security 🔐.

another principle seems to be first-mover advantage 🏃‍♀️💨. several equally interesting technologies have had totally different fates, depending on whether an earlier system already gave most of the benefits of the new one 🥇. again, even with real problems in an already-deployed technology, improvements are hard to roll out because there aren't immediate incentives 📉 and the competing, already-deployed alternative keeps moving forward in the ecosystem 🚂. like, WebPKI is super widely deployed and used 🌍, but DNSSEC [RFC4033] is not 😭. is that because of WebPKI's earlier commercial adoption 💸, the more complex interdependencies between systems that wanted to deploy DNSSEC 🕸️, or some other reason? 🤷‍♀️

the definition of "success" in [RFC5218] seems to be part of the problem 🙈. the only way to control deployments up front is to prevent wild success 🚫, but wild successes are literally what we want 🎉. and it seems really hard to predict these successes 🔮.

the workshop also talked about how much protocol work should even be controlled by the IETF, or the IESG 🏛️. it seems unproductive to try to constrain deployment models 🙅‍♀️, since you can only offer possibilities, not force anyone to use a particular one 🎁.

the workshop also looked at different types of deployment patterns on the Internet 🌐:

  • delivering functionality over the Internet as a web service 💻. the Internet is an open, standardized system, but the service on top can be closed 🔒, basically running two components of the same provider's software against each other over the browser and Internet infrastructure 😵‍💫. several big application systems have grown this way, covering tons of functionality and a large fraction of Internet users 📈. this makes it easier for web apps to grow by themselves, without cross-fertilization or interoperability 🌱🚫
  • delivering concentrated network services that offer the standard capabilities of the Internet 📮. examples include some mail services, DNS resolution, and so on 📬

the second case is more interesting for an Internet architecture discussion 🧐. there can be different underlying situations even there, though 🎭. the service might just be a concentrated way to provide a commodity service 📦, and the market should find a natural equilibrium for that 🌤️. this may be fine, especially where the service doesn't give whoever provides it any new underlying advantage 🤑 (like user data they can monetize, or training data for an important Machine Learning service 🤖).

secondly, the service might be an extension beyond standard protocols 🧩, which raises questions about how well standards and user expectations match 🤨. but those questions could be handled by better or newer standards 📚. thirdly, and potentially most disturbingly 😱, the service may be provided in this concentrated way because of business patterns that make it easier for particular entities to deploy such services 🏢💅.

the group also talked about monocultures 🌾, and how they hurt the Internet's stability and its resistance to various problems and attacks 💥.

regulation can affect Internet businesses too ⚖️. it can come in multiple forms, based on economic rationale (e.g., competition law) or other factors 📜. for instance, user privacy is a super common regulatory topic 🔏.

4.3. Centralized Deployment Models 🏰

so many participants have struggled with these trends 😩 and with how they hit desirable characteristics of Internet systems, like the distributed, end-to-end architecture 🧩 or privacy 🫶. yet there are tons of business and technical drivers pushing the Internet architecture to become more and more centralized 📈💀.

some observations that were made:

  • when standardizing new tech, the parties involved may think they agree on the goals, but in reality they're often surprised in the end 😲. for instance, with DNS (queries) over HTTPS (DoH) [RFC8484], there were very different aspirations 🎯. some were about improving confidentiality of queries 🔐, some about operational and latency improvements to DNS operations ⚡, and some about shifting business and deployment models 🔄. the full picture wasn't clear until the work was completed 🙈
  • in DNS, DDoS is a practical reality 💥, and only a handful of providers can handle the traffic load in these attacks 😵.

the hopeful side of this issue is that there are some potential answers 🌈:

  • DDoS defenses don't have to come through large entities, since layered defenses and federation help in similar ways 🛡️🫶
  • surveillance state data capture can be fought with data object encryption 🔐 and by not storing all of the data in one place 🗄️
  • web tracking can be combatted by browsers choosing to avoid techniques that are sensitive to tracking 🕵️‍♀️🚫. competition in the browser market may help drive some of these changes 🏁
  • open interfaces help guard against bundling services in one large entity 🎁. as long as there are open, well-defined interfaces to specific functions, other parties can perform those functions too 🤝
  • commercial surveillance doesn't seem to be curbed by current means 😤. but there are still possibilities, like stronger regulation 📜, data minimization 🧹, or browsers acting on behalf of users 🦸‍♀️. there are hopeful signs that at least some browsers are getting more aggressive about this 👀. but more is needed 💪

one comment made in the workshop was that the Internet community needs to curb the architectural trend of centralization 🛑. another comment was that discussing this in the abstract isn't as useful as concrete, practical actions 🛠️. for instance, one might imagine different DoH deployments with wildly different implications for privacy or tolerance of failures 🎭. getting to the specifics of how a particular service can be made better is important 💖.

4.4. Security 🔐

this part of the discussion focused on whether, in the current state of the Internet, we actually need a new threat model 🕵️‍♀️💭.

many of the security concerns about communications have been addressed over the past few years 🎉, with increasing encryption 🔒. however, issues with trusting endpoints on the other side of the communication haven't been addressed yet 😬, and they're getting more urgent with the rise of centralized service architectures 🚨.

further effort may be needed to minimize centralization 🧯, since having only a few places to tap increases the likelihood of surveillance 👁️.

there may be a need to update [RFC3552] and [RFC7258] 📝.

the participants in the workshop agreed that a new threat model is needed 🙌, and that non-communications-security issues need to be handled too 🫣.

other security discussions focused on IoT systems 🤖, algorithm agility issues 🔄, experiences from difficult security upgrades like DNSSEC key rollovers 🔑, and routing security 🛣️.

the participants cautioned against relying too much on device manufacturers for security 📵, and about being clear on security models and assumptions 📋. security is often poorly understood 😵‍💫, and the assumptions about who the system defends against, and who it doesn't, aren't clear 🕳️💀.

4.5. Future ✨

okay so the workshop basically turned into a big "what do we actually DO about this" convo 💅 People threw out a bunch of options:

  • Documenting our experiences? 📝
  • Providing advice (to the IETF or to others)? 🫶
  • Waiting for the catastrophe that will make people agree to changes? The participants of course did not wish for this. 😭
  • Work at the IETF? 💼
  • Technical solutions/choices? 🔧

ngl the best way for the IETF to do things is through standards 📜, because convincing people through other requests is genuinely hard 😩. So the IETF needs to:

  • Pick pieces that it is responsible for. 🎯
  • Be reactive for the rest, be available as an expert in other discussions, provide Internet technology knowledge where needed, etc. 🧠✨

One key question is what other parties need to be involved in any discussions. Platform developers (mobile platforms, cloud systems, etc.) are one group 📱☁️, and specific technology or business groups (such as email provider or certificate authority forums) are another 🦋.

The workshop also got into specific tech issues, like IoT systems 🤖. One thing people noticed is that there is no single model for applications, because they vary a lot 🌈. There are so many different constraints in different systems and different control points, it's wild 🙈. What is perhaps most needed today is user control and transparency (for instance, via Manufacturer Usage Descriptions (MUDs) [RFC8520]) 🔍💜. Another issue is management, especially for devices that could be operational for decades 🕰️. Given how diverse IoT systems are, it may also make more sense to build support systems for broader solutions than for specific solutions or specific protocols 🧩.

There are also a lot of security issues 🚨. Some of them are trivial (like default passwords 🙃), but we should also look forward and be prepared to have solutions for things like trust management on long time scales, or be able to provide data minimization to cut down on the potential for leakages 🔐. And the difficulty of establishing peer-to-peer security strengthens the need for a central point, which may also be harmful from a long-term privacy perspective 😬💔.

5. Conclusions 🎀

5.1. Summary of Discussions 🌸

The workshop met in the sunny Finnish countryside ☀️🇫🇮 and made the not-so-shocking observation that technologies sometimes get deployed in surprising ways 🙃. But the consequences of deployment choices can have an impact on security, privacy, centralized vs. distributed models, competition, and surveillance 👀. Since the IETF community cares deeply about these aspects, it is worthwhile to spend time on analyzing these choices 💅.

The prime factor driving deployments is perceived needs. Expecting people to recognize obvious virtues and therefore deploy them is not likely to work 🙅‍♀️.

And the ecosystem is complex 🌀, with lots of parties: different business roles, users, regulators, and so on. Perceptions of needs and the ability to act depend highly on what party you talk to 🗣️.

While the workshop discussed actions and advice, there is a critical question of who these are targeted towards 🎯. There is a need to construct a map of what parties need to perform what actions 🗺️.

The workshop also made some technical observations 🔧. One issue is that the workshop identified a set of hard issues that affect deployment and for which we have no good solutions 😤. These issues include, for instance, dealing with DDoS attacks and how to handle spam 📧💀. Similarly, a lack of good solutions for micropayments is one factor behind a lot of the Internet economy being based on advertisements 📺.

One recent trend is that technology is moving up the stack, e.g., in the areas of services, transport protocol functionality, security, naming, and so on 🧗. This impacts how easy or hard changes are and who is able to perform them 🪄.

It was also noted that interoperability continues to be important 🤝. We need to explore what new interfaces need standardization, because this will enable different deployment models and competition 🏆. The prime factor driving deployments is actual needs. We cannot force anything on others, but we can provide solutions for those that need them 💖. Needs and actions may fall to different parties 🫧.

The workshop also considered the balancing of user non-involvement and transparency, as well as choice 🎚️. It looked at relevant threats such as communicating with malicious endpoints 👾, the role and willingness of browsers in increasing the ability to defend users' privacy 🛡️, and concerns around centralized control or data storage points 🏰.

The workshop also discussed specific issues around routing, DoS attacks, IoT systems, the role of device manufacturers, the DNS, and regulatory reactions and their possible consequences ⚖️🌐.

5.2. Actions 🚀

The prime conclusion from the workshop was that the topics we discussed were not completed in the workshop 😭. Much more work is needed 📚. The best way for the IETF to make an impact is through standards 📜. The IETF should focus on the parts that it is responsible for and be available as an expert on other discussions 🫶.

5.2.1. Potential Architecture Actions and Outputs 🏗️

The documents/outputs and actions described in the following items were deemed relevant by the participants 👑.

  • Develop and document a modern threat model. 🕵️
  • Continue discussion of consolidation/centralization issues. 🧩
  • Document architectural principles, e.g., (re)application of the end-to-end principle. 📐

The first receiver of these thoughts is the IETF and protocol community, but combined with some evangelizing and validation elsewhere 📣🦋.

5.2.2. Other Potential Actions 🌷

  • Pursuit of specific IETF topics, e.g., working on taking into account reputation systems in IETF work, working to ensure that certificate scoping can be appropriately limited, building end-to-end encryption tools for applications, etc. 🔐💜
  • General deployment experiences/advice, and documenting deployment assumptions possibly already in WG charters 📋.
  • A report will be produced from the workshop (this RFC) 🎀.

5.3. Other Publications 📰

The workshop results have also been reported at [ISPColumn] by Geoff Huston 🌟.

5.4. Feedback 💌

Feedback regarding the workshop is appreciated and can be sent to the program committee, the IAB, or the architecture-discuss list 💖📮.

6. Security Considerations 🚨

Proposals discussed at the workshop would have significantly different security impacts, and each workshop paper should be read for its own security considerations 🔐😱. Don't skip this part, bestie 🫶.

7. Informative References ✨

Okay bestie, this is the reading list 📚 Every source the document leans on is here, with its details, so you can go find the whole thing yourself. Most of these are position papers from the IAB DEDR workshop in June 2019 💅

  • [Arkko2019]: Arkko, J., "Changes in the Internet Threat Model", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Bertola2019]: Bertola, V., "How the Internet Was Won and Where It Got Us", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Bormann2019]: Bormann, C. and J. Rieckers, "WiFi authentication: Some deployment observations from eduroam", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Bortzmeyer2019]: Bortzmeyer, S., "Encouraging better deployments", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Carpenter2019]: Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", position paper submitted for the IAB DEDR workshop, June 2019.
  • [CFP]: IAB, "Design Expectations vs. Deployment Reality in Protocol Development Workshop 2019", June 2019, <https://www.iab.org/activities/workshops/dedr-workshop/>.
  • [Cooper2019]: Cooper, A., "Don't Forget the Access Network", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Farrell2019]: Farrell, S., "We're gonna need a bigger threat model", position paper submitted for the IAB DEDR workshop, June 2019.
  • [HallamBaker2019]: Hallam-Baker, P., "The Devil is in the Deployment", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Hardie2019]: Hardie, T., "Instant Messaging and Presence: A Cautionary Tale", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Hoffman2019]: Hoffman, P., "Realities in DNSSEC Deployment", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Huitema2019]: Huitema, C., "Concentration is a business model", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Huston2019]: Huston, G., "The Border Gateway Protocol, 25 years on", position paper submitted for the IAB DEDR workshop, June 2019.
  • [ISPColumn]: Huston, G., "Network Protocols and their Use", June 2019, <https://www.potaroo.net/ispcol/2019-06/dedr.html>.
  • [Kutscher2019]: Kutscher, D., "Great Expectations: Protocol Design and Socioeconomic Realities", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Maisonneuve2019]: Maisonneuve, J., "DNS, side effects and concentration", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Mattsson2019]: Mattsson, J., "Consolidation, Privacy, Jurisdiction, and the Health of the Internet", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Muller2019]: Müller, M., "Rolling Forward: An Outlook on Future Root Rollovers", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Ott2019]: Ott, J., "Protocol Design Assumptions and PEPs", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Pardue2019]: Pardue, L., "Some challenges with IP multicast deployment", position paper submitted for the IAB DEDR workshop, June 2019.
  • [POS]: IAB, "Position Papers: DEDR Workshop", June 2019, <https://www.iab.org/activities/workshops/dedr-workshop/position-papers/>.
  • [Reid2019]: Reid, J., "Where/Why has DNS gone wrong?", position paper submitted for the IAB DEDR workshop, June 2019.
  • [RFC3552]: Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
  • [RFC4033]: Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
  • [RFC4271]: Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
  • [RFC5218]: Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.
  • [RFC7258]: Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
  • [RFC8170]: Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.
  • [RFC8484]: Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
  • [RFC8520]: Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.
  • [Sethi2019]: Sethi, M. and T. Aura, "IoT Security and the role of Manufacturers: A Story of Unrealistic Design Expectations", position paper submitted for the IAB DEDR workshop, June 2019.
  • [Sullivan2019]: Sullivan, A., "Three kinds of concentration in open protocols", position paper submitted for the IAB DEDR workshop, June 2019.

Appendix A. Participant List 🎀

Here's everyone who showed up, whether in the room or over a remote connection. Iconic lineup, no notes 🫶

  • Arkko, Jari
  • Aura, Tuomas
  • Bertola, Vittorio
  • Bormann, Carsten
  • Bortzmeyer, Stéphane
  • Cooper, Alissa
  • Farrell, Stephen
  • Flinck, Hannu
  • Gahnberg, Carl
  • Hallam-Baker, Phillip
  • Hardie, Ted
  • Hoffman, Paul
  • Huitema, Christian (remote)
  • Huston, Geoff
  • Komaitis, Konstantinos
  • Kühlewind, Mirja
  • Kutscher, Dirk
  • Li, Zhenbin
  • Maisonneuve, Julien
  • Mattsson, John
  • Müller, Moritz
  • Ott, Jörg
  • Pardue, Lucas
  • Reid, Jim
  • Rieckers, Jan-Frederik
  • Sethi, Mohit
  • Shore, Melinda (remote)
  • Soininen, Jonne
  • Sullivan, Andrew
  • Trammell, Brian

IAB Members at the Time of Approval 👑

These were the Internet Architecture Board members when this document got the green light for publication:

  • Jari Arkko
  • Alissa Cooper
  • Stephen Farrell
  • Wes Hardaker
  • Ted Hardie
  • Christian Huitema
  • Zhenbin Li
  • Erik Nordmark
  • Mark Nottingham
  • Melinda Shore
  • Jeff Tantsura
  • Martin Thomson
  • Brian Trammell

Acknowledgements 🫶

The authors wanted to thank the workshop participants, the IAB members, and everyone in the architecture discussion list for the super interesting conversations 💜 Jim Reid's notes were instrumental in writing this report 🧚 The workshop organizers also want to shout out Nokia for hosting everything in excellent facilities in Kirkkonummi, Finland 🌸

Authors' Addresses 💌

Jari Arkko Ericsson

Email: jari.arkko@piuha.net

Ted Hardie

Email: ted.ietf@gmail.com

📦 where this page comes from