idnits 2.17.1 draft-ietf-bmwg-secperf-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1319 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...he rule set. Forwarded packets MUST be...' RFC 2119 keyword, line 146: '...DUT/SUT. All other packets MUST NOT be...' RFC 2119 keyword, line 209: '... access MUST require authentication ...' RFC 2119 keyword, line 216: '...ng authenticated MAY be the client mac...' RFC 2119 keyword, line 220: '... Servers SHOULD also authenticate th...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9388 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 112 looks like a reference -- Missing reference section? '3' on line 168 looks like a reference -- Missing reference section? '4' on line 224 looks like a reference -- Missing reference section? '5' on line 279 looks like a reference -- Missing reference section? '6' on line 335 looks like a reference -- Missing reference section? '7' on line 391 looks like a reference -- Missing reference section? '8' on line 447 looks like a reference -- Missing reference section? '9' on line 503 looks like a reference -- Missing reference section? '10' on line 558 looks like a reference -- Missing reference section? '11' on line 613 looks like a reference -- Missing reference section? '12' on line 669 looks like a reference -- Missing reference section? '13' on line 724 looks like a reference -- Missing reference section? '14' on line 779 looks like a reference -- Missing reference section? '15' on line 835 looks like a reference -- Missing reference section? '16' on line 891 looks like a reference -- Missing reference section? '17' on line 946 looks like a reference -- Missing reference section? '18' on line 1001 looks like a reference -- Missing reference section? '19' on line 1057 looks like a reference -- Missing reference section? '20' on line 1112 looks like a reference -- Missing reference section? '21' on line 1167 looks like a reference -- Missing reference section? '22' on line 1191 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Newman, editor 3 INTERNET-DRAFT Data Communications 4 Expires in January 1999 July 1998 6 Benchmarking Terminology for Firewall Performance 7 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Table of Contents 29 Introduction .......................................................2 31 2. Existing definitions ............................................3 33 3. Term definitions ................................................3 35 3.1 Allowed traffic .............................................3 37 3.2 Application proxy ...........................................3 39 3.3 Authentication ..............................................4 41 3.4 Bit forwarding rate .........................................5 43 3.5 Circuit proxy ...............................................6 45 3.6 Concurrent connections ......................................6 47 3.7 Connection ..................................................7 49 3.8 Connection establishment rate ...............................8 51 3.9 Connection overhead .........................................9 53 3.10 Data source ................................................9 55 3.11 Demilitarized zone (DMZ) ..................................10 57 3.12 Firewall ..................................................10 58 3.13 Goodput ...................................................11 60 3.14 Homed .....................................................12 62 3.15 Illegal traffic ...........................................12 64 3.16 Logging ...................................................13 66 3.17 Network address translation (NAT) .........................14 68 3.18 Packet filtering ..........................................14 70 3.19 Perimeter network .........................................15 72 3.20 Policy ....................................................15 74 3.21 Protected network .........................................16 76 3.22 Proxy .....................................................17 78 3.23 Rejected traffic ..........................................17 80 3.24 Rule set ..................................................18 82 3.25 Stateful packet filtering .................................18 84 3.26 Tri-homed .................................................19 86 3.27 Unprotected network .......................................19 88 3.28 User ......................................................20 90 4. Security considerations ........................................21 92 5. References .....................................................21 94 6. Acknowledgments ................................................22 96 7. Contact information ............................................22 98 1. Introduction 100 This document defines terms used in measuring the performance of 101 firewalls. It extends the terminology already used for benchmarking 102 routers and switches and adds terminology specific to firewalls. The 103 primary metrics used in this document are bit forwarding rate and 104 connections. 106 There are several reasons why firewall performance measurements are 107 needed. First, despite the rapid rise in firewall deployment, there 108 is no standard means of performance measurement. Second, 109 implementations vary widely, making it difficult to do direct 110 performance comparisons. Finally, more and more organizations are 112 Newman Page [2] 113 deploying firewalls on internal networks operating at relatively high 114 speeds, while most firewall implementations remain optimized for use 115 over low-speed wide-area connections. As a result, users are often 116 unsure whether the products they buy will stand up to relatively 117 heavy loads. 119 2. Existing definitions 121 This document uses the conceptual framework established in RFCs 1242 122 and 1944 (for routers) and RFC 2285 (for switches). The router and 123 switch documents contain discussions of several terms relevant to 124 benchmarking the performance of firewalls. Readers should consult the 125 router and switch documents before making use of this document. 127 This document uses the definition format described in RFC 1242, 128 Section 2. The sections in each definition are: definition, 129 discussion, measurement units (optional), issues (optional), and 130 cross-references. 132 3. Term definitions 134 3.1 Allowed traffic 136 Definition: 138 Packets forwarded as a result of the rule set of the device under 139 test/system under test (DUT/SUT). 141 Discussion: 143 Firewalls typically are configured to forward only those packets 144 explicitly permitted in the rule set. Forwarded packets MUST be 145 included in calculating the bit forwarding rate or maximum bit 146 forwarding rate of the DUT/SUT. All other packets MUST NOT be 147 included in bit forwarding rate calculations. 149 Measurement units: 151 not applicable 153 Issues: 155 See also: 157 policy rule set 159 3.2 Application proxy 161 Definition: 163 A type of proxy service that is application aware. As such these 164 proxies can ensure that only specific types of application 165 commands and data pass through; authenticate the user creating the 166 connection; dynamically open and close auxiliary ports sometimes 168 Newman Page [3] 169 required by applications. 171 Discussion: 173 Application proxies are aware of the type of data and application 174 commands that are expected to be associated with a given TCP or 175 UDP port and ensures that only such traffic is passed through 176 those ports. For example, TCP port 21 should only allow FTP 177 commands and responses through and not allow a non-FTP protocol to 178 be used for potentially malicious means. An application proxy also 179 can determine which dynamically allocated ports are required to 180 allow the service to work properly. In the case of FTP, it 181 requires that port 20 (ftp-data) be open for a period of time and 182 then closed after the transfer is complete. 184 Measurement units: 186 not applicable 188 Issues: 190 circuit proxy 191 rule sets 193 See also: 195 allowed traffic 196 circuit proxy 197 proxy rejected 198 traffic rule set 200 3.3 Authentication 202 Definition: 204 The process of verifying that a user requesting a network resource 205 is who he, she, or it claims to be, and vice versa. 207 Discussion: Trust is a critical concept in network security. Any 208 network resource (such as a file server or printer) with restricted 209 access MUST require authentication before granting access. 211 Authentication takes many forms, including but not limited to IP 212 addresses; TCP or UDP port numbers; passwords; external token 213 authentication cards; and biometric identification such as signature, 214 speech, or retina recognition systems. 216 The entity being authenticated MAY be the client machine (for 217 example, by proving that a given IP source address really is that 218 address, and not a rogue machine spoofing that address) or a user (by 219 proving that the user really is who he, she, or it claims to be). 220 Servers SHOULD also authenticate themselves to clients. 222 Testers should be aware that in an increasingly mobile society, 224 Newman Page [4] 225 authentication based on machine-specific criteria such as an IP 226 address or port number is not equivalent to verifying that a given 227 individual is making an access request. At this writing systems that 228 verify the identity of users are typically external to the firewall, 229 and may introduce additional latency to the overall SUT. 231 Measurement units: 233 not applicable 235 Issues: 237 See also: 239 user 241 3.4 Bit forwarding rate 243 Definition: 245 The number of bits per second of allowed traffic a DUT/SUT can be 246 observed to transmit to the correct destination interface(s) in 247 response to a specified offered load. 249 Discussion: 251 This definition differs substantially from section 3.17 of RFC 252 1242 and section 3.6.1 of RFC 2285. 254 Unlike both RFCs 1242 and 2285, this definition introduces the 255 notion of different classes of traffic: allowed, illegal, and 256 rejected (see definitions for each term). Any bit forwarding rate 257 measurement MUST include only allowed traffic. 259 Unlike RFC 1242, there is no reference to lost or retransmitted 260 data. Forwarding rate is assumed to be a goodput measurement, in 261 that only data successfully forwarded to the destination interface 262 is measured. Bit forwarding rate MUST be measured in relation to 263 the offered load. Bit forwarding rate MAY be measured with 264 differed load levels, traffic orientation, and traffic 265 distribution. 267 Unlike RFC 2285, this measurement counts bits per second rather 268 than frames per second. Per-frame metrics are not meaningful in 269 the context of a flow of application data between endpoints. 271 Units of measurement: 273 bits per second 275 Issues: 277 Allowed traffic vs. rejected traffic 279 Newman Page [5] 280 See also: 282 allowed traffic 283 goodput 284 illegal traffic 285 rejected traffic 287 3.5 Circuit proxy 289 Definition: 291 A type of proxy service that copies bytes between authorized 292 source and destinations for defined TCP ports. The data is copied 293 without any intelligent processing and the proxy cannot 294 dynamically open and close application specific auxiliary ports 295 that are sometimes required. 297 Discussion: 299 The key distinction with circuit proxies is that they are static 300 and thus will always set up a connection if the DUT/SUT's rule set 301 allows it. For example, if a firewall's rule set permits ftp 302 connections, a circuit proxy will forward traffic on TCP port 20 303 (ftp default data) even if no control connection was first 304 established on TCP port 21 (ftp control). 306 Measurement units: 308 not applicable 310 Issues: 312 application proxy 313 rule sets 315 See also: 317 allowed traffic 318 application proxy 319 proxy 320 rejected traffic 321 rule set 323 3.6 Concurrent connections 325 Definition: 327 The aggregate number of simultaneous connections between hosts 328 across the DUT/SUT, or between hosts and the DUT/SUT. 330 Discussion: 332 The number of concurrent connections a firewall can support is 333 just as important a metric for some users as maximum bit 335 Newman Page [6] 336 forwarding rate. 338 While "connection" describes only a state and not necessarily the 339 transfer of data, concurrency assumes that all existing 340 connections are in fact capable of transferring data. If a data 341 cannot be sent over a connection, that connection should not be 342 counted toward the number of concurrent connections. 344 Measurement units: 346 Concurrent connections 347 Maximum number of concurrent connections 349 Issues: 351 See also: 353 connections 354 connection establishment rate 355 connection overhead 357 3.7 Connection 359 Definition: 361 A state in which two hosts, or a host and the DUT/SUT, agree to 362 exchange data using a known protocol. 364 Discussion: 366 A connection is an abstraction describing an agreement between two 367 nodes: One agrees to send data and the other agrees to receive it. 369 Connections may be TCP sessions, but they don't have to be. Other 370 connection-oriented protocols such as ATM also may be used, either 371 instead of or in addition to TCP connections. 373 What constitutes a connection depends on the application. For a 374 "native ATM" application like a video stream, connections and 375 virtual circuits can be synonymous. For TCP/IP applications on ATM 376 networks (where multiple TCP sessions may ride over a single ATM 377 virtual circuit), the number of TCP connections is probably the 378 most important consideration. 380 Additionally, in some cases firewalls may handle a mixture of 381 native TCP and native ATM connections. In this situation, the 382 wrappers around user data will differ. The most meaningful metric 383 describes what an end-user will see. 385 Data connections describe state, not data transfer. The existence 386 of a connection does not imply that data travels on that 387 connection at any given time, although if data cannot be forwarded 388 on a previously established connection that connection should not 389 be considered in any aggregrate connection count (see concurrent 391 Newman Page [7] 392 connections). 394 A firewall's architecture dictates where a connection is 395 terminated. In the case of proxy-based systems, a connection 396 terminates at the DUT/SUT. But firewalls using packet filtering or 397 stateful packet filtering designs act only as passthrough devices, 398 in that they reside between two connection endpoints. Regardless 399 of firewall architecture, the number of data connections is still 400 relevant, since all firewalls perform some form of connection 401 maintenance; at the very least, all check connection requests 402 against their rule sets. 404 Though it seems paradoxical, connectionless protocols such as UDP 405 may also involve connections, at least for the purposes of 406 firewall performance measurement. For example, one host may send 407 UDP packets to another across a firewall. If the destination host 408 is listening on the correct UDP port, it receives the UDP packets. 409 For the purposes of firewall performance measurement, this is 410 considered a connection. Indeed, some firewall implementations 411 dynamically alter their rule sets to allow such connections. 413 Measurement units: 415 Connection establishment rate 416 Concurrent connections 417 Maximum number of concurrent connections 419 Issues: 421 proxy-based vs. stateful packet filtering 422 TCP/IP vs. ATM 423 connection-oriented vs. connectionless 425 See also: 427 data source 428 concurrent connections 429 connection establishment rate 431 3.8 Connection establishment rate 433 Definition: 435 The length of time needed for two hosts, or a host and the 436 DUT/SUT, to agree to set up a data exchange using a known 437 protocol. 439 Discussion: 441 Each connection-oriented protocol has its own defined mechanisms 442 for setting up a connection. For purposes of benchmarking firewall 443 performance, this shall be the interval between receipt of the 444 first octet of the packet carrying a connection establishment 445 request on a DUT/SUT interface until transmission of the last 447 Newman Page [8] 448 octet of the last packet of the connection setup traffic headed in 449 the opposite direction. 451 This definition applies only to connection-oriented protocols such 452 as TCP. For connectionless protocols such as UDP, the notion of 453 connection setup time is not meaningful. 455 Measurement units: 457 Connection establishment rate 459 Issues: 461 See also: 463 concurrent connections 464 connection connection overhead 466 3.9 Connection overhead 468 Definition: 470 The degradation in bit forwarding rate, if any, observed as a 471 result of the addition of one connection between two hosts through 472 the DUT/SUT, or the addition of one connection from a host to the 473 DUT/SUT. 475 Discussion: 477 The memory cost of connection establishment and maintenance is 478 highly implementation-specific. This metric is intended to 479 describe that cost in a method visible outside the firewall. 481 It may also be desirable to invert this metric to show the 482 performance improvement as a result of tearing down one 483 connection. 485 Measurement units: 487 bit forwarding rate 489 Issues: 491 3.10 Data source 493 Definition: 495 A station capable of generating traffic to the DUT/SUT. 497 Discussion: 499 One data source MAY emulate multiple users or stations. In 500 addition, one data source MAY offer traffic to multiple network 501 interfaces on the DUT/SUT. 503 Newman Page [9] 504 Measurement units: 506 not applicable 508 Issues: 510 The term "data source" is deliberately independent of any number 511 of users. It is useful to think of data sources simply as traffic 512 generators, without any correlation to any given number of users. 514 See also: 516 connection 518 3.11 Demilitarized zone (DMZ) 520 Definition: 522 A network segment or segments located between protected and 523 unprotected networks. DMZ networks are sometimes called perimeter 524 networks. 526 Discussion: 528 As an extra security measure, networks are often designed such 529 that protected and unprotected segments are never directly 530 connected. Instead, firewalls (and possibly public resources such 531 as WWW or FTP servers) often reside on the so-called DMZ network. 532 To connect protected, DMZ, and unprotected networks with one 533 device, the device MUST have at least three network interfaces. 535 Multiple firewalls MAY bound the DMZ. In this case, the firewalls 536 connecting the protected network with the DMZ and the DMZ with the 537 unprotected network MUST each have at least two network 538 interfaces. 540 Measurement units: 542 not applicable 544 Issues: 546 Homed 548 See also: 550 unprotected network 551 perimeter network 552 protected network 554 3.12 Firewall 556 Definition: 558 Newman Page [10] 559 A device or group of devices that enforces an access control 560 policy between networks. 562 Discussion: 564 While there are many different ways to accomplish it, all 565 firewalls do essentially the same thing: control access between 566 networks. 568 The most common configuration involves a firewall connecting two 569 segments (one protected and one unprotected), but this is not the 570 only possible configuration. Many firewalls support tri-homing, 571 allowing use of a DMZ network. It is possible for a firewall to 572 accommodate more than three interfaces, each attached to a 573 different network segment. 575 The criteria by which access is controlled is deliberately not 576 specified here. Typically this has been done using network- or 577 transport-layer criteria (such as IP subnet or TCP port number), 578 but there is no reason this must always be so. A growing number of 579 firewalls are controlling access at the application layer, using 580 user identification as the criterion. And firewalls for ATM 581 networks may control access based on data link-layer criteria. 583 Measurement units: 585 not applicable 587 Issues: 589 See also: 591 DMZ 592 tri-homed 593 user 595 3.13 Goodput 597 Definition: 599 The number of bits per unit of time forwarded to the correct 600 destination interface of the DUT/SUT, minus any bits lost or 601 retransmitted. 603 Discussion: 605 Firewalls are generally insensitive to packet loss in the network. 606 As such, measurements of gross bit forwarding rates are not 607 meaningful since (in the case of proxy-based and stateful packet 608 filtering firewalls) a receiving endpoint directly attached to a 609 DUT/SUT would not receive any data dropped by the DUT/SUT. 611 The type of traffic lost or retransmitted is protocol-dependent. 613 Newman Page [11] 614 TCP and ATM, for example, request different types of 615 retransmissions. Testers MUST observe retransmitted data for the 616 protocol in use, and subtract this quantity from measurements of 617 gross bit forwarding rate. 619 Measurement unit: 621 bits per second 623 Issues: 625 allowed vs. rejected traffic 627 See also: 629 allowed traffic 630 bit forwarding rate 631 rejected traffic 633 3.14 Homed 635 Definition: 637 The number of logical interfaces a DUT/SUT contains. 639 Discussion: 641 Firewalls MUST contain at least two logical interfaces. In network 642 topologies where a DMZ is used, the firewall contains at least 643 three interfaces and is said to be tri-homed. Additional 644 interfaces would make a firewall quad-homed, quint-homed, and so 645 on. 647 It is theoretically possible for a firewall to contain one 648 physical interface and multiple logical interfaces. This 649 configuration is strongly discouraged for testing purposes because 650 of the difficulty in verifying that no leakage occurs between 651 protected and unprotected segments. 653 Measurement units: 655 not applicable 657 Issues: 659 See also: 661 tri-homed 663 3.15 Illegal traffic 665 Definition: 667 Packets specified for rejection in the rule set of the DUT/SUT. 669 Newman Page [12] 670 Discussion: 672 A buggy or misconfigured firewall may forward packets even though 673 its rule set specifies that these packets be dropped. Illegal 674 traffic differs from rejected traffic in that it describes all 675 traffic specified for rejection by the rule set, while rejected 676 traffic specifies only those packets actually dropped by the 677 DUT/SUT. 679 Measurement units: 681 not applicable 683 Issues: 685 See also: 687 accepted traffic 688 policy 689 rejected traffic 690 rule set 692 3.16 Logging 694 Definition: 696 The recording of user requests made to the firewall. 698 Discussion: 700 Firewalls MUST log all requests they handle, both allowed and 701 rejected. For many firewall designs, logging requires a 702 significant amount of processing overhead, especially when complex 703 rule sets are in use. 705 The type and amount of data logged varies by implementation. 706 Testers SHOULD attempt to log equivalent data when comparing 707 different DUT/SUTs. 709 Logging MAY take place on systems other than the DUT/SUT. 711 Measurement units: 713 not applicable 715 Issues: 717 rule sets 719 See also: 721 allowed traffic 722 connection 724 Newman Page [13] 725 rejected traffic 727 3.17 Network address translation (NAT) 729 Definition: 731 A function that maps the original IP source and/or destination 732 addresses of packets arriving at a given interface of the firewall 733 to a different address or addresses. 735 Discussion: 737 Firewalls use NAT to ensure that the IP addresses of a protected 738 network are not visible to systems and users on the Internet or 739 some other untrusted network. This is typically required since 740 many networks use RFC 1918 reserved addresses. 742 In the interest of conserving the IPv4 address space, RFC 1918 743 proposed the use of certain private (reserved) blocks of IP 744 addresses. Connections to public networks are made by use of a 745 device that translates one or more RFC 1918 addresses to one or 746 more public addresses--a network address translator (NAT). 748 The use of private addressing also introduces a security benefit 749 in that RFC 1918 addresses are not visible to hosts on the public 750 Internet. 752 Some NAT implementations are computationally intensive, and may 753 affect bit forwarding rate. 755 There are two common methods for NAT: many to one (aggregation) 756 and one to one mapping. It should be noted that all proxy 757 firewalls always perform NAT as a function of their architecture, 758 while, by default, packet filtering firewalls do not. In general 759 all application and circuit proxy firewalls, by default, perform 760 NAT as a function of their architecture using the aggregation 761 method, while stateful packet filtering firewalls do not perform 762 NAT by default, but can be configured to do so. 764 Measurement units: 766 not applicable 768 Issues: 770 See also: 772 3.18 Packet filtering 774 Definition: 776 The process of controlling access by examining packets based on 777 packet header content. 779 Newman Page [14] 780 Discussion: 782 Packet-filtering firewalls forward or deny packets based on 783 information in each packet's header, such as IP address or TCP 784 port number. A packet- filtering firewall uses a rule set to 785 determine which traffic should be forwarded and which should be 786 blocked. 788 Measurement units: 790 not applicable 792 Issues: 794 static vs. stateful packet filtering 796 See also: 798 application proxy 799 circuit proxy 800 proxy 801 rule set 802 stateful packet filtering 804 3.19 Perimeter network 806 Definition: 808 A network segment or segments located between protected and 809 unprotected networks. Perimeter networks are often called DMZ 810 networks. 812 Discussion: 814 See the definition of DMZ for a discussion. 816 Measurement units: 818 not applicable 820 Issues: 822 Tri-homed 824 See also: 825 demilitarized zone (DMZ) 826 unprotected network 827 protected network 829 3.20 Policy 831 Definition: 833 A document defining acceptable access to protected, DMZ, and 835 Newman Page [15] 836 unprotected networks. 838 Discussion: 840 Security policies generally do not spell out specific 841 configurations for firewalls; rather, they set general guidelines 842 for what is and is not acceptable network access. 844 The actual mechanism for enforcing the access policies is usually 845 the rule set implemented in the DUT/SUT. 847 Measurement units: 849 not applicable 851 Issues: 853 See also: 855 rule set 857 3.21 Protected network 859 Definition: 861 A network segment or segments to which access is controlled by the 862 DUT/SUT. 864 Discussion: 866 Firewalls are intended to prevent unauthorized access either to or 867 from the protected network. Depending on the configuration 868 specified by the policy and rule set, the DUT/SUT may allow 869 stations on the protected segment to act as clients for servers on 870 either the DMZ or the unprotected network, or both. 872 Protected networks are often called "internal networks." That term 873 is not used here because firewalls increasingly are deployed 874 within an organization, where all segments are by definition 875 internal. It is also possible for a firewall to protected 876 multiple, but different protected networks from each other. 878 Measurement units: 880 not applicable 882 Issues: 884 See also: 886 demilitarized zone (DMZ) 887 unprotected network 888 policy 889 rule set 891 Newman Page [16] 892 unprotected network 894 3.22 Proxy 896 Definition: 898 A request for a connection made on behalf of a host. 900 Discussion: 902 Proxy-based firewalls do not allow direct connections between 903 hosts. Instead, two connections are established: one between the 904 client host and the DUT/SUT, and another between the DUT/SUT and 905 server host. 907 As with packet-filtering firewalls, proxy-based devices use a rule 908 set to determine which traffic should be forwarded and which 909 should be rejected. 911 There are two types of proxies: application proxies and circuit 912 proxies. 914 Measurement units: 916 not applicable 918 Issues: 920 application 922 See also: 924 application 925 proxy circuit 926 proxy 927 packet filtering 928 stateful packet filtering 930 3.23 Rejected traffic 932 Definition: 934 Packets dropped as a result of the rule set of the DUT/SUT. 936 Discussion: 938 Firewalls MUST reject any traffic not explicitly permitted in the 939 rule set. Dropped packets MUST NOT be included in calculating the 940 bit forwarding rate or maximum bit forwarding rate of the DUT/SUT. 942 Measurement units: 944 not applicable 946 Newman Page [17] 947 Issues: 949 See also: 951 policy 952 rule set 954 3.24 Rule set 956 Definition: 958 The collection of access control rules that determines which 959 packets the DUT/SUT will forward and which it will reject. 961 Discussion: 963 Rule sets control access to and from the network interfaces of the 964 DUT/SUT. By definition, rule sets MUST NOT apply equally to all 965 network interfaces; otherwise there would be no need for the 966 firewall. Therefore, a specific rule set MUST be applied to each 967 network interface in the DUT/SUT. 969 The order of rules within the rule set is critical. Firewalls 970 generally scan rule sets in a "top down" fashion, which is to say 971 that the device compares each packet received with each rule in 972 the rule set until it finds a rule that applies to the packet. 973 Once the device finds an applicable rule, it applies the actions 974 defined in that rule (such as forwarding or rejecting the packet) 975 and ignores all subsequent rules. For testing purposes, the rule 976 set MUST conclude with a rule denying all access. 978 Measurement units: 980 not applicable 982 Issues: 984 See also: 986 demilitarized zone (DMZ) 987 policy 988 protected network 989 rejected traffic 990 unprotected network 992 3.25 Stateful packet filtering 994 Definition: 996 The process of forwarding or rejecting traffic based on the 997 contents of a state table maintained by a firewall. 999 Discussion: 1001 Newman Page [18] 1002 Stateful packet filtering ensures that packets associated with an 1003 already established (and authorized) connection are allowed to be 1004 forwarded through the firewall. This differs from a simple packet 1005 filter firewall that would allow any packets through regardless of 1006 the state of that connection. For example, a stateful packet 1007 filtering device will reject a packet on port 20 (ftp-data) if no 1008 session has been established over the ftp control port (usually 1009 port 21). 1011 Measurement units: 1013 not applicable 1015 Issues: 1017 See also: 1019 application proxy 1020 circuit proxy 1021 packet filter 1022 proxy 1024 3.26 Tri-homed 1026 Definition: 1028 A firewall with three network interfaces. 1030 Discussion: 1032 Tri-homed firewalls connect three network segments with different 1033 network addresses. Typically, these would be protected, DMZ, and 1034 unprotected segments. 1036 A tri-homed firewall may offer some security advantages over 1037 firewalls with two interfaces. An attacker on an unprotected 1038 network may compromise hosts on the DMZ but still not reach any 1039 hosts on the protected network. 1041 Measurement units: 1043 not applicable 1045 Issues: 1047 Usually the differentiator between one segment and another is its 1048 IP address. However, firewalls may connect different networks of 1049 other types, such as ATM or Netware segments. 1051 See also: 1053 homed 1055 3.27 Unprotected network 1057 Newman Page [19] 1058 Definition: 1060 A network segment or segments to which access is not controlled by 1061 the DUT/SUT. 1063 Discussion: 1065 Firewalls are deployed between protected and unprotected segments. 1066 The unprotected network is not protected by the DUT/SUT. 1068 Note that a DUT/SUT's policy MAY specify hosts on an unprotected 1069 network. For example, a user on a protected network may be 1070 permitted to access an FTP server on an unprotected network. But 1071 the DUT/SUT cannot control access between hosts on the unprotected 1072 network. 1074 Measurement units: 1076 not applicable 1078 Issues: 1080 See also: 1082 demilitarized zone (DMZ) 1083 policy 1084 protected network 1085 rule set 1087 3.28 User 1089 Definition: 1091 A person or process requesting access to resources protected by 1092 the DUT/SUT. 1094 Discussion: 1096 "User" is a problematic term in the context of firewall 1097 performance testing, for several reasons. First, a user may in 1098 fact be a process or processes requesting services through the 1099 DUT/SUT. Second, different "user" requests may require radically 1100 different amounts of DUT/SUT resources. Third, traffic profiles 1101 vary widely from one organization to another, making it difficult 1102 to characterize the load offered by a typical user. 1104 For these reasons, it's probably not a good idea to measure 1105 DUT/SUT performance in terms of users supported. The only 1106 exception is in cases where traffic patterns are well understood 1107 and constant--conditions that unfortunately don't exist in many 1108 networks. Instead, it's preferable to describe performance in 1109 terms of maximum bit forwarding rate and maximum number of 1110 connections sustained. It's also preferable to use the term "data 1112 Newman Page [20] 1113 source" rather than "user" to describe the traffic generator(s) to 1114 avoid any confusion with actual user data profiles. 1116 Measurement units: 1118 not applicable 1120 Issues: 1122 See also: 1124 data source 1126 4. Security considerations 1128 The primary goal of this memo is to describe terms used in 1129 benchmarking firewall performance. However, readers should be aware 1130 that there is some overlap between performance and security issues. 1131 Specifically, the optimal configuration for firewall performance may 1132 not be the most secure, and vice-versa. 1134 Further, certain forms of attack may degrade performance. One common 1135 form of denial-of-service (DoS) attack bombards a firewall with so 1136 much rejected traffic that it cannot forward allowed traffic. DoS 1137 attacks do not always involve heavy loads; DoS describes any state in 1138 which a firewall is offered rejected traffic that prohibits it from 1139 forwarding some or all allowed traffic. Even a small amount of 1140 traffic-- such as the recent Teardrop2 attack involving a few packet 1141 fragments-- may significantly degrade firewall performance, or stop 1142 the firewall altogether. Further, the safeguards in firewalls to 1143 guard against such attacks may have a significant negative impact on 1144 performance. 1146 Since the library of attacks is constantly expanding, no attempt is 1147 made here to define specific attacks that may affect performance. 1148 Nonetheless, any reasonable performance benchmark must take 1149 safeguards against such attacks into consideration. Specifically, the 1150 same safeguards must be in place when comparing performance of 1151 different firewall implementations. 1153 5. References 1155 Bradner, S., editor. "Benchmarking Terminology for Network 1156 Interconnection Devices." RFC 1242. 1158 Bradner, S., and McQuaid, J. "Benchmarking Methodology for Network 1159 Interconnect Devices." RFC 1944. 1161 Mandeville, R. "Benchmarking Terminology for LAN Switching Devices." 1162 RFC 2285. 1164 Rekhter, Y., et al. "Address Allocation for Private Internets." RFC 1165 1918. 1167 Newman Page [21] 1168 6. Acknowledgments 1170 The editor wishes to thank the IETF Benchmarking Working Group for 1171 agreeing to review this document. Many persons offered valuable 1172 contributions and critiques during this project: Ted Doty (Internet 1173 Security Systems), Kevin Dubray (Bay Networks), Helen Holzbaur 1174 (NSTL), Jim Hurd (NSTL), Dale Lancaster (Axent Technologies), Robert 1175 Mandeville (European Network Laboratories), Brent Melson (NSTL), 1176 Steve Platt (NSTL), Marcus Ranum (Network Flight Recorder Inc.), Greg 1177 Shannon (Ascend Communications), Christoph Schuba (Sun Microsystems), 1178 Rick Siebenaler (Cyberguard), and Greg Smith (Check Point Software 1179 Technologies). 1181 7. Contact information 1183 David Newman 1184 Data Communications magazine 1185 1221 Avenue of the Americas, 41st floor 1186 New York, NY 10020 USA 1187 212-512-6182 voice 1188 212-512-6833 fax 1189 dnewman@data.com 1191 Newman Page [22]