rfc1636.txt

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


RFC 1636                  IAB Workshop Report                  June 1994


         Consider some cases where firewalls do not make sense.  An
         individual can be thought of as an organization of one host.
         The security of all the host(s) is thus (trivially) identical,
         and by definition the best available to the organization.  In
         this case the choice of firewall is simple.  Does this
         individual wish to communicate with the outside or not?  If
         not, then the "perfect" firewall is implemented (by complete
         disconnection).  If yes, then the host perimeter will be the
         same as the firewall perimeter, so a firewall becomes
         unnecessary.

         Another interesting case is an organization that consists of
         individuals with few shared interests.  This might be the case
         of a service provider that sells public access to the network.
         An unrelated community of subscribers should probably be
         considered as individuals, rather than an organization.
         Firewalls for the whole organization may make little sense in
         this case.

         To summarize, the benefit of a firewall depends upon the nature
         of the organization it protects.  A firewall can be used to
         extend the best available protection within the organization
         across the entire organization, and thus be of benefit to large
         organizations with large numbers of poorly administered hosts.
         A firewall may produce little or no perceived benefit, however,
         to the individuals within an organization who have strong host
         perimeters already.

   3.2  Application-Layer Firewalls

      An application-layer firewall can be represented by the following
      diagram.

          C <---> F <---> S

      Here the requesting client C opens its transport connection to the
      firewall F rather than directly to the desired server S.  One
      mechanism for redirecting C's request to F's IP address rather
      than S's could be based on the DNS.  When C attempts to resolve
      S's name, its DNS lookup would return a "service redirection"
      record (analogous to an MX record) for S.  The service redirection
      record would return the IP address of F.

      C enters some authentication conversation to identify itself to F,
      and specifies its intention to request a specific service from S.
      F then decides if C is authorized to invoke this service.  If C is
      authorized, F initiates a transport layer connection to S and
      begins the operation, passing requests and responses between C and



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


      S.

      A major advantage of this scenario over an IP-layer firewall is
      that raw IP datagrams are never passed through the firewall.
      Because the firewall operates at the application layer, it has the
      opportunity to handle and verify all data passing through it, and
      it may be more secure against illicit rendezvous attacks (see
      below).

      Application layer firewalls also have important disadvantages.
      For full benefit, an application level firewall must be coded
      specifically for each application.  This severely limits the
      deployment of new applications.  The firewall also represents a
      new point of failure; if it ceases to be reachable, the
      application fails.  Application layer firewalls also may affect
      performance more than IP-layer firewalls, depending on specific
      mechanisms in use.

   3.3  IP-Layer Firewalls

      Our model of an IP-layer firewall is a multi-ported IP router that
      applies a set of rules to each incoming IP datagram, to decide
      whether it will be forwarded.  It is said to "filter" IP
      datagrams, based on information available in the packet headers.

      A firewall router generally has a set of filtering rules, each of
      which specifies a "packet profile" and an "action".  The packet
      profile specifies values for particular header fields, e.g.,
      source and destination IP address, protocol number, and other
      suitable source and destination identifying information (for
      instance, port numbers).  The set of possible information that may
      be used to match packets is called an "association".  The exact
      nature of an association is an open issue.

      The high-speed datagram forwarding path in the firewall processes
      every arriving packet against all the packet profiles of all
      active rules, and when a profile matches, it applies the
      corresponding action.  Typical actions may include forwarding,
      dropping, sending a failure response, or logging for exception
      tracking.  There may be a default rule for use when no other rule
      matches, which would probably specify a drop action.

      In addition to the packet profile, some firewalls may also use
      some cryptographic information to authenticate the packet, as
      described below in section 3.3.2.






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


      3.3.1  Policy Control Level

         This section presents a model for the control of a firewall
         router, with some examples of specific mechanisms that might be
         used.

         1.   A client C attempts to access a service S.  (Client here
              can mean either a person or a process - that also is an
              issue to be resolved.)

         2.   The initiation of access to that service may result in an
              attempt to cross one or more boundaries of protection via
              firewall router(s).

         3.   The policy control level sets filters in the firewall
              router(s), to permit or deny that attempt.

         The policy control level consists of two distinct functions,
         authentication and authorization.  Authentication is the
         function of verifying the claimed identity of a user.  The
         authentication function should be distributed across the
         Internet, so that a user in one organization can be
         authenticated to another organization.  Once a user is
         authenticated, it is then the job of the authorization service
         local to the resource being requested to determine if that user
         is authorized to access that resource.  If authorization is
         granted, the filter in the firewall can be updated to permit
         that access.

         As an aid to understanding the issues, we introduce a
         particular detailed mechanism.  We emphasize that this
         mechanism is intended only as an illustrative example; actual
         engineering of the mechanism will no doubt lead to many
         changes.  Our mechanism is illustrated by the following sketch.
         Here a user wishes to connect from a computer C behind firewall
         F1, to a server S behind firewall F2.  A1 is a particular
         authentication server and Z1 is a particular authorization
         server.

                C <-------> F1 <-------> F2 <-------> S
                 \          /
                  \_____   /
                   \    \ /
                    A1  Z1

         C attempts to initiate its conversation by sending an initial
         packet to S.  C uses a normal DNS lookup to resolve S's name,
         and uses normal IP routing mechanisms.  C's packet reaches



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


         firewall router F1, which rejects the packet because it does
         not match any acceptable packet profile.  F1 returns an
         "Authentication Required" error indication to C, including a
         list of authentication/authorization servers that F1 trusts.
         This indication might be a new type of ICMP Destination
         Unreachable packet, or some other mechanism for communicating
         with C.

         When C receives the error indication, authenticates itself with
         A1, one of the authentication servers listed in the error
         indication, after validating A1's identity.  C then requests
         authorization from server Z1 (using a ticket provided by A1),
         informs Z1 of the application it wishes to perform, and
         provides a profile for the packets it wishes to pass through
         F1.  Z1 then performs an authorization function to decide
         whether to allow C to penetrate F1.  If C is to be allowed, Z1
         then informs the firewall F1 to allow packets matching the
         packet profile to pass through the firewall F1.

         After C's packets penetrate F1, they may again be rejected by a
         second firewall F2.  C could perform the same procedures with
         authentication server A2 and authorization server Z2, which F2
         trusts.  This is illustrated by the following schematic diagram
         of the sequence of events.



























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



          ----------+--------+--------+------------+------------+----
         |    C     |   A1   |   Z1   |    F1      |     F2     |  S
          ----------+--------+--------+------------+------------+----
         | Sends pkt|        |        |            |            |
         | to S  ----------------------->Intercept;|            |
         |          |        |        | requires   |            |
         |          |        |        |authenticat'n            |
         |   <-------------------------------      |            |
         |Auth'cate |        |        |            |            |
         | C to A1 ---->     |        |            |            |
         |          |Provide |        |            |            |
         |    <------- ticket|        |            |            |
         | Request  |        |        |            |            |
         |authoriz'n|        |        |            |            |
         |   -------------------> Is C|            |            |
         |          |        |allowed?|            |            |
         |          |        |  OK --------->      |            |
         |Resend    |        |        | Set filter |            |
         | first pkt|        |        |            |            |
         | to S -------------------------->(OK)------>Intercept;|
         |          |        |        |            | requires   |
         |          |        |        |            |authenticat'n
         |  <-------------------------------------------        |
         | (Repeat  |        |        |            |            |
         |procedure |        |        |            |            |
         with A2,Z2)|        |        |            |            |
         |  ...     |        |        |            |            |
         |Resend    |        |        |            |            |
         | first pkt|        |        |            |            |
         |   ------------------------------>(OK)--------(OK)------>
         |          |        |        |            |            |
         -----------+--------+--------+------------+------------+----


         Again, we emphasize that this is only intended as a partial
         sketch of one possible mechanism.  It omits some significant
         issues, including the possibility of asymmetric routes (see
         3.3.3 below), and the possibility that the profiles may be
         different in the two directions between C and S.

         We could imagine generalizing this to an arbitrary sequence of
         firewalls.  However, security requires that each of the
         firewalls be able to verify that data packets actually come
         from C.  This packet authentication problem, which is discussed
         in the next section, could be extremely difficult if the data
         must traverse more than one or possibly two firewalls in
         sequence.



Braden, Clark, Crocker & Huitema                               [Page 15]