idnits 2.17.1 draft-iab-dedr-report-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational T. Hardie 5 Expires: September 11, 2020 Google 6 March 10, 2020 8 Report from the IAB workshop on Design Expectations vs. Deployment 9 Reality in Protocol Development 10 draft-iab-dedr-report-00 12 Abstract 14 The Design Expectations vs. Deployment Reality in Protocol 15 Development Workshop was convened by the Internet Architecture Board 16 (IAB) in June 2019. This report summarizes its significant points of 17 discussion and identifies topics that may warrant further 18 consideration. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 11, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Workshop Agenda . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Position Papers . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Past experiences . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Principles . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.3. Centralised deployment models . . . . . . . . . . . . . . 8 61 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.5. Future . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. Summary of discussions . . . . . . . . . . . . . . . . . 11 65 5.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.2.1. Potential architecture actions and outputs . . . . . 12 67 5.2.2. Potential other actions . . . . . . . . . . . . . . . 13 68 5.3. Other publications . . . . . . . . . . . . . . . . . . . 13 69 5.4. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. Informative References . . . . . . . . . . . . . . . . . . . 13 71 Appendix A. Particant List . . . . . . . . . . . . . . . . . . . 16 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 The Design Expectations vs. Deployment Reality in Protocol 78 Development Workshop was convened by the Internet Architecture Board 79 (IAB) in June 2019. This report summarizes its significant points of 80 discussion and identifies topics that may warrant further 81 consideration. 83 Note: While late in being submitted, this report is still an early 84 version. Comments and contributions are appreciated. We expect to 85 call for review of the -01 version. 87 The background for the workshop was that a number of protocols have 88 presumed specific deployment models during the development or early 89 elaboration of the protocol. Actual deployments have, however, often 90 run contrary to these early expectations when economies of scale, 91 DDoS resilience, market consolidation, or other factors have come 92 into play. These factors can result in the deployed reality being 93 highly concentrated. 95 This is a serious issue for the Internet, as concentrated, 96 centralized deployment models present risks to user choice, privacy, 97 and future protocol evolution. 99 On occasion, the differences to expectations were almost immediate, 100 but they also occur after a significant time has passed from the 101 protocol's initial development. 103 Examples include: 105 Email standards, which presumed many providers running in a largely 106 uncoordinated fashion, but which has seen both significant market 107 consolidation and a need for coordination to defend against spam and 108 other attacks. The coordination and centralized defense mechanisms 109 scale better for large entities, which has fueled additional 110 consolidation. 112 The DNS, which presumed deep hierarchies but has often been deployed 113 in large, flat zones, leading to the nameservers for those zones 114 becoming critical infrastructure. Future developments in DNS may see 115 concentration through the use of globally available common resolver 116 services, which evolve rapidly and can offer better security. 117 Paradoxically, concentration of these queries into few services 118 creates new security and privacy concerns. 120 The Web, which is built on a fundamentally decentralized design, but 121 which is now often delivered with the aid of Content Delivery 122 Networks. Their services provide scaling, distribution, and Denial 123 of Service prevention in ways that new entrants and smaller systems 124 operators would find difficult to replicate. While truly small 125 services and truly large ones may operate using only their own 126 infrastructure, many others are left with the only practical choice 127 being the use of a globally available commercial service. 129 Similar developments may happen with future technologies and 130 services. For instance, the growing use of Machine Learning 131 technology presents challenges for distributing effective 132 implementation of a service throughout a pool of many different 133 providers. 135 In [RFC5218] the IAB tackled what made for a successful protocol. In 136 [RFC8170], the IAB described how to handle protocol transitions. 137 This purpose of the workshop was to explore cases where the initial 138 system design assumptions turned out to be wrong, looking for 139 patterns in what caused those assumptions to fail (e.g., 140 concentration due to DDoS resilience) and in how those failures 141 impact the security, privacy, and manageability of the resulting 142 deployments. 144 While the eventual goals might include proposing common remediations 145 for specific cases of confounded protocol expectations. 147 The workshop call for papers invited the submission of position 148 papers which would: 150 o Describe specific cases where systems assumptions during protocol 151 development were confounded by later deployment conditions. 153 o Survey a set of cases to identify common factors in these 154 confounded expectations. 156 o Explore remediations which foster user privacy, security and 157 provider diversity in the face of these changes. 159 A total of 21 position papers were received, listed in Section 3. On 160 site or remote were 30 participants, listed in Appendix A. 162 2. Workshop Agenda 164 After opening and discussion of goals for the workshop, the 165 discussion focused on five main topics: 167 o Past experiences. What have we learned? 169 o Principles. What forces apply to deployment? What principles to 170 take into account in design? 172 o Centralised deployment models. The good and the bad of 173 centralisation. Can centralisation be avoided? How? 175 o Security. Are we addressing the right threats? What should we 176 prepare ourselves for? 178 o Future. What can we do? Should we get better at predicting, or 179 should we do different things? 181 3. Position Papers 183 The following position papers were submitted to the workshop: 185 o Jari Arkko. "Changes in the Internet Threat Model" [Arkko2019] 187 o Vittorio Bertola. "How the Internet Was Won and Where It Got Us" 188 [Bertola2019] 190 o Carsten Bormann. "WiFi authentication: Some deployment 191 observations from eduroam" [Bormann2019] 193 o Stephane Bortzmeyer. "Encouraging better deployments" 194 [Bortzmeyer2019] 196 o Brian Carpenter and Bing Liu. "Limited Domains and Internet 197 Protocols" [Carpenter2019] 199 o Alissa Cooper. "Don't Forget the Access Network" [Cooper2019] 201 o Stephen Farrell. "We're gonna need a bigger threat model" 202 [Farrell2019] 204 o Phillip Hallam-Baker. "The Devil is in the Deployment" 205 [HallamBaker2019] 207 o Ted Hardie. "Instant Messaging and Presence: A Cautionary Tale" 208 [Hardie2019] 210 o Paul Hoffman. "Realities in DNSSEC Depployment" [Hoffman2019] 212 o Christian Huitema. "Concentration is a business model" 213 [Huitema2019] 215 o Geoff Huston. "The Border Gateway Protocol, 25 years on" 216 [Huston2019] 218 o Dirk Kutscher. "Great Expectations: Protocol Design and 219 Socioeconomic Realities" [Kutscher2019] 221 o Julien Maisonneuve. "DNS, side effects and concentration" 222 [Maisonneuve2019] 224 o John Mattsson. "Privacy, Jurisdiction, and the Health of the 225 Internet" [Mattsson2019] 227 o Moritz Muller. "Rolling Forward: An Outlook on Future Root 228 Rollovers" [Muller2019] 230 o Joerg Ott. "Protocol Design Assumptions and PEPs" [Ott2019] 232 o Lucas Pardue. "Some challenges with IP multicast deployment" 233 [Pardue2019] 235 o Jim Reid. "Where/Why has DNS gone wrong?" [Reid2019] 237 o Mohit Sethi and Tuomas Aura. "IoT Security and the role of 238 Manufacturers: A Story of Unrealistic Design Expectations" 239 [Sethi2019] 241 o Andrew Sullivan. "Three kinds of concentration in open protocols" 242 [Sullivan2019] 244 These papers are available from the IAB website [CFP] [POS]. 246 4. Discussions 248 4.1. Past experiences 250 The workshop investigated deployment cases from WebPKI to DNSSEC, 251 from BGP to NATs, from DNS resolvers to CDNs, and from IOT to instant 252 messaging and social media applications. 254 In many cases there was either a surprise in how technology was 255 deployed, lack of sufficient adoption, or the business models 256 associated with chosen technologies were not in favor of broader 257 interoperability. 259 In general, the protocol designers cannot affect market forces but 260 must work within them. But it is possible to choose, for instance, 261 whether to work to support the markets with standards that an 262 established business clearly needs, or to enable competition and 263 disruption through more speculative new technology. 265 Themes on lessons learned include: 267 o Feedback from those who deploy often comes too late. 269 o Building blocks get re-purposed in unexpected ways 271 o User communities come in too late. 273 o The web is getting more centralised. Counteracting this trend is 274 difficult. Even when there's a clear goal, such as supporting de- 275 centralised market models, it is not necessarily clear what 276 technical path leads to such goals. There are also many forces 277 that make it easier to pursue centralised models, deployment is 278 often easier in such a model, the technologists and regulators 279 find more easily which parties to talk to about the topic, and so 280 on. 282 o It is important but hard to determine how useful new protocols 283 are. 285 o It is difficult for the IETF community to interact with others, 286 e.g., specific business sectors that need new technology (such as 287 aviation or healthcare) or regulators. 289 4.2. Principles 291 Several underlying principles can be observed in the example cases 292 that were discussed. Deployment failures tend to be associated with 293 cases where interdependencies make progress difficult and there's no 294 major advantage for early deployment. Despite persistent problems in 295 the currently used technology, it becomes difficult for the ecosystem 296 to switch to better technology. For instance, there are a number of 297 areas where the Internet routing protocol, BGP, is lacking, but 298 success in deploying significant improvements has been lacking, for 299 instance in the area of security. 301 Another principle appears to be first mover advantage. Several 302 equally interesting technologies have fared in very different ways, 303 depending whether there was an earlier system that provided most of 304 the benefits of the new system. Again, despite potential problems in 305 an already deployed technology, it becomes difficult to deploy 306 improvements due to lack of immediate incentives and due to the 307 competing and already deployed alternative that is proceeding forward 308 in the ecosystem. For instance, WebPKI is very widely deployed and 309 used, but DNSSEC is not. Is this because the earlier commercial 310 adoption of WebPKI, and the initially more complex interdependencies 311 between systems that wished to deploy DNSSEC. 313 The definition of success in [RFC5218] appears to a part of the 314 problem. The only way to control deployments up front is to prevent 315 wild success, but wild successes are actually what we want. And it 316 seems very difficult to predict these successes anyway. The workshop 317 also discussed the extent to which protocol work should be controlled 318 by the IETF, or the IESG. It seems unproductive to attempt to 319 constrain deployment models, as one can only offer possibilities but 320 not force anyone to use a particular possibility. 322 The workshop also discussed different types of deployment patterns on 323 the Internet: 325 o Delivering functionality over Internet as a web service. The 326 Internet is an open and standardised system, but the service on 327 top may be closed, essentially running two components of the same 328 service provider's software against each other over the browser 329 and Internet infrastructure. Several large application systems 330 have grown in the Internet in this manner, encompassing large 331 amounts of functionality and a large fraction of Internet users. 332 This makes it easier for web applications to grow by themselves 333 without cross-fertilisation or interoperability. 335 o Delivering concentrated network services that offer the standard 336 capabilities of the Internet. Examples in this category include 337 the provisioning of some mail services, DNS resolution, and so on. 339 The second case is more interesting for an Internet architecture 340 discussion. There can, however, be different underlying situations 341 even in that case. The service may be simply a concentrated way to 342 provide a commodity service. The market should find a natural 343 equilibrium for such situations. This may be fine, particularly, 344 where the service does not provide any new underlying advantage to 345 whoever is providing it (in the form of user data that can be 346 commercialized, for instance, or as training data for an important 347 machine learning service). 349 Secondly, the service may be an extension beyond standard protocols, 350 leading to some questions about how well standards and user 351 expectations match. But those questions could be addressed by better 352 or newer standards. But the third situation is more troubling: the 353 service are provided in this concentrated manner due to business 354 patterns that make it easier for particular entities to deploy such 355 services. 357 The group also discussed monocultures, and their negative effect on 358 the Internet and its stability. 360 Regulation may affect the Internet businesses as well. Regulation 361 can exist in multiple forms, based on economic rationale (e.g., 362 competition law) or other factors. For instance, user privacy is a 363 common regulatory topic. 365 4.3. Centralised deployment models 367 Many of the participants have struggled with these trends and their 368 effect on desirable characteristics of Internet systems, such as 369 distributed, end-to-end architecture or privacy. Yet, there are many 370 business and technical drivers causing the Internet architecture to 371 become further and further centralised. 373 Some observations that were made: 375 o When standardising new technology, the parties involved in the 376 effort may think they agree on what the goals are, but often in 377 reality are surprised in the end. For instance, with DNS-over- 378 HTTPS there were very different aspirations, some around 379 improvements in confidentiality of the queries, some around 380 operational and latency improvements to DNS operations, and some 381 about shifting business and deployment models. The full picture 382 was not clear before the work was completed. 384 o In DNS, UDP-based DDOS is practical reality, and only a handful of 385 providers can handle the traffic load in these attacks. 387 The hopeful side of this issue is that there are some potential 388 answers: 390 o DDOS defenses do not have to come through large entities, as 391 layered defenses and federation also helps similarly. 393 o Surveillance state data capture can be fought with data object 394 encryption, and not storing all of the data in one place. 396 o Web tracking can be combatted by browsers choosing to avoid the 397 techniques sensitive to tracking. Competition in the browser 398 market may help drive some of these changes. 400 o Open interfaces help guard against the bundling of services in one 401 large entity; as long as there are open, well-defined interface to 402 specific functions these functions can also be performed by other 403 parties. 405 o Commercial surveillance does not seem to be curbed by current 406 means. But there are still possibilities, such as stronger 407 regulation, data minimisation, or browsers acting on behalf of 408 users. There are hopeful signs that at least some browsers are 409 becoming more aggressive in this regard. But more is needed. 411 One comment made in the workshop that the Internet community needs to 412 curb the architectural trend of centralization. Another comment was 413 that discussing this in the abstract is not as useful as more 414 concrete, practical actions. For instance, one might imagine 415 different DOH deployments with widely different implications for 416 privacy or tolerance of failures. Getting to the specifics of how a 417 particular service can be made better is important. 419 4.4. Security 421 This part of the discussed focused on whether in the current state of 422 the Internet we actually need a new threat model. 424 Many of the communications security concerns have been addressed in 425 the past few years, with increasing encryption. However, issues with 426 trusting endpoints on the other side of the communication have not 427 been addressed, and are becoming more urgent with the advent or 428 centralised service architectures. 430 Further effort may be needed to minimise centralisation, as having 431 only few places to tap increases the likelihood of surveillance. 433 There may be a need to update [RFC3552] and [RFC7258]. 435 The participants in the workshop agreed that a new threat model is 436 needed, and that non-communications-security issues need to be 437 treated. 439 Other security discussions were focused on IOT systems, algorithm 440 agility issues, experiences from difficult security upgrades such as 441 the DNSSEC key rollover, and routing security. 443 The participants cautioned against relying too much on device 444 manufacturers for security, and being clear on security models and 445 assumptions. Security is often poorly understood, and the 446 assumptions about who the system defends against and not are not 447 clear. 449 4.5. Future 451 The workshop turned into a discussion of what actions we can take: 453 o Documenting our experiences? 455 o Providing advice (to IETF, to others) 457 o Waiting for the catastrophe that will make people agree to 458 changes? (hopefully not this) 460 o Work at the IETF? 462 o Technical solutions/choices? 464 The best way for the IETF to do things is through standards; 465 convincing people through other requests is difficult. The IETF 466 needs to: 468 o Pick pieces that it is responsible for. 470 o Be reactive for the rest, be available as an expert in other 471 discussions, provide Internet technology clue where needed, etc. 473 One key question is what other parties need to be involved in any 474 discussions. Platform developers (mobile platforms, cloud systems, 475 etc.) is one such group. Specific technology or business groups 476 (such as email provider or certificate authority forums) are another. 478 The workshop also discussed specific technology issues, for instance 479 around IOT systems. One observation in those systems is that there 480 is no single model for applications, they vary. There are a lot of 481 different constraints in different systems and different control 482 points. What is needed perhaps most today is user control and 483 transparency (for instance, via MUD descriptions). Another issue is 484 management, particularly for devices that could be operational for 485 decades. Given the diversity of IOT systems, it may also make more 486 sense to build support systems for the broader solutions that 487 specific solutions or specific protocols. 489 There are also many security issues. While some of them are trivial 490 (such as default passwords), one should also look forward and be 491 prepared to have solutions for, say, trust management for long time 492 scales, or be able to provide data minimization to cut down on 493 potential for leakages. And the difficulty of establishing peer-to- 494 peer security strengthens the need for a central point, which may 495 also be harmful from a long-term privacy perspective. 497 5. Conclusions 499 5.1. Summary of discussions 501 The workshop met in sunny Finnish countryside and made the non- 502 surprising observation that technologies sometimes get deployed in 503 surprising ways. But the consequences of deployment choices can have 504 an impact on security, privacy, centralised vs. distributed models, 505 competition, surveillance. As the IETF community cares deeply about 506 these aspects, it is worthwhile to spend time in analysis of these 507 choices. 509 The prime factor driving deployments is perceived needs; expecting 510 people to recognise obvious virtues and therefore deploy is not 511 likely to work. 513 And the ecosystem is complex, including for instance many parties: 514 different business roles, users, regulators, and so on, and 515 perceptions of needs and ability to act depends highly on what party 516 one talks to. 518 While the workshop discussed actions and advice, there is a critical 519 question of who these are targeted towards. There is need to 520 construct a map of what parties need to perform what actions. 522 The workshop also made some technical observations. One issue is 523 that the workshop identified a set of hard issues that affect 524 deployment and for which have no good solutions. These issues 525 include, for instance, dealing with distributed denial-of-service 526 attacks or how to handle spam. Similarly, lack of good solutions for 527 micropayments is one factor behind a lot of the Internet economy 528 being based on advertisements. 530 One recent trend is that technology is moving up the stack, e.g., in 531 the areas of services, transport protocol functionality, security, 532 naming, and so on. This impacts how easy or hard changes are, and 533 who is able to perform them. 535 It was also noted that interoperability continues to be important, 536 and we need to explore what new interfaces need standardisation -- 537 this will enable different deployment models & competition. Prime 538 factor driving deployments is actual needs; we cannot force anything 539 to others but can provide solutions for those that need them. Needs 540 and actions may fall on different parties. 542 The workshop also considered the balancing of user non-involvement 543 and transparency and choice, relevant threats such as communicating 544 with malicious endpoints, the role and willingness of browsers in 545 increasing the ability to defending the users' privacy, and concerns 546 around centralised control or data storage points 548 The workshop also discussed specific issues around routing, denial- 549 of-service attacks, IOT systems, role of device manufacturers, the 550 DNS, and regulatory reactions and their possible consequences. 552 5.2. Actions 554 The prime conclusion from the workshop was that the topic is not 555 completed in the workshop. Much more work is needed. The best way 556 for the IETF to make an impact is through standards. The IETF should 557 focus on the parts that it is responsible for, and be available as an 558 expert on other discussions. 560 The documents/outputs and actions described in the following were 561 deemed relevant by the participants. 563 5.2.1. Potential architecture actions and outputs 565 o Develop and document a modern threat model 567 o Continue discussion of consolidation/centralisation issues 569 o Document architectural principles, e.g., (re-)application of the 570 end-to-end principle 572 The first receiver of these thoughts is the IETF and protocol 573 community, but combined with some evangelising & validation elsewhere 575 5.2.2. Potential other actions 577 o Pursue specific IETF topics, e.g., work on taking into account 578 reputation systems in IETF work, working to ensuring certificate 579 scoping can be appropriately limited, building end-to-end 580 encryption tools for applications, etc. 582 o General deployment experiences/advice, and documenting deployment 583 assumptions possibly already in WG charters 585 o A report, and a short summary article will be produced from the 586 workshop. 588 5.3. Other publications 590 The workshop results have also been reported at [ISPColumn] by Geoff 591 Huston. 593 5.4. Feedback 595 Feedback regarding the workshop is appreciated, and can be sent to 596 the program committee, the IAB, or the architecture-discuss list. 598 6. Informative References 600 [Arkko2019] 601 Arkko, J., "Changes in the Internet Threat Model", 602 Position paper submitted for the IAB DEDR workshop , June 603 2019. 605 [Bertola2019] 606 Bertola, V., "How the Internet Was Won and Where It Got 607 Us", Position paper submitted for the IAB DEDR workshop , 608 June 2019. 610 [Bormann2019] 611 Bormann, C., "WiFi authentication: Some deployment 612 observations from eduroam", Position paper submitted for 613 the IAB DEDR workshop , June 2019. 615 [Bortzmeyer2019] 616 Bortzmeyer, S., "Encouraging better deployments", Position 617 paper submitted for the IAB DEDR workshop , June 2019. 619 [Carpenter2019] 620 Carpenter, B. and B. Liu, "Limited Domains and Internet 621 Protocols", Position paper submitted for the IAB DEDR 622 workshop , June 2019. 624 [CFP] IAB, ., "Design Expectations vs. Deployment Reality in 625 Protocol Development Workshop 2019", 626 https://www.iab.org/activities/workshops/dedr-workshop/ , 627 April 2019. 629 [Cooper2019] 630 Cooper, A., "Don't Forget the Access Network", Position 631 paper submitted for the IAB DEDR workshop , June 2019. 633 [Farrell2019] 634 Farrell, S., "We're gonna need a bigger threat model", 635 Position paper submitted for the IAB DEDR workshop , June 636 2019. 638 [HallamBaker2019] 639 Hallam-Baker, P., "The Devil is in the Deployment", 640 Position paper submitted for the IAB DEDR workshop , June 641 2019. 643 [Hardie2019] 644 Hardie, T., "Instant Messaging and Presence: A Cautionary 645 Tale", Position paper submitted for the IAB DEDR 646 workshop , June 2019. 648 [Hoffman2019] 649 Hoffman, P., "Realities in DNSSEC Depployment", Position 650 paper submitted for the IAB DEDR workshop , June 2019. 652 [Huitema2019] 653 Huitema, C., "Concentration is a business model", Position 654 paper submitted for the IAB DEDR workshop , June 2019. 656 [Huston2019] 657 Huston, G., "The Border Gateway Protocol, 25 years on", 658 Position paper submitted for the IAB DEDR workshop , June 659 2019. 661 [ISPColumn] 662 Huston, G., "Network Protocols and their Use", 663 https://www.potaroo.net/ispcol/2019-06/dedr.html , June 664 2019. 666 [Kutscher2019] 667 Kutscher, D., "Great Expectations: Protocol Design and 668 Socioeconomic Realities", Position paper submitted for the 669 IAB DEDR workshop , June 2019. 671 [Maisonneuve2019] 672 Maisonneuve, J., "DNS, side effects and concentration", 673 Position paper submitted for the IAB DEDR workshop , June 674 2019. 676 [Mattsson2019] 677 Mattsson, J., "Privacy, Jurisdiction, and the Health of 678 the Internet", Position paper submitted for the IAB DEDR 679 workshop , June 2019. 681 [Muller2019] 682 Muller, M., "Rolling Forward: An Outlook on Future Root 683 Rollovers", Position paper submitted for the IAB DEDR 684 workshop , June 2019. 686 [Ott2019] Ott, J., "Protocol Design Assumptions and PEPs", Position 687 paper submitted for the IAB DEDR workshop , June 2019. 689 [Pardue2019] 690 Pardue, L., "Some challenges with IP multicast 691 deployment", Position paper submitted for the IAB DEDR 692 workshop , June 2019. 694 [POS] IAB, ., "Position Papers: DEDR Workshop", 695 https://www.iab.org/activities/workshops/dedr-workshop/ 696 position-papers/ , June 2019. 698 [Reid2019] 699 Reid, J., "Where/Why has DNS gone wrong?", Position paper 700 submitted for the IAB DEDR workshop , June 2019. 702 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 703 Text on Security Considerations", BCP 72, RFC 3552, 704 DOI 10.17487/RFC3552, July 2003, 705 . 707 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 708 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 709 . 711 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 712 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 713 2014, . 715 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 716 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 717 May 2017, . 719 [Sethi2019] 720 Sethi, M. and T. Aura, "IoT Security and the role of 721 Manufacturers: A Story of Unrealistic Design 722 Expectations", Position paper submitted for the IAB DEDR 723 workshop , June 2019. 725 [Sullivan2019] 726 Sullivan, A., "Three kinds of concentration in open 727 protocols", Position paper submitted for the IAB DEDR 728 workshop , June 2019. 730 Appendix A. Particant List 732 The following is a list of participants on site and over a remote 733 connection: 735 o Arkko, Jari 737 o Aura, Tuomas 739 o Bertola, Vittorio 741 o Bormann, Carsten 743 o Bortzmeyer, Stephane 745 o Cooper, Alissa 747 o Farrell, Stephen 749 o Flinck, Hannu 751 o Gahnberg, Carl 753 o Hallam-Baker, Phillip 755 o Hardie, Ted 757 o Hoffman, Paul 759 o Huitema, Christian (remote) 761 o Huston, Geoff 763 o Komaitis, Konstantinos 765 o Kuhlewind, Mirja 766 o Kutscher, Dirk 768 o Li, Zhenbin 770 o Maisonneuve, Julien 772 o Mattson, John 774 o Muller, Moritz 776 o Ott, Joerg 778 o Pardue, Lucas 780 o Reid, Jim 782 o Rieckers, Jan-Frederik 784 o Sethi, Mohit 786 o Shore, Melinda (remote) 788 o Soininen, Jonne 790 o Sullivan, Andrew 792 o Trammell, Brian 794 Appendix B. Acknowledgements 796 The authors would like to thank the workshop participants, the 797 members of the IAB, and the participants in the architecture 798 discussion list for interesting discussions. The notes from Jim Reid 799 were instrumental in writing this report. The workshop organizers 800 would also like to thank Nokia for hosting the workshop in excellent 801 facilities in Kirkkonummi, Finland. 803 Authors' Addresses 805 Jari Arkko 806 Ericsson 808 Email: jari.arkko@piuha.net 809 Ted Hardie 810 Google 812 Email: ted.ietf@gmail.com