Protocol Success Mark Townsley, Cisco Fellow Presenting Material - - PowerPoint PPT Presentation

Protocol Success

Mark Townsley, Cisco Fellow Presenting Material from The IETF’s Internet Architecture Board (IAB), Dave Thaler (Microsoft), and Brian Carpenter (IBM)

3 Important RFCs

• RFC 5218 - “What Makes for a Successful

Protocol” (Dave Thaler, Bernard Aboba)

• RFC 1958 - “Architectural Principles of the

Internet” (IAB, Brian Carpenter as “Editor”)

• RFC 2775 - “Internet Transparency” (IAB

Workshop, Brian Carpenter as “Editor”)

Objectives

• Understand what RFC 5218 deems a
• Successful Protocol
• Wildly Successful Protocol
• Failed Protocol
• Identify
• Initial Success Factors
• Wild Success Factors
• Provide some introductory insight into
• Internet Architecture (RFC1958)
• End-to-end transparency (RFC 2775)

12/6/07 IETF 70 Technical Plenary 1

What makes for a successful protocol?

draft-iab-protocol-success-01.txt Dave Thaler

dthaler@microsoft.com

12/6/07 IETF 70 Technical Plenary 2

What is success?

• A protocol can be successful and still not be

widely deployed, if it meets its original goals

– However, it’s not very interesting to us for this discussion, so let’s just look at things that are widely deployed. – Widely deployed ≠ inter-domain

• We might consider the following as some

examples of successes:

– Inter-domain: IPv4, TCP, HTTP, DNS, BGP, UDP, SMTP, SIP, etc – Intra-domain: ARP, PPP, DHCP, RIP, OSPF, Kerberos, etc

12/6/07 IETF 70 Technical Plenary 3

Original Protocol Design Space

Success Axes

Scale Purpose

12/6/07 IETF 70 Technical Plenary 4

Some Definitions

• "successful": a protocol that is used in the

way it was originally envisioned, and to the scale it was originally envisioned

• "wildly successful": a successful protocol

that is deployed on a scale much greater than originally envisioned and/or in ways beyond what it was originally designed for.

12/6/07 IETF 70 Technical Plenary 5

“Successful”

Scale Purpose

12/6/07 IETF 70 Technical Plenary 6

“Wildly Successful”

Scale Purpose

12/6/07 IETF 70 Technical Plenary 7

HTTP

Scale Purpose

Web VPN Firewall Traversal

12/6/07 IETF 70 Technical Plenary 8

IPv4

Scale Purpose

IP over everything, everything over IP

12/6/07 IETF 70 Technical Plenary 9

ARP

Scale Purpose

DNA Non- Ethernet Non-IP

12/6/07 IETF 70 Technical Plenary 10

Wild success

• Can be both good and bad

– Undesirable side effects when used outside intended purpose – Performance problems – Ugly hacks to work around design limitations – High value target for attackers – “Death by success”

12/6/07 IETF 70 Technical Plenary 11

What is failure?

• Sufficient time has passed (e.g. >10 years)
• No mainstream implementations exist

– No support in hosts/routers/whatever

• No deployment exists

– Boxes which support it are not deployed, or – Protocol is not enabled on boxes that are

• No use exists

– No applications exist that can utilize

• Cycle between the last three known as the “chicken-and-

egg” problem

– Not a cause of failure, just a term used to explain lack of a value chain in existence

12/6/07 IETF 70 Technical Plenary 12

Some ways people try to solve the initial chicken-and-egg problem

• 1. Address a critical and imminent problem
• 2. Provide a “killer app” with low deployment costs
• 3. Provide value under existing unmodified apps
• 4. Narrow the intended purpose to an area where

it is easiest to succeed

– Reduce cost by removing complexity not required for that purpose

• 5. Governmental (dis)incentives: promise of long-

term economic or military benefits

– Increase financial benefits (or penalties) to industry – E.g. strong crypto for US DoD, IPv6 incentives in Japan, etc.

12/6/07 IETF 70 Technical Plenary 13

Success Factors

• What factors contribute to protocol

success?

• What additional factors contribute to “wild”

success?

• A successful protocol won’t necessarily

meet all criteria

– Each one met may facilitate success – Each one not met may hinder success

12/6/07 IETF 70 Technical Plenary 14

Potential Success Factors

1. Positive net value (meet a real need) 2. Incremental deployability 3. Open code availability 4. Freedom from usage restrictions 5. Open spec availability 6. Open development and maintenance processes 7. Good technical design Additional “wild” success factors: 8. Extensible 9. No hard scalability bound

• 10. Threats sufficiently mitigated

12/6/07 IETF 70 Technical Plenary 15

• 1. Positive net value (1/4)
• The benefits (e.g., monetary) of deploying

the protocol clearly outweigh the costs of deploying it.

Time $ Benefit Cost Time $ Benefit Cost

A) B)

12/6/07 IETF 70 Technical Plenary 16

