rfc1636.txt

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

RFC 1636                  IAB Workshop Report                  June 1994


         A firewall router may require re-authentication because:

         *    it has been added to the path by a routing change, or

         *    it has timed out the profile entry, or

         *    it has been newly re-activated, perhaps after a crash that
              lost its list of acceptable profiles.

         If C contacts authentication and authorization servers that S
         trusts, C may utilize tickets given it by these servers when
         initiating its use of S, and avoid re-authenticating itself to
         S.

         Although the authentication server A1 and the authorization
         server Z1 are conceptually separate, they may run on the same
         computer or router or even be separate aspects of a single
         program.  The protocol that C speaks to an An, the protocol
         that C speaks to a Zn, and the protocol that Zn speaks to Fn
         are not specified in these notes.  The authentication mechanism
         used with An and the packet profile required by a firewall Fn
         are considered matters of policy.

      3.3.2  Source Authentication

         We next consider how to protect against spoofing the IP source
         address, i.e., injecting packets that are alleged from come
         from C but do not.  There are three classes of mechanisms to
         prevent such spoofing of IP-level firewalls.  The mechanisms
         outlined here are also discussed in Section 4.3 below.

         o    Packet Profile Only

              The lowest level of security consists of allowing the IP-
              layer firewall to filter packets purely on the basis of
              the packet profile.  This is essentially the approach used
              by filtering routers today, with the addition of (1)
              authentication and authorization servers to control the
              filtering profiles, and (2) the automatic "Authentication
              Required" notification mechanism.  This approach provides
              almost no security; it does not prevent other computers
              from spoofing packets that appear to be transmitted by C,
              or from taking over C's transport level connection to S.

         o    Sealed Packets

              In the second level of security, each packet is "sealed"
              with a secure hash algorithm.  An authentication server Ai



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


              chooses a secret and shares it with the source host S and
              also with the authorization server Zi, which shares the
              secret with the firewall Fi.  Every packet that C
              transmits contains a hash value that depends upon both the
              contents of the packet and the secret value.  The firewall
              Fi can compute the same hash function and verify that the
              packet was originated by a computer that knew the shared
              secret.

              This approach does raise issues of how much C trusts Zi
              and Fi.  Since they know C's secret, Zi or Fi could spoof
              C.  If C does not trust all Z's and F's in its path, a
              stronger mechanism (see below) is needed.

              A more difficult problem arises in authenticating C's
              packets when more than one firewall lies in the path.
              Carrying a separate seal for each firewall that is
              penetrated would be costly in terms of packet size.  On
              the other hand, in order to use a single seal, all the
              firewalls would have to cooperate, and this might require
              a much more complex mechanism than the one sketched in the
              previous section.  Morever, it may require mutual trust
              among all of the authentication servers Ai and
              authorization servers Zi; any of these servers could
              undermine all the others.  Another possibility to be
              investigated is to use hop-by-hop rather than end-to-end
              authentication of C's packets.  That is, each firewall
              would substitute into the packet the hash needed by the
              next firewall.

              Multi-firewall source authentication is a difficult
              problem that needs more investigation.

         o    Packet Signatures

              In the third level of security, each packet is "signed"
              using a public/private key algorithm.  C shares its public
              key with Zn, which shares it with Fn.  In this scenario, C
              can safely use one pair of keys for all authorization
              servers and firewalls.  No authorization server or
              firewall can spoof C because they cannot sign packets
              correctly.

              Although packet signing gives a much higher level of
              security, it requires public key algorithms that are
              patented and currently very expensive to compute; their
              time must be added to that for the hash algorithm.  Also,
              signing the hash generally makes it larger.



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


      3.3.3 Other Firewall Issues

         o    Performance

              An Internet-layer firewall has the advantage of generality
              and flexibility.  However, filtering introduces a
              potential performance problem.  Performance may depend
              upon the number and position of the packet fields used for
              filtering, and upon the number of rules against which a
              packet has to be matched.

              Denial of service attacks require that the per-packet rule
              matching and the drop path be able to keep up with the
              interface speed.

         o    Multicasting

              To allow multicast traffic to penetrate a firewall, the
              rule that is needed should be supplied by the receiver
              rather than the sender.  However, this will not work with
              the challenge mechanism outlined in Section 3.3.1, since
              "Authentication Required" notifications would be sent to
              the sender, not to the receiver(s).

              Multicast conversations may use any of the three levels of
              security described in the previous section, but all
              firewalls will have to share the same secret with the
              originator of the data stream.  That secret would have to
              be provided to the receivers through other channels and
              then passed to the firewalls at the receivers' initiative
              (in much the same way that resources are reserved at
              receiver's initiative in RSVP).

         o    Asymmetric Routing

              Given a client computer C utilizing a service from another
              computer C through a firewall F: if the packets returning
              from S to C take a different route than packets from C to
              S, they may encounter another firewall F' which has not
              been authorized to pass packets from S to C (unlike F,
              which has been).  F' will challenge S rather than C, but S
              may not have credentials to authenticate itself with a
              server trusted by F'.

              Fortunately, this asymmetric routing situation is not a
              problem for the common case of single homed administrative
              domains, where any asymmetric routes converge at the
              firewall.



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


         o    Illicit Rendezvous

              None of these mechanisms prevent two users on opposite
              sides of a firewall from rendezvousing with a custom
              application written over a protocol that may have been
              authorized to run through a firewall.

              For example, if an organization has a policy that certain
              information is sensitive and must not be allowed outside
              its premises, a firewall will not be enough to enforce
              this policy if users are able to attach sensitive
              information to mail and send it outside to arbitrary
              parties.  Similarly, a firewall will not prevent all
              problems with incoming data.  If users import programs and
              execute them, the programs may have Trojan horses which
              disclose sensitive information or modify or delete
              important data.  Executable code comes in many, many
              forms, including PostScript files, scripts for various
              interpreters, and even return addresses for sendmail.  A
              firewall can detect some of these and scan for some forms
              of potentially hazardous code, but it cannot stop users
              from transforming things that look like "data" into
              programs.

              We consider these problems to be somewhat outside the
              scope of the firewall router mechanism.  It is a matter of
              the policies implemented by the organization owning the
              firewalls to address these issues.

         o    Transparency for Security Packets

              For the mechanisms described above to operate, the
              "Authentication Required" notification and the
              authentication/authorization protocol that is used between
              the client computer and the authentication and
              authorization servers trusted by a firewall, must be
              passed by all firewalls automatically.  This might be on
              the basis of the packet profiles involved in security.
              Alternatively, firewall routers might serve as
              application-layer firewalls for these types of
              communications.  They could then validate the data they
              pass to avoid spoofing or illicit rendezvous.

      3.3.4 Firewall-Friendly Applications

         Firewall routers have problems with certain communication
         patterns where requests are initiated by the server, including
         callbacks and multiple connections (e.g., FTP).  It was



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


         suggested that it would be useful to have guidelines to
         application designers to help them to build 'firewall-friendly
         applications'.  The following guidelines were suggested:

         1)   no inbound calls (the xterm problem),

         2)   fixed port numbers (no portmapper or tcpmux),

         3)   integral redirection is good (application gateways),

         4)   no redirection in the protocol,

         5)   32 bit sequence numbers that are crypto-strong random #'s,
              and

         6)   fixed length and number of header fields.

         Type fields are good, but they may not be needed if there are
         fixed port numbers.

      3.3.5  Conclusions

         Compared to an application-layer firewall, an IP-layer firewall
         scheme could provide a number of benefits:

         -    No extra authentication is required for end hosts.

         -    A single authentication protocol can be used for all
              intended applications.

         -    An IP-layer firewall causes less performance degradation.

         -    An IP-layer firewall may be able to crash and recover
              state without disturbing open TCP connections.

         -    Routes can shift without disturbing open TCP connections.

         -    There is no single point of failure.

         -    It is independent of application.

         However, there are substantial difficult design issues to be
         solved, particularly in the areas of multiple firewalls,
         assymmetric routes, multicasting, and performance.







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