GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5218

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",
                <http://www.nttdocomo.com/services/imode/index.html>.
 [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", <http://
                www.openmobilealliance.org/tech/affiliates/
                LicenseAgreement.asp?DocName=/wap/
                wap-210-waparch-20010712-a.pdf>.

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5218.txt · Last modified: 2008/07/17 22:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki