idnits 2.17.1 draft-ietf-bmwg-secperf-00.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-26) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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 an Authors' Addresses Section. ** There are 104 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 83: '...estricted access MUST require authenti...' RFC 2119 keyword, line 91: '... Authentication MAY work either by cl...' RFC 2119 keyword, line 95: '... SHOULD also authenticate them...' RFC 2119 keyword, line 115: '...d to the DUT/SUT MUST be bidirectional...' RFC 2119 keyword, line 136: '... One data source MAY emulate multiple ...' (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.) -- 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) No issues found here. Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Benchmarking Working Group D. Newman 2 INTERNET-DRAFT Data Communications 3 Expires in January 1998 H. Holzbaur, J. Hurd, and S. Platt 4 National Software Testing Laboratories 6 Benchmarking Terminology for Network Security Devices 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 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as "work 20 in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 This memo provides information for the Internet community. This 29 memo does not specify an Internet standard of any kind. 30 Distribution of this memo is unlimited. 32 1. Introduction 33 Despite the rapid rise in deployment of network security devices 34 such as firewalls and authentication/encryption products, there is 35 no standard method for evaluating the performance of these 36 devices. 38 The lack of a standard is troubling for two reasons. First, 39 hardware and software implementations vary widely, making it 40 difficult to do direct performance comparisons. Second, a growing 41 number of organizations are deploying these devices on internal 42 networks that operate at relatively high data rates, while many 43 network security devices are optimized for use over relatively 44 low-speed wide-area connections. As a result, users are often 45 unsure whether the products they buy will stand up to the 46 relatively heavy loads found on internal networks. 48 This document defines terms used in measuring the performance of 49 network security devices. It extends the terminology already used 50 for benchmarking routers and switches to network security devices. 51 The primary metrics defined in this document are maximum 52 forwarding rate and maximum number of connections. 54 Depending on the outcome of discussions within the BMWG, we may 55 also attempt to classify devices using various architectural 56 considerations (proxy, packet filter) or offered load levels 57 (high, medium, low) as criteria. Additionally, new metrics may 58 need to be defined to evaluate application-level issues. 60 2. Existing definitions 61 This document uses the conceptual framework established in RFCs 62 1242 and 1944 and draft-ietf-bmwg-lanswitch-05.txt, which 63 describes benchmarking of LAN 64 switch performance. In addition to defining basic practices, these 65 documents 66 contain discussions of several terms relevant to benchmarking 67 performance of network security devices. This document uses the 68 definition format described in RFC 1242, Section 2. Readers should 69 consult these documents before making use of this document. 71 3. Term definitions 73 3.1 Authentication 75 Definition: 76 The process of verifying that a client user or machine requesting 77 a network resource is who he, she, or it claims to be, and vice 78 versa. 80 Discussion: 81 Trust is a critical concept in network security. Obviously, any 82 network resource (such as a file server or printer) with 83 restricted access MUST require authentication before granting 84 access. 86 Authentication takes many forms, including but not limited to IP 87 addresses; TCP or UDP port numbers; passwords; external token 88 authentication cards; and pattern matching based on human 89 characteristics such as signature, speech, or retina patterns. 91 Authentication MAY work either by client machine (for example, by 92 proving that a given IP source address really is that address, and 93 not a rogue machine spoofing that address) or by user (by proving 94 that the user really is who he or she claims to be). Servers 95 SHOULD also authenticate themselves to clients. 97 Measurement units: 98 Not applicable 100 Issues: 102 See also: 103 forwarding rate (3.9) 104 user (3.25) 105 virtual client (3.26) 107 3.2 Bidirectional traffic 109 Definition: 111 Packets presented to a DUT/SUT such that the network interfaces of 112 the DUT/SUT both receive and transmit traffic. 114 Discussion: 115 Traffic patterns offered to the DUT/SUT MUST be bidirectional or 116 fully meshed. See forwarding rate (3.9) for a more complete 117 discussion of issues with traffic patterns. 119 Measurement units: 120 Not applicable 122 Issues: 123 truncated binary exponential back-off algorithm 125 See Also: 126 forwarding rate (3.9) 127 fully meshed traffic (3.10) 128 unidirectional traffic (3.24) 130 3.3 Data source 132 Definition: 133 A station capable of generating traffic to the DUT/SUT. 135 Discussion: 136 One data source MAY emulate multiple users or stations. In 137 addition, one data source MAY offer traffic to multiple network 138 interfaces on the DUT/SUT. However, each virtual client MUST offer 139 traffic to only one interface. 141 Measurement units: 142 Not applicable 144 Issues: 146 See also: 147 user (3.25) 148 virtual client (3.26) 150 3.4 Demilitarized zone (DMZ) 152 Definition: 153 A network segment or segments located between protected and 154 external networks. DMZ networks are sometimes called perimeter 155 networks. 157 Discussion: 158 As an extra security measure, networks are often designed such 159 that protected and external segments are never directly connected. 160 Instead, security devices (and possibly other public resources 161 such as WWW or FTP servers) often reside in the so-called DMZ 162 network. To connect protected, DMZ, and external networks with one 163 device, the device MUST have at least three network interfaces. 165 Multiple devices MAY constitute the DMZ, in which case the devices 166 connected the protected network with the DMZ and the DMZ with the 167 external network MUST have two network interfaces. 169 Measurement units: 170 Not applicable 172 Issues: 173 Dual-homed 174 Multihomed 176 See also: 177 external network (3.8) 178 perimeter network (3.15) 179 protected network (3.17) 181 3.5 Device under test (DUT) 183 Definition: 184 The network security device to which traffic is offered and 185 response measured. 187 Discussion: 188 A single station, generally equipped with at least two network 189 interfaces. 191 Measurement units: 192 Not applicable 194 Issues: 196 See also: 197 system under test (SUT) (3.23) 199 3.6 Dual-homed 201 Definition: 202 A station with at least two network interfaces. 204 Discussion: 205 Dual-homed network security devices connect two segments with 206 different network-layer addresses. 208 Measurement units: 209 Not applicable 211 Issues: 213 See also: 214 multihomed (3.12) 216 3.7 Dynamic proxy 218 Definition: 220 A proxy service that is set up and torn down in response to a 221 client request, rather than existing on a static basis. 223 Discussion: 224 Proxy services (see section 3.18) typically are configured to 225 "listen" on a given port number for client requests. However, some 226 devices set up a proxy service only when a client requests the 227 service. 229 Measurement units: 230 Not applicable 232 Issues: 233 rule sets 235 See also: 236 proxy (3.18) 237 rule sets (3.20) 239 3.8 External network 241 Definition: 242 The segment or segments not protected by the network security 243 DUT/SUT. 245 Discussion: 246 Network security devices are deployed between protected and 247 unprotected segments. The external network is not protected by the 248 DUT/SUT. 250 Measurement units: 251 Not applicable 253 Issues: 255 See also: 256 demilitarized zone (DMZ) (3.4) 257 protected network (3.17) 259 3.9 Forwarding rate 261 Definition: The number of bits per second a DUT/SUT can transmit 262 to the correct destination network interface in response to a 263 specified offered load. 265 Discussion: 266 Network security devices are by definition session-oriented: They 267 will only grant access to a desired resource once authentication 268 occurs and a session has been established. 270 Because application-layer sessions are always involved, 271 unidirectional packet-per-second metrics are not meaningful in the 272 context of testing network security devices. Instead, this 273 definition MUST measure application-layer performance once a 274 session has been established. 276 Forwarding rate refers to the number of bits per second observed 277 on the output side of the network interface under test. Forwarding 278 rate can be measured with different traffic orientations and 279 distributions. When multiple network interfaces are measured, 280 measurements MUST be observed from the interface with the highest 281 forwarding rate. 283 Measurement units: 284 bits per second (bit/s) 285 kilobits per second (kbit/s) 286 Megabits per second (Mbit/s) 288 Issues: 289 truncated binary exponential back-off algorithm 290 unidirectional vs. bidirectional 292 See Also: 293 authentication (3.1) 294 maximum forwarding rate (3.11) 295 offered load (3.13) 296 unidirectional traffic (3.24) 298 3.10 Fully meshed traffic 300 Definition: 301 Packets forwarded simultaneously among all of a designated number 302 of network interfaces of a DUT/SUT such that each of the 303 interfaces under test will both forward packets to and receive 304 packets from all of the other interfaces. 306 Discussion: 307 Fully meshed traffic is the most thorough method of exercising the 308 transmitting and receiving capabilities of the DUT/SUT. 310 Unlike past definitions for router or switch testing, it should be 311 noted that fully meshed traffic in this context is not necessarily 312 symmetrical. While all of a designated group of network interfaces 313 MUST simultaneously send and receive traffic, the type and amount 314 of traffic offered MAY differ on each interface. For example, a 315 network security device may see more traffic from the protected 316 network bound for the external network than the opposite (although 317 the inverse could be true during an attack on the DUT/SUT). 319 Measurement units: 320 Not applicable 322 Issues: 323 Half duplex 324 Full duplex 326 See also: 328 bidirectional traffic (3.2) 329 unidirectional traffic (3.24) 331 3.11 Maximum forwarding rate 333 Definition: 334 The highest forwarding rate of a network security device taken 335 from a set of iterative measurements. 337 Discussion: 338 Maximum forwarding rate may degrade before maximum load is 339 offered. 341 Unlike benchmarks for evaluating router and switch performance, 342 this definition MUST involve measurement of application-layer 343 performance rather than network-layer packet-per-second metrics. 345 Measurement units: 346 Megabits per second 347 kbytes per second 348 bytes per second 350 Issues: 351 full duplex vs. half duplex 352 truncated binary exponential back-off algorithm 354 See also: 355 bidirectional traffic (3.2) 356 partially meshed traffic (3.24) 357 unidirectional traffic 359 3.12 Multihomed 361 Definition: 362 A network security device with more than two network interfaces. 364 Discussion: 365 Multihoming is a way to connect three or more networks-protected, 366 DMZ, and external-with a single network security device. However, 367 this configuration is not mandatory if multiple network security 368 devices are used. For example, one device could secure the 369 connection between an external and DMZ network, while another 370 could secure the connection between a DMZ and protected network; 371 the two stations collectively form the SUT. 373 Because of the differences in traffic patterns between dual-homed 374 and multihomed devices, direct performance comparisons should be 375 avoided. However, it is acceptable to compare results between a 376 dual-homed device and a DUT/SUT in which only two network 377 interfaces are used. 379 Measurement units: 380 Not applicable 381 Issues: 382 truncated binary exponential back-off algorithm 384 See also: 385 bidirectional traffic (3.2) 386 dual-homed (3.6) 387 fully meshed traffic (3.10) 389 3.13 Offered load 391 Definition: 392 The number of bits per second that an external source can transmit 393 to a DUT/SUT for forwarding to a specified network interface or 394 interfaces. 396 Discussion: 397 The load that an external source actually applies to a DUT/SUT may 398 be lower than the external source attempts to apply because of 399 collisions on the wire. The transmission capabilities of the 400 external source SHOULD be verified without the DUT/SUT by 401 transmitting unidirectional traffic. 403 Measurement units: 404 bits per second 405 kilobits per second (kbit/s) 406 Megabits per second (Mbit/s) 408 Issues: 409 truncated binary exponential back-off algorithm 411 See also: 412 forwarding rate (3.9) 413 maximum forwarding rate (3.11) 415 3.14 Packet filtering 417 Definition: 418 The process of controlling access by examining packets based on 419 network-layer or transport-layer criteria. 421 Discussion: 422 Packet-filtering devices forward or deny packets based on 423 information in each packet's header. A packet-filtering network 424 security device uses a rule set (see section 3.20) to determine 425 which traffic should be forwarded and which should be blocked. 426 Packet filtering may be used in a dual-homed or multihomed device. 428 Measurement units: 429 Not applicable 431 Issues: 433 See also: 434 dynamic proxy (3.7) 435 proxy (3.18) 436 rule set (3.20) 437 stateful inspection (3.22) 439 3.15 Perimeter network 441 Definition: 442 A network segment or segments located between protected and 443 external networks. Perimeter networks are often called DMZ 444 networks. 446 Discussion: 447 See the definition of DMZ (which see) for a discussion. 449 Measurement units: 450 Not applicable 452 Issues: 453 Dual-homed 454 Multihomed 456 See also: 457 Demilitarized zone (DMZ) (3.4) 458 external network (3.8) 459 protected network (3.17) 461 3.16 Policy 463 Definition: 464 A document defining acceptable use of protected, DMZ, and external 465 networks. 467 Discussion: 468 Security policies generally do not spell out specific 469 configurations for network security devices; rather, they set 470 general guidelines for what it and is not acceptable network 471 behavior. 473 The actual mechanism for controlling access is usually the rule 474 set (see section 3.20) implemented in the DUT/SUT. 476 Measurement units: 477 Not applicable 479 Issues: 481 See also: 482 Rule set (3.20) 484 3.17 Protected network 486 Definition: 487 A network segment or segments to which access is controlled by the 488 DUT/SUT. 490 Discussion: 491 Network security devices are intended to prevent unauthorized 492 access either to or from the protected network. Depending on the 493 configuration specified by the policy and rule set, the DUT/SUT 494 may allow stations on the protected segment to act as clients for 495 servers on either the DMZ or the external network, or both. 497 Protected networks are often called "internal networks." That term 498 is not used here because network security devices increasingly are 499 deployed within an organization, where all segments are by 500 definition internal. 502 Measurement units: 503 Not applicable 505 Issues: 507 See also: 508 Demilitarized zone (DMZ) (3.4) 509 external network (3.8) 510 policy (3.16) 511 rule set (3.20) 513 3.18 Proxy 515 Definition: 516 The process of requesting sessions with servers on behalf of 517 clients. 519 Discussion: 520 Proxy-based network security devices never involve direct 521 connections between client and server. Instead, two sessions are 522 established: one between the client and the DUT/SUT, and another 523 between the DUT/SUT and server. 525 As with packet-filtering network security devices, proxy-based 526 devices use a rule set (which see) to determine which traffic 527 should be forwarded and which should be blocked. 529 Measurement units: 530 Not applicable 532 Issues: 534 See also: 535 dynamic proxy (3.7) 536 packet filtering (3.14) 537 stateful inspection (3.22) 539 3.19 Rejected traffic 541 Definition: 542 Packets dropped as a result of the rule set of the DUT/SUT. 544 Discussion: 545 Network security devices typically are configured to drop any 546 traffic not explicitly permitted in the rule set (which see). 547 Dropped packets MUST NOT be included in calculating the forwarding 548 rate or maximum forwarding rate of the DUT/SUT. 550 Measurement units: 551 Not applicable 553 Issues: 555 See also: 556 forwarding rate (3.9) 557 maximum forwarding rate (3.11) 558 policy (3.16) 559 rule set (3.20) 561 3.20 Rule set 563 Definition: 564 The collection of definitions that determines which packets the 565 DUT/SUT will forward and which it will reject. 567 Discussion: 568 Rule sets control access to and from the network interfaces of the 569 DUT/SUT. By definition, rule sets MUST NOT apply equally to all 570 network interfaces; otherwise there would be no need for the 571 network security device. Therefore, a specific rule set MUST be 572 applied to each network device used in the DUT/SUT. 574 The order of rules within the rule set is critical. Network 575 security devices generally scan rule sets in a "top down" fashion, 576 which is to say that the device compares each packet received with 577 each rule in the rule set until it finds a rule that applies to 578 the packet. Once the device finds an applicable rule, it applies 579 the actions defined in that rule (such as forwarding or rejecting 580 the packet) and ignores all subsequent rules. For purposes of this 581 document, the rule set MUST conclude with a rule denying all 582 access except that which is permitted in the rule set. 584 Measurement units: 585 Not applicable 587 Issues: 589 See also: 590 Demilitarized zone (DMZ) (3.4) 591 external network (3.8) 592 policy (3.17) 593 protected network (3.18) 594 rejected traffic (3.19) 596 3.21 Session 597 Definition: 598 A logical connection established between two stations using a 599 known protocol. For purposes of this document, a session MUST be 600 conducted over either TCP (RFC 793) or UDP (RFC 768). 602 Discussion: 603 Because of the application-layer focus of many network security 604 devices, sessions are a more useful metric than the packet-based 605 measurements used in benchmarking routers and switches. Although 606 network security device rule sets generally work on a per-packet 607 basis, it is ultimately sessions that a network security device 608 must handle. For example, the number of file transfer protocol 609 (ftp) sessions a DUT/SUT can handle concurrently is a more 610 meaningful measurement in benchmarking performance than the number 611 of ftp "open" packets it can reject. Further, a stateful 612 inspection device (which see) will not forward individual packets 613 if those packets' headers conflict with state information 614 maintained in the device's rule set. 616 For purposes of this document, a session MUST be established using 617 a known protocol. A traffic pattern is not considered a session 618 until it successfully completes the establishment procedures 619 defined by that protocol. 621 Also for purposes of this document, a session constitutes the 622 logical connection between two end-stations and not the 623 intermediate connections that proxy-based network security devices 624 may use. 626 Issues: 628 See also: 629 policy (3.16) 630 proxy (3.18) 631 rule set (3.20) 632 stateful inspection (3.22) 634 3.22 Stateful inspection 636 Definition: 637 The process of forwarding or rejecting traffic based on the 638 contents of a state table maintained by the network security 639 device. 641 Discussion: 642 Packet filtering and proxy devices are essentially static, in that 643 they always forward or reject traffic based on the contents of the 644 rule set. Devices using stateful inspection, in contrast, will 645 only forward traffic if it corresponds with state information 646 maintained by the device about each session. For example, a 647 stateful inspection device will reject a packet on TCP port 21 648 (ftp DATA) if no ftp session has been established. 650 Measurement units: 651 Not applicable 653 Issues: 655 See also: 656 dynamic proxy (3.7) 657 packet filter (3.14) 658 proxy (3.18) 660 3.23 System under test (SUT) 662 Definition: 663 The collective set of network security devices to which traffic is 664 offered as a single entity and response measured. 666 Discussion: 667 A system under test may comprise multiple network security 668 devices. A typical configuration involves two or more devices, 669 with at least one located between the protected network and DMZ 670 and at least one other located between the DMZ and external 671 network. Some devices may be active, such as firewalls or 672 authentication products; other devices, such as systems for 673 logging, may be passive. 675 Measurement units: 676 Not applicable 678 Issues: 680 See also: 681 demilitarized zone (DMZ) (3.4) 682 device under test (3.5) 683 external network (3.8) 684 protected network (3.17) 686 3.24 Unidirectional traffic 688 Definition: 689 Packets offered to the DUT/SUT such that the sending and receiving 690 network interface or interfaces are mutually exclusive. 692 Discussion: 693 This definition is included mainly for purposes of completeness; 694 it is not particularly meaningful in the context of network 695 security device performance. As noted in the discussion of 696 forwarding rate (see section 3.9), network security devices almost 697 invariably involve sessions with bidirectional traffic flow. 699 However, unidirectional traffic is appropriate for evaluating the 700 maximum forwarding rate of data sources (absent the DUT/SUT), and 701 for evaluating the maximum forwarding rate of certain 702 connectionless protocols. 704 Measurement units: 705 Not applicable 707 Issues: 708 half duplex vs. full duplex 710 See also: 711 bidirectional traffic (3.2) 712 forwarding rate (3.9) 713 maximum forwarding rate (3.11) 715 3.25 User 717 Definition: 718 The person or machine requesting access to resources protected by 719 the DUT/SUT. 721 Discussion: 722 "User" is a problematic term in the context of security device 723 performance testing, for several reasons. First, a user may in 724 fact be a machine or machines requesting services through the 725 DUT/SUT. Second, different "user" requests may require radically 726 different amounts of DUT/SUT resources. Third, traffic profiles 727 vary widely from one organization to another, making it difficult 728 to characterize the load offered by a typical users. For these 729 reasons, we prefer not to measure DUT/SUT performance in terms of 730 users supported. Instead, we describe performance in terms of 731 maximum forwarding rate and maximum number of sessions sustained. 733 Measurement units: 734 Not applicable 736 Issues: 738 See also: 739 data source (3.3) 740 virtual client (3.26) 742 3.26 Virtual client 744 Definition: 745 A subset of a data source that represents one individual user. 747 Discussion: 748 In offering traffic to the DUT/SUT it may be useful for one data 749 source to emulate multiple users, machines, or networks. For 750 purposes of this document, each emulated user should be considered 751 a virtual client. 753 One data source MAY offer traffic from multiple virtual clients to 754 multiple network interfaces on the DUT/SUT. However, each virtual 755 client MUST offer traffic to just one network interface. 757 Measurement units: 758 Not applicable 760 Issues: 762 See also: 763 data source (3.3) 764 user (3.25) 766 4. Security considerations 767 Security considerations are explicitly excluded from this memo. 768 The authors plan to address security and management concerns in a 769 separate proposal brought to the IETF's security directorate. 771 5. References 773 Bradner, S., editor. "Benchmarking Terminology for Network 774 Interconnection Devices." RFC 1242. 776 Bradner, S., and McQuaid, J. "Benchmarking Methodology for Network 777 Interconnect Devices." RFC 1944. 779 Mandeville, B. "Benchmarking Terminology for LAN Switching 780 Devices." ftp://ietf.org/internet-drafts/draft-ietf-bmwg- 781 lanswitch-05.txt 783 Newman, D., and Melson, B. "Can Firewalls Take the Heat?" Data 784 Communications, November 21, 1995. 785 http://www.data.com/Lab_Tests/Firewalls.html 787 Newman, D., Holzbaur, H., and Bishop, K. "Firewalls: Don't Get 788 Burned," Data Communications, March 21, 1997. 789 http://www.data.com/lab_tests/firewalls97.html 791 Ranum, M. "Firewall Performance Measurement Techniques: A 792 Scientific Approach." 793 http://www.clark.net/pub/mjr/pubs/fwperf/intro.htm 795 Shannon, G. "Profile of Corporate Internet Application Traffic." 796 http://www.milkyway.com/libr/prof.html 798 6. Acknowledgments 799 The authors wish to thank the IETF Benchmarking Working Group for 800 agreeing to review this document. Ted Doty (Network Systems), 801 Shlomo Kramer (Check Point Software Technologies), Bob Mandeville 802 (European Network Laboratories), Brent Melson (National Software 803 Testing Laboratories), Marcus Ranum (Network Flight Recorder 804 Inc.), Greg Shannon (Milkyway Networks), Rick Siebenaler 805 (Cyberguard), and Greg Smith (Check Point Software Technologies) 806 offered valuable contributions and critiques during this project. 808 7. Contact Information 809 David Newman 810 Data Communications magazine 811 1221 Avenue of the Americas, 41st Floor 812 New York, NY 10020 813 USA 814 212-512-6182 voice 815 212-512-6833 fax 816 dnewman@data.com 818 Helen Holzbaur 819 National Software Testing Laboratories Inc. 820 625 Ridge Pike 821 Conshohocken, PA 19428 822 USA 823 helen@nstl.com 825 Jim Hurd 826 National Software Testing Laboratories Inc. 827 625 Ridge Pike 828 Conshohocken, PA 19428 829 USA 830 jimh@nstl.com 832 Steven Platt, PhD. 833 National Software Testing Laboratories Inc. 834 625 Ridge Pike 835 Conshohocken, PA 19428 836 USA 837 steve@nstl.com