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.
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.
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.
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.
- the goal is connectivity,
- the tool is the Internet Protocol, and
- the intelligence is end-to-end.
- Email and the Internet snowball
- Connectivity is more than email, more than the Web
- Cooperation between network providers
- Be liberal…
- Interconnection of networks (overlay)
- IP and new technologies
- Unique addresses (Internet addresses)
- One main networking protocol
- 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.
- 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…
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…
Connectivity Is Its Own Reward
IP Over Everything
The End-to-End Argument
Developing The Internet Architecture
- 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
- 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.
- 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.
- No Connections
- All packets are treated equally
- Rapid adaptation to topology changes
- Minimal first-packet delay
- Fixed length addresses
- Be unlike the phone system
- Unicast is just as important as multicast
- No usage-sensitive billing
- Telecommunications and computation merge
- Network research and Telcos work together
- SONET base
- HIPPI/ATM popular
- 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
The Search for Internet Architectural Principles
What is the Internet?
… the current state of network evolution
What are the characteristics of Architectural principles
IPng = IP the Next Generation
The Old Way (some say the Internet way)
The REK Six Commandments
The Deering addendum
The New PC Way
Design Principles – Dave Clark 88
Other Examples of Expert Forecasting
|Heavier-than-Air Flying Machines are impossible.|
|There is not the slightest indication that [Nuclear] Energy will ever be obtainable.|
|Thomas J. Watson
|I think there is a world model for about five computers.|
|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
IAB Strawman Architectural Principles and Methods
(a.k.a. Apple Pie and Motherhood)
Brian E. Carpenter
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.
- 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
- IPSEC specs are now out
- Key management is still open
- Manual keying works bilaterally
- Measurable change by Dallas
- IPSEC with manual keying in
- Terminal room terminals
- Available for laptops
- In terminal room firewall
- Available in commercial firewalls
- Volunteers to implement IPSEC on laptops and firewalls
- Volunteers major host implementations
- Volunteer firewall for IETF meeting
- Coordination team Send mail to firstname.lastname@example.org
Deployment of Security
Don’t leave home without it