rfc1636.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,379 行 · 第 1/5 页

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


                and cryptographic techniques.

      B.   End-System Security

           Every host has its own security defenses, but the strength of
           these defenses depends upon the care that is taken in
           administering them.  Careful host security administration
           means plugging security holes in the kernel and applications
           as well as enforcing discipline on users to set good (hard to
           crack) passwords.

           Good security administration is labor-intensive, and
           therefore organizations often find it difficult to maintain
           the security of a large number of internal machines.  To
           protect their machines from outside subversion, organizations
           often erect an outer security wall or "perimeter".  Machines
           inside the perimeter communicate with the rest of the
           Internet only through a small set of carefully managed
           machines called "firewalls".  Firewalls may operate at the
           application layer, in which case they are application relays,
           or at the IP layer, in which case they are firewall routers.

           The workshop spent considerable time on the architecture of
           firewall routers.  The results are contained in Section 3.

      C.   Secure QOS

           The Internet is being extended to provide quality-of-service
           capabilities; this is the topic called "realtime service" in
           the workshop.  These extensions raise a new set of security
           issues for the architecture, to assure that users are not
           allowed to attach to resources they are not authorized to
           use, both to prevent theft of resources and to prevent denial
           of service due to unauthorized traffic.  The resources to be
           protected include link shares, service classes or queues,
           multicast trees, and so on.  These resources are used as
           virtual channels within the network, where each virtual
           channel is intended to be used by a particular subset or
           "class" of packets.

           Secure QOS, i.e., protection against improper virtual channel
           usage, is a form of access control mechanism.  In general it
           will be based on some form of state establishment (setup)
           that defines authorized "classes".  This setup may be done
           via management configuration (typically in advance and for
           aggregates of users), or it may be done dynamically via
           control information in packets or special messages (typically
           at the time of use by the source or receiver(s) of the



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


           flow/data).  In addition to state establishment, some form of
           authentication will be needed to assure that successive
           packets belong to the established class.  The general case to
           be solved is the multicast group, since in general the
           multicast problem includes the two-party case as a subset.
           The workshop developed an approach to the secure QOS problem,
           which appears in Section 4 below.

      D.   Secure Network Infrastructure

           Network operation depends upon the management and control
           protocols used to configure and operate the network
           infrastructure, including routers and DNS servers.  An attack
           on the network infrastructure may cause denial-of-service
           from the user viewpoint, but from the network operators'
           viewpoint, security from attack requires authentication and
           integrity for network control and management messages.

           Securing the routing protocols seems to be a straightforward
           engineering task.  The workshop concluded the following.

           a)   All routing information exchanges should be
                authenticated between neighboring routers.

           b)   The sources of all route information should be
                authenticated.

           c)   Although authenticating the authority of an injector of
                route information is feasible, authentication of
                operations on that routing information (e.g.,
                aggregation) requires further consideration.

           Securing router management protocols (e.g., SNMP, Telnet,
           TFTP) is urgent, because of the currently active threats.
           Fortunately, the design task should be a straightforward
           application of existing authentication mechanisms.

           Securing DNS is an important issue, but it did not receive
           much attention at the workshop.

   2.3  DNS Names for Certificates

      As noted in Section 2.1, work on PEM has assumed the use of X.509
      distinguished names as the basis for issuing certificates, with
      public-key encryption.  The most controversial discussion at the
      workshop concerned the possibility of using DNS (i.e., domain)
      names instead of X.509 distinguished names as (at least) an
      interim basis for Internet security.



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


      The argument in favor of DNS names is that they are simple and
      well understood in the Internet world.  It is easy for a computer
      operating in the Internet to be identified this way, and users who
      receive email on such machines already have DNS mailbox names.  In
      contrast, introducing X.509 distinguished names for security will
      add a new layer of names.  Most importantly, there is an existing
      administrative model for assigning DNS names.  There is no
      administrative infrastructure for assigning X.509 distinguished
      names, and generating them may be too complex for early
      acceptance.  The advocates of DNS names for certificates hope that
      using DNS names would encourage the widespread use of security in
      the Internet.  It is expected that DNS names can be replaced later
      by a more capable naming mechanism such as X.509-based
      certificates.

      The basic argument against DNS names as a basis for security is
      that they are too "weak".  Their use may lead to confusion in many
      instances, and this confusion can only grow as more organizations
      and individuals attach to the Internet.  Some commercial email
      systems employ numeric mailbox names, and in many organizations
      there are uncertainties such as whether "[e-mail]" belongs
      to Bill Umber or Tom Bumber.  While it is feasible to make DNS
      names more descriptive, there is a concern that the existing
      infrastructure, with millions of short, non-descriptive names,
      will be an impediment to adoption of more descriptive names.

      It was noted that the question of what name space to use for
      certificates is independent of the problem of building an
      infrastructure for retrieving those names.  Because of UDP packet
      size restrictions, it would not be feasible to store certificates
      in the DNS without significant changes, even if the DNS were
      expanded to hold records for individual email users.

      The group was unable to reach a consensus on the issue of using
      DNS names for security; further discussion in the Internet
      community is needed.















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