• 1. Positive net value (2/4)
• Three types of benefits:
• 1. Relieving pain
• 2. Enabling new scenarios
• Often higher risk than type 1
• 3. Incremental improvements
• Often lower gain than type 1

12/6/07 IETF 70 Technical Plenary 17

• 1. Positive net value (3/4)
• Some costs:

– Hardware cost: protocol changes that don't require changes to hardware are easier to deploy than those that do.

• Overlays are one way to avoid

– Operational interference: protocol changes that don’t require changes to other operational processes and tools are easier to deploy than ones that do. (e.g., IPsec interferes with netflow, deep packet inspection, etc.)

• Overlays are one way to partially mitigate

– Retraining: protocols that have no configuration, or are easy to configure/manage are easier to deploy

12/6/07 IETF 70 Technical Plenary 18

• 1. Positive net value (4/4)

– Business dependencies: protocols that don’t require changes to a business model (whether for implementors or deployers) are easier to deploy than

• nes that do
• Dialup and always-on
• Multicast
• Provisioning and Peer-to-peer

– Pay to play: The natural incentive structure is aligned with the deployment requirements.

• Those who are required to deploy/manage/configure

something are the same as those who gain the most benefit.

• That is, there must be positive net value at each organization

where change is required

12/6/07 IETF 70 Technical Plenary 19

• 2. Incremental deployability
• Early adopters gain some benefit even though

the rest of the Internet does not yet support

– Autonomy: protocols that can be deployed by a single group/team are easier than those that require cooperation across multiple organizations (no flag day) – One-end benefit: protocols that provide benefit when

• nly one end changes are easier to deploy than ones

that don’t (e.g., MIPv6 vs. HIP) – Backward compatibility: protocol updates that are backward compatible with legacy implementations are easier to deploy than ones that aren’t.

12/6/07 IETF 70 Technical Plenary 20

• 3. Open code availability
• Implementation code freely available
• Often this is more important than technical

considerations

– IPv4 vs IPX – RADIUS vs TACACS+

12/6/07 IETF 70 Technical Plenary 21

• 4. Freedom from usage restrictions
• Anyone who wishes to implement or

deploy the protocol can do so without legal

• r financial hindrance.

12/6/07 IETF 70 Technical Plenary 22

• 5. Open spec availability
• The protocol is published and made available in

a way that ensures it is accessible to anyone who wishes to use it.

– World-wide distribution: accessible from anywhere in the world – Unrestricted distribution: no legal restrictions on getting spec – Permanence: stays even after creator goes away – Stable: document doesn’t change

• This is of course true for everything that's an

RFC.

12/6/07 IETF 70 Technical Plenary 23

• 6. Open development and

maintenance processes

• The protocol is developed and maintained

by open processes.

• Mechanisms exist for public commentary
• n the protocol.
• The protocol maintenance process allows

the participation of all constituencies that are affected by the protocol.

• This is of course true for IETF RFCs.

12/6/07 IETF 70 Technical Plenary 24

• 6. Good technical design
• Follows good design principles that lead to ease
• f implementation, interoperability, etc.

– Simplicity – Modularity – Robust to failures

12/6/07 IETF 70 Technical Plenary 25

• 8. Extensible
• Can carry general purpose

payloads/options

• Easy to add a new payload/option type

12/6/07 IETF 70 Technical Plenary 26

• 9. No hard scalability bound
• No inherent limit near the edge of the
• riginally envisioned scale

– Size of “address” fields – Performance “knee” that causes meltdown

12/6/07 IETF 70 Technical Plenary 27

• 10. Threats sufficiently mitigated
• The more successful a protocol becomes, the

more attacks there will be to mitigate

12/6/07 IETF 70 Technical Plenary 28

How Important Are The Success Factors?

• Very Important

– (Very) positive net value (i.e., Fills a perceived need) – Incremental deployability – Open code availability

• Open source availability initially more important than open spec maintenance

– Open spec availability

• Technically inferior proposals can win if they are openly available.

– Restriction free

• IP did not become a wild success until removal of NSF restrictions.
• Less important for Initial success

– Open spec maintenance

• Many successful protocols initially developed outside the IETF

– Technical design

• Many successful protocols would not pass IESG review today
• Less important for Initial success, but important for Wild success

– Extensibility – No hard scalability bound – Threats mitigated

• Security vulnerabilities do not seem to limit initial success

12/6/07 IETF 70 Technical Plenary 29

How/when might we apply learnings?

• Focus on initial success factors in early stages:

– WG charter time (if specific protocol in charter) – Protocol selection time (if WG selects among proposals) – Protocol creation time

• Focus on wild success factors when revising successful protocols
• Possible questions to ask:

– Do the success factors exist? – Can the technology help potential high-profile customers? – Are there potential niches in desperate need? – How extensible should the protocol be? – If success is uncertain, should IETF wait or work on multiple alternatives?

12/6/07 IETF 70 Technical Plenary 30

What is the role of the IETF?

• Most of the success stories are ones

