IAB Open Meeting

Reported by Abel Weinrib/Intel

An on-line copy of these and other IAB minutes are available from http://www.iab.org/documents/IABmins.

IAB Chair

It was announced that Christian Huitema has stepped down as chair of the IAB. Appreciation for his years of dedicated service was expressed by all. Brian Carpenter has been elected as the new chair.

Architectural Principles

The IAB has decided to try to write down the architectural principles of the Internet. The IAB is eager to have community input on this topic, and used the bulk of the open meeting to start the process. Christian Huitema, Paul Mockapetris and Brian Carpenter made presentations on this topic. See the copies of their slides included with these minutes.

Additional architectural principles suggested by the audience included: the importance of performance and cost; large clouds are bad; layers are bad, especially when they duplicate functions; and virtual circuits do not suck. A number of people also brought up the concern that such an architectural document will become dogma, limiting the evolution of the Internet. In response, it was emphasized that the IAB’s goal is to develop architectural principles that can help our understanding of what makes the Internet successful, not an architectural framework that would limit innovation. In a similar vein, members of the audience also suggested that whatever document the IAB comes up with should be published as a draft and then immediately go to Historical.

Security

In addition to the architectural principles presentations, Steve Crocker presented a challenge to the IETF community in the area of security. He asked that we deploy at the next IETF meeting the security infrastructure that will enable participants to safely log in back to their home locations. The discussion following Steve’s talk touched on the fact that a firewall as part of this infrastructure might well get in the way (for example, for Kerberos-authenticated remote mail) and that we should have an official packet sniffer on the terminal room LAN. There was considerable interest in taking Steve up on his challenge, and a mailing list for implementors who want to take part will be set up.

---

Slides

Huitema

Is There An Internet Architecture?

Many say there is only a tradition, it was not written down for 20 years, or at least not by the IAB, but…

• the goal is connectivity,
• the tool is the Internet Protocol, and
• the intelligence is end-to-end.

Connectivity Is Its Own Reward

• Email and the Internet snowball
• Connectivity is more than email, more than the Web
• Cooperation between network providers
• Be liberal…

IP Over Everything

• Interconnection of networks (overlay)
• IP and new technologies
• Unique addresses (Internet addresses)
• One main networking protocol

The End-to-End Argument

• Avoid states and fate-sharing
• Datagrams are better than virtual circuits
• You shall not trust networks
• Networks should do routing
• Avoid rigidity in the network
• Error control, security, deployment from fringes
  

  Saltzer, J. H., D. P. Reed, and D. Clark, “End-to-End Arguments in System Design, ” ACM Transactions on Computers Systems, Vol. 2, No. 4, Pages 277-288.

Developing The Internet Architecture

• Nobody owns the Internet
• Nobody can turn it off
• There is no centralized control
• (Not even DARPA)
• Rough consensus and running code
• Feedback from implementation
  

  from architecture to engineering…

---

Slides- Mockapetris

The Search for Internet Architectural Principles

(Internet 2000)
pvm@home.net

What is the Internet?

… the current state of network evolution

Era:	1969 ARPANET	1983  Internet	1994 Internet	1996? Future
Backbone speed (000s)	56	56	45,000	9,600,000
Host interface speed (000s)	56	10,000	10,000	1,000,000
Computers	4	200	4,500,000	10,000,000
Managers	1	64	40,000	100,000

What are the characteristics of Architectural principles

• Time Dependent
• Method to create cooperation, i.e. common standards
• “Most significant bits” of the standards
• A small “spanning set” of rules that generates a varied space

IPng = IP the Next Generation

• IP is running out of gas (or at least class B addresses).
• We can make it better than before.
• The IETF can do it best.
• One protocol to bind them all.
• The internet of the future needs new capabilities.

Gigabit Principles

• We can’t do things the old way.
• We need to explore far out speeds, not the next speed.
• Gigabit problems are different.
• Gigabits enable new services.

The Old Way (some say the Internet way)

The REK Six Commandments
• No Connections
• All packets are treated equally
• Rapid adaptation to topology changes
• Minimal first-packet delay
• Fixed length addresses
• Be unlike the phone system

The Deering addendum

• Unicast is just as important as multicast
• No usage-sensitive billing

The New PC Way

• Telecommunications and computation merge
• Network research and Telcos work together
• SONET base
• HIPPI/ATM popular

Design Principles – Dave Clark 88

