idnits 2.17.1 draft-ietf-bmwg-secperf-02.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-04-25) 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 14 longer pages, the longest (page 13) being 62 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 102: '...et. Forwarded packets MUST be included...' RFC 2119 keyword, line 104: '...ll other packets MUST NOT be included ...' RFC 2119 keyword, line 125: '...r) with restricted access MUST require...' RFC 2119 keyword, line 133: '...ng authenticated MAY be the client mac...' RFC 2119 keyword, line 136: '... it claims to be). Servers SHOULD also...' (17 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 110 looks like a reference -- Missing reference section? '3' on line 166 looks like a reference -- Missing reference section? '4' on line 222 looks like a reference -- Missing reference section? '5' on line 278 looks like a reference -- Missing reference section? '6' on line 334 looks like a reference -- Missing reference section? '7' on line 390 looks like a reference -- Missing reference section? '8' on line 446 looks like a reference -- Missing reference section? '9' on line 502 looks like a reference -- Missing reference section? '10' on line 557 looks like a reference -- Missing reference section? '11' on line 612 looks like a reference -- Missing reference section? '12' on line 668 looks like a reference -- Missing reference section? '13' on line 724 looks like a reference -- Missing reference section? '14' on line 780 looks like a reference -- Missing reference section? '15' on line 835 looks like a reference -- Missing reference section? '16' on line 873 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Newman 2 INTERNET-DRAFT Data Communications 3 Expires in September 1998 H. Holzbaur, J. Hurd, and S. Platt 4 National Software Testing Laboratories 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), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 1. Introduction ....................................................2 28 2. Existing definitions ............................................3 29 3. Term definitions ................................................3 30 3.1 Allowed traffic ..............................................3 31 3.2 Authentication ...............................................3 32 3.3 Connection ...................................................4 33 3.4 Data source ..................................................5 34 3.5 Demilitarized zone (DMZ) .....................................5 35 3.6 Dynamic proxy ................................................5 36 3.7 Firewall .....................................................6 37 3.8 Forwarding rate ..............................................6 38 3.9 Goodput ......................................................7 39 3.10 Homed .......................................................7 40 3.11 Logging .....................................................8 41 3.12 Network address translation (NAT) ...........................8 42 3.13 Packet filtering ............................................9 43 3.14 Perimeter network ...........................................9 44 3.15 Policy .....................................................10 45 3.16 Protected network ..........................................10 46 3.17 Proxy ......................................................11 47 3.18 Rejected traffic ...........................................11 48 3.19 Rule set ...................................................11 49 3.20 Session ....................................................12 50 3.21 Stateful packet filtering ..................................13 51 3.22 Tri-homed ..................................................13 52 3.23 Unprotected network ........................................14 53 3.24 User .......................................................14 54 4. Security considerations ...........................................15 55 5. References ........................................................15 56 6. Acknowledgments ...................................................15 57 7. Contact information ...............................................16 59 1. Introduction 60 This document defines terms used in measuring the performance of 61 firewalls. It extends the terminology already used for benchmarking 62 routers and switches and adds terminology specific to firewalls. The 63 primary metrics defined in this document are maximum forwarding rate 64 and maximum number of connections. 66 Why are firewall performance measurements needed? First, despite the 67 rapid rise in firewall deployment, there is no standard means of 68 performance measurement. Second, implementations vary widely, making 69 it difficult to do direct performance comparisons. Finally, more and 70 more organizations are deploying firewalls on internal networks 71 operating at relatively high speeds, while most firewall 72 implementations remain optimized for use over low-speed wide-area 73 connections. As a result, users are often unsure whether the products 74 they buy will stand up to relatively heavy loads. 76 We may also create additional terminology and methodology documents 77 to define other types of network security products such as virtual 78 private network (VPN) and encryption devices. This document, however, 79 focuses solely on firewall terminology. 81 2. Existing definitions 82 This document uses the conceptual framework established in RFCs 1242 83 and 1944 (for routers) and RFC 2285 (for switches). The router and 84 switch documents contain discussions of several terms relevant to 85 benchmarking the performance of firewalls. Readers should consult the 86 router and switch documents before making use of this document. 88 This document uses the definition format described in RFC 1242, 89 Section 2. The sections in each definition are: definition, 90 discussion, measurement units (optional), issues (optional), and 91 cross-references. 93 3. Term definitions 95 3.1 Allowed traffic 97 Definition: 98 Packets forwarded as a result of the rule set of the DUT/SUT. 100 Discussion: 101 Firewalls typically are configured to forward only those packets 102 explicitly permitted in the rule set. Forwarded packets MUST be included 103 in calculating the forwarding rate or maximum forwarding rate of the 104 DUT/SUT. All other packets MUST NOT be included in forwarding rate 105 calculations. 107 Measurement units: 108 not applicable 110 Newman et al. Page [2] 111 Issues: 113 See also: 114 policy 115 rule set 117 3.2 Authentication 119 Definition: 120 The process of verifying that a user requesting a network resource is 121 who he, she, or it claims to be, and vice versa. 123 Discussion: 124 Trust is a critical concept in network security. Any network resource 125 (such as a file server or printer) with restricted access MUST require 126 authentication before granting access. 128 Authentication takes many forms, including but not limited to IP 129 addresses; TCP or UDP port numbers; passwords; external token 130 authentication cards; and biometric identification such as signature, 131 speech, or retina recognition systems. 133 The entity being authenticated MAY be the client machine (for example, 134 by proving that a given IP source address really is that address, and 135 not a rogue machine spoofing that address) or a user (by proving that 136 the user really is who he, she, or it claims to be). Servers SHOULD also 137 authenticate themselves to clients. 139 Testers should be aware that in an increasingly mobile society, 140 authentication based on machine-specific criteria such as an IP address 141 or port number is not equivalent to verifying that a given individual is 142 making an access request. At this writing systems that verify the 143 identity of users are typically external to the firewall, and may 144 introduce additional latency to the overall SUT. 146 Measurement units: 147 not applicable 149 Issues: 151 See also: 152 user 154 3.3 Connection 156 Definition: 157 A logical path established between two hosts, or between a host and the 158 DUT/SUT. 160 Discussion: 161 The number of concurrent connections a firewall can support is just as 162 important a metric for some users as maximum forwarding rate. 164 Connections MAY be TCP sessions, but they don't have to be. Users of 166 Newman et al. Page [3] 167 other connection-oriented protocols such as ATM may wish to use other 168 definitions of a connection, either instead of or in addition to TCP 169 connections. 171 What constitutes a connection depends on the application. For a "native 172 ATM" application like a video stream, connections and VCs can be 173 synonymous. For TCP/IP applications on ATM networks (where multiple TCP 174 sockets may ride over a single ATM virtual circuit), TCP sockets and 175 connections are synonymous. 177 Additionally, in some cases firewalls may handle a mixture of native TCP 178 and native ATM connections. In this situation, the wrappers around user 179 data will differ. The most meaningful metric describes what an end-user 180 will see. 182 Data connections describe state, not data transfer. The existence of a 183 connection does NOT imply that data travels on that connection at any 184 given time. 186 A firewall's architecture dictates where a connection is terminated. In 187 the case of proxy-based systems, a connection by definition terminates 188 at the DUT/SUT. But firewalls using packet filtering or stateful packet 189 filtering designs act only as passthrough devices, in that they reside 190 between two connection endpoints. Regardless of firewall architecture, 191 the number of data connections is still relevant, since all firewalls 192 perform some form of connection maintenance; at the very least, all 193 check connection requests against their rule sets. 195 Measurement units: 196 Maximum number of connections 198 Issues: 199 proxy-based vs. stateful packet filtering 200 TCP/IP vs. ATM 202 See also: 203 data source 204 session 206 3.4 Data source 208 Definition: 209 A station capable of generating traffic to the DUT/SUT. 211 Discussion: 212 One data source MAY emulate multiple users or stations. In addition, one 213 data source MAY offer traffic to multiple network interfaces on the 214 DUT/SUT. 216 Measurement units: 217 not applicable 219 Issues: 220 The term "data source" is deliberately independent of any number of 222 Newman et al. Page [4] 223 users. It is useful to think of data sources simply as traffic 224 generators, without any correlation to any given number of users. 226 See also: 227 connection 229 3.5 Demilitarized zone (DMZ) 231 Definition: 232 A network segment or segments located between protected and unprotected 233 networks. DMZ networks are sometimes called perimeter networks. 235 Discussion: 236 As an extra security measure, networks are often designed such that 237 protected and unprotected segments are never directly connected. 238 Instead, firewalls (and possibly public resources such as WWW or FTP 239 servers) often reside on the so-called DMZ network. To connect 240 protected, DMZ, and unprotected networks with one device, the device 241 MUST have at least three network interfaces. 243 Multiple firewalls MAY bound the DMZ. In this case, the firewalls 244 connecting the protected network with the DMZ and the DMZ with the 245 unprotected network MUST each have at least two network interfaces. 247 Measurement units: 248 not applicable 250 Issues: 251 Homed 253 See also: 254 unprotected network 255 perimeter network 256 protected network 258 3.6 Dynamic proxy 260 Definition: 261 A proxy service that is set up and torn down in response to a client 262 request, rather than existing on a static basis. 264 Discussion: 265 Proxy services typically "listen" on a given TCP port number for client 266 requests. With static proxies, a firewall always forwards packets 267 containing a given TCP port number if that port number is permitted by 268 the rule set. Dynamic proxies, in contrast, forward TCP packets only 269 once an authenticated connection has been established. When the 270 connection closes, a firewall using dynamic proxies rejects individual 271 packets, even if they contain port numbers allowed by a rule set. 273 Measurement units: 274 not applicable 276 Issues: 278 Newman et al. Page [5] 279 rule sets 281 See also: 282 allowed traffic 283 proxy 284 rejected traffic 285 rule set 287 3.7 Firewall 289 Definition: 290 A device or group of devices that enforces an access control policy 291 between networks. 293 Discussion: 294 While there are many different ways to accomplish it, all firewalls do 295 the same thing: control access between networks. 297 The most common configuration involves a firewall connecting two 298 segments (one protected and one unprotected), but this is not the only 299 possible configuration. Many firewalls support tri-homing, allowing use 300 of a DMZ network. It is possible for a firewall to accommodate more than 301 three interfaces, each attached to a different network segment. 303 The criteria by which access is controlled is deliberately not specified 304 here. Typically this has been done using network- or transport-layer 305 criteria (such as IP subnet or TCP port number), but there is no reason 306 this must always be so. A growing number of firewalls are controlling 307 access at the application layer, using user identification as the 308 criterion. And firewalls for ATM networks may control access based on 309 data link-layer criteria. 311 Measurement units: 312 not applicable 314 Issues: 316 See also: 317 DMZ 318 tri-homed 319 user 321 3.8 Forwarding rate 323 Definition: 324 The number of bits per second that a firewall can be observed to 325 transmit successfully to the correct destination interface in response 326 to a specified offered load. 328 Discussion: 329 This definition differs substantially from section 3.17 of RFC 1242 and 330 section 3.6.1 of RFC 2285. Unlike RFC 1242, there is no reference to 331 lost or retransmitted data. Forwarding rate is assumed to be a goodput 332 measurement, in that only data successfully forwarded to the destination 334 Newman et al. Page [6] 335 interface is measured. Forwarding rate MUST be measured in relation to 336 the offered load. Forwarding rate MAY be measured with differed load 337 levels, traffic orientation, and traffic distribution. 339 Unlike RFC 2285, this measurement counts bits per second rather than 340 frames per second. Per-frame metrics are not meaningful in the context 341 of a flow of application data between endpoints. 343 Units of measurement: 344 bits per second 346 Issues: 347 Allowed traffic vs. rejected traffic 349 See also: 350 allowed traffic 351 goodput 352 rejected traffic 354 3.9 Goodput 356 Definition: 357 The number of bits per unit of time forwarded to the correct destination 358 interface of the DUT/SUT, minus any bits lost or retransmitted. 360 Discussion: 361 Firewalls are generally insensitive to packet loss in the network. As 362 such, measurements of gross forwarding rates are not meaningful since 363 (in the case of proxy-based and stateful packet filtering firewalls) a 364 receiving endpoint directly attached to a DUT/SUT would not receive any 365 data dropped by the DUT/SUT. 367 The type of traffic lost or retransmitted is protocol-dependent. TCP and 368 ATM, for example, request different types of retransmissions. Testers 369 MUST observe retransmitted data for the protocol in use, and subtract 370 this quantity from measurements of gross forwarding rate. 372 Unit of measurement: 373 bits per second 375 Issues: 376 allowed vs. rejected traffic 378 See also: 379 allowed traffic 380 forwarding rate 381 rejected traffic 383 3.10 Homed 385 Definition: 386 The number of logical interfaces a DUT/SUT contains. 388 Discussion: 390 Newman et al. Page [7] 391 Firewalls MUST contain at least two logical interfaces. In network 392 topologies where a DMZ is used, the firewall contains at least three 393 interfaces and is said to be tri-homed. Additional interfaces would make 394 a firewall quad-homed, quint-homed, and so on. 396 It is theoretically possible for a firewall to contain one physical 397 interface and multiple logical interfaces. This configuration is 398 strongly discouraged for testing purposes because of the difficulty in 399 verifying that no leakage occurs between protected and unprotected 400 segments. 402 Measurement units: 403 not applicable 405 Issues: 407 See also: 408 tri-homed 410 3.11 Logging 412 Definition: 413 The recording of user requests made to the firewall. 415 Discussion: 416 Firewalls SHOULD log all requests they handle, both allowed and 417 rejected. For many firewall designs, logging requires a significant 418 amount of processing overhead, especially when complex rule sets are in 419 use. 421 The type and amount of data logged varies by implementation. Testers 422 SHOULD attempt to log equivalent data when comparing different DUT/SUTs. 424 Logging MAY take place on systems other than the DUT/SUT. 426 Measurement units: 427 not applicable 429 Issues: 430 rule sets 432 See also: 433 allowed traffic 434 connection 435 rejected traffic 436 session 438 3.12 Network address translation (NAT) 440 Definition: 441 A method of mapping one or more private, reserved IP addresses to one or 442 more public IP addresses. 444 Discussion: 446 Newman et al. Page [8] 447 In the interest of conserving the IPv4 address space, RFC 1918 proposed 448 the use of certain private (reserved) blocks of IP addresses. 449 Connections to public networks are made by use of a device that 450 translates one or more RFC 1918 addresses to one or more public 451 addresses--a network address translator (NAT). 453 The use of private addressing also introduces a security benefit in that 454 RFC 1918 addresses are not visible to hosts on the public Internet. 456 Some NAT implementations are computationally intensive, and may affect 457 forwarding rate. 459 Measurement units: 460 not applicable 462 Issues: 464 See also: 466 3.13 Packet filtering 468 Definition: 469 The process of controlling access by examining packets based on packet 470 header content. 472 Discussion: 473 Packet-filtering devices forward or deny packets based on information in 474 each packet's header, such as IP address or TCP port number. A packet- 475 filtering firewall uses a rule set to determine which traffic should be 476 forwarded and which should be blocked. 478 Measurement units: 479 not applicable 481 Issues: 482 static versus stateful packet filtering 484 See also: 485 dynamic proxy 486 proxy 487 rule set 488 stateful packet filtering 490 3.14 Perimeter network 492 Definition: 493 A network segment or segments located between protected and unprotected 494 networks. Perimeter networks are often called DMZ networks. 496 Discussion: 497 See the definition of DMZ for a discussion. 499 Measurement units: 500 not applicable 502 Newman et al. Page [9] 503 Issues: 504 Tri-homed 506 See also: 507 demilitarized zone (DMZ) 508 unprotected network 509 protected network 511 3.15 Policy 513 Definition: 514 A document defining acceptable access to protected, DMZ, and unprotected 515 networks. 517 Discussion: 518 Security policies generally do not spell out specific configurations for 519 firewalls; rather, they set general guidelines for what is and is not 520 acceptable network access. 522 The actual mechanism for controlling access is usually the rule set 523 implemented in the DUT/SUT. 525 Measurement units: 526 not applicable 528 Issues: 530 See also: 531 rule set 533 3.16 Protected network 535 Definition: 536 A network segment or segments to which access is controlled by the 537 DUT/SUT. 539 Discussion: 540 Firewalls are intended to prevent unauthorized access either to or from 541 the protected network. Depending on the configuration specified by the 542 policy and rule set, the DUT/SUT may allow stations on the protected 543 segment to act as clients for servers on either the DMZ or the 544 unprotected network, or both. 546 Protected networks are often called "internal networks." That term is 547 not used here because firewalls increasingly are deployed within an 548 organization, where all segments are by definition internal. 550 Measurement units: 551 not applicable 553 Issues: 555 See also: 557 Newman et al. Page [10] 558 demilitarized zone (DMZ) 559 unprotected network 560 policy 561 rule set 562 unprotected network 564 3.17 Proxy 566 Definition: 567 A request for a connection made on behalf of a host. 569 Discussion: 570 Proxy-based firewalls do not allow direct connections between hosts. 571 Instead, two connections are established: one between the client host 572 and the DUT/SUT, and another between the DUT/SUT and server host. 574 As with packet-filtering firewalls, proxy-based devices use a rule set 575 to determine which traffic should be forwarded and which should be 576 rejected. 578 Proxies are generally application-specific. 580 Measurement units: 581 not applicable 583 Issues: 584 application 586 See also: 587 dynamic proxy 588 packet filtering 589 stateful packet filtering 591 3.18 Rejected traffic 593 Definition: 594 Packets dropped as a result of the rule set of the DUT/SUT. 596 Discussion: 597 Firewalls MUST reject any traffic not explicitly permitted in the rule 598 set. Dropped packets MUST NOT be included in calculating the forwarding 599 rate or maximum forwarding rate of the DUT/SUT. 601 Measurement units: 602 not applicable 604 Issues: 606 See also: 607 policy 608 rule set 610 3.19 Rule set 612 Newman et al. Page [11] 613 Definition: 614 The collection of access control rules that determines which packets the 615 DUT/SUT will forward and which it will reject. 617 Discussion: 618 Rule sets control access to and from the network interfaces of the 619 DUT/SUT. By definition, rule sets MUST NOT apply equally to all network 620 interfaces; otherwise there would be no need for the firewall. 621 Therefore, a specific rule set MUST be applied to each network interface 622 in the DUT/SUT. 624 The order of rules within the rule set is critical. Firewalls generally 625 scan rule sets in a "top down" fashion, which is to say that the device 626 compares each packet received with each rule in the rule set until it 627 finds a rule that applies to the packet. Once the device finds an 628 applicable rule, it applies the actions defined in that rule (such as 629 forwarding or rejecting the packet) and ignores all subsequent rules. 630 For testing purposes, the rule set MUST conclude with a rule denying all 631 access. 633 Measurement units: 634 not applicable 636 Issues: 638 See also: 639 demilitarized zone (DMZ) 640 policy 641 protected network 642 rejected traffic 643 unprotected network 645 3.20 Session 647 Definition: 648 Data flowing through a previously established connection established 649 between two stations using a known protocol. 651 Discussion: 652 Because of the application-layer focus of many firewalls, sessions are a 653 more useful metric than the packet-based measurements used in 654 benchmarking routers and switches. Although firewall rule sets generally 655 work on a per-packet basis, it is ultimately sessions that a firewall 656 must handle. For example, the number of file transfer protocol (ftp) 657 sessions a DUT/SUT can handle concurrently is a more meaningful 658 measurement in benchmarking performance than the number of ftp "open" 659 packets it can reject. Further, a stateful packet filtering firewall 660 will not forward individual packets if those packets' headers conflict 661 with state information maintained by the firewall. 663 For purposes of this document, a session MUST be established using a 664 known protocol such as TCP. A traffic pattern is not considered a 665 session until it successfully completes the establishment procedures 666 defined by that protocol. 668 Newman et al. Page [12] 669 Also for purposes of this document, a session constitutes the logical 670 connection between two end-stations and not the intermediate connections 671 that proxy-based firewalls may use. 673 Issues: 674 TCP/IP vs. ATM 676 See also: 677 connection 678 policy 679 proxy 680 rule set 681 stateful packet filtering 683 3.21 Stateful packet filtering 685 Definition: 686 The process of forwarding or rejecting traffic based on the contents of 687 a state table maintained by a firewall. 689 Discussion: 690 Packet filtering and proxy firewalls are essentially static, in that 691 they always forward or reject packets based on the contents of the rule 693 set. 695 In contrast, devices using stateful packet filtering will only forward 696 packets if they correspond with state information maintained by the 697 device about each session. For example, a stateful packet filtering 698 device will reject a packet on port 20 (ftp-data) if no session has been 699 established over the ftp control port (usually port 21). 701 Measurement units: 702 not applicable 704 Issues: 706 See also: 707 dynamic proxy 708 packet filter 709 proxy 711 3.22 Tri-homed 713 Definition: 714 A firewall with three network interfaces. 716 Discussion: 717 Tri-homed firewalls connect three network segments with different 718 network addresses. Typically, these would be protected, DMZ, and 719 unprotected segments. 721 A tri-homed firewall may offer some security advantages over firewalls 722 with two interfaces. An attacker on an unprotected network may 724 Newman et al. Page [13] 725 compromise hosts on the DMZ but still not reach any hosts on the 726 protected network. 728 Measurement units: 729 not applicable 731 Issues: 732 Usually the differentiator between one segment and another is its IP 733 address. However, firewalls may connect different networks of other 734 types, such as ATM or Netware segments. 736 See also: 737 homed 739 3.23 Unprotected network 741 Definition: 742 A network segment or segments to which access is not controlled by the 743 DUT/SUT. 745 Discussion: 746 Firewalls are deployed between protected and unprotected segments. The 747 unprotected network is not protected by the DUT/SUT. 749 Note that a DUT/SUT's policy MAY specify hosts on an unprotected 750 network. For example, a user on a protected network may be permitted to 751 access an FTP server on an unprotected network. But the DUT/SUT cannot 752 control access between hosts on the unprotected network. 754 Measurement units: 755 not applicable 757 Issues: 759 See also: 760 demilitarized zone (DMZ) 761 policy 762 protected network 763 rule set 765 3.24 User 767 Definition: 768 A person or process requesting access to resources protected by the 769 DUT/SUT. 771 Discussion: 772 "User" is a problematic term in the context of firewall performance 773 testing, for several reasons. First, a user may in fact be a process or 774 processes requesting services through the DUT/SUT. Second, different 775 "user" requests may require radically different amounts of DUT/SUT 776 resources. Third, traffic profiles vary widely from one organization to 777 another, making it difficult to characterize the load offered by a 778 typical user. 780 Newman et al. Page [14] 781 For these reasons, we prefer not to measure DUT/SUT performance in terms 782 of users supported. Instead, we describe performance in terms of maximum 783 forwarding rate and maximum number of sessions sustained. Further, we 784 use the term "data source" rather than user to describe the traffic 785 generator(s). 787 Measurement units: 788 not applicable 790 Issues: 792 See also: 793 data source 795 4. Security considerations 797 The primary goal of this memo is to describe terms used in measuring 798 firewall performance. However, readers should be aware that there is 799 some overlap between performance and security issues. Readers should be 800 aware that the optimal configuration for firewall performance may not be 801 the most secure, and vice-versa. 803 Further, certain forms of attack may degrade performance. One common 804 form of denial-of-service (DoS) attack bombards a firewall with so much 805 rejected traffic that it cannot forward allowed traffic. DoS attacks do 806 not always involve heavy loads; by definition, DoS describes any state 807 in which a firewall is offered rejected traffic that prohibits it from 808 forwarding some or all allowed traffic. Even a small amount of traffic-- 809 such as the recent Teardrop2 attack involving a few packet fragments-- 810 may significantly degrade firewall performance, or stop the firewall 811 altogether. 813 5. References 815 Bradner, S., editor. "Benchmarking Terminology for Network 816 Interconnection Devices." RFC 1242. 818 Bradner, S., and McQuaid, J. "Benchmarking Methodology for Network 819 Interconnect Devices." RFC 1944. 821 Mandeville, R. "Benchmarking Terminology for LAN Switching Devices." RFC 822 2285. 824 Rekhter, Y., et al. "Address Allocation for Private Internets." RFC 825 1918. 827 6. Acknowledgments 829 The authors wish to thank the IETF Benchmarking Working Group for 830 agreeing to review this document. Several other persons offered valuable 831 contributions and critiques during this project: Ted Doty (Internet 832 Security Systems), Shlomo Kramer (Check Point Software Technologies), 833 Robert Mandeville (European Network Laboratories), Brent Melson 835 Newman et al. Page [15] 836 (National Software Testing Laboratories), Marcus Ranum (Network Flight 837 Recorder Inc.), Greg Shannon (Ascend Communications), Christoph Schuba 838 (Sun Microsystems), Rick Siebenaler (Cyberguard), and Greg Smith (Check 839 Point Software Technologies). 841 7. Contact information 843 David Newman 844 Data Communications magazine 845 1221 Avenue of the Americas, 41st Floor 846 New York, NY 10020 847 USA 848 212-512-6182 voice 849 212-512-6833 fax 850 dnewman@data.com 852 Helen Holzbaur 853 National Software Testing Laboratories Inc. 854 625 Ridge Pike 855 Conshohocken, PA 19428 856 USA 857 helen@nstl.com 859 Jim Hurd 860 National Software Testing Laboratories Inc. 861 625 Ridge Pike 862 Conshohocken, PA 19428 863 USA 864 jimh@nstl.com 866 Steven Platt 867 National Software Testing Laboratories Inc. 868 625 Ridge Pike 869 Conshohocken, PA 19428 870 USA 871 steve@nstl.com 873 Newman et al. Page [16]