which originated outside the IETF, and where technical quality was not a primary factor in success

• IETF had a role in improving many of

these, often after success of v1 was certain

• Key is that v1 had to be extensible to allow

IETF to fix after success

1

The end-to-end principle (1)

Note how TCP works - it assumes that packets may be lost, delayed, corrupted or delivered out of order. The two ends of a TCP connection cooperate to overcome this Note how SSH works - it assumes that messages may be intercepted and that attackers may try to insert false

• messages. The two ends of an SSH connection

cooperate to overcome this Note how DNS works - if a DNS (UDP) message is lost, no harm results except a delay. These are all examples of the end-to-end principle at work

Background slide

2

The end-to-end principle* (2)

Certain required end-to-end functions can only be performed correctly by the end-systems themselves Any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to give responsibility for the integrity of communication to the end systems. A similar argument applies to intrusions No solution buried inside the network can give the same level of assurance as the end systems

For example, end-to-end encryption is intrinsically safer than router-to- router encryption * see References

Background slide

3

Other principles (1)

Heterogeneity by design Avoid duplicate solutions Scaleable designs Performance and cost must be considered as well as functionality KISS (keep it simple, stupid!) Modularity is good Good enough is enough (don't seek perfection) Minimise use of options Be strict when sending and tolerant when receiving

Background slide

4

Other principles (2)

Be parsimonious with unsolicited packets, especially multicasts and broadcasts Circular dependencies must be avoided Objects should be self-describing (type and size) Nothing gets fully standardised until there are multiple instances of running code Avoid design that requires hard coded addresses Addresses must be unambiguous (NAT breaks this!) Designs should be fully international All protocols need strong security (early ones didn't!)

Background slide

5

References

RFC 1958: Architectural principles of the Internet

End-to-end principle paraphrased from "End-To-End Arguments in System Design", J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, 1984

“Why the Internet only just works” by Prof. Mark Handley, University College London http://www.cs.ucl.ac.uk/staff/ M.Handley/papers/only-just-works.pdf

Background slide

Transparency of the network layer

Brian Carpenter

draft-carpenter-transparency-00.txt March 1999

Transparency 101

The basic concept of the Internet, established around 1973, is one of transparent transmission of datagrams across an arbitrary network of networks.

logical addresses were unique. datagrams were not changed in transit. end systems handle error detection, retransmission, security, naming, and binding.

This concept has determined the basic design of most Internet applications.

Transparency has gone!

Why we have lost transparency:

Intranet concept (isolation viewed as good) Dynamic addresses (SLIP, PPP, DHCP) Private addresses ("Net 10") Firewalls and SOCKS Network address translators (NATs) Proxies and caches Split DNS Load sharing tricks with names or addresses

Consequences

Dynamic addresses, firewalls, proxies are normal, and NATs are common. Applications either fail completely, or need modification, or must be specially handled by the firewall/NAT. Fog on the Internet.

Consequence: it's almost impossibe to deploy new applications protocols globally Consequence: there is a strong temptation to layer new applications over old ones ("everything over HTTP")

Can we restore transparency?

Several of the causes of loss of tranparency are due to shortage of IPv4 addresses

IPv6 will remove this issue

IPv6 transition will take years. The Internet cannot be transparent during those years. IPv6 will not abolish the Intranet concept. Firewalls, proxies and caches are here to stay.

True transparency of the network layer has gone for ever.

Scenario 1

IPv6 deploys successfully. Address transparency is restored and IPSEC works end to end. Intranets, proxies and firewalls may remain. The fog clears.

Clearly this is a long term scenario following a transition period of many years

Scenario 2

Complete failure of IPv6 to deploy

• 1. Successful recycling of address space.

Global address space survives at ISP level. Noticeable fog and limited IPSEC. generalised use of NAPT

• r, Realm-specific IP addresses (aka HNAT)
• r, map-and-encapsulate
• 2. Address exhaustion. NATs between and

even within ISPs. Permanent thick fog. IPSEC broken.

Partial deployment of IPv6 (some countries

• r some market sectors). Transition tools

such as dual stack and protocol translation become permanent features. DNS complexities and only partial IPSEC. Noticeable fog.

This scenario arises anyway during transition to Scenario 1

Scenario 3

Objectives

• Understand what RFC 5218 deems a
• Successful Protocol
• Wildly Successful Protocol
• Failed Protocol
• Identify
• Initial Success Factors
• Wild Success Factors
• Provide some introductory insight into
• Internet Architecture (RFC1958)
• End-to-end transparency (RFC 2775)

Success == Deployment Scale vs. Purpose Important Initial: Positive Net Value, Incremental Deployability, Open Code, No usage restrictions Less Important Initial: Open Spec, Technical Design Wild: Extensibility, No hard Scalability Bound, SecurityThreats Mitigated “End to End Principle” - The network is imperfect by design, complexity pushed to the edges. Loss of transparency is at odds with the end-to- end principle “Strict in what you send, liberal in what you receive” KISS!