rfc1636.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                          R. Braden
Request for Comments: 1636                                           ISI
Category: Informational                                         D. Clark
                                     MIT Laboratory for Computer Science
                                                              S. Crocker
                                       Trusted Information Systems, Inc.
                                                              C. Huitema
                                                        INRIA, IAB Chair
                                                               June 1994


                       Report of IAB Workshop on

                 Security in the Internet Architecture

                          February 8-10, 1994

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document is a report on an Internet architecture workshop,
   initiated by the IAB and held at USC Information Sciences Institute
   on February 8-10, 1994.  This workshop generally focused on security
   issues in the Internet architecture.

   This document should be regarded as a set of working notes containing
   ideas about security that were developed by Internet experts in a
   broad spectrum of areas, including routing, mobility, realtime
   service, and provider requirements, as well as security.  It contains
   some significant diversity of opinions on some important issues.
   This memo is offered as one input in the process of developing viable
   security mechanisms and procedures for the Internet.














Braden, Clark, Crocker & Huitema                                [Page 1]

RFC 1636                  IAB Workshop Report                  June 1994


Table of Contents

   1. INTRODUCTION ..................................................  2
   2. OVERVIEW ......................................................  4
      2.1  Strategic and Political Issues ...........................  4
      2.2  Security Issues ..........................................  4
      2.3  DNS Names for Certificates ...............................  7
   3. FIREWALL ARCHITECTURE .........................................  9
      3.1  Introduction .............................................  9
      3.2  Application-Layer Firewalls .............................. 11
      3.3  IP-Layer Firewalls ....................................... 12
   4. SECURE QOS FORWARDING ......................................... 21
      4.1  The Requirement for Setup ................................ 21
      4.2  Securing the Setup Process. .............................. 22
      4.3  Validating an LLID ....................................... 24
      4.4  Dynamics of Setup ........................................ 28
      4.5  Receiver-Initiated Setup ................................. 30
      4.6  Other Issues ............................................. 30
   5. AN AUTHENTICATION SERVICE ..................................... 35
      5.1  Names and Credentials .................................... 36
      5.2  Identity-Based Authorization ............................. 37
      5.3  Choosing Credentials ..................................... 38
   6. OTHER ISSUES .................................................. 39
      6.1  Privacy and Authentication of Multicast Groups ........... 39
      6.2  Secure Plug-and-Play a Must .............................. 41
      6.3  A Short-Term Confidentiality Mechanism ................... 42
   7. CONCLUSIONS ................................................... 44
      7.1  Suggested Short-Term Actions ............................. 44
      7.2  Suggested Medium-Term Actions ............................ 46
      7.3  Suggested Long-Term Actions .............................. 46
   APPENDIX A -- Workshop Organization .............................. 48
   Security Considerations .......................................... 52
   Authors' Addresses ............................................... 52

1. INTRODUCTION

   The Internet Architecture Board (IAB) holds occasional workshops
   designed to consider long-term issues and strategies for the
   Internet, and to suggest future directions for the Internet
   architecture.  This long-term planning function of the IAB is
   complementary to the ongoing engineering efforts performed by working
   groups of the Internet Engineering Task Force (IETF), under the
   leadership of the Internet Engineering Steering Group (IESG) and area
   directorates.

   An IAB-initiated workshop on the role of security in the Internet
   Architecture was held on February 8-10, 1994 at the Information
   Sciences Institute of the University of Southern California, in



Braden, Clark, Crocker & Huitema                                [Page 2]

RFC 1636                  IAB Workshop Report                  June 1994


   Marina del Rey, California.  This RFC reports the results of the
   workshop.

   In addition to the IAB members, attendees at this meeting included
   the IESG Area Directors for the relevant areas (Internet, Transport,
   Security, and IPng) and a group of 15 other experts in the following
   areas:  IPng, routing, mobility, realtime service, and security (see
   Appendix for a list of attendees).  The IAB explicitly tried to
   balance the number of attendees from each area of expertise.
   Logistics limited the attendance to about 30, which unfortunately
   meant that many highly qualified experts were omitted from the
   invitation list.

   In summary, the objectives of this workshop were (1) to explore the
   interconnections between security and the rest of the Internet
   architecture, and (2) to develop recommendations for the Internet
   community on future directions with respect to security.  These
   objectives arose from a conviction in the IAB that the two most
   important problem areas for the Internet architecture are scaling and
   security.  While the scaling problems have led to a flood of
   activities on IPng, there has been less effort devoted to security.

   Although some came to the workshop eager to discuss short-term
   security issues in the Internet, the workshop program was designed to
   focus more on long-term issues and broad principles.  Thus, the
   meeting began with the following ground rule: valid topics of
   discussion should involve both security and at least one from the
   list: (a) routing (unicast and multicast), (b) mobility, and (c)
   realtime service.  As a basis for initial discussion, the invitees
   met via email to generate a set of scenarios (see Appendix)
   satisfying this ground rule.

   The 30 attendees were divided into three "breakout" groups, with each
   group including experts in all the areas.  The meeting was then
   structured as plenary meetings alternating with parallel breakout
   group sessions (see the agenda in Appendix).  On the third day, the
   groups produced text summarizing the results of their discussions.
   This memo is composed of that text, somewhat rearranged and edited
   into a single document.

   The meeting process determined the character of this document.  It
   should be regarded as a set of working notes produced by mostly-
   autonomous groups, containing some diversity of opinions as well as
   duplication of ideas.  It is not the output of the "security
   community", but instead represents ideas about security developed by
   a broad spectrum of Internet experts.  It is offered as a step in a
   process of developing viable security mechanisms and procedures for
   the Internet.



