idnits 2.17.1 draft-ietf-bmwg-acc-bench-meth-opsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 320. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 23 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 42 instances of lines with control characters in the document. ** The abstract seems to contain references ([4], [6], [7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 246, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 249, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 252, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 259, but no explicit reference was found in the text == Unused Reference: 'NANOG25' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'IEEECQR' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'CONVMETH' is defined on line 282, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2544 (ref. '3') == Outdated reference: A later version (-13) exists of draft-ietf-bmwg-acc-bench-term-05 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-acc-bench-term (ref. '4') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-05 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-term (ref. '5') == Outdated reference: A later version (-09) exists of draft-ietf-bmwg-acc-bench-meth-03 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-acc-bench-meth (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 3871 (ref. '7') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-05 Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: October 2005 4 Scott Poretsky 5 Reef Point Systems 7 Shankar Rao 8 Qwest Communications 10 July 2005 12 Methodology for Benchmarking 13 Accelerated Stress with Operational Security 14 16 Intellectual Property Rights (IPR) statement: 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 ABSTRACT 44 Routers in an operational network are simultaneously configured with 45 multiple protocols and security policies while forwarding traffic and 46 being managed. To accurately benchmark a router for deployment it is 47 necessary that the router be tested in these simultaneous operational 48 conditions, which is known as Stress Testing. This document provides 49 the Methodology for performing Stress Benchmarking of networking 50 devices when subjected to instability as described in [7]. 51 Descriptions of test topology, benchmarks and reporting format are 52 provided in addition to procedures for conducting various test cases. 53 This methodology is based upon the accelerated stress methodology 54 guidelines [6] and is to be used with the companion terminology 55 document [4]. 57 Table of Contents 58 1. Introduction ............................................... 2 59 2. Existing definitions ....................................... 2 60 3. Test Setup.................................................. 2 61 4. Test Cases.................................................. 3 62 4.1 Restart Under Load......................................... 3 63 4.2 Destination Control Processor.............................. 3 64 4.3 Destination Control Processor with Rate-Limiting........... 4 65 4.4 Destination Interfaces..................................... 4 66 4.5 DoS Attack................................................. 5 67 5. Security Considerations..................................... 5 68 6. Normative References........................................ 5 69 7. Informative References...................................... 6 70 8. Author's Address............................................ 6 72 1. Introduction 74 Routers in an operational network are simultaneously configured with 75 multiple protocols and security policies while forwarding traffic and 76 being managed. To accurately benchmark a router for deployment it is 77 necessary that the router be tested in these simultaneous operational 78 conditions, which is known as Stress Testing. This document provides 79 the Methodology for performing Stress Benchmarking of networking 80 devices when subjected to instability as described in the OpSec 81 Requirements for Service Providers [7]. Descriptions of 82 Test Topology, Benchmarks and Reporting Format are provided in 83 addition to procedures for conducting various test cases. This 84 methodology is based upon the accelerated stress methodology 85 guidelines [6] and is to be used with the companion terminology 86 document [4]. 88 2. Existing definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in BCP 14, RFC 2119 92 [8]. RFC 2119 defines the use of these key words to help make the 93 intent of standards track documents as clear as possible. While this 94 document uses these keywords, this document is not a standards track 95 document. 97 Terms related to Accelerated Stress Benchmarking are defined in [4]. 99 3. Test Setup 101 Test Setup, Test Topologies, Considerations, and Reporting Format 102 MUST be as described in [6]. 104 4. Test Cases 106 4.1 Restart Under Load 108 Objective 109 The purpose of this test is to benchmark the performance of the DUT 110 during restart when stress conditions are applied. 112 Procedure 113 1. Report Configuration Set 114 2. Begin Startup Conditions with the DUT 115 3. Establish Configuration Sets with the DUT 116 4. Report benchmarks (for stability) 117 5. Restart DUT. This marks the beginning on the recovery period. 118 6. Report benchmarks (for recovery) 119 7. Optional - Change Configuration Set and/or Instability 120 Conditions for next iteration 121 NOTE 1: Restart via the DUT's Command Line Interface rather than 122 power cycle is typically more stressful than power cycle 123 since hardware can maintain state. 124 NOTE 2: Instability Conditions are not applied for this test case. 126 Results 127 DUT should re-establish all control protocol sessions and have 128 a Recovery Time [4] that is not infinite. 130 4.2 Destination Control Processor 131 Objective 132 The purpose of this test is to benchmark the performance 133 of the DUT during stress conditions when traffic is destined for 134 the Control Processor of the DUT. 136 Procedure 137 1. Report Configuration Set 138 2. Begin Startup Conditions with the DUT 139 3. Start Configuration Sets with the DUT, except Data Plane 140 Configuration Set 141 4. Report benchmarks (for stability) 142 5. Apply Instability Conditions 143 6. Send offered load at maximum forwarding rate of DUT interfaces 144 to all DUT interfaces. Traffic MUST be configured so that the 145 offered load has a destination address that is the DUT's central 146 control processor 147 7. Report benchmarks (for instability) 148 8. Stop applying all Instability Conditions, including data traffic 149 9. Report benchmarks (for recovery) 150 10. Optional - Change Configuration Set and/or Instability 151 Conditions for next iteration 153 Results 154 Results will vary with specific vendor implementations. 155 It is possible that significant session loss is observed. 157 4.3 Destination Control Processor with Rate-Limiting 159 Objective 160 The purpose of this test is to benchmark the performance 161 of the DUT during stress conditions when traffic is destined for 162 the Control processor of the DUT. 164 Procedure 165 1. Report Configuration Set 166 2. Apply policy filter to rate-limit traffic arriving at the Central 167 Processor to be only 1% of the offered load. 168 3. Begin Startup Conditions with the DUT 169 4. Start Configuration Sets with the DUT, except Data Plane 170 Configuration Set 171 5. Report benchmarks (for stability) 172 6. Apply Instability Conditions 173 7. Send offered load at maximum forwarding rate of DUT interfaces 174 to all DUT interfaces. Traffic MUST be configured so that the 175 offered load has a destination address that is the DUT's central 176 control processor 177 8. Report benchmarks (for instability) 178 9. Stop applying all Instability Conditions, including data traffic 179 10. Report benchmarks (for recovery) 180 11. Optional - Change Configuration Set and/or Instability 181 Conditions for next iteration 183 Results 184 Results will vary with specific vendor implementations. There should be 185 no session loss observed. 187 4.4 Destination Interfaces 188 Objective 189 The purpose of this test is to benchmark the performance 190 of the DUT during stress conditions when traffic is destined for 191 the interfaces of the DUT. 193 Procedure 194 1. Report Configuration Set 195 2. Begin Startup Conditions with the DUT 196 3. Start Configuration Sets with the DUT, except Data Plane 197 Configuration Set 198 4. Report benchmarks (for stability) 199 5. Apply Instability Conditions 200 6. Send offered load at maximum forwarding rate of DUT interfaces 201 to all DUT interfaces. Traffic MUST be configured so that the 202 offered load has destination addresses of the interfaces receiving 203 traffic. 204 7. Report benchmarks (for instability) 205 8. Stop applying all Instability Conditions, including data traffic 206 9. Report benchmarks (for recovery) 207 10. Optional - Change Configuration Set and/or Instability 208 Conditions for next iteration 210 Results 211 Results will vary with specific vendor implementations. 212 There should be no session loss observed. 214 4.5 DoS Attack 216 Objective 217 The purpose of this test is to benchmark the performance of the 218 DUT during stress conditions while experiencing a DoS attack. 220 Procedure 221 1. Report Configuration Set 222 2. Begin Startup Conditions with the DUT 223 3. Establish Configuration Sets with the DUT 224 4. Report benchmarks (for stability) 225 5. Apply Instability Conditions 226 6. Initiate DoS Attack against DUT. It is RECOMMENDED that 227 the SYN Flood attack be used for the DoS attack. 228 7. Report benchmarks (for instability) 229 8. Stop applying all Instability Conditions 230 9. Report benchmarks (for recovery) 231 10. Optional - Change Configuration Set and/or Instability 232 Conditions for next iteration 234 Results 235 DUT should be able to defend against DoS attack without additional 236 packet loss or session loss. 238 5. Security Considerations 239 Documents of this type do not directly affect the security of 240 the Internet or of corporate networks as long as benchmarking 241 is not performed on devices or systems connected to operating 242 networks. 244 6. Normative References 246 [1] Bradner, S., Editor, "Benchmarking Terminology for Network 247 Interconnection Devices", RFC 1242, July 1991. 249 [2] Mandeville, R., "Benchmarking Terminology for LAN Switching 250 Devices", RFC 2285, June 1998. 252 [3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 253 Network Interconnect Devices", RFC 2544, March 1999. 255 [4] Poretsky, S. and Rao, S., "Terminology for Accelerated 256 Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-05, 257 work in progress, July 2005. 259 [5] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 260 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-05, 261 work in progress, July 2005. 263 [6] Poretsky, S. and Rao, S., "Methodology Guidelines for Accelerated 264 Stress Benchmarking", draft-ietf-bmwg-acc-bench-meth-03, 265 work in progress, July 2005. 267 [7] RFC 3871 "Operational Security Requirements for Large 268 Internet Service Provider (ISP) IP Network Infrastructure. 269 G. Jones, Ed.. IETF, September 2004. 271 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 272 Levels", RFC 2119, March 1997. 274 7. Informative References 276 [NANOG25] "Core Router Evaluation for Higher Availability", Scott 277 Poretsky, NANOG 25, June 8, 2002, Toronto, CA. 279 [IEEECQR] "Router Stress Testing to Validate Readiness for Network 280 Deployment", Scott Poretsky, IEEE CQR 2003. 282 [CONVMETH] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 283 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-05, 284 work in progress, July 2005. 286 8. Author's Address 288 Scott Poretsky 289 Reef Point Systems 290 8 New England Executive Park 291 Burlington, MA 01803 292 USA 294 Phone: + 1 781 395 5090 295 EMail: sporetsky@reefpoint.com 297 Shankar Rao 298 1801 California Street 299 8th Floor 300 Qwest Communications 301 Denver, CO 80202 302 USA 303 Phone: + 1 303 437 6643 304 Email: shankar.rao@qwest.com 305 Intellectual Property Statement 307 The IETF takes no position regarding the validity or scope of any Intel- 308 lectual Property Rights or other rights that might be claimed to pertain 309 to the implementation or use of the technology described in this docu- 310 ment or the extent to which any license under such rights might or might 311 not be available; nor does it represent that it has made any independent 312 effort to identify any such rights. Information on the procedures with 313 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 315 Copies of IPR disclosures made to the IETF Secretariat and any 316 assurances of licenses to be made available, or the result of an attempt 317 made to obtain a general license or permission for the use of such 318 proprietary rights by implementers or users of this specification can be 319 obtained from the IETF on-line IPR repository at 320 http://www.ietf.org/ipr. 322 The IETF invites any interested party to bring to its attention any 323 copyrights, patents or patent applications, or other proprietary rights 324 that may cover technology that may be required to implement this stan- 325 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 327 Disclaimer of Warranty 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 331 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 332 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 333 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 334 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 335 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Copyright Statement 339 Copyright (C) The Internet Society (2005). This document is subject to 340 the rights, licenses and restrictions contained in BCP 78, and except as 341 set forth therein, the authors retain all their rights.