Internet Activities Board
Meeting Minutes — January 8-9, 1991
FOREWARD
This document contains minutes of the meeting of the Internet Activities Board (IAB) held on January 8-9, 1991 at the USC Information Sciences Institute in Marina del Rey, CA. The Internet Engineering Steering Group (IESG) participated in the entire meeting, which featured an extended discussion of architectural directions for the Internet.
The meeting agenda will be found in Appendix A. The attendees were:
IAB Members:
- Bob Braden, ISI
- Vint Cerf, CNRI
- Lyman Chapin, BBN
- David Clark, MIT LCS
- Phill Gross, CNRI
- Christian Huitema, INRIA
- Steve Kent, BBN
- Tony Lauck, DEC
- Barry Leiner, ADS
- Dan Lynch, Interop, Inc.
- Jon Postel, ISI
IESG Members:
- Ross Callon, DEC
- J. Noel Chiappa, Consultant
- David Crocker, DEC
- Steve Crocker, TIS
- Chuck Davin, MIT LCS
- Phillip Gross, CNRI
- Robert Hagens, U-WISC
- Robert Hinden, BBN
- Russell Hobby, UC-Davis
- Joyce Reynolds, USC/ISI
- Gregory Vaudreuil, CNRI
FNC Visitors:
- Ira Richer, DARPA
Scribe:
- Gregory Vaudreuil, CNRI
These minutes were prepared by Greg Vaudreuil of CNRI and edited by Vint Cerf, Chair of the IAB, and by Bob Braden, the IAB Executive Director (ExecD). We have endeavored to accurately reflect the content and thrust of the discussions. Although the IAB has reviewed the results, we must take responsibility for any unintentional misrepresentation.
- Bob Braden
- Vint Cerf
- Greg Vaudreuil
Greg Vaudreuil
1. AGENDA AND ACTION ITEMS
The agenda is contained in Appendix A.
Vint Cerf welcomed Christian Huitema of INRIA, France as the newest IAB member.
Action Items from earlier meetings were reviewed; the disposition will be found in Appendix B. The discussion led to the following new actions:
NEW ACTION: Gross: Document Terms of Reference of IEPG.
NEW ACTION: Lauck: Publish ANSI’s registration procedures for OSI.
Lauck summarized the major issues in testability of protocols:
- Testability defined into protocol definitions.
- Tools and test suites.
-
- Testing procedures.
- Political aspects — who tests and approves.
Lauck has an action item to elaborate on these points.
2. EXTERNAL RELATIONS
2.1 Internet Registry and Connected Status
The policies recommended by the IAB in RFC-1174 (“IAB Recommended Policy on Distributing Internet Identifier Assignment, and IAB Recommended Policy Change to Internet ‘Connected’ Status”, August 1990) were approved by the Federal Networking Council (FNC). See Reference [1] in Appendix C. However, the Defense Communications Agency (DCA), which funds the DDN NIC, was not willing to change the registration procedures while a procurement action was in progress to select a follow-on contractor.
Subsequently, NSF agreed to consider for sponsorship any networks that wish to be registered under the RFC-1174 rules. NSF cannot provide a “blanket” sponsorship, since each instance has to be validated against existing US government policies. Once the pro- curement action has been completed, the implementation of RFC-1174 will be somewhat easier, since the global Internet registry func- tions now performed by the DDN NIC will have been separated from the DDN registration functions to be performed under the new contract. The details of implementation are still being worked out, but the IAB is confident that the matter is well in hand.
The IAB reaffirmed that the RFC-1174 registration process is necessary for global registration, to support an increasingly international Internet.
2.2 OTA Conference on NREN
The OTA is conducting a computer moderated conference to gather information on NREN technology. Vint Cerf, who is a participant in the conference, reported that it totals some 60KB of messages per day! He has found that some of the information on the list is technically inaccurate, and he is not convinced that OTA is being well informed. It was the sense of the IAB that as recognized authorities on Internet technology, the IAB should contribute to the OTA effort. Several approaches were discussed, and the fol- lowing were agreed.
NEW ACTION: Cerf: (1) Send RFC-1167 to the OTA panel as a sub- mission on NREN. (2) Offer to comment on the final document when it is available.
3. Internationalization
The IAB discussed ways to acquire a better international perspective. It was agreed that the ITU Standards Summit Meeting to be held 11-13 March in Nice, France, is a good opportunity to call attention to our intention of making the Internet support both OSI and TCP/IP. The the IAB will be represented there by Dan Lynch and Lyman Chapin.
It was agreed that the IAB needs to:
-
-
- Make our international agenda clear both within and outside the IAB.
- Increase the non-US membership of the IAB, as previously announced.
- Solve the logistic problems of holding international meetings without too much expensive travel.
-
The group discussed (3) in particular. Video and telephone confer- ences can be used, perhaps with the aid of BBN’s mmconf software, in lieu of face-to-face meetings. The technical features of mmconf were discussed. Richer pointed out that Forsdick of BBN is working on ruggedizing mmconf and adding tablet support; he suggested waiting until July 1, 1991 to use it. There was some dismay that we have waited so long and tried so often to make progress in this area.
NEW ACTION: Kent: Discuss IAB needs with the mmconf group at BBN, and report on configuration requirements.
For the present, we will simply include Huitema in telephone confer- ence calls, setting the time to make it reasonable for him to parti- cipate.
NEW ACTION: Cerf & ExecD: Decide upon mode for April 3, 1991 meeting [DONE].
4. Privacy and Security
4.1 IPSO Status
The DoD IP security option (IPSO) has a long and interesting his- tory; it was assigned an RFC number (RFC-1108) but never pub- lished. The need for that option is now great, and a group was convened to complete the RFC. Steve Kent rewrote the document to address many of the shortcomings of the original.
There is a more general problem with IPSO: for historical reasons, the IPSO is specific to the US DoD. A more general approach is required for commercial security and for international use. IPSO does include an extended security option, which in principle would allow arbitrary extensions, but DCA (as opposed to the IANA) currently assigns extended option numbers; this would be a problem for vendors using the protocol for their own purposes.
There is another security option in the works which promises to be more useful to commercial and international users; this is known as CIPSO (Commercial IP Security Option).
NEW ACTION: S. Crocker, Kent: Complete IPSO document and pub- lish is as an Internet Draft [DONE].
4.2 PEM Status
Kent distributed a PERT chart for the release of Privacy Enhanced Mail (PEM) software.
-
-
-
- On April 25, 1991, Trusted Information Systems (TIS) is scheduled to make an initial release of PEM, with support for the MH mail system and its close relatives.
- There are five implementations under development: MIT, TIS, DEC, ConTel, and Fisher International. MIT will integrate PEM with Gnu EMACS.
- The certificate “postage meter” development is making good progress; Kent handed around a prototype board.
-
-
Steve Crocker pointed out that there will be a “start point”, after which keys will be parmanent. This will happen when RSA creates the root certificate, from which all others are derived.
4.3 Export Control Policy
The Federal Networking Council (FNC) is exploring possible changes to the export rules for cryptographic technology, specifically DES and RSADSI.
Huitema noted that there is a problem in France, where a World War I law prohibits encryption on any electromagnetic communication channel, except as allowed by the military. In practice, only banks and other financial institutions are allowed to perform encryption.
NEW ACTION: Kent: Revise his summary of the export control pol- icy, to include DEC comments.
4.4 Authentication
This agenda item was omitted for lack of time.
5. Architectural Issues
The meeting devoted the afternoon of the first day and the morning of the second day to an extended discussion of the future directions for Internet architecture. This discussion will be reported separately. (See Appendix D.)
The meeting did an excellent job of laying out the architectural issues and alternatives, but made little progress towards deciding on future directions. The group therefore decided to schedule a future 3-day “architecture workshop” for the IESG and IAB. All participants should come prepared with papers, and be prepared to compromise; getting an agreement is most important. This workshop is scheduled for June 11-13, 1991.
6. OSI ISSUES
6.1 NSAP Format
Callon briefed the meeting on NSAP issues. He distinguished three issues:
-
-
-
- NSAP structure (i.e., the format of the low-order part)
- NSAP administration
- The “care and feeding” of NSAPs: how do we map their hierarchy into the Internet, and what does an administrator do?
-
-
He presented the structure recommended by the IETF NSAP working group. The IETF group further proposed that regional networks be tasked to serve as addressing authorities for their client networks. NSAPS will be tagged to the regional to take advantage of hierarchy.
The issue was complex, and the IAB was unable to endorse the option chosen by the IETF working group without further consideration.
6.2 X.400 briefing
Hagens briefed the meeting on the current state of X.400 deployment in the Internet.
Major Issues:
-
-
-
-
- How will we assign OR names? OR addressing is expected to disappear as soon as X.500 is deployed.
- Building an Infrastructure. There is a lack of deployed software and little incentive to use what exists. (No multi- media support, awkward addressing)
- Management issues; how do PRMD’s communicate? How do they coor- dinate routing? Technical agreements and routing coordination are needed.
-
-
-
6.3 X.500 Pilot Project
Rob Hagens briefed the IAB on the current status of the X.500 effort.
The X.500 pilot program currently lists 13 countries, 400 organiza- tions, and 350,000 entries. Most of the current usage is lookup of US names. The goals of the X.500 effort in the Internet is to provide White Pages service, OSI applications support, and storage of security certificates.
There continue to be significant problems in the deployment of X.500, including missing standards for schema, replication, and security, and resolution of incompatible lower layers (1006/CLNP/X.25). The IETF is working on interim solutions for the missing elements of X.500. The group plans to identify holes, document solutions, and deploy on a large scale starting this year.
Kent pointed out the need for a definition of distinguished names for use in PEM. He will ask Steve Kille to check the PEM draft.
NEW ACTION: Kent: Ask Kille to review distinguished names as defined in PEM.
7. Standards Formalization
Dave Crocker reported on a close interaction with the IAB’s Policy Work- ing Group to merge suggested standards practices and procedures. There are still details to be worked out.
7.1 Interior Gateway Protocols
The Phill Gross summarized the current state of the standards-track IGPs, OSPF and IS-IS. A year ago, the IAB decided that there should be one IGP recommended for universal implementation. The question to be resolved is: “how do we pick the recommended IGP?” The original IESG recommendation suggested that the IAB choose when one protocol has sig- nificant operational experience. The IESG has considered waiting for information on both protocols to do a complete technical evaluation; however, the community is expressing increasing urgency to make the decision soon.
-
-
-
- It has been a year since this debate began.
- The Router Requirements Working Group needs a recommendation to incorporate into their document.
- OSPF will shortly be raised to Draft Standard. There is pressure to address the “requiredness” of that protocol.
- The trade press is gearing up for the debate and decision, by pub- lishing profiles and deployment schedules.
- It may be more important for the health of the Internet as a whole to make a choice, even if it not demonstrably optimal.
-
-
Several issues were raised.
-
-
-
- Are there real technical differences between the protocols?Callon: yes; these differences stem from different basic assump- tions about the environment.Huitema pointed out that IS-IS as applied in OSI handles a routing domain that is roughly equivalent to one subnetted class B IP net- work; as applied in TCP/IP, IS-IS is used for a much larger aggre- gation.
- Should the IAB pick the protocol based on information from the first deployed protocol or wait to gather information from both protocols?
- Can the IAB issue a mixed recommendation: e.g., OSPF for pure IP environments, and Dual IS-IS for mixed environments.
- Is it appropriate to make a Draft Standard a Recommended protocol?
- Should the IAB resolve the differences in architecture and environ- ments implied by the two protocols?
- Is an IAB decision important, considering that in reality every vendor will probably end up implementing both protocols?
-
-
No conclusions were reached on these questions. However, the group agreed on the importance of setting an objective set of criteria for advancing a routing protocol towards a standard. Hinden agreed to draft such a list.
NEW ACTION: Hinden: Draft a set of criteria for advancing routing protocols to Draft Standard.
APPENDIX A — AGENDA
IAB MEETING — JANUARY 8-9, 1991USC-ISI, Los Angeles, CA
-
- TUESDAY JANUARY 8, 1991
9:00 Agenda and Action Items — Cerf
9:30 External Relations
o Internet Registry and Connected Status [1]
o OTA Workshop on NREN
10:00 Break
10:30 Internationalization
o Strategy
o Practical issues
12:00 Lunch
13:30 Privacy & Security
o IPSO
o PEM status
o Export Control policy
o Authentication framework
14:30 Break
15:00 Architecture I
o Dave Clark: Introduction (.5 hr)
o Detailed discussion of topics (2 hr)
17:30 Adjourn
WEDNESDAY, JANUARY 9, 1991
9:00 Architecture II
o Detailed discussion of topics, continued (1.5 hrs)
10:30 break
o Conclusions (2 hrs)
[12:00 lunch]
13:30 OSI Issues
o NSAP format (1 hr)
o X.400 & X.500 progress (.5 hr)
15:00 Break
15:30 Standards Issues
o Standards Procedures
o High-speed TCP
16:00 IGP Decision (OSPF vs. IS-IS)
16:50 Future Meetings
17:00 Adjourn
18:30 IAB & IESG Joint dinner —
China Palace Restaurant
3905 Sepulveda Boulevard
Culver City 391 8389
APPENDIX B — ACTION ITEM SUMMARY — JANUARY 10, 1991
Continued Actions from Previous Meetings:
OBE: Cerf: Write up concerns on Operational Infrastructure.
OBE: Gross: Report on distribution of IETF members among WG activi- ties.
DONE: Lynch: Write to COS to encourage their participation in IETF and their suggestions for joint projects.
DONE: Kent: Provide a document specifying the configuration needed to run the PEM software.
OBE: Lauck: Report on status of OSI registration procedures and authorities.
OBE: Cerf: Get a note from Microsoft that the Lan Manager MIB effort is accepted and supported.
OBE: ExecD: Send out list of IETF areas and gather signups from IAB members for standards interest.
DONE: Gross: Ask Steve Kille to take Braun’s draft of the X.500 RFC and add a rationale section to it.
DONE: Cerf: Draft an RFC containing general recommendations about acceptable use of services such as mailing lists.
DONE: Cerf: Discuss crypto export rules with FNC.
DONE: Cerf, Leiner: Chat offline about IAB role in global operational issues.
ACTION: Gross/Vaudreuil: Send message to IAB on how to use IETF WG database.
ACTION: Gross: Finish RFC on technical guidelines for international Internet connections.
ACTION: Postel: Draft “Principles of the Internet [Architecture?]” document.
ACTION: Cerf: Send letter to Sun and Microsoft explaining require- ments for Internet standards.
***My notes say: Need copies for IAB. I don’t recall if this means Vint already sent the letters, or not: ExecD ****
ACTION: Gross: Publish the charter (“Terms of Reference”) and ethics statements of the CCIRN and IEPG as RFCs.
ACTION: Lauck: Write down elaboration of his brief summary of proto- col testing issues.
ACTION: Gross: Obtain document describing subset of BGP that is currently being implemented.
ACTION: Cerf: Form a working party to construct straw-person bylaws for an “Internet society”.
ACTION: ExecD: Check whether any earlier action items for the PWG have fallen through the crack.
ACTION: Postel: Try to publish all acceptable-use policies.
ACTION: IAB: Review VCerf’s RFC-1167 on the NREN.
ACTION: Cerf: Write a more in-depth version of RFC-1167 on the NREN, for later OTA submission.
ACTION: VCerf, DClark, PGross, JPostel: Caucus on an Internet Visions document.
New actions from this meeting:
NEW ACTION: Gross: Document Terms of Reference of IEPG.
NEW ACTION: Lauck: Cause publication of ANSI registration procedures.
NEW ACTION: Cerf: (1) Send RFC-1167 to the OTA panel as a submission on NREN. (2) Offer to comment on the final document when it is available.
NEW ACTION: Kent: Discuss IAB needs with the mmconf group at BBN, and report on configuration requirements.
DONE: S. Crocker, Kent: Complete IPSO document and publish as an Internet Draft.
DONE: Cerf & ExecD: Decide upon mode for April 3, 1991 meeting.
NEW ACTION: Kent: Revise his summary of the export control policy, to include DEC comments.
NEW ACTION: Kent: Ask Kille to review distinguished names as defined in PEM.
NEW ACTION: Hinden: Draft a set of criteria for advancing routing protocols to Draft Standard.
APPENDIX C — REFERENCES
[1] INTERNET REGISTRY AND RFC-1174
DDN Information Bulletin #80 contains:
RFC 1174 recommended eliminating the distinction between “connected” and “unconnected” networks, i.e. between those networks connected to the DDN and Internet, and those that are not. Although the NIC had made some procedural changes in order to comply with the recommendations of RFC 1174, it is now necessary to reinstate the previous IP network number registration polices. This reinstatement of the former methods is taken to provide time for a more thorough investigation into the impact and cost of such changes. In order to accomplish this reinstatement, the distinction of “connected” and “unconnected” networks must be re-established. The following changes are being made to restablish this distinction:
-
- Effective immediately, applicants wishing to obtain IP network numbers must use the application dated 7/90 (later applications will be returned to the applicants with a request for further information). This application is online on the NIC.DDN.MIL host as NETINFO:INTERNET-NUMBER-TEMPLATE.TXT. Applicants wishing connected status for their networks must identify a government sponsor authorizing their connection.
- Information regarding unconnected networks and Autonomous System Numbers (ASNs) will no longer be available through WHOIS.
- The NIC will contact people who registered networks or inverse addressing (IN-ADDR) information from the end of September to the present in order to ascertain their status according to the change in policy. If such networks are unconnected or do not have government sponsors, their data will no longer be available via WHOIS.
APPENDIX D — Internet Activities Board Summary of Internet Architecture Discussion, January 8-9, 1991
1. INTRODUCTION
The Internet Activities Board (IAB) met with the Internet Engineering Steering Group (IESG) on January 8-9, 1991 at the USC Information Sciences Institute in Marina del Rey, CA. The meeting devoted the afternoon of the first day and the morning of the second day to an extended discussion of the future directions for Internet architecture. This document reports on this architecture discussion, which was led by Dave Clark. The minutes of the rest of the meeting are reported elsewhere.
2. DEFINING THE PROBLEM
The first afternoon was spent trying to define the problems to be solved. Clark began the discussion with a presentation of his view of the key issues; his slides are reproduced in Appendix A. Each of his topic slides (7-12) were then discussed in turn.
2.1 The Multi-Protocol Internet [Slide 7]
The discussion began by setting a timeframe for evolution of the Internet and the TCP/IP protocol suite. This timeframe determines the importance of several issues, in particular routing and addressing. It was accepted that OSI is not yet here, and the general feeling was that it will not be for some time. A question: does OSI lead or follow current technology? Alternative scenarios were:
-
-
-
- OSI and TCP/IP both live forever,
- TCP/IP fades,
- OSI fades,
- Next Generation replaces both.
-
-
Debate ensued over the merit of evolving two protocol suites in tandem; some advocated friendly competition, while others called it a waste of effort which could lead to the demise of both.
One alternative discussed was to redirect IAB/IETF efforts to emphasize OSI, devoting all our resources to making OSI a reality. Such actions could include profiling standards, merging standards, and fixing broken OSI standards. However, it was observed that the IAB can only have direct influence over protocols that it controls; an effort based on profiling other protocols is not likely to be successful.
Here is a sample of comments on this topic, lightly paraphrased:
-
-
-
- “The answer will come from the grass roots; people won’t switch unless the old suite breaks or the new one has more features”.
- “Are we asking the wrong question? We’re facing really heterogeneous networks, and must include variety in our thinking”.
- “The IAB can exert more leadership over the (only) suite that it controls”.
- “Even productive competition may be a diversion of effort; we may be getting too complex”.
- “If the goal is interoperation, the world must agree on the protocol basis; right now that means TCP/IP”.
- “I prefer TCP/IP because
- prefer the [development and standardization] process [of the IAB/IETF]”.
- “I am sympathetic to the concern about dilution of effort, but
- doubt that there is really a tradeoff; it will be different people”.
-
-
The concensus most nearly supported the continuation of parallel development of both TCP/IP and OSI suites.
2.2 Routing and Addressing [Slide 8]
The problems of routing and addressing may be strongly affected by the rise of commercial common carrier networks. Some of the scaling and topology problems we experience today will look different as access control and topology become important aspects of the interconnection of commercial service providers.
The target size of the Internet is an important consideration. One viewpoint expressed was that commercial common carriers will dominate, so we only have to wait for them to solve our problems of routing and addressing. However, the more widely held viewpoint was that, while the topology may eventually be whatever the common carriers give us, we cannot count on their providing us the complete service we want. The Internet must be seen as a large and diverse system, and the evolving architecture must be able to deal with combined public/private Internet with a very large address space.
Currently there are many different grades of service, rather than one uniform service. It was suggested that a package transportation service is a better service analogy than the telephone system. Thus, the telephone system offers a homogeneous service, while planes, ships, trains all transport packages but offer different grades of service. Such a diverse infrastructure is needed in internetting.
It seemed likely that some policy-based routing will be necessary.
If we assume that the Internet architecture will continue in use indefinitely, then we need flexibility.
Multicast was a controversial topic. Currently there are no applications available that can make use of its facilities. However, there are some future uses of multicast, including routing, mailing lists, and mass distributions.
2.3 Getting BIG [Slide 9]
Getting big presents several obstacles. The IAB’s past X.500 deployment planning effort was discussed as an example of the problems that can arise. The problem was partly that X.500 is an international standard, hard to adapt.
It was suggested that testing new services like X.500 in the Internet can be very valuable, but it is possible only when there is government funding: “For success in applications testing, you need to find a sugar daddy”. We need more tools for applications — IPC, RPC, authentication — but unfortunately funding for applications development is largely missing. It is important to distinguish research from infrastructure development.
2.4 Dealing with Divestiture [Slide 10]
A number of points were made.
-
-
-
- The introduction of commercial services and the need for accounting will impact the protocols.
- We need to develop a variety of means for measurement and accounting; pricing can be determined later.
- Charging may lead to protocol changes to minimize costs, and the consequences are unpredictable.
- There is no difference in the mechanics of accounting information collection between a connection-oriented and a connectionless network. However, billing on a per-packet basis in a datagram network could lead to very high overhead.
- There is a need for authentication, to prevent fraud.
- The ability to share a common link between two or more administrations is needed.
-
-
2.5 New Services [Slide 11]
Video is an important new service. Video is defined here as a point to point frame-oriented delay-sensitive service. There is a need to do this in a few years, just ahead of the 200MIPs multimedia workstation.
Distributed computing and transaction protocols need to be developed. There is an authentication problem in an operating system when a transaction just appears at a host. One problem with running real distributed applications in the Internet has been the need to set up a lot of configuration information at each end.
It was also observed that even so simple a distributed application as the DNS does not work very well, so we need to do a lot more work on distributed application tools.
2.6 Security [Slide 12]
We need more sophistated models of authentication.
Application relays make it hard to build new applications.
3. ARCHITECTURAL SOLUTIONS
It was intended that the second part of the discussion would home in on some solutions. However, the group was far from a concensus on most issues. Therefore, the time was spent in detailed viewpoint presentations by a number of the participants.
3.1 Vint Cerf
Cerf opened with a list of assertions about the future of the Internet.
-
-
-
- It is less important that a particular technical prediction actually occurs than it is that the architecture makes it POSSIBLE.
- All technologies are eventually overtaken by new ones. Must accomodate PEAK requirements, and must also be prepared for some technologies to linger long past their peak.
- The number of “terminations” (e.g., IP addresses) per person varies from .001 to 1000.
- Total terminations ~ P/4 * 3 * 10, where P = number of persons = 250M, 3 corresponds to home + 2 workers, and the last factor of 10 is for safety. Implies terminations ~ 2*10**9 for US, 36*10**9 for the world.Note that the phone system has extremely high fan-out, Internet fan-out is much lower. Can (will? should?) this change?
- The routing problem is a function of the number of networks and the topology (hierarchy). Suppose we separate HOST# from NET#, and place NET# into a hierarchical structure with provision for “break-out”. Would 32 bits of NET# be enough to cover the administrative overhead of delegated assignment of address space?Strawman:
NET#
32HOST#
32where NET# is hierarchical, and HOST# is perhaps globally unique.
[Debate on this was postponed.]
- Hosts incapable of supporting DNS and other core requirements must ultimately be abandoned to their fate (when can we stop catering to them?). Backward compatibility need not be absolute; a rational window of new and old technology should be defined.Within each protocol suite, there must be a “central, core” set of protocols that defines the network architecture.The question was raised: At what level should multi-protocols exist: IP, Mail, Postscript?
-
-
Cerf continued with a proposed list of requirements, and attempted to gather from the group a general sense of agreement or uncertainty about each one (noted in square brackets).
-
-
-
- Must support more than one protocol suite operating concurrently.It is NOT required that they interwork with each other. Some common applications might be usefully interworked.[Much discussion].
- Must be able to accomodate transmission bandwidths 2.4Kbps (?) to over 10 Gbps.[Not universal agreement; perhaps lower end should be increased.]
- Must accomodate new switching and transmission media wherever possible (e.g., SMDS; ISDN; BISDN; Frame Relay; optically- switched networks; color-multiplexed, tuned-laser nets, and radio technology).[Agreed]
- Must accomodate an address space for 36*10**9 terminations, 1*10**9 networks.
NET#
32HOST#
32[Needs debate]
- Must accomodate private and public network components.[Agreed]
- Must support (at least, not inhibit) collection of statistics for accounting, billing.[Agreed: need example billing and reconciliation scenarios, and need reverse charging. Need debate: IP “charge code” option, authenticable charge codes. Question: in what level of architecture do these features show up??]
- Must support administratively-restricted connectivity.May be at different layers.
- Security constraints (IPSO)
- Closed/partially open “user groups”
- DNS “tailoring” (non-uniform configuration)?
- Router configuration tables (e.g., NSFNET configuration)
[Needs discussion.]
- Must support several classes of service.(Pick a few to start, e.g., “guaranteed bandwidth”, “bounded delay”, and figure out how they might work. What if not supportable by all networks?)[General agreement]
- Must provide for end-to-end authenticated and/or secure (private) communication.
- Application level, so that authentication/privacy survives across application-level relay.
- Transport level?
- SNMP
- Routing Protocols
- DNS/X.500?
- Playback-immune authentication
[General agreement]
- Support host mobility.
Initiate communications FROM “mobile” host
=> temporary binding of IP address (PPP, SLIP). EASY CASE (?).
Receive communications when mobile (or at destination)
=> dynamic tracking of mobile address. HARD!
Would dynamic name/address binding suffice?
How to authenticate DNS update?
Delay and responsiveness?(Some network technologies make it easy).
[Timescale is an issue. Maybe not at high speed? (Rate of change of connectivity is the big issue). What about military applications?]
-
-
3.2 Christian Huitema
Huitema saw the biggest problem in the Internet as one of getting big, or rather, “getting wide”. Topology is moving to multiple backbones and multiple registries.
To scale to the sizes we are considering, a fully dynamic routing process is impossible. What is needed is a directory of address to network translations and routing info. Flooding of routing information should be replaced by a route server, which can either hold pre-computed routes or compute routes as needed.
3.3 Noel Chiappa
Security is the key to the future evolution of the Internet. The solution to this problem will dictate the architecture of the rest of the system.
3.4 Bob Hinden
Hinden commented on each of the topic slides.
-
-
-
- Multi-Protocol InternetIt would be nice to have one protocol suite, but we must live with both TCP/IP and OSI.A useful strategy might be to feed TCP/IP protocol developments into OSI process (e.g., BGP -> IDRP).
- Routing and Addressing
- Need 1 to 2 orders of magnitude growth.
- Addresses should be identifiers, logically distinct from routes.
- We will have to impose a hierarchical structure to handle growth. A 3-tier topology (backbone, regional, private) is sufficient, but it must provide for arbitrary interconnections.
- Policy: Source controlled. Backbone, regional, private networks will support distinct policies (where they provide parallel service).
- Mobile host support would be desirable.
- Multicasting will not be useful until there are real applications.
- Getting BigApplications are badly needed.
- Make email good enough for commerce.
- Desktop conferencing with video.
- Bulletin board paradigm: it is powerful and should be exploited more.
- Information collection (Knowbots?)
- Video retrieval and libraries.
- Distributed simulation.
- Divestiture
- Does not believe common carriers will provide universal service (“the Cheriton conjecture”); we will still need to do internetting.
- Need accounting, not billing.
- New ServicesVideo is very important.
- SecurityThe network needs to protect itself: control protocols need security.The network should provide an authentication service. All other security needed by an application can be end-to-end.
-
-
3.5 Russ Hobby
Hobby emphasized the need for new applications. Tools are needed for building distributed applications, including RPC and standard presentation formats. Both personal communication and “virtual computer” applications need work. There is a pressing need to recruit a set of experts and secure funding for them.
3.6 Joyce Reynolds
Reynolds enumerated a list of needed user services. There is a need to international coordination and for more publicity. A network information services infrastructure and yellow pages are needed. Issues of copyright and intellectual property need to be explored.
3.7 Dave Crocker
Crocker identified the need for upper layer development. There is a missing skill set in the IETF, presentation and applications development. There is a need to begin hiding the complexity of the network.
3.8 Tony Lauck
Lauck presented many points.
-
-
-
- Architecture is more than the protocols, it is addressing.
- Relays are a necessary evil, because of history, pragmatics, and especially corporate security policies. Better Internet security will result in fewer relays. The IAB should work to limit the growth of relays.
- There is not chance to constrain the development of multiple protocol suites; they are here today. Beware of problems of testing interoperability, with exponential combinations at various layers.
- The size of the Internet is not a big issue. 10**9? 10**11? 10**12?
- In large networks, addresses, routes, and topology must be related for reasonable performance — log(n) vs. n. Hierarchy is sub-optimal, but at least it is possible, and will allow the construction of large networks.
- Policy routing is all solutions with no questions.
- Support for mobile hosts is needed, to make them more useful for personal work.
- Multicast has marginal value, could be dangerous.
- Phase out fragmentation, it’s a mistake in IP that OSI copied.
- The network should support devices ranging from small thermostats to large supercomputers.
- Charging is important because without it there is little motivation to develop new applications. The ban on commercial use also restricts innovation.
- Must have controls for limited sharing of links. Hard problem is to keep this simple.
- Transaction processing standards are complex and farther along in OSI.
- Distributed processing is coming (slowly) in OSI. We should work with existing efforts in these applications.
- End node cannot be the only point for security. Mis- configuration is a real danger and the Internet should be able to defend itself.
- Global authentication is most important part of distributed processing.
-
-
3.9 Ross Callon
Callon discussed the coexistence of multiple protocol suites, starting from a series of questions:
-
-
-
- What is meta-architecture for a multi-protocol Internet?
- Does the concept of a “pure suite” exist? For example, the Internet includes other defacto standards like NFS and Postscript.
- Might it make sense to fill the holes in one suite using protocols from another suite?
- This does not break the notion of distinct TCP/IP and OSI protocol suites, but it might be a good idea to break it.
-
-
The idea of merely sharing the links and letting the rest of the protocol stack be different defeats interoperability. He proposed to chip away at the differences by sharing: routing, user agents, directories (DNS-X.500 merge), mail protocols (SMTP exchange of X.400 format), ODA and RDI, and EDI. This sharing would unify the architecture, save some effort, and enhance interoperability.
3.10 Lyman Chapin
The Internet will change with the introduction of commercial carriers.
A multi-protocol-suite Internet is currently a necessity, although this is not best architectural choice. OSI efforts really need the input of the IETF community. There is the very real possibility that the IETF can have profound impact on the course of OSI protocols.
Chapin summarized the possibilities in the following diagram:
|
_______ |
| TCP |---------------------->
|_______| | |
______|____ |
|"new stuff"| | "Future"
|___________| |
| |
_______ V |
| OSI |---------------------->
|_______| |
3.11 Steve Kent
Kent offered ideas on the internet security architecture.
-
-
- Do we put security in only the endpoints? “Hosts will always be the best defense or the weakest link”.
- Site administrators erect perimeter defenses; architecture needs to include them. Now that hosts are being managed by users, managers are increasingly unable to administer individual computers, so they use using perimeter defense.
- Need both end security services and also some functions in intermediate system, e.g., accounting and billing.
- Security is ultimately linked to routing and addressing.
- He dislikes application level relays, and there are also some security problems. Where does security go in the protocol stack? In the application there is too much duplication, and presentation syntax is a problem if security is in the applications.
- Global authentication would be a Good Thing.
-
4. WRAP-UP
Clark led a final high-level wrap up. He saw three alternative futures:
-
-
- Relays dominate the world. X.400 becomes the only ubiquitous protocol, while IP/CLNP are used only locally. X.400 and X.500 become generalized to accommodate other applications.Clark rejects this as the “only” solution.
- Commercial carriers dominate. Routing is handled entirely inside the common carriers; this is the “Cheriton Conjecture”.We must accept this as an ultimate possibility.
- Heterogeneity dominates. Can it be global?
-
The group felt a need to build a future that accommodates these diverse visions, even if the complex solution ends up not being needed. The IAB is in a position to influence the future, and should work towards the preferable outcomes.
The IAB felt that vision 1 is a nightmare. However, it will exist to a limited extent, so application level gateways should be architected into the system. Vision 2 is a possibility the IAB must deal with. Vision 3 is the most general, and constitutes the basis for a plan.
Further discussion is needed, and the IAB planned an “architectural summit”. There was lots of interest in an architecture summit. Participation will be limited to the IAB and IESG and all participants should come prepared with papers. This is tentatively scheduled for June 11-13, 1991.
APPENDIX A: Dave Clark Introduction
Slide 1
WHITHER THE INTERNET?
OPTIONS FOR ARCHITECTURE
IAB/IESG — Jan 1990
David D. Clark
Slide 2
SETTING THE TOPIC OF DISCUSSION
Goals:
-
-
- Establish a common frame of understanding for IAB, IESG and the Internet community.
- Understand the set of problems to be solved.
- Understand the range of solutions open to us.
- Draw some conclusions, or else “meta-conclusions”.
-
Slide 3
SOME CLAIMS — MY POSITION
We have two different goals:
-
-
- Make it possible to build “The Internet”
- Define a protocol suite called Internet
-
Claim: These goals have very different implications. The protocols are but a means, though a powerful one.
Claim: If “The Internet” is to succeed and grow, it will require specific design efforts. This need will continue for at least another 10 years.
Claim: Uncontrolled growth could lead to chaos.
Claim: A grass-roots solution seems to be the only means to success. Top-down mandates are powerless.
Slide 4
OUTLINE OF PRESENTATION
1) The problem space and the solution space.
2) A set of specific questions — discussion.
3) Return to top-level questions — discussion.
4) Plan for action — meta discussion.
Try to separate functional requirements from technical approach.
Understand how we are bounded by our problem space and our solution space.
Is architecture anything but protocols?
Slide 5
WHAT IS THE PROBLEM SPACE?
Routing and addressing:
How big, what topology, and what routing model?
Getting big:
User services, what technology for host and nets?
Divestiture of the Internet:
Accounting, controlling usage and fixing faults.
New services:
Video? Transactions? Distributed computing?
Security:
End node or network? Routers or relays?
Slide 6
BOUNDING THE SOLUTION SPACE
How far can we migrate from the current state?
-
-
- Can we change the IP header (except to OSI)?
- Can we change host requirements in mandatory ways?
- Can we manage a long-term migration objective? – Consistent direction vs. diverse goals, funding.
-
Can we assume network-level connectivity?
-
-
- Relays are the wave of the future (?)
- Security a key issue; along with conversion.
- Do we need a new “relay-based” architecture?
-
How “managed” can/must “The Internet” be?
-
-
- Can we mandage or constrain connectivity?
-
What protocols are we working with? One or many?
Slide 7
THE MULTI-PROTOCOL INTERNET
“Making the problem harder for the good of mankind.”
Are we migrating, interoperating, or tolerating multiple protocols?
-
-
- Not all protocol suites will have same range of functionality at the same time.
- “The Internet” will require specific functions.
-
Claim: Fundamental conflict (not religion or spite):
-
-
- Meeting aggressive requirements for the Internet
- Dealing with OSI migration.
-
Conclusion: One protocol must “lead”, and the others must follow.
When do we “switch” to OSI?
Consider every following slide in this context
Slide 8
ROUTING and ADDRESSING
What is the target size of “The Internet”?
-
-
- How do addresses and routes relate?
- What is the model of topology?
- What solutions are possible?
-
What range of policy routing is required?
-
-
- BGP and IDRP are two answers. What is the question?
- Fixed classes, or variable paths?
- Source controlled routing is a minimum.
-
How seamless is the needed support for mobile hosts?
-
-
- New address class, rebind to local address, use DNS?
-
Shall we push for Internet multicast?
Slide 9
GETTING BIG — AN OLD TITLE
(Addressing and routing was on previous slide…)
What user services will be needed in the next 10 years?
-
-
- Can we construct a plan?
- Do we need architectural changes?
-
Is there a requirement for dealing better with ranges in speed, packet sizes, etc.
-
-
- Policy to phase out fragmentation?
-
What range of hosts (things != Unix) will we support?
Slide 10
DEALING WITH DIVERSTITURE
The Internet is composed of parts separately managed and controlled.
What support is needed for network charging?
-
-
- No architecture implies bulk charges and re-billing, pay for lost packets.
- Do we need controls to supply billing id or routing?
-
Requirement: we must support links with controlled sharing. (Simple form is classes based on link id.)
-
-
- How general?
-
Is there an increased need for fault isolation? (I vote yes!)
-
-
- How can we find managerst to talk to?
- Do we need services in hosts?
-
Slide 11
NEW SERVICES
Shall we support video and audio? Real time? What %?
-
-
- Need to plan for input from research. What quality?
- Target date for heads-up to vendors.
-
Shall we “better” support transactions?
-
-
- Will TCP do? VMTP? Presentation? Locking?
-
What application support veneers are coming?
-
-
- Distributed computing — will it actuall happen?
- Information networking?
-
Slide 12
SECURITY
Can we persist in claiming the end-node is the only line of defense?
-
-
- What can we do inside the network?
- What can ask the host to do?
-
Do we tolerate relays, or architect them?
Can find a better way to construct security boundaries? Do we need global authentication?
Do we need new host requirements:
-
- Logging.
- Authentication.
- Management interfaces.
- Phone number or point of reference.