• Goal: effective technique for multiplexed utilization of existing interconnected networks
• Prioritized second level goals:
  • Communications must continue despite loss of networks & gateways
  • Must support multiple TOS
  • Must accommodate a variety of networks
  • Must permit distributed management of resources
  • Must be cost effective
  • Must permit host attachment with a low level of effort
  • Must be accountable
• Features: Datagrams, IP/TCP split

Other Examples of Expert Forecasting

EXPERT	FORECAST
Lord Kelvin (1895)	Heavier-than-Air Flying Machines are impossible.
Albert Einstein (1932)	There is not the slightest indication that [Nuclear] Energy will ever be obtainable.
Thomas J. Watson (1943)	I think there is a world model for about five computers.
Kenneth Olsen (1977)	There is no reason for an individual to have a computer in the home.

Source: Christopher Cerf and Victor Navasky, The Experts Speak (New York; Pantheon Books, 1984).

---

Slides – Carpenter

APAM
IAB Strawman Architectural Principles and Methods

(a.k.a. Apple Pie and Motherhood)

Brian E. Carpenter
CERN/IAB
July 1995

1. General Design Issues

1.1 There should be one, and only one, protocol at the Internet level (but perhaps two versions for an extended period during transition). Therecan be many protocols at other levels.

1.2 End-to-end functions can best be realisedby end-to-end protocols. [End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288]

1.3 All designs must fit into the Internet security architecture.

1.4 All designs must scale readily to very manynodes per site and to many millions of sites.

1.5 Heterogeneity is inevitable and must be sup-ported by design.

1.6 Keep it simple. When in doubt during design,choose the simplest solution.

1.7 Avoid options and parameters whenever possible. If there are several ways of doing the same thing, choose one. Any options and parametersshould be configured or negotiated dynamically rather than manually.

1.8 Be strict when sending and tolerant when receiving. When in doubt, discard faulty input silently.

1.9 Be parsimonious with unsolicited packets, especially multicasts and broadcasts. (IPv6 eliminates broadcast by design.)

1.10 Circular dependencies must be avoided. For example, routing should not depend on DNS.

1.11 Objects should be self decribing (include type and size). Only type codes and other magic numbers assigned by IANA may be used.

1.12 All specifications should use the same ter-minology and notation, and the same bit- and byte-order convention.

1.13 Running code before standardization.

2. Name and address issues

2.1 Avoid any design that requires addresses tobe hard coded or stored on non-volatile storage (except of course where this is an essential re-quirement as in a name server or configuration server). In general, user applications should usenames rather than addresses.

2.2 A single naming structure should be used.

2.3 All names should be case-independent???

2.4 Addresses must be unambiguous (unique within any scope where they may appear).

2.5 Upper layer protocols must be able to identify end-points unambiguously. (In practice this means that addresses must be the same at startand finish of transmission???)

3. External Issues

3.1 Prefer unpatented technology, but if the besttechnology is patented and is available to all at reasonable terms, then incorporation of patentedtechnology is acceptable.

3.2 The existence of export controls on someaspects of Internet technology is only of secondary importance in choosing which technologyto adopt into the standards.

3.3 Any implementation which does not includeall of the required components cannot claim conformance with the standard.

3.4 Designs should be “internationally user-friendly”

4. Confidentiality and Authentication

4.1 Confidentiality and Authentication are GoodThings

4.2 Confidentiality is the responsibility of endusers and must be implemented in the protocols used by the end users. (I.e. users should notdepend on the confidentiality of the carriers.)

4.3 Wherever a cryptographic algorithm is calledfor in a protocol, the protocol should be designed to permit alternative algorithms to be used.

4.4 In choosing algorithms, the algorithm shouldbe one which is widely regarded as strong enough to serve the purpose.

---

Slides- Crocker

Deployment of Security Don’t leave home without it

Outline

• Problem
• Status
• Challenge

The Problem

• Still amazingly little deployment of strong security on the Internet
• Everyone using IETF terminal room — or other public network room — is particularly vulnerable to sniffing
• Security implementation is still not a priority, although public and corporate concern is increasing

Status

• IPSEC specs are now out
• Key management is still open
• Manual keying works bilaterally

The Challenge

• Measurable change by Dallas
• IPSEC with manual keying in
  • Terminal room terminals
  • Available for laptops
  • In terminal room firewall
  • Available in commercial firewalls

Action Items

• Volunteers to implement IPSEC on laptops and firewalls
• Volunteers major host implementations
• Volunteer firewall for IETF meeting
• Coordination team Send mail to crocker@cybercash.com