rfc2647.txt

RFC 的详细文档！

     access except for those packets allowed by the rule set.

   Unit of measurement:
     not applicable

   Issues:

   See also:
     allowed traffic
     demilitarized zone (DMZ)
     illegal traffic
     policy
     protected network
     rejected traffic
     unprotected network

3.28 Security association

   Definition:
     The set of security information relating to a given network
     connection or set of connections.





Newman                       Informational                     [Page 20]

RFC 2647            Firewall Performance Terminology         August 1999


   Discussion:
     This definition covers the relationship between policy and
     connections. Security associations (SAs) are typically set up
     during connection establishment, and they may be reiterated or
     revoked during a connection.

     For purposes of benchmarking firewall performance, measurements of
     bit forwarding rate or UOTs per second must be taken after all
     security associations have been established.

   Unit of measurement:
     not applicable

   See also:
     connection
     connection establishment
     policy
     rule set

3.29 Stateful packet filtering

   Definition:
     The process of forwarding or rejecting traffic based on the
     contents of a state table maintained by a firewall.

   Discussion:
     Packet filtering and proxy firewalls are essentially static, in
     that they always forward or reject packets based on the contents of
     the rule set.

     In contrast, devices using stateful packet filtering will only
     forward packets if they correspond with state information
     maintained by the device about each connection. For example, a
     stateful packet filtering device will reject a packet on port 20
     (ftp-data) if no connection has been established over the ftp
     control port (usually port 21).

   Unit of measurement:
     not applicable

   Issues:

   See also:
     applicaton proxy
     packet filtering
     proxy





Newman                       Informational                     [Page 21]

RFC 2647            Firewall Performance Terminology         August 1999


3.30 Tri-homed

   Definition:
     A firewall with three network interfaces.

   Discussion:
     Tri-homed firewalls connect three network segments with different
     network addresses. Typically, these would be protected, DMZ, and
     unprotected segments.

     A tri-homed firewall may offer some security advantages over
     firewalls with two interfaces. An attacker on an unprotected
     network may compromise hosts on the DMZ but still not reach any
     hosts on the protected network.

   Unit of measurement:
     not applicable

   Issues:
     Usually the differentiator between one segment and another is its
     IP address. However, firewalls may connect different networks of
     other types, such as ATM or Netware segments.

   See also:
     homed

3.31 Unit of transfer

   Definition:
     A discrete collection of bytes comprising at least one header and
     optional user data.

   Discussion:
     This metric is intended for use in describing steady-state
     forwarding rate of the DUT/SUT.

     The unit of transfer (UOT) definition is deliberately left open to
     interpretation, allowing the broadest possible application.
     Examples of UOTs include TCP segments, IP packets, Ethernet frames,
     and ATM cells.

     While the definition is deliberately broad, its interpretation must
     not be. The tester must describe what type of UOT will be offered
     to the DUT/SUT, and must offer these UOTs at a consistent rate.
     Traffic measurement must begin after all connection establishment
     routines complete and before any connection completion routine
     begins.  Further, measurements must begin after any security
     associations (SAs) are established and before any SA is revoked.



Newman                       Informational                     [Page 22]

RFC 2647            Firewall Performance Terminology         August 1999


     Testers also must compare only like UOTs. It is not appropriate,
     for example, to compare forwarding rates by offering 1,500-byte
     Ethernet UOTs to one DUT/SUT and 53-byte ATM cells to another.

   Unit of measurement:
     Units of transfer
     Units of transfer per second

   Issues:

   See also:
     bit forwarding rate
     connection

3.32 Unprotected network

   Definition:
     A network segment or segments to which access is not controlled by
     the DUT/SUT.

   Discussion:
     Firewalls are deployed between protected and unprotected segments.
     The unprotected network is not protected by the DUT/SUT.

     Note that a DUT/SUT's policy may specify hosts on an unprotected
     network. For example, a user on a protected network may be
     permitted to access an FTP server on an unprotected network. But
     the DUT/SUT cannot control access between hosts on the unprotected
     network.

   Unit of measurement:
     not applicable

   Issues:

   See also:
     demilitarized zone (DMZ)
     policy
     protected network
     rule set

3.33 User

   Definition:
     A person or process requesting access to resources protected by the
     DUT/SUT.





Newman                       Informational                     [Page 23]

RFC 2647            Firewall Performance Terminology         August 1999


   Discussion:
     "User" is a problematic term in the context of firewall performance
     testing, for several reasons. First, a user may in fact be a
     process or processes requesting services through the DUT/SUT.
     Second, different "user" requests may require radically different
     amounts of DUT/SUT resources. Third, traffic profiles vary widely
     from one organization to another, making it difficult to
     characterize the load offered by a typical user.

     For these reasons, testers should not attempt to measure DUT/SUT
     performance in terms of users supported. Instead, testers should
     describe performance in terms of maximum bit forwarding rate and
     maximum number of connections sustained. Further, testers should
     use the term "data source" rather than user to describe traffic
     generator(s).

   Unit of measurement:
     not applicable

   Issues:

   See also:
     data source

4. Security Considerations

   The primary goal of this memo is to describe terms used in
   benchmarking firewall performance. However, readers should be aware
   that there is some overlap between performance and security issues.
   Specifically, the optimal configuration for firewall performance may
   not be the most secure, and vice-versa.

   Further, certain forms of attack may degrade performance. One common
   form of denial-of-service (DoS) attack bombards a firewall with so
   much rejected traffic that it cannot forward allowed traffic. DoS
   attacks do not always involve heavy loads; by definition, DoS
   describes any state in which a firewall is offered rejected traffic
   that prohibits it from forwarding some or all allowed traffic. Even a
   small amount of traffic may significantly degrade firewall
   performance, or stop the firewall altogether. Further, the safeguards
   in firewalls to guard against such attacks may have a significant
   negative impact on performance.

   Since the library of attacks is constantly expanding, no attempt is
   made here to define specific attacks that may affect performance.
   Nonetheless, any reasonable performance benchmark should take into





Newman                       Informational                     [Page 24]

RFC 2647            Firewall Performance Terminology         August 1999


   consideration safeguards against such attacks. Specifically, the same
   safeguards should be in place when comparing performance of different
   firewall implementations.

5. References

   Bradner, S., Ed., "Benchmarking Terminology for Network
           Interconnection Devices", RFC 1242, July 1991.

   Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network
           Interconnect Devices", RFC 2544, March 1999.

   Mandeville, R., "Benchmarking Terminology for LAN Switching Devices",
           RFC 2285, February 1998.

   Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear,
           "Address Allocation for Private Internets", BCP 5, RFC 1918,
           February 1996.

6. Acknowledgments

   The author wishes to thank the IETF Benchmarking Working Group for
   agreeing to review this document. Several other persons offered
   valuable contributions and critiques during this project: Ted Doty
   (Internet Security Systems), Kevin Dubray (Ironbridge Networks),
   Helen Holzbaur, Dale Lancaster, Robert Mandeville, Brent Melson
   (NSTL), Steve Platt (NSTL), Marcus Ranum (Network Flight Recorder),
   Greg Shannon, Christoph Schuba (Sun Microsystems), Rick Siebenaler,
   and Greg Smith (Check Point Software Technologies).

7. Contact Information

   David Newman
   Data Communications magazine
   3 Park Ave.
   31st Floor
   New York, NY 10016
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]









Newman                       Informational                     [Page 25]

RFC 2647            Firewall Performance Terminology         August 1999


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Newman                       Informational                     [Page 26]