3. FIREWALL ARCHITECTURE

   3.1  Introduction

      A firewall may be used to isolate a specific connected segment of
      Internet topology.  When such a segment has multiple links to the
      rest of the Internet, coordinated firewall machines are required
      on all the links.

      Firewalls may be implemented at different layers in the protocol
      stack.  They are most commonly implemented at the application
      layer by forwarding (application) gateways, or at the IP
      (Internet) layer by filtering routers.  Section 3.2 discusses
      application gateways.  Section 3.3 concerns Internet-layer
      firewalls, which filter IP datagrams entering or leaving a
      security perimeter.

      The general architectural model for a firewall should separate
      policy, i.e., determining whether or not the requester of a
      service should be granted access to that service, from control,
      i.e., limiting access to resources to those who have been granted
      access.

      3.1.1  The Use for Firewalls

         Firewalls are a very emotional topic in the Internet community.
         Some community members feel the firewall concept is very
         powerful because firewalls aggregate security functions in a
         single place, simplifying management, installation and
         configuration.  Others feel that firewalls are damaging for the
         same reason: they provide "a hard, crunchy outside with a soft
         chewy center", i.e., firewalls foster a false sense of
         security, leading to lax security within the firewall
         perimeter.  They observe that much of the "computer crime" in
         corporate environments is perpetrated by insiders, immune to
         the perimeter defense strategy.  Firewall advocates counter
         that firewalls are important as an additional safeguard; they
         should not be regarded as a substitute for careful security
         management within the perimeter.  Firewall detractors are also
         concerned about the difficulty of using firewalls, requiring
         multiple logins and other out-of-band mechanisms, and their
         interference with the usability and vitality of the Internet.

         However, firewalls are a fact of life in the Internet today.
         They have been constructed for pragmatic reasons by
         organizations interested in a higher level of security than may
         be possible without them.  This section will try to outline
         some of the advantages and disadvantages of firewalls, and some



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


         instances where they are useful.

         Consider a large organization of thousands of hosts.  If every
         host is allowed to communicate directly with the outside world,
         attackers will attempt to penetrate the organization by finding
         the weakest host in the organization, breaching its defenses,
         and then using the resources of that host to extend the
         penetration further within the organization.  In some sense,
         firewalls are not so much a solution to a security problem as
         they are a reaction to a more basic software
         engineering/administration problem: configuring a large number
         of host systems for good security.  If this more basic problem
         could be solved, firewalls would generally be unnecessary.

         It is interesting to consider the effect that implementing a
         firewall has upon various individuals in the organization.
         Consider first the effect upon an organization's most secure
         host.  This host basically receives little or no extra
         protection, because its own perimeter defenses are as strong or
         stronger than the firewall.  In addition, the firewall will
         probably reduce the connectivity available to this host, as
         well as the reliability of the communications path to the
         outside world, resulting in inconvenience to the user(s) of
         this host.  From this (most secure) user's point of view, the
         firewall is a loss.

         On the other hand, a host with poor security can "hide" behind
         the firewall.  In exchange for a more limited ability to
         communicate with the outside world, this host can benefit from
         the higher level of security provided by the firewall, which is
         assumed to be based upon the best security available in the
         entire  organization.  If this host only wants to communicate
         with other hosts inside the organization, the outside
         communications limitations imposed by the firewall may not even
         be noticed.  From this host's viewpoint, better security has
         been gained at little or no cost.

         Finally, consider the point of view of the organization as a
         whole.  A firewall allows the extension of the best security in
         the organization across the whole organization.  This is a
         benefit (except in the case where all host perimeter defenses
         in the organization are equal).  Centralized access control