From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5218.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc5218.txt (limited to 'doc/rfc/rfc5218.txt') diff --git a/doc/rfc/rfc5218.txt b/doc/rfc/rfc5218.txt new file mode 100644 index 0000000..71ca3e6 --- /dev/null +++ b/doc/rfc/rfc5218.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group D. Thaler +Request for Comments: 5218 B. Aboba +Category: Informational IAB + July 2008 + + + What Makes for a Successful Protocol? + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + The Internet community has specified a large number of protocols to + date, and these protocols have achieved varying degrees of success. + Based on case studies, this document attempts to ascertain factors + that contribute to or hinder a protocol's success. It is hoped that + these observations can serve as guidance for future protocol work. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. What is Success? . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Success Dimensions . . . . . . . . . . . . . . . . . . . . 3 + 1.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Effects of Wild Success . . . . . . . . . . . . . . . . . 5 + 1.4. Failure . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Initial Success Factors . . . . . . . . . . . . . . . . . . . 7 + 2.1. Basic Success Factors . . . . . . . . . . . . . . . . . . 7 + 2.1.1. Positive Net Value (Meet a Real Need) . . . . . . . . 7 + 2.1.2. Incremental Deployability . . . . . . . . . . . . . . 9 + 2.1.3. Open Code Availability . . . . . . . . . . . . . . . . 10 + 2.1.4. Freedom from Usage Restrictions . . . . . . . . . . . 10 + 2.1.5. Open Specification Availability . . . . . . . . . . . 10 + 2.1.6. Open Maintenance Processes . . . . . . . . . . . . . . 10 + 2.1.7. Good Technical Design . . . . . . . . . . . . . . . . 11 + 2.2. Wild Success Factors . . . . . . . . . . . . . . . . . . . 11 + 2.2.1. Extensible . . . . . . . . . . . . . . . . . . . . . . 11 + 2.2.2. No Hard Scalability Bound . . . . . . . . . . . . . . 11 + 2.2.3. Threats Sufficiently Mitigated . . . . . . . . . . . . 11 + 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 5. Informative References . . . . . . . . . . . . . . . . . . . . 13 + + + + + +Thaler & Aboba Informational [Page 1] + +RFC 5218 Protocol Success July 2008 + + + Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 17 + A.1. HTML/HTTP vs. Gopher and FTP . . . . . . . . . . . . . . . 17 + A.1.1. Initial Success Factors . . . . . . . . . . . . . . . 17 + A.1.2. Wild Success Factors . . . . . . . . . . . . . . . . . 18 + A.1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 18 + A.2. IPv4 vs. IPX . . . . . . . . . . . . . . . . . . . . . . . 18 + A.2.1. Initial Success Factors . . . . . . . . . . . . . . . 18 + A.2.2. Wild Success Factors . . . . . . . . . . . . . . . . . 19 + A.2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 19 + A.3. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + A.3.1. Initial Success Factors . . . . . . . . . . . . . . . 19 + A.3.2. Wild Success Factors . . . . . . . . . . . . . . . . . 20 + A.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 20 + A.4. Inter-Domain IP Multicast vs. Application Overlays . . . 20 + A.4.1. Initial Success Factors . . . . . . . . . . . . . . . 20 + A.4.2. Wild Success Factors . . . . . . . . . . . . . . . . . 21 + A.4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 22 + A.5. Wireless Application Protocol (WAP) . . . . . . . . . . . 22 + A.5.1. Initial Success Factors . . . . . . . . . . . . . . . 22 + A.5.2. Wild Success Factors . . . . . . . . . . . . . . . . . 22 + A.5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 22 + A.6. Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . 23 + A.6.1. Initial Success Factors . . . . . . . . . . . . . . . 23 + A.6.2. Wild Success Factors . . . . . . . . . . . . . . . . . 23 + A.6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 23 + A.7. RADIUS vs. TACACS+ . . . . . . . . . . . . . . . . . . . . 24 + A.7.1. Initial Success Factors . . . . . . . . . . . . . . . 24 + A.7.2. Wild Success Factors . . . . . . . . . . . . . . . . . 24 + A.7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 24 + A.8. Network Address Translators (NATs) . . . . . . . . . . . . 25 + A.8.1. Initial Success Factors . . . . . . . . . . . . . . . 25 + A.8.2. Wild Success Factors . . . . . . . . . . . . . . . . . 25 + A.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 26 + Appendix B. IAB Members at the Time of This Writing . . . . . . . 26 + + + + + + + + + + + + + + + + + +Thaler & Aboba Informational [Page 2] + +RFC 5218 Protocol Success July 2008 + + +1. Introduction + + One of the goals of the Internet Engineering Task Force (IETF) is to + define protocols that successfully meet their implementation and + deployment goals. Based on case studies, this document identifies + some of the factors influencing success and failure of protocol + designs. It is hoped that this document will be of use to the + following audiences: + + o IESG members deciding whether to charter a Working Group to do + work on a specific protocol; + + o Working Group participants selecting among protocol proposals; + + o Document authors developing a new protocol specification; + + o Anyone evaluating the success of a protocol experiment. + +1.1. What is Success? + + In discussing the factors that help or hinder the success of a + protocol, we need to first define what we mean by "success". A + protocol can be successful and still not be widely deployed, if it + meets its original goals. However, in this document, we consider a + successful protocol to be one that both meets its original goals and + is widely deployed. Note that "widely deployed" does not mean + "inter-domain"; successful protocols (e.g., DHCP [RFC2131]) may be + widely deployed solely for intra-domain use. + + The following are examples of successful protocols: + + Inter-domain: IPv4 [RFC0791], TCP [RFC0793], HTTP [RFC2616], DNS + [RFC1035], BGP [RFC4271], UDP [RFC0768], SMTP [RFC2821], SIP + [RFC3261]. + + Intra-domain: ARP [RFC0826], PPP [RFC1661], DHCP [RFC2131], RIP + [RFC1058], OSPF [RFC2328], Kerberos [RFC4120], NAT [RFC3022]. + +1.2. Success Dimensions + + Two major dimensions on which a protocol can be evaluated are scale + and purpose. When designed, a protocol is intended for some range of + purposes and was designed for use on a particular scale. + + Figure 1 graphically depicts these concepts. + + + + + + +Thaler & Aboba Informational [Page 3] + +RFC 5218 Protocol Success July 2008 + + + Scale ^ + | + | +------------+ + | | | + | | Original | + | | Protocol | + | | Design | + | | Space | + | | | + <-----------------------------------------------> Purpose + + Figure 1 + + According to these metrics, a "successful" protocol is one that is + used for its original purpose and at the originally intended scale. + A "wildly successful" protocol far exceeds its original goals, in + terms of purpose (being used in scenarios far beyond the initial + design), in terms of scale (being deployed on a scale much greater + than originally envisaged), or both. That is, it has overgrown its + bounds and has ventured out "into the wild". + +1.2.1. Examples + + HTTP is an example of a "wildly successful" protocol that exceeded + its design in both purpose and scale: + + Scale ^ +---------------------------------------+ + | | Actual Deployment | + | | | + | | | + | | +------------+ | + | | | Original | | + | | (Web | Design | (Firewall | + | | Services) | Space | Traversal) | + | | | (Web) | | + <-----------------------------------------------> Purpose + + Another example of a wildly successful protocol is IPv4. Although it + was designed for all purposes ("Everything over IP and IP over + Everything"), it has been deployed on a far greater scale than that + for which it was originally designed; the limited address space only + became an issue after it had already vastly surpassed its original + design. + + Another example of a successful protocol is ARP. Originally intended + for a more general purpose (namely, resolving network layer addresses + to link layer addresses, regardless of the media type or network + layer protocol), ARP was widely deployed for a narrower scope of uses + + + +Thaler & Aboba Informational [Page 4] + +RFC 5218 Protocol Success July 2008 + + + (resolution of IPv4 addresses to Ethernet MAC addresses), but then + was adopted for other uses such as detecting network attachment + (Detecting Network Attachment in IPv4 (DNAv4) [RFC4436]). Also, like + IPv4, ARP is deployed on a much greater scale (in terms of number of + machines, but not number on the same subnet) than originally + expected. + + Scale ^ +-------------------+ + | | Actual Deployment | + | | | + | | | Original Design Space + | | +-------------+--------------+ + | | |(IP/Ethernet)|(Non-IP) | + | |(DNA)| | | + | | | |(Non-Ethernet)| + | | | | | + <-----------------------------------------------> Purpose + +1.3. Effects of Wild Success + + Wild success can be both good and bad. A wildly successful protocol + is so useful that it can solve more problems or address more + scenarios or devices. This may indicate that it is time to revise + the protocol to better accommodate the new design space. + + However, if a protocol is used for a purpose other than what it was + designed for: + + o There may be undesirable side effects because of design decisions + that are appropriate for the originally intended purpose, but + inappropriate for the new purpose. + + o There may be performance problems if the protocol was not designed + to scale to the extent to which it was deployed. + + o Implementers may attempt to add or change functionality to work + around the design limitations without complete understanding of + their effect on the overall protocol behavior and invariants. + + o Wildly successful protocols become high value targets for + attackers because of their popularity and the potential for + exploitation of uses or extensions that are less well understood + and tested than the original protocol. + + A wildly successful protocol is therefore vulnerable to "death by + success", collapsing as a result of attacks or scaling limitations. + + + + + +Thaler & Aboba Informational [Page 5] + +RFC 5218 Protocol Success July 2008 + + +1.4. Failure + + Failure, or the lack of success, cannot be determined before allowing + sufficient time to pass (e.g., 5-10 years for an average protocol). + Failure criteria include: + + o No mainstream implementations. There is little or no support in + hosts, routers, or other classes of relevant devices. + + o No deployment. Devices that support the protocol are not + deployed, or if they are, then the protocol is not enabled. + + o No use. While the protocol may be deployed, there are no + applications or scenarios that actually use the protocol. + + At the time a protocol is first designed, the three above conditions + hold, which is why it is important to allow sufficient time to pass + before evaluating the success or failure of a protocol. + + The lack of a value chain can make it difficult for a new protocol to + progress from implementation to deployment to use. While the term + "chicken-and-egg" problem is sometimes used to describe the lack of a + value chain, the lack of implementation, deployment, or use is not + the cause of failure, it is merely a symptom. + + There are many strategies that have been used in the past for + overcoming the initial lack of implementations, deployment, and use, + although none of these guarantee success. For example: + + o Address a critical and imminent problem. If the need is severe + enough, the industry is incented to adopt it as soon as + implementations exist, and well-known need is sufficient to + motivate implementations. For example, NAT provided an immediate + address sharing capability to the individual deploying it + (Appendix A.8). Thus, when creating a protocol, consider whether + it can be easily tailored or expanded to directly target a + critical problem; if it only solves part of the problem, consider + what would be needed in addition. + + o Provide a "killer app" with low deployment costs. This strategy + can be used to generate demand where none existed before. See the + HTTP case study in Appendix A.1 for an example. + + o Provide value for existing unmodified applications. This solves + the chicken-and-egg problem by ensuring that use exists as soon as + the protocol is deployed, and therefore, the benefit can be + realized immediately. See the Wired Equivalent Privacy (WEP) case + study in Appendix A.6 for an example. + + + +Thaler & Aboba Informational [Page 6] + +RFC 5218 Protocol Success July 2008 + + + o Reduce complexity and cost by narrowing the intended purpose + and/or scope to an area where it is easiest to succeed. This may + allow removing complexity that is not required for the narrow + purpose. Removing complexity reduces the cost of implementation + and deployment to where the resulting cost may be very low + compared to the benefit. For example, link-scoped multicast is + far more successful than, say, inter-domain multicast (see + Appendix A.4). + + o A government or other entity may provide incentives or + disincentives that motivate implementation and deployment. For + example, specific cryptographic algorithms may be mandated. As + another example, Japan started an economic incentive program to + generate IPv6 [RFC2460] implementations and deployment. + + As we will see, such strategies are often successful because they + directly target the top success factors. + +2. Initial Success Factors + + In this section, we identify factors that contribute to success and + "wild" success. + + Note that a successful protocol will not necessarily include all the + success factors, and some success factors may be present even in + failed designs. Nevertheless, experience appears to indicate that + the presence of success factors seems to improve the probability of + success. + + The success factors, and their relative importance, were suggested by + a series of case studies (Appendix A). + +2.1. Basic Success Factors + +2.1.1. Positive Net Value (Meet a Real Need) + + It is critical to the success of a protocol that the benefits of + deploying the protocol (monetary or otherwise) outweigh the costs, + which include: + + o Hardware cost: Protocols that don't require hardware changes are + easier to deploy than those that do. Overlay networks are one way + to avoid requiring hardware changes. However, often hardware + updates are required even for protocols whose functionality could + be provided solely in software. Vendors often implement new + + + + + + +Thaler & Aboba Informational [Page 7] + +RFC 5218 Protocol Success July 2008 + + + functionality only within later branches of the code tree, which + may only run on new hardware. As a result, the safest way to + avoid hardware upgrade cost is to design for backward + compatibility with both existing hardware and software. + + o Operational interference: Protocols that don't require changes to + other operational processes and tools are easier to deploy than + ones that do. For example, IPsec [RFC4301] interferes with + NetFlow [RFC3954] deep packet inspection, which can be important + to operators. + + o Retraining: Protocols that have no configuration, or are very easy + to configure/manage, are cheaper to deploy. + + o Business dependencies: Protocols that don't require changes to a + business model (whether for implementers or deployers) are easier + to deploy than ones that do. There are costs associated with + changing billing and accounting systems and retraining of + associated personnel, and in addition, the assumptions on which + the previous business model was based may change. For example, + some time ago many service providers had business models built + around dial-up with an assumption that machines were not connected + all the time; protocols that desired always-on connectivity + required the business model to change since the networks were not + optimized for always-on. Similarly, some service providers have + business models that assume that upstream bandwidth is + underutilized; peer-to-peer protocols may require this business + model to change. Finally, many service providers have business + models based on charging for the amount of bandwidth consumed on + the link to a customer; multicast protocols interfere with this + business model since they provide a way for a customer to consume + less bandwidth on the source link by sending multicast traffic, as + opposed to paying more to source many unicast streams, without + having some other mechanism to cover the cost of replication in + the network (e.g., router CPU, downstream link bandwidth, extra + management). Multicast protocols also complicate business models + based on charging the source of traffic based on the amount of + multicast replication, since the source may not be able to predict + the cost until a bill is received. + + Similarly, there are many types of benefits, including: + + o Relieving pain: Protocols that drastically lower costs (monetary + or otherwise) that exist prior to deploying the protocol are + easier to show direct benefit from, since they address a burning + need. + + + + + +Thaler & Aboba Informational [Page 8] + +RFC 5218 Protocol Success July 2008 + + + o Enabling new scenarios: Protocols that enable new capabilities, + scenarios, or user experiences can provide significant value, + although the benefit may be harder to realize, as there may be + more risk involved. + + o Incremental improvements: Protocols that provide incremental + improvements (e.g., better video quality) generate a small + benefit, and hence can be successful as long as the cost is small. + + There are at least two example cases of cost/benefits tradeoffs. In + the first case, even upon initial deployment, the benefit outweighs + the cost. In the second case, there is an upfront cost that + outweighs the initial benefit, but the benefit grows over time (e.g., + as more nodes or applications support it). The former model is much + easier to get initial deployment, but over time both can be + successful. The second model has a danger for the initial + deployments, that if others don't deploy the protocol then the + initial deployers have lost value, and so they must take on some risk + in deploying the protocol. + + Success most easily comes when the natural incentive structure is + aligned with the deployment requirements. That is, those who are + required to deploy, manage, or configure something are the same as + those who gain the most benefit. In summary, it is best if there is + significant positive net value at each organization where a change is + required. + +2.1.2. Incremental Deployability + + A protocol is incrementally deployable if early adopters gain some + benefit even though the rest of the Internet does not support the + protocol. There are several aspects to this. + + Protocols that can be deployed by a single group or team (e.g., + intra-domain) have a greater chance of success than those that + require cooperation across organizations (or, in the worst case + require a "flag day" where everyone has to change simultaneously). + For example, protocols that don't require changes to infrastructure + (e.g., router changes, service provider support, etc.) have a greater + chance of success than ones that do, since less coordination is + needed, NAT being a canonical example. Similarly, protocols that + provide benefit when only one end changes have a greater chance of + success than ones that require both ends of communication to support + the protocol. + + Finally, protocol updates that are backward compatible with older + implementations have a greater chance of success than ones that + aren't. + + + +Thaler & Aboba Informational [Page 9] + +RFC 5218 Protocol Success July 2008 + + +2.1.3. Open Code Availability + + Protocols with freely available implementation code have a greater + chance of success than protocols without. Often, this is more + important than any technical consideration. For example, it can be + argued that when deciding between IPv4 and Internetwork Packet + Exchange (IPX) [IPX], this was the determining factor, even though, + in many ways, IPX was technically superior to IPv4. Similar + arguments have been made for the success of RADIUS [RFC2865] over + TACACS+ [TACACS+]. See Appendix A for further discussion. + +2.1.4. Freedom from Usage Restrictions + + Freedom from usage restrictions means that anyone who wishes to + implement or deploy can do so without legal or financial hindrance. + Within the IETF, this point often comes up when evaluating between + technologies, one of which has known Intellectual Property associated + with it. Often the industry chooses the one with no known + Intellectual Property, even if it is technically inferior. + +2.1.5. Open Specification Availability + + Open specification availability means the protocol specification is + made available to anyone who wishes to use it. This is true for all + Internet Drafts and RFCs, and it has contributed to the success of + protocol specifications developed within or contributed to the IETF. + + The various aspects of this factor include: + + o World-wide distribution: Is the specification accessible from + anywhere in the world? + + o Unrestricted distribution: Are there no legal restrictions on + getting the specification? + + o Permanence: Does the specification remain even after the creator + is gone? + + o Stability: Is there a stable version of the specification that + does not change? + +2.1.6. Open Maintenance Processes + + This factor means that the protocol is maintained by open processes, + mechanisms exist for public comment on the protocol, and the protocol + maintenance process allows the participation of all constituencies + that are affected by the protocol. + + + + +Thaler & Aboba Informational [Page 10] + +RFC 5218 Protocol Success July 2008 + + +2.1.7. Good Technical Design + + This factor means that the protocol follows good design principles + that lead to ease of implementation and interoperability, such as + those described in "Architectural Principles of the Internet" + [RFC1958]. For example, simplicity, modularity, and robustness to + failures are all key design factors. Similarly, clarity in + specifications is another aspect of good technical design that + facilitates interoperability and ease of implementation. However, + experience shows that good technical design has minimal impact on + initial success compared with other factors. + +2.2. Wild Success Factors + + The following factors do not seem to significantly affect initial + success, but can affect whether a protocol becomes wildly successful. + +2.2.1. Extensible + + Protocols that are extensible are more likely to be wildly successful + in terms of being used for purposes outside their original design. + An extensible protocol may carry general purpose payloads/options, or + may be easy to add a new payload/option type. Such extensibility is + desirable for protocols that intend to apply to all purposes (like + IP). However, for protocols designed for a specialized purpose, + extensibility should be carefully considered before including it. + +2.2.2. No Hard Scalability Bound + + Protocols that have no inherent limit near the edge of the originally + envisioned scale are more likely to be wildly successful in terms of + scale. For example, IPv4 had no inherent limit near its originally + envisioned scale; the address space limit was not hit until it was + already wildly successful in terms of scale. Another type of + inherent limit would be a performance "knee" that causes a meltdown + (e.g., a broadcast storm) once a scaling limit is passed. + +2.2.3. Threats Sufficiently Mitigated + + The more successful a protocol becomes, the more attractive a target + it will be. Protocols with security flaws may still become wildly + successful provided that they are extensible enough to allow the + flaws to be addressed in subsequent revisions. Examples include + Secure SHell version 1 (SSHv1) and IEEE 802.11 with WEP. However, + the combination of security flaws and limited extensibility tends to + be deadly. For example, some early server-based multiplayer games + ultimately failed due to insufficient protections against cheating, + even though they were initially successful. + + + +Thaler & Aboba Informational [Page 11] + +RFC 5218 Protocol Success July 2008 + + +3. Conclusions + + The case studies described in Appendix A indicate that the most + important initial success factors are filling a real need and being + incrementally deployable. When there are competing proposals of + comparable benefit and deployability, open specifications and code + become significant success factors. Open source availability is + initially more important than open specification maintenance. + + In most cases, technical quality was not a primary factor in initial + success. Indeed, many successful protocols would not pass IESG + review today. Technically inferior proposals can win if they are + openly available. Factors that do not seem to be significant in + determining initial success (but may affect wild success) include + good design, security, and having an open specification maintenance + process. + + Many of the case studies concern protocols originally developed + outside the IETF, which the IETF played a role in improving only + after initial success was certain. While the IETF focuses on design + quality, which is not a factor in determining initial protocol + success, once a protocol succeeds, a good technical design may be key + to it staying successful, or in dealing with wild success. Allowing + extensibility in an initial design enables initial shortcomings to be + addressed. + + Security vulnerabilities do not seem to limit initial success, since + vulnerabilities often become interesting to attackers only after the + protocol becomes widely deployed enough to become a useful target. + Finally, open specification maintenance is not important to initial + success since many successful protocols were initially developed + outside the IETF or other standards bodies, and were only + standardized later. + + In light of our conclusions, we recommend that the following + questions be asked when evaluating protocol designs: + + o Does the protocol exhibit one or more of the critical initial + success factors? + + o Are there implementers who are ready to implement the technology + in ways that are likely to be deployed? + + o Are there customers (especially high-profile customers) who are + ready to deploy the technology? + + o Are there potential niches where the technology is compelling? + + + + +Thaler & Aboba Informational [Page 12] + +RFC 5218 Protocol Success July 2008 + + + o If so, can complexity be removed to reduce cost? + + o Is there a potential killer app? Or can the technology work + underneath existing unmodified applications? + + o Is the protocol sufficiently extensible to allow potential + deficiencies to be addressed in the future? + + o If it is not known whether the protocol will be successful, should + the market decide first? Or should the IETF work on multiple + alternatives and let the market decide among them? Are there + factors listed in this document that may predict which is more + likely to succeed? + + In the early stages (e.g., BOFs, design of new protocols), evaluating + the initial success factors is important in facilitating success. + Similarly, efforts to revise unsuccessful protocols should evaluate + whether the initial success factors (or enough of them) were present, + rather than focusing on wild success, which is not yet a problem. + For a revision of a successful protocol, on the other hand, focusing + on the wild success factors is more appropriate. + +4. Security Considerations + + This document discusses attributes that affect the success of + protocols. It has no specific security implications. + Recommendations on security in protocol design can be found in + [RFC3552]. + +5. Informative References + + [IEEE-802.11] IEEE, "Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications", ANSI/IEEE + Std 802.11, 2007. + + [IMODE] NTT DoCoMo, "i-mode", + . + + [IPX] Novell, "IPX Router Specification", Novell Part + Number 107-000029-001, 1992. + + [ISO-8879] ISO, "Information processing -- Text and office + systems -- Standard Generalized Markup Language + (SGML)", ISO 8879, 1986. + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + + + +Thaler & Aboba Informational [Page 13] + +RFC 5218 Protocol Success July 2008 + + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or + converting network protocol addresses to 48.bit + Ethernet address for transmission on Ethernet + hardware", STD 37, RFC 826, November 1982. + + [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, October 1985. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, + June 1988. + + [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, + D., Torrey, D., and B. Alberti, "The Internet Gopher + Protocol (a distributed document search and retrieval + protocol)", RFC 1436, March 1993. + + [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, July 1994. + + [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup + Language - 2.0", RFC 1866, November 1995. + + [RFC1958] Carpenter, B., "Architectural Principles of the + Internet", RFC 1958, June 1996. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + April 1998. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, + "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, + June 1999. + + + + +Thaler & Aboba Informational [Page 14] + +RFC 5218 Protocol Success July 2008 + + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", + RFC 2821, April 2001. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing + RFC Text on Security Considerations", BCP 72, + RFC 3552, July 2003. + + [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export + Version 9", RFC 3954, October 2004. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", + RFC 4120, July 2005. + + [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Protocol Architecture", RFC 4251, January 2006. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting + Network Attachment in IPv4 (DNAv4)", RFC 4436, + March 2006. + + [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., + and E. Klein, "Local Network Protection for IPv6", + RFC 4864, May 2007. + + [TACACS+] Carrel, D. and L. Grant, "The TACACS+ Protocol, + Version 1.78", Work in Progress, January 1997. + + + + + +Thaler & Aboba Informational [Page 15] + +RFC 5218 Protocol Success July 2008 + + + [WAP] Open Mobile Alliance, "Wireless Application Protocol + Architecture Specification", . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thaler & Aboba Informational [Page 16] + +RFC 5218 Protocol Success July 2008 + + +Appendix A. Case Studies + + In this Appendix, we include several case studies to illustrate the + importance of potential success factors. Many other equally good + case studies could have been included, but, in the interests of + brevity, only a sampling is included here that is sufficient to + justify the conclusions in the body of this document. + +A.1. HTML/HTTP vs. Gopher and FTP + +A.1.1. Initial Success Factors + + Positive net value: HTTP [RFC2616] with HTML [RFC1866] provided + substantially more value than Gopher [RFC1436] and FTP [RFC0959]. + Among other things, HTML/HTTP provided support for forms, which + opened the door for commercial uses of the technology. In this + sense, it enabled new scenarios. Furthermore, it only required + changes by entities that received benefits; hence, the cost and + benefits were aligned. + + Incremental deployability: Browsers and servers were incrementally + deployable, but initial browsers were also backward compatible with + existing protocols such as FTP and Gopher. + + Open code availability: Server code was open. Client source code was + initially open to academic use only. + + Restriction-free: Academic use licenses were freely available. HTML + encumbrance only surfaced later. + + Open specification availability: Yes. + + Open maintenance process: Not at first, but eventually. This + illustrates that it is not necessary to have an open maintenance + process at first to achieve success. The maintenance process becomes + important after initial success. + + Good technical design: Fair. Initially, there was no support for + graphics, HTML was missing many SGML [ISO-8879] features, and HTTP + 1.0 had issues with congestion control and proxy support. These + sorts of issues would typically prevent IESG approval today. + However, they did not prevent the protocol from becoming successful. + + + + + + + + + +Thaler & Aboba Informational [Page 17] + +RFC 5218 Protocol Success July 2008 + + +A.1.2. Wild Success Factors + + Extensible: Extensibility was excellent along multiple dimensions, + including HTTP, HTML, graphics, forms, Java, JavaScript, etc. + + No hard scalability bound: Excellent. There was no registration + process, as there was with Gopher, which allowed it to scale much + better. + + Threats sufficiently mitigated: No. There was initially no support + for confidentiality (e.g., protection of credit card numbers), and + HTTP 1.0 had cleartext passwords in Basic auth. + +A.1.3. Discussion + + HTML/HTTP addressed scenarios that no other protocol addressed. + Since deployment was easy, the protocol quickly took off. Only after + HTML/HTTP became successful did security become an issue. HTML/ + HTTP's initial success occurred outside the IETF, although HTTP was + later standardized and refined, addressing some of the limitations. + +A.2. IPv4 vs. IPX + +A.2.1. Initial Success Factors + + Positive net value: There were initially many competitors, including + IPX, AppleTalk, NetBEUI, OSI, and DECNet. All of them had positive + net value. However, NetBEUI and DECNet were not designed for + internetworking, which limited scalability and eventually stunted + their growth. + + Incremental deployability: None of the competitors (including IPv4) + had incremental deployability, although there were few enough nodes + that a flag day was manageable at the time. + + Open code availability: IPv4 had open code from BSD, whereas IPX did + not. Many argue that this was the primary reason for IPv4's success. + + Restriction-free: Yes for IPv4; No for IPX. + + Open specification availability: Yes for IPv4; No for IPX. + + Open maintenance process: Yes for IPv4; No for IPX. + + Good technical design: The initial design of IPv4 was fair, but + arguably IPX was initially better. Improvements to IPv4 such as DHCP + came much later. + + + + +Thaler & Aboba Informational [Page 18] + +RFC 5218 Protocol Success July 2008 + + +A.2.2. Wild Success Factors + + Extensible: Both IPv4 and IPX were extensible to new transports, new + link types, and new applications. + + No hard scalability bound: Neither had a hard scalability bound close + to the design goals. IPX arguably scaled higher before hitting any + bound. + + Threats sufficiently mitigated: Neither IPv4 nor IPX had threats + sufficiently mitigated. + +A.2.3. Discussion + + Initially, it wasn't clear that IPv4 would win. There were also + other competitors, such as OSI. However, the Advanced Research + Projects Agency (ARPA) funded IPv4 implementation on BSD and this + open source initiative led to many others picking up IPv4, which + ultimately made a difference in IPv4 succeeding rather than its + competitors. Even though IPX initially had a technically superior + design, IPv4 succeeded because of its openness. + +A.3. SSH + +A.3.1. Initial Success Factors + + Positive net value: SSH [RFC4251] provided greater value than + competitors. Kerberized telnet required deployment of a Kerberos + server. IPsec required a public key infrastructure (PKI) or pre- + shared key authentication. While the benefits were comparable, the + overall costs of the alternatives were much higher, and they + potentially required deployment by entities that did not directly + receive benefit. Hence, unlike the alternatives, the cost and + benefits of SSH were aligned. + + Incremental deployability: Yes, SSH required SSH clients and servers, + but did not require a key distribution center (KDC) or credential + pre-configuration. + + Open code availability: Yes + + Restriction-free: It is unclear whether SSH was truly restriction- + free or not. + + Open specification availability: Not at first, but eventually. + + Open maintenance process: Not at first, but eventually. + + + + +Thaler & Aboba Informational [Page 19] + +RFC 5218 Protocol Success July 2008 + + + Good technical design: SSHv1 was fair. It had a number of technical + issues that were addressed in SSHv2. + +A.3.2. Wild Success Factors + + Extensibility: Good. SSH allowed adding new authentication + mechanisms. + + No hard scalability bound: SSH had excellent scalability properties. + + Threats sufficiently mitigated: No. SSHv1 was vulnerable to man-in- + the-middle attacks. + +A.3.3. Discussion + + The "leap of faith" trust model (accept an untrusted certificate the + first time you connect) was initially criticized by "experts", but + was popular with users. It provided vastly more functionality and + didn't require a KDC and so was easy to deploy. These factors made + SSH a clear winner. + +A.4. Inter-Domain IP Multicast vs. Application Overlays + + We now look at a protocol that has not been successful (i.e., has not + met its original design goals) after a long period of time has + passed. Note that this discussion applies only to inter-domain + multicast, not intra-domain or intra-subnet multicast. + +A.4.1. Initial Success Factors + + Positive net value: Unclear. When many receivers of the same stream + exist, the benefit relieves pain near the sender, and in some cases + enables new scenarios. However, when few receivers exist, the + benefits are only incremental improvements when compared with + multiple streams. While there was positive value in bandwidth + savings, this was offset by the lack of viable business models, and + lack of tools. Hence, the costs generally outweighed the benefits. + + Furthermore, the costs are not necessarily aligned with the benefits. + Inter-domain Multicast requires changes by (at least) applications, + hosts, and routers. However, it is the applications that get the + primary benefit. For application layer overlaps, on the other hand, + only the applications need to change, and hence the cost is lower + (and so are the benefits), and cost and benefits are aligned. + + Incremental deployability: Poor for inter-domain multicast, since it + required every router in the end-to-end path between a source and any + receiver to support multicast. This severely limited the + + + +Thaler & Aboba Informational [Page 20] + +RFC 5218 Protocol Success July 2008 + + + deployability of native multicast. Initially, the strategy was to + use an overlay network (the Multicast Backbone (MBone)) to work + around this. However, the overlay network eventually suffered from + performance problems at high fan-out points, and so adding another + node required more coordination with other organizations to find + someone that was not overloaded and agreed to forward traffic on + behalf of the new node. + + Incremental deployability was good for application-layer overlays, + since only the applications need to change. However, benefit only + exists when the sender(s) and receivers both support the overlay + mechanism. + + Open code availability: Yes. + + Restriction-free: Yes. + + Open specification availability: Yes for inter-domain multicast. + Application-layer overlays are not standardized, but left to each + application. + + Open maintenance process: Yes for inter-domain multicast. + Application-layer overlays are not standardized, but left to each + application. + + Good technical design: This is debatable for inter-domain multicast. + In many respects, the technical design is very efficient. In other + respects, it results in per-connection state in all intermediate + routers, which is questionable at best. Application-layer overlays + do not have the disadvantage, but receive a smaller benefit. + +A.4.2. Wild Success Factors + + Extensible: Yes. + + No hard scalability bound: Inter-domain multicast had scalability + issues in terms of number of groups, and in terms of number of + sources. It scaled extremely well in terms of number of receivers. + Application-layer overlays scale well in all dimensions, except that + they do not scale as well as inter-domain multicast in terms of + bandwidth since they still result in multiple streams over the same + link. + + Threats sufficiently mitigated: No for inter-domain-multicast, since + untrusted hosts can create state in intermediate routers along an + entire path. Better for application-layer multicast. + + + + + +Thaler & Aboba Informational [Page 21] + +RFC 5218 Protocol Success July 2008 + + +A.4.3. Discussion + + Because the benefits weren't enough to outweigh the costs for + entities (service providers and application developers) to use it, + instead the industry has tended to choose application overlays with + replicated unicast. + +A.5. Wireless Application Protocol (WAP) + + The Wireless Application Protocol (WAP) [WAP] is another protocol + that has not been successful, but is worth comparing against other + protocols. + +A.5.1. Initial Success Factors + + Positive net value: Compared to competitors such as HTTP/TCP/IP, and + NTT DoCoMo's i-mode [IMODE], the relative value of WAP is unclear. + It suffered from a poor experience, and a lack of tools. + + Incremental deployability: Poor. WAP required a WAP-to-HTTP proxy in + the service provider and WAP support in phones; adding a new site + often required participation by the service provider. + + Open code availability: No. + + Restriction-free: No. WAP has two patents with royalties required. + + Open specification availability: No. + + Open maintenance process: No, there was a US$27000 entrance fee. + + Good technical design: No, a common complaint was that WAP was + underspecified and hence interoperability was difficult. + +A.5.2. Wild Success Factors + + Extensible: Unknown. + + No hard scalability bound: Excellent. + + Threats sufficiently mitigated: Unknown. + +A.5.3. Discussion + + There were a number of close competitors to WAP. Incremental + deployability was easier with the competitors, and the restrictions + on code and specification access were significant factors that + hindered its ability to succeed. + + + +Thaler & Aboba Informational [Page 22] + +RFC 5218 Protocol Success July 2008 + + +A.6. Wired Equivalent Privacy (WEP) + + WEP is a part of the IEEE 802.11 standard [IEEE-802.11], which + succeeded in being widely deployed in spite of its faults. + +A.6.1. Initial Success Factors + + Positive net value: Yes. WEP provided security when there was no + alternative, and it only required changes by entities that got + benefit. + + Incremental deployability: Yes. Although one needed to configure + both the access point and stations, each wireless network could + independently deploy WEP. + + Open code availability: Essentially no, because of Rivest Cipher 4 + (RC4). + + Restriction-free: No for RC4, but otherwise yes. + + Open specification availability: No for RC4, but otherwise yes. + + Open maintenance process: Yes. + + Good technical design: No, WEP had an inappropriate use of RC4. + +A.6.2. Wild Success Factors + + Extensible: IEEE 802.11 was extensible enough to enable development + of replacements for WEP. However, WEP itself was not extensible. + + No hard scalability bound: No. + + Threats sufficiently mitigated: No. + +A.6.3. Discussion + + Even though WEP was not completely open and restriction free, and did + not have a good technical design, it still became successful because + it was incrementally deployable and it provided significant value + when there was no alternative. This again shows that value and + deployability are more significant success factors than technical + design or openness, particularly when no alternatives exist. + + + + + + + + +Thaler & Aboba Informational [Page 23] + +RFC 5218 Protocol Success July 2008 + + +A.7. RADIUS vs. TACACS+ + +A.7.1. Initial Success Factors + + Positive net value: Yes for both, and it only required changes by + entities that got benefit. + + Incremental deployability: Yes for both (just change clients and + servers). + + Open code availability: Yes for RADIUS; initially no for TACACS+, but + eventually yes. + + Restriction-free: Yes for RADIUS; unclear for TACACS+. + + Open specification availability: Yes for RADIUS; initially no for + TACACS+, but eventually yes. + + Open maintenance process: Initially no for RADIUS, but eventually + yes. No for TACACS+. + + Good technical design: Fair for RADIUS (there was no confidentiality + support, and no authentication of Access Requests; it had home grown + ciphersuites based on MD5). Good for TACACS+. + +A.7.2. Wild Success Factors + + Extensible: Yes for both. + + No hard scalability bound: Excellent for RADIUS (UDP-based); good for + TACACS+ (TCP-based). + + Threats sufficiently mitigated: No for RADIUS (no support for + confidentiality, existing implementations are vulnerable to + dictionary attacks, use of MD5 now vulnerable to collisions). + TACACS+ was better since it supported encryption. + +A.7.3. Discussion + + Since both provided positive net value and were incrementally + deployable, those factors were not significant. Even though TACACS+ + had a better technical design in most respects, and eventually + provided openly available specifications and source code, the fact + that RADIUS had an open maintenance process as well as openly + available specifications and source code early on was the determining + factor. This again shows that having a better technical design is + less important in determining success than other factors. + + + + +Thaler & Aboba Informational [Page 24] + +RFC 5218 Protocol Success July 2008 + + +A.8. Network Address Translators (NATs) + + Although NAT is not, strictly speaking, a "protocol" per se, but + rather a "mechanism" or "algorithm", we include a case study since + there are many mechanisms that only require a single entity to change + to reap the benefit (TCP congestion control algorithms are another + example in this class), and it is important to include this class of + mechanisms in the discussion since it exemplifies a key point in the + discussion of incremental deployability. + +A.8.1. Initial Success Factors + + Positive net value: Yes. NATs provided the ability to connect + multiple devices when only a limited number of addresses were + available, and also provided a (limited) security boundary as a side + effect. Hence, it both relieved pain involved with acquiring + multiple addresses, as well as enabled new scenarios. Finally, it + only required deployment by the entity that got the benefit. + + Incremental deployability: Yes. One could deploy a NAT without + coordinating with anyone else, including a service provider. + + Open code availability: Yes. + + Restriction-free: Yes at first (patents subsequently surfaced). + + Open specification availability: Yes. + + Open maintenance process: Yes. + + Good technical design: Fair. NAT functionality was underspecified, + leading to unpredictable behavior in general. In addition, NATs + caused problems for certain classes of applications. + +A.8.2. Wild Success Factors + + Extensible: Fair. NATs supported some but not all UDP and TCP + applications. Adding application layer gateway functionality was + difficult. + + No hard scalability bound: Good. There is a scalability bound + (number of ports available), but none near the original design goals. + + Threats sufficiently mitigated: Yes. + + + + + + + +Thaler & Aboba Informational [Page 25] + +RFC 5218 Protocol Success July 2008 + + +A.8.3. Discussion + + The absence of an unambiguous specification was not a hindrance to + initial success since the test cases weren't well defined; therefore, + each implementation could decide for itself what scenarios it would + handle correctly. + + Even with its technical problems, NAT succeeded because of the value + it provided. Again, this shows that the industry is willing to + accept technically problematic solutions when there is no alternative + and the technology is easy to deploy. + + Indeed, NAT became wildly successful by being used for additional + purposes [RFC4864], and to a large scale including multiple levels of + NATs in places. + +Appendix B. IAB Members at the Time of This Writing + + Loa Andersson + Leslie Daigle + Elwyn Davies + Kevin Fall + Russ Housley + Olaf Kolkman + Barry Leiba + Kurtis Lindqvist + Danny McPherson + David Oran + Eric Rescorla + Dave Thaler + Lixia Zhang + + + + + + + + + + + + + + + + + + + + +Thaler & Aboba Informational [Page 26] + +RFC 5218 Protocol Success July 2008 + + +Authors' Addresses + + Dave Thaler + IAB + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + Bernard Aboba + IAB + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 706 6605 + EMail: bernarda@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thaler & Aboba Informational [Page 27] + +RFC 5218 Protocol Success July 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Thaler & Aboba Informational [Page 28] + -- cgit v1.2.3