idnits 2.17.1 draft-hamilton-bmwg-ca-bench-meth-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4666 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3511 (ref. '3') (Obsoleted by RFC 9411) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. '8') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Hamilton 3 Internet-Draft BreakingPoint Systems 4 Intended status: Informational S. Banks 5 Expires: January 12, 2012 Cisco Systems 6 July 11, 2011 8 Benchmarking Methodology for Content-Aware Network Devices 9 draft-hamilton-bmwg-ca-bench-meth-07 11 Abstract 13 The purpose of this document is to define a set of test scenarios 14 which may be used to create a series of statistics that will help to 15 better understand the performance of network devices that operate at 16 nework layers above IP. More specifically, these scenarios are 17 designed to most accurately predict performance of these devices when 18 subjected to dynamic traffic patterns. This document will operate 19 within the constraints of the Benchmarking Working Group charter, 20 namely black box characterization in a laboratory environment. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 12, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 58 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Test Considerations . . . . . . . . . . . . . . . . . . . 6 61 3.2. Clients and Servers . . . . . . . . . . . . . . . . . . . 6 62 3.3. Traffic Generation Requirements . . . . . . . . . . . . . 6 63 3.4. Discussion of Network Mathematics . . . . . . . . . . . . 7 64 3.5. Framework for Traffic Specification . . . . . . . . . . . 8 65 3.6. Multiple Client/Server Testing . . . . . . . . . . . . . . 8 66 3.7. Device Configuration Considerations . . . . . . . . . . . 9 67 3.7.1. Network Addressing . . . . . . . . . . . . . . . . . . 9 68 3.7.2. Network Address Translation . . . . . . . . . . . . . 9 69 3.7.3. TCP Stack Considerations . . . . . . . . . . . . . . . 9 70 3.7.4. Other Considerations . . . . . . . . . . . . . . . . . 9 71 4. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1. Maximum Application Flow Rate . . . . . . . . . . . . . . 10 73 4.1.1. Objective . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 10 75 4.1.2.1. Application-Layer Parameters . . . . . . . . . . . 10 76 4.1.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1.4. Measurement . . . . . . . . . . . . . . . . . . . . . 10 78 4.1.4.1. Maximum Application Flow Rate . . . . . . . . . . 10 79 4.1.4.2. Application Flow Duration . . . . . . . . . . . . 10 80 4.1.4.3. Packet Loss . . . . . . . . . . . . . . . . . . . 11 81 4.1.4.4. Application Flow Latency . . . . . . . . . . . . . 11 82 4.2. Application Throughput . . . . . . . . . . . . . . . . . . 11 83 4.2.1. Objective . . . . . . . . . . . . . . . . . . . . . . 11 84 4.2.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 11 85 4.2.2.1. Parameters . . . . . . . . . . . . . . . . . . . . 11 86 4.2.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 11 87 4.2.4. Measurement . . . . . . . . . . . . . . . . . . . . . 11 88 4.2.4.1. Maximum Throughput . . . . . . . . . . . . . . . . 11 89 4.2.4.2. Packet Loss . . . . . . . . . . . . . . . . . . . 12 90 4.2.4.3. Maximum Application Flow Rate . . . . . . . . . . 12 91 4.2.4.4. Application Flow Duration . . . . . . . . . . . . 12 92 4.2.4.5. Packet Loss . . . . . . . . . . . . . . . . . . . 12 93 4.2.4.6. Application Flow Latency . . . . . . . . . . . . . 12 94 4.3. Malicious Traffic Handling . . . . . . . . . . . . . . . . 12 95 4.3.1. Objective . . . . . . . . . . . . . . . . . . . . . . 12 96 4.3.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 12 97 4.3.2.1. Parameters . . . . . . . . . . . . . . . . . . . . 12 98 4.3.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 13 99 4.3.4. Measurement . . . . . . . . . . . . . . . . . . . . . 13 100 4.4. Malformed Traffic Handling . . . . . . . . . . . . . . . . 13 101 4.4.1. Objective . . . . . . . . . . . . . . . . . . . . . . 13 102 4.4.2. Setup Parameters . . . . . . . . . . . . . . . . . . . 13 103 4.4.3. Procedure . . . . . . . . . . . . . . . . . . . . . . 13 104 4.4.4. Measurement . . . . . . . . . . . . . . . . . . . . . 14 105 5. Appendix A: Example Test Case . . . . . . . . . . . . . . . . 14 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 109 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 110 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 113 1. Introduction 115 Content-aware and deep packet inspection (DPI) device penetration has 116 grown significantly over the last decade. No longer are devices 117 simply using Ethernet headers and IP headers to make forwarding 118 decisions. Devices that could historically be classified as 119 'stateless' or raw forwarding devices are now seeing more DPI 120 functionality. Devices such as core and edge routers are now being 121 developed with DPI functionality to make more intelligent routing and 122 forwarding decisions. 124 The Benchmarking Working Group (BMWG) has historically produced 125 Internet Drafts and Requests for Comment that are focused 126 specifically on creating output metrics that are derived from a very 127 specific and well-defined set of input parameters that are completely 128 and unequivocally reproducible from testbed to testbed. The end goal 129 of such methodologies is to, in the words of the BMWG charter "reduce 130 specmanship" from network equipment manufacturers(NEM's). Existing 131 BMWG work has certainly met this stated goal. 133 Today, device sophistication has expanded beyond existing 134 methodologies, allowing vendors to reengage in specmanship. In order 135 to achieve the stated BMWG goals, the methodologies designed to hold 136 vendors accountable must evolve with the enhanced device 137 functionality. 139 The BMWG has historically avoided the use of the term "realistic" 140 throughout all of its drafts and RFCs. While this document will not 141 explicitly use this term, the end goal of the terminology and 142 methodology is to generate performance metrics that will be as close 143 as possible to equivalent metrics in a production environment. It 144 should be further noted than any metrics acquired from a production 145 network MUST be captured according to the policies and procedures of 146 the IPPM or PMOL working groups. 148 An explicit non-goal of this document is to replace existing 149 methodology/terminology pairs such as RFC 2544 [1]/RFC 1242 [2] or 150 RFC 3511 [3]/RFC 2647 [4]. The explicit goal of this document is to 151 create a methodology and terminology pair that is more suited for 152 modern devices while complementing the data acquired using existing 153 BMWG methodologies. Existing BMWG work generally revolves around 154 completely repeatable input stimulus, expecting fully repeatable 155 output. This document departs from this mantra due to the nature of 156 modern traffic and is more focused on output repeatability than on 157 static input stimulus. 159 Some of the terms used throughout this draft have previously been 160 defined in "Benchmarking Terminology for Firewall Performance" RFC 161 2647 [4]. This document SHOULD be consulted prior to using this 162 document. 164 1.1. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [5]. 170 2. Scope 172 Content-aware devices take many forms, shapes and architectures. 173 These devices are advanced network interconnect devices that inspect 174 deep into the application payload of network data packets to do 175 classification. They may be as simple as a firewall that uses 176 application data inspection for rule set enforcement, or they may 177 have advanced functionality such as performing protocol decoding and 178 validation, anti-virus, anti-spam and even application exploit 179 filtering. 181 It shall be explicitly stated that this methodology does not imply 182 the use of traffic captured from live networks and replayed. 184 This document is strictly focused on examining performance and 185 robustness across a focused set of metrics that may be used to more 186 accurately predict device performance when deployed in modern 187 networks. These metrics will be implementation independent. 189 It should also be noted that the purpose of this document is not to 190 perform functional testing of the potential features in the Device/ 191 System Under Test (DUT/SUT)[4] nor specify the configurations that 192 should be tested. Various definitions of proper operation and 193 configuration may be appropriate within different contexts. While 194 the definition of these parameters are outside the scope of this 195 document, the specific configuration of both the DUT and tester 196 SHOULD be published with the test results for repeatability and 197 comparison purposes. 199 While a list of devices that fall under this category will quickly 200 become obsolete, an initial list of devices that would be well served 201 by utilizing this type of methodology should prove useful. Devices 202 such as firewalls, intrusion detection and prevention devices, 203 application delivery controllers, deep packet inspection devices, and 204 unified threat management systems generally fall into the content- 205 aware category. 207 3. Test Setup 209 This document will be applicable to most test configurations and will 210 not be confined to a discussion on specific test configurations. 211 Since each DUT/SUT will have their own unique configuration, users 212 MUST configure their device with the same parameters that would be 213 used in the actual deployment of the device. The DUT configuration 214 MUST be published with the final benchmarking results. If available, 215 command-line scripts used to configured the DUT and any configuration 216 information for the tester SHOULD be published with the final results 218 3.1. Test Considerations 220 3.2. Clients and Servers 222 Content-aware device testing SHOULD involve multiple clients and 223 multiple servers. As with RFC 3511 [3], this methodology will use 224 the terms virtual clients/servers because both the client and server 225 will be represented by the tester and not actual clients/servers. 226 Similarly defined in RFC 3511 [3], a data source may emulate multiple 227 clients and/or servers within the context of the same test scenario. 228 The test report MUST indicate the number of virtual clients/servers 229 used during the test. In Appendix C of RFC 2544 [1], the range of IP 230 addresses assigned to the BMWG by the IANA are listed. This address 231 range SHOULD be adhered to in accordance with RFC 2544 [1]. 232 Additionally, section 5.2 of RFC 5180 [6] SHOULD be consulted for the 233 appropriate address ranges when testing IPv6-enabled configurations. 235 3.3. Traffic Generation Requirements 237 The explicit purposes of content-aware devices vary widely, but these 238 devices use information deeper inside the application flow to make 239 decisions and classify traffic. This methodology will utilize 240 traffic flows that resemble real application traffic without 241 utilizing captures from live production networks. Application Flows, 242 as defined in RFC 2722 [7] are able to be well-defined without simply 243 referring to a network capture. The traffic template is defined and 244 listed in the appendix of this document. 246 The test tool MUST be able to create application flows between every 247 client and server, regardless of direction. The tester MUST be able 248 to open TCP connections on multiple destination ports and MUST be 249 able to direct UDP traffic to multiple destination ports. 251 While it is duly noted that no two production networks look alike, 252 this document will illustrate an example mix of what traffic may look 253 like on a sample production network. A user of this methodology is 254 free to utilize the sample mix as provided in the appendix. If a 255 user of this methodology understands the traffic patterns in their 256 production network, that user SHOULD use the framework provided in 257 the appendix to create a traffic mix appropriate to their 258 environment. 260 3.4. Discussion of Network Mathematics 262 Prior to executing the methodology as outlined in the following 263 sections, it is imperative to understan the implications of utilizing 264 representative application flows for the actual traffic content of 265 the benchmarking effort. One interesting aspect of utilizing 266 application flows is that each flow is inherently different from 267 every other application flow. The content of each flow will vary 268 from application to application, and in most cases, even varies 269 within the same type of application flow. The following description 270 of the methodology will individually benchmark every individual type 271 and subset of application flow, prior to performing similar tests 272 with a traffic mix as specified either by the sample mix in the 273 appendix, or as defined by the user of this methodology. 275 The purpose of this process is to ensure that any performance 276 implications that are discovered during the mixed testing aren't due 277 to the inherent physical network limitations. As an example of this 278 phenomina, let's take a simgle-homed network device, as illustrated 279 in the following diagram. 281 +----------+ 282 +---+ 1gE | DUT/ | 1gE +---+ 283 |C/S|------| SUT |------|C/S| 284 +---+ +----------+ +---+ 286 Simple DUT Configruation 288 Figure 1: Single-Homed Example 290 For the purpose of this discussion, let's take a theoretical 291 application flow that utilizes UDP for the transport layer. Assume 292 that the sample transaction we will be using to model this particular 293 flow requires 10 UDP datagrams to complete the transaction. For 294 simplicity, each datagram within the flow is exactly 64 bytes, 295 including associated Ethernet, IP, and UDP overhead. With any 296 network device,there are always three metrics which interact with 297 each other: concurrent application flows, application flows per 298 second, and throughput. 300 Our example testbed is a single-homed device connected with 1 gigabit 301 ethernet links. The purpose of this benchmark effort is to quantify 302 the number of application flows per second that may be processed 303 through our device under test. Let's assume that the result from our 304 scenario is that the DUT is able to process 10,000 application flows 305 per second. The question is whether that ceiling is the actual 306 ceiling of the device, or if it is actual being gated by one of the 307 other metrics. If we do the appropriate math, 10000 flows per 308 second, with each flow at 640 total bytes means that we are acheiving 309 a throughput of roughtly 49 Mbps. This is dramatically less than the 310 1 gigabit physical link we are using. We can conclude that 10,000 311 flows per second is in fact the performance limit of the device. 313 If we change the example slightly and change the size of each 314 datagram to 1312 bytes, then we'll need to redo our math. Assuming 315 the same observed DUT limitation of 10,000 flows per second, we need 316 to ensure that this is an artifact of the DUT, and not of physical 317 limitations. For each flow, we'll require 104,960 bits. 10,000 flows 318 per second implies a throughput of roughly 1 Gbps. At this point, we 319 cannot difinitively answer whether the DUT is actually limited to 320 10,000 flows per second. If we are able to modify the scenario, and 321 utilize 10 Gigabit interfaces, then perhaps the flow per second 322 ceiling will be reached at a higher number than 10,000. 324 This example illustrates why a user of this methodology MUST 325 benchmark each application variant individually to ensure that each 326 flow's ceilings are true ceilings, rather than an artifact of a 327 different limitation. 329 3.5. Framework for Traffic Specification 331 The following table MUST be specified for each application flow 332 variant. 334 o Flow Size in Bits 336 o Percentage of Aggregate Flows: 25% 338 o Transport Protocol(s): TCP,UDP 340 o Destination Port(s): 80 342 3.6. Multiple Client/Server Testing 344 In actual network deployments, connections are being established 345 between multiple clients and multiple servers simultaneously. Device 346 vendors have been known to optimize the operation of their devices 347 for easily defined patterns. The connection sequence ordering 348 scenarios a device will see on a network will likely be much less 349 deterministic. In fact, many application flows have multiple layer 4 350 connections within a single flow, with client and server reversing 351 roles. This methodology makes no assumptions about flow initiation 352 sequence across multiple ports. 354 3.7. Device Configuration Considerations 356 The configruation of the DUT may have an effect on the observed 357 results of the following methodology. A comprehensive, but certainly 358 not exhaustive, list of potential considerations is listed below. 360 3.7.1. Network Addressing 362 The IANA has issued a range of IP addresses to the BMWG for purposes 363 of benchmarking. Please refer to RFC 2544 [1] for more details. 365 3.7.2. Network Address Translation 367 Many content-aware devices are capable of performing Network Address 368 Translation (NAT)[4]. If the final deployment of the DUT will have 369 this functionality enabled, then the DUT MUST also have it enabled 370 during the execution of this methodology. It MAY be beneficial to 371 perform the test series in both modes in order to determine the 372 performance differential when using NAT. The test report MUST 373 indicate whether NAT was enabled during the testing process. 375 3.7.3. TCP Stack Considerations 377 As with RFC 3511 [3], TCP options SHOULD remain constant across all 378 devices under test in order to ensure truly comparable results. This 379 document does not attempt to specify which TCP options should be 380 used, but all devices tested SHOULD be subject to the same 381 configuration options. 383 3.7.4. Other Considerations 385 Various content-aware devices will have widely varying feature sets. 386 In the interest of representative test results, the DUT features that 387 will likely be enabled in the final deployment SHOULD be used. This 388 methodology is not intended to advise on which features should be 389 enabled, but to suggest using actual deployment configurations. 391 4. Benchmarking Tests 393 Each of the following benchmark scenarios SHOULD be run with each of 394 the single application flow templates. Upon completion of all 395 iterations, the mixed test SHOULD be completed, subject to the 396 traffic mix as defined by the user. 398 4.1. Maximum Application Flow Rate 400 4.1.1. Objective 402 To determine the maximum rate through which a device is able to 403 establish and complete application flows as defined by RFC 2647 [4]. 405 4.1.2. Setup Parameters 407 The following parameters MUST be defined for all tests: 409 4.1.2.1. Application-Layer Parameters 411 For each application protocol in use during the test run, the table 412 provided in Section 3.5 must be published. 414 4.1.3. Procedure 416 The test SHOULD generate application network traffic that meets the 417 conditions of Section 3.3. The traffic pattern SHOULD begin with an 418 application flow rate of 10% of expected maximum. The test SHOULD be 419 configured to increase the attempt rate in units of 10% up through 420 110% of expected maximum. The duration of each loading phase SHOULD 421 be at least 30 seconds. This test MAY be repeated, each subsequent 422 iteration beginning at 5% of expected maximum and increasing session 423 establishment rate to 10% more than the maximum observed from the 424 previous test run. 426 This procedure MAY be repeated any number of times with the results 427 being averaged together. 429 4.1.4. Measurement 431 The following metrics MAY be determined from this test, and SHOULD be 432 observed for each application protocol within the traffic mix: 434 4.1.4.1. Maximum Application Flow Rate 436 The test tool SHOULD report the maximum rate at which application 437 flows were completed, as defined by RFC 2647 [4], Section 3.7. This 438 rate SHOULD be reported individually for each application protocol 439 present within the traffic mix. 441 4.1.4.2. Application Flow Duration 443 The test tool SHOULD report the minimum, maximum and average 444 application duration, as defined by RFC 2647 [4], Section 3.9. This 445 duration SHOULD be reported individually for each application 446 protocol present within the traffic mix. 448 4.1.4.3. Packet Loss 450 The test tool SHOULD report the number of flow packets lost or 451 dropped from source to destination. 453 4.1.4.4. Application Flow Latency 455 The test tool SHOULD report the minimum, maximum and average amount 456 of time an application flow member takes to traverse the DUT, as 457 defined by RFC 1242 [2], Section 3.13. This rate SHOULD be reported 458 individually for each application protocol present within the traffic 459 mix. 461 4.2. Application Throughput 463 4.2.1. Objective 465 To determine the maximum rate through which a device is able to 466 forward bits when using application flows as defined in the previous 467 sections. 469 4.2.2. Setup Parameters 471 The following parameters MUST be defined and reported for all tests: 473 4.2.2.1. Parameters 475 The same parameters as described in Section 4.1.2 MUST be used. 477 4.2.3. Procedure 479 This test will attempt to send application flows through the device 480 at a flow rate of 30% of the maximum, as observed in Section 4.1. 481 This procedure MAY be repeated with the results from each iteration 482 averaged together. 484 4.2.4. Measurement 486 The following metrics MAY be determined from this test, and SHOULD be 487 observed for each application protocol within the traffic mix: 489 4.2.4.1. Maximum Throughput 491 The test tool SHOULD report the minimum, maximum and average 492 application throughput. 494 4.2.4.2. Packet Loss 496 The test tool SHOULD report the number of network packets lost or 497 dropped from source to destination. 499 4.2.4.3. Maximum Application Flow Rate 501 The test tool SHOULD report the maximum rate at which application 502 flows were completed, as defined by RFC 2647 [4], Section 3.7. This 503 rate SHOULD be reported individually for each application protocol 504 present within the traffic mix. 506 4.2.4.4. Application Flow Duration 508 The test tool SHOULD report the minimum, maximum and average 509 application duration, as defined by RFC 2647 [4], Section 3.9. This 510 duration SHOULD be reported individually for each application 511 protocol present within the traffic mix. 513 4.2.4.5. Packet Loss 515 The test tool SHOULD report the number of flow packets lost or 516 dropped from source to destination. 518 4.2.4.6. Application Flow Latency 520 The test tool SHOULD report the minimum, maximum and average amount 521 of time an application flow member takes to traverse the DUT, as 522 defined by RFC 1242 [2], Section 3.13. This rate SHOULD be reported 523 individually for each application protocol present within the traffic 524 mix. 526 4.3. Malicious Traffic Handling 528 4.3.1. Objective 530 To determine the effects on performance that malicious traffic may 531 have on the DUT. While this test is not designed to characterize 532 accuracy of detection or classification, it MAY be useful to record 533 these measurements as specified below. 535 4.3.2. Setup Parameters 537 4.3.2.1. Parameters 539 The same parameters as described in Section 4.1.2 MUST be used. 541 Additionally, the following parameters MUST be defined and reported 542 for all tests: 544 o Attack List: A listing of the malicious traffic that was generated 545 by the test. 547 4.3.3. Procedure 549 This test will utilize the procedures specified previously in 550 Section 4.1.3 and Section 4.2.3. When performing the procedures 551 listed previously, the tester should generate malicious traffic 552 representative of the final network deployment. The mix of attacks 553 MAY include software vulnerability exploits, network worms, back-door 554 access attempts, network probes and other malicious traffic. 556 If a DUT may be run with and without the attack mitigation, both 557 procedures SHOULD be run with and without the feature enabled on the 558 DUT to determine the affects of the malicious traffic on the baseline 559 metrics previously derived. If a DUT does not have active attack 560 mitigation capabilities, this procedure SHOULD be run regardless. 561 Certain malicious traffic could affect device performance even if the 562 DUT does not actively inspect packet data for malicious traffic. 564 4.3.4. Measurement 566 The metrics specified by Section 4.1.4 and Section 4.2.4 SHOULD be 567 determined from this test. 569 4.4. Malformed Traffic Handling 571 4.4.1. Objective 573 To determine the effects on performance and stability that malformed 574 traffic may have on the DUT. 576 4.4.2. Setup Parameters 578 The same parameters must be used for Transport-Layer and Application 579 Layer Parameters previously specified in Section 4.1.2 and 580 Section 4.2.2. 582 4.4.3. Procedure 584 This test will utilize the procedures specified previously in 585 Section 4.1.3 and Section 4.2.3. When performing the procedures 586 listed previously, the tester should generate malformed traffic at 587 all protocol layers. This is commonly known as fuzzed traffic. 588 Fuzzing techniques generally modify portions of packets, including 589 checksum errors, invalid protocol options, and improper protocol 590 conformance. This test SHOULD be run on a DUT regardless of whether 591 it has built-in mitigation capabilities. 593 4.4.4. Measurement 595 For each protocol present in the traffic mix, the metrics specified 596 by Section 4.1.4 and Section 4.2.4 MAY be determined. This data may 597 be used to ascertain the effects of fuzzed traffic on the DUT. 599 5. Appendix A: Example Test Case 601 This appendix shows an example case of a protocol mix that may be 602 used with this methodology. 604 +---------------------------+-----------------------+-------------+ 605 | Protocol | Label | Value | 606 +---------------------------+-----------------------+-------------+ 607 | Web 1kB | | | 608 | | Flow Size | 1kB | 609 | | Flow Percentage | 15% | 610 | | Transport Protocol(s) | TCP | 611 | | Destination Port(s) | 80 | 612 | Web 10kB | | | 613 | | Flow Size | 10kB | 614 | | Flow Percentage | 15% | 615 | | Transport Protocol(s) | TCP | 616 | | Destination Port(s) | 80 | 617 | Web 100kB | | | 618 | | Flow Size | 100kB | 619 | | Flow Percentage | 15% | 620 | | Transport Protocol(s) | TCP | 621 | | Destination Port(s) | 80 | 622 | BitTorrent Movie Download | | | 623 | | Flow Size | 500 MB | 624 | | Flow Percentage | 5% | 625 | | Transport Protocol(s) | TCP | 626 | | Destination Port(s) | 6881-6889 | 627 | SMTP Email | | | 628 | | Flow Size | 50 kB | 629 | | Flow Percentage | 10% | 630 | | Transport Protocol(s) | TCP | 631 | | Destination Port(s) | 25 | 632 | IMAP Email | | | 633 | | Flow Size | 100 kB | 634 | | Flow Percentage | 15% | 635 | | Transport Protocol(s) | TCP | 636 | | Destination Port(s) | 143 | 637 | DNS | | | 638 | | Flow Size | 2 kB | 639 | | Flow Percentage | 10% | 640 | | Transport Protocol(s) | UDP | 641 | | Destination Port(s) | 53 | 642 | RTP | | | 643 | | Flow Size | 100 mB | 644 | | Flow Percentage | 10% | 645 | | Transport Protocol(s) | UDP | 646 | | Destination Port(s) | 20000-65535 | 647 +---------------------------+-----------------------+-------------+ 649 Table 1: Sample Traffic Pattern 651 6. IANA Considerations 653 This memo includes no request to IANA. 655 All drafts are required to have an IANA considerations section (see 656 the update of RFC 2434 [8] for a guide). If the draft does not 657 require IANA to do anything, the section contains an explicit 658 statement that this is the case (as above). If there are no 659 requirements for IANA, the section will be removed during conversion 660 into an RFC by the RFC Editor. 662 7. Security Considerations 664 Benchmarking activities as described in this memo are limited to 665 technology characterization using controlled stimuli in a laboratory 666 environment, with dedicated address space and the other constraints 667 RFC 2544 [1]. 669 The benchmarking network topology will be an independent test setup 670 and MUST NOT be connected to devices that may forward the test 671 traffic into a production network, or misroute traffic to the test 672 management network 674 8. References 676 8.1. Normative References 678 [1] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 679 Network Interconnect Devices", RFC 2544, March 1999. 681 [2] Bradner, S., "Benchmarking terminology for network 682 interconnection devices", RFC 1242, July 1991. 684 [3] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, 685 "Benchmarking Methodology for Firewall Performance", RFC 3511, 686 April 2003. 688 [4] Newman, D., "Benchmarking Terminology for Firewall Performance", 689 RFC 2647, August 1999. 691 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 692 Levels", BCP 14, RFC 2119, March 1997. 694 [6] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, 695 "IPv6 Benchmarking Methodology for Network Interconnect 696 Devices", RFC 5180, May 2008. 698 [7] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: 699 Architecture", RFC 2722, October 1999. 701 8.2. Informative References 703 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 704 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 706 Authors' Addresses 708 Mike Hamilton 709 BreakingPoint Systems 710 Austin, TX 78717 711 US 713 Phone: +1 512 636 2303 714 Email: mhamilton@breakingpoint.com 716 Sarah Banks 717 Cisco Systems 718 San Jose, CA 95134 719 US 721 Email: sabanks@cisco.com