Braden, Clark, Crocker & Huitema                                [Page 3]

RFC 1636                  IAB Workshop Report                  June 1994


2. OVERVIEW

   2.1  Strategic and Political Issues

      Despite the workshop emphasis on architectural issues, there was
      considerable discussion of the real-politik of security.

      For a number of years, the IETF, with IAB backing, has worked on
      developing PEM, which provides email security with a great deal of
      functionality.  A question was repeatedly raised at the workshop:
      why has user acceptance of PEM been slow?  A number of answers to
      this question were suggested.

      (a)  High-quality implementations have been slow in coming.

      (b)  The use of a patented technology, the RSA algorithm, violates
           social conventions of the Internet.

      (c)  Export restrictions dampen vendor enthusiasm.

      (d)  PEM currently depends upon a certificate hierarchy for its
           names, and certificates form a new and complex name space.
           There is no organizational infrastructure in place for creat-
           ing and managing this name space.

      (e)  There is no directory infrastructure available for looking up
           certificates.

           The decision to use X.500 has been a complete failure, due to
           the slow deployment of X.500 in the Internet.  Because of UDP
           packet size restrictions, it is not currently feasible to
           store certificates in the DNS, even if the DNS were expanded
           to hold records for individual email users.

      It seems probable that more than one, and possibly all, of these
      reasons are at work to discourage PEM adoption.

      The baleful comment about eating: "Everything I enjoy is either
      immoral, illegal, or fattening" seems to apply to the cryptography
      technology that is required for Internet security.

   2.2  Security Issues

      Almost everyone agrees that the Internet needs more and better
      security.  However, that may mean different things to different
      people.  Four top-level requirements for Internet security were
      identified: end-to-end security, end-system security, secure QOS,
      and secure network infrastructure.



Braden, Clark, Crocker & Huitema                                [Page 4]

RFC 1636                  IAB Workshop Report                  June 1994


      A.   End-to-End Security

           One requirement is to support confidentiality, authentication
           and integrity for end-to-end communications.  These security
           services are best provided on an end-to-end basis, in order
           to minimize the number of network components that users must
           trust.  Here the "end" may be the end system itself, or a
           proxy (e.g., a firewall) acting on behalf of an end system.

           For point-to-point applications, the workshop felt that
           existing security techniques are well suited to support
           confidentiality, authentication and integrity services
           efficiently.  These existing techniques include symmetric
           encryption applied on an end-to-end basis, message digest
           functions, and key management algorithms.  Current work in
           these areas in the IETF include the PEM and Common
           Authentication Technologies working groups.

           The group favored a strategic direction for coping with
           export restrictions:  separate authentication from privacy
           (i.e., confidentiality).  This will allow work to proceed on
           authentication for the Internet, despite government
           restrictions on export of privacy technology.  Conversely, it
           will allow easy deployment of privacy without authentication,
           where this is appropriate.

           The workshop explored the implications of multicasting for
           end-to-end security.  Some of the unicast security techniques
           can be applied directly to multicast applications, while
           others must be modified.  Section 6.2 contains the results of
           these discussions; in summary, the conclusions were:

           a)   Existing technology is adequate to support
                confidentiality, authentication, and integrity at the
                level of an entire multicast group.  Supporting
                authentication and integrity at the level of an
                individual multicast source is performance-limited and
                will require technology advances.

           b)   End-to-end controls should be based on end system or
                user identifiers, not low level identifiers or locator
                information.  This requirement should spawn engineering
                work which consists of applying known key distribution