idnits 2.17.1 draft-ietf-bmwg-ipsec-term-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 38 instances of lines with control characters in the document. 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 (November 2003) is 7467 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GW1' is mentioned on line 1026, but not defined == Missing Reference: 'GW2' is mentioned on line 1026, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 1026, but not defined == Missing Reference: 'GW3' is mentioned on line 1026, but not defined == Missing Reference: 'GW4' is mentioned on line 1026, but not defined == Missing Reference: 'ESP' is mentioned on line 1199, but not defined == Missing Reference: 'AH' is mentioned on line 1166, but not defined == Missing Reference: 'IP' is mentioned on line 1034, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 1199, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 1199, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 1199, but not defined == Missing Reference: 'IP ORIG' is mentioned on line 1199, but not defined == Missing Reference: 'L4 HDR' is mentioned on line 1199, but not defined == Missing Reference: 'IP NEW' is mentioned on line 1199, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1289, but not defined == Unused Reference: 'RFC2119' is defined on line 2316, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 2332, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 2335, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 2338, but no explicit reference was found in the text == Unused Reference: 'RFC2408' is defined on line 2347, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 2354, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 2357, but no explicit reference was found in the text == Unused Reference: 'RFC2451' is defined on line 2363, but no explicit reference was found in the text == Unused Reference: 'RFC2547' is defined on line 2369, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 2372, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-nat-t-ike' is defined on line 2377, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-udp-encaps' is defined on line 2382, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-nat-reqts' is defined on line 2387, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2392, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 ** Downref: Normative reference to an Informational RFC: RFC 2285 ** Obsolete normative reference: RFC 2393 (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Informational RFC: RFC 2544 ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-11 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-07 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-06 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-nat-reqts (ref. 'I-D.ietf-ipsec-nat-reqts') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipsec-properties' == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-dpd-02 Summary: 17 errors (**), 0 flaws (~~), 36 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group M. Bustos 3 Internet-Draft IXIA 4 Expires: May 1, 2004 T. Van Herck 5 Cisco Systems, Inc. 6 M. Kaeo 7 Merike, Inc. 8 November 2003 10 Terminology for Benchmarking IPSec Devices 11 draft-ietf-bmwg-ipsec-term-02 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 1, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This purpose of this document is to define terminology specific to 42 measuring the performance of IPsec devices. It builds upon the 43 tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF 44 Benchmarking Methodology Working Group (BMWG) documents used for 45 benchmarking routers and switches. This document seeks to extend 46 these efforts specific to the IPsec paradigm. The BMWG produces two 47 major classes of documents: Benchmarking Terminology documents and 48 Benchmarking Methodology documents. The Terminology documents present 49 the benchmarks and other related terms. The Methodology documents 50 define the procedures required to collect the benchmarks cited in the 51 corresponding Terminology documents. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . 4 57 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 58 2.1.1 Security Associations . . . . . . . . . . . . . . . . . . 6 59 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Definition Format . . . . . . . . . . . . . . . . . . . . 8 62 5. Key Words to Reflect Requirements . . . . . . . . . . . . 9 63 6. Existing Definitions . . . . . . . . . . . . . . . . . . . 9 64 7. Term Definitions . . . . . . . . . . . . . . . . . . . . . 10 65 7.1 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1.1 Configured Tunnel . . . . . . . . . . . . . . . . . . . . 10 67 7.1.2 Established Tunnel . . . . . . . . . . . . . . . . . . . . 11 68 7.1.3 Active Tunnel . . . . . . . . . . . . . . . . . . . . . . 11 69 7.1.4 Terminated Tunnel . . . . . . . . . . . . . . . . . . . . 12 70 7.2 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.3 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.3.1 Initiator . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.3.2 Responder . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7.3.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.3.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . . . 16 76 7.4 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7.5 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7.6 Security Association (SA) . . . . . . . . . . . . . . . . 18 79 7.7 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 18 80 7.7.1 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . 19 81 7.7.2 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . 19 82 7.8 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 20 83 7.8.1 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . 20 84 7.8.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . 21 85 7.9 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 21 86 7.9.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 21 87 7.9.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 22 88 7.10 Transform protocols . . . . . . . . . . . . . . . . . . . 23 89 7.10.1 Authentication Protocols . . . . . . . . . . . . . . . . . 24 90 7.10.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 24 91 7.11 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 25 92 7.11.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 25 93 7.11.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 26 94 7.12 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 27 95 7.13 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 28 96 7.14 IP Compression . . . . . . . . . . . . . . . . . . . . . . 28 97 7.15 Security Context . . . . . . . . . . . . . . . . . . . . . 29 98 8. Performance Metrics . . . . . . . . . . . . . . . . . . . 31 99 8.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 31 100 8.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 31 101 8.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 32 102 9. Test Definitions . . . . . . . . . . . . . . . . . . . . . 32 103 9.1 Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32 104 9.1.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 105 9.1.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 106 9.1.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34 107 9.1.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 35 108 9.2 Internet Mix Traffic (IMIX) . . . . . . . . . . . . . . . 35 109 9.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36 110 9.3.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . . . . 36 111 9.3.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37 112 9.3.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 37 113 9.4 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 9.4.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . . . . 38 115 9.4.2 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 39 116 9.4.3 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 40 117 9.4.4 Time To First Packet . . . . . . . . . . . . . . . . . . . 40 118 9.5 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 41 119 9.5.1 Tunnel Frame Loss Rate . . . . . . . . . . . . . . . . . . 41 120 9.5.2 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 42 121 9.5.3 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 43 122 9.6 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 43 123 9.6.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . . . . 43 124 9.6.2 Encryption Back-to-back Frames . . . . . . . . . . . . . . 44 125 9.6.3 Decryption Back-to-back Frames . . . . . . . . . . . . . . 45 126 9.7 Maximum Number of Tunnels . . . . . . . . . . . . . . . . 45 127 9.7.1 Maximum Configured Tunnels (MCT) . . . . . . . . . . . . . 45 128 9.7.2 Maximum Active Tunnels (MAT) . . . . . . . . . . . . . . . 46 129 9.8 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 46 130 9.8.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 46 131 9.8.2 IKE Setup Rate . . . . . . . . . . . . . . . . . . . . . . 47 132 9.8.3 IPsec Setup Rate . . . . . . . . . . . . . . . . . . . . . 47 133 9.9 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 48 134 9.9.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 48 135 9.9.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 49 136 9.10 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 49 137 10. IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 50 138 11. Security Considerations . . . . . . . . . . . . . . . . . 51 139 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 51 140 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 51 141 Normative References . . . . . . . . . . . . . . . . . . . 51 142 Informative References . . . . . . . . . . . . . . . . . . 53 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 144 Intellectual Property and Copyright Statements . . . . . . 55 146 1. Introduction 148 Despite the need to secure communications over a public medium there 149 is no standard method of performance measurement nor a standard in 150 the terminology used to develop such hardware/software solutions. 151 This results in varied implementations which challenge 152 interoperability and direct performance comparisons. Standarized 153 IPsec terminology and performance test methodologies will enable 154 users to decide if the IPsec device they select will withstand 155 relatively heavy loads of secured traffic. 157 To appropriately define the parameters and scope of this 158 document,this section will give a brief overview of the IPsec 159 standard: 161 2. IPsec Fundamentals 163 IPsec is a framework of open standards that provides data 164 confidentiality, data integrity, and data authenticity between 165 participating peers. IPsec provides these security services at the IP 166 layer. IPsec uses IKE to handle negotiation of protocols and 167 algorithms based on local policy, and to generate the encryption and 168 authentication keys to be used. IPsec can be used to protect one or 169 more data flows between a pair of hosts, between a pair of security 170 gateways, or between a security gateway and a host. The IPsec 171 protocol suite set of standards is documented in RFC's 2401 through 172 2412 and RFC 2451. The reader is assumed to be familiar with these 173 documents. Some Internet Drafts supersede these RFC's and will be 174 taken into consideration. 176 IPsec itself defines the following: 178 Authentication Header (AH): A security protocol, defined in 179 [RFC2402], which provides data authentication and optional 180 anti-replay services. AH ensures the integrity and data origin 181 authentication of the IP datagram as well as the invariant fields in 182 the outer IP header. 184 Encapsulating Security Payload (ESP): A security protocol, defined in 185 [RFC2406], which provides confidentiality, data origin 186 authentication, connectionless integrity, an anti-replay service and 187 limited traffic flow confidentiality. The set of services provided 188 depends on options selected at the time of Security Association (SA) 189 establishment and on the location of the implementation in a network 190 topology. ESP authenticates only headers and data after the IP 191 header. 193 Internet Key Exchange (IKE): A hybrid protocol which implements 194 Oakley and SKEME key exchanges inside the ISAKMP framework. While IKE 195 can be used with other protocols, its initial implementation is with 196 the IPsec protocol. IKE provides authentication of the IPsec peers, 197 negotiates IPsec security associations, and establishes IPsec keys. 199 The AH and ESP protocols each support two modes of operation: 200 transport mode and tunnel mode. In transport mode, two hosts provide 201 protection primarily for upper-layer protocols. The cryptographic 202 endpoints (where the encryption and decryption take place) are the 203 source and destination of the data packet. In IPv4, a transport mode 204 security protocol header appears immediately after the IP header and 205 before any higher-layer protocols (such as TCP or UDP). 207 In the case of AH in transport mode, all upper-layer information is 208 protected, and all fields in the IPv4 header excluding the fields 209 typically are modified in transit. The fields of the IPv4 header that 210 are not included are, therefore, set to 0 before applying the 211 authentication algorithm. These fields are as follows: 213 * TOS 214 * TTL 215 * Header Checksum 216 * Offset 217 * Flags 219 In the case of ESP in transport mode, security services are provide 220 only for the higher-layer protocols, not for the IP header. A tunnel 221 is a vehicle for encapsulating packets inside a protocol that is 222 understood at the entry and exit points of a given network. These 223 entry and exit points are defined as tunnel interfaces. 225 Tunnel mode can be supported by data packet endpoints as well as by 226 intermediate security gateways. In tunnel mode, there is an "outer" 227 IP header that specifies the IPsec processing destination, plus an 228 "inner" IP header that specifies the ultimate destination for the 229 packet. The source address in the outer IP header is the initiating 230 cryptographic endpoint; the source address in the inner header is the 231 true source address of the packet. The security protocol header 232 appears after the outer IP header and before the inner IP header. 234 If AH is employed in tunnel mode, portions of the outer IP header are 235 given protection (those same fields as for transport mode, described 236 earlier in this section), as well as all of the tunneled IP packet 237 (that is, all of the inner IP header is protected as are the 238 higher-layer protocols). If ESP is employed, the protection is 239 afforded only to the tunneled packet, not to the outer header. 241 2.1 IPsec Operation 243 2.1.1 Security Associations 245 The concept of a Security Association (SA) is fundamental to IPsec. 246 An SA is a relationship between two or more entities that describes 247 how the entities will use security services to communicate securely. 248 The SA includes: an encryption algorithm, an authentication algorithm 249 and a shared session key. 251 Because an SA is unidirectional, two SAs (one in each direction) are 252 required to secure typical, bidirectional communication between two 253 entities. The security services associated with an SA can be used for 254 AH or ESP, but not for both. If both AH and ESP protection is applied 255 to a traffic stream, two (or more) SAs are created for each direction 256 to protect the traffic stream. 258 The SA is uniquely identified by the security parameter index (SPI) 259 [RFC2406]. When a system sends a packet that requires IPsec 260 protection, it looks up the SA in its database and applies the 261 specified processing and security protocol (AH/ESP), inserting the 262 SPI from the SA into the IPsec header. When the IPsec peer receives 263 the packet, it looks up the SA in its database by destination 264 address, protocol, and SPI and then processes the packet as required. 266 2.1.2 Key Management 268 IPsec uses cryptographic keys for authentication/integrity and 269 encryption services. Both manual and automatic distribution of keys 270 is supported. IKE is specified as the public-key-based approach for 271 automatic key management. 273 IKE authenticates each peer involved in IPsec, negotiates the 274 security policy, and handles the exchange of session keys. IKE is a 275 hybrid protocol, combining parts of the following protocols to 276 negotiate and derive keying material for SAs in a secure and 277 authenticated manner: 279 1. ISAKMP (Internet Security Association and Key Management 280 Protocol), which provides a framework for authentication and key 281 exchange but does not define them. ISAKMP is designed to be key 282 exchange independent; it is designed to support many different 283 key exchanges. 285 2. Oakley, which describes a series of key exchanges, called modes, 286 and details the services provided by each (for example, perfect 287 forward secrecy for keys, identity protection, and 288 authentication). [RFC2412] 290 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 291 describes a versatile key exchange technique that provides 292 anonymity, reputability, and quick key refreshment. 294 IKE creates an authenticated, secure tunnel between two entities and 295 then negotiates the security association for IPsec. This is performed 296 in two phases. 298 In Phase 1, the two unidirectional SA's establish a secure, 299 authenticated channel with which to communicate. Phase 1 has two 300 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 301 provides identity protection. When identity protection is not needed, 302 Aggressive Mode can be used. The completion of Phase 1 an IKE SA is 303 established. 305 The following attributes are used by IKE and are negotiated as part 306 of the IKE SA: 308 o Encryption algorithm. 310 o Hash algorithm. 312 o Authentication method (digital signature, public-key encryption, 313 or pre-shared key). 315 o Diffie-Hellman group information. 317 After the attributes are negotiated, both parties must be 318 authenticated to each other. IKE supports multiple authentication 319 methods. At this time, the following mechanisms are generally 320 implemented: 322 o Preshared keys. The same key is pre-installed on each host. IKE 323 peers authenticate each other by computing and sending a keyed 324 hash of data that includes the preshared key. If the receiving 325 peer can independently create the same hash using its preshared 326 key, it knows that both parties must share the same secret, and 327 thus the other party is authenticated. 329 o Public key cryptography. Each party generates a pseudo-random 330 number (a nonce) and encrypts it and its ID using the other 331 party's public key. The ability for each party to compute a keyed 332 hash containing the other peer's nonce and ID, decrypted with the 333 local private key, authenticates the parties to each other. This 334 method does not provide nonrepudiation; either side of the 335 exchange could plausibly deny that it took part in the exchange. 337 o Digital signature. Each device digitally signs a set of data and 338 sends it to the other party. This method is similar to the 339 public-key cryptography approach except that it provides 340 nonrepudiation. 342 Note that both digital signature and public-key cryptography require 343 the use of digital certificates to validate the public/private key 344 mapping. IKE allows the certificate to be accessed independently or 345 by having the two devices explicitly exchange certificates as part of 346 IKE. Both parties must have a shared session key to encrypt the IKE 347 tunnel. The Diffie-Hellman protocol is used to agree on a common 348 session key. 350 In Phase 2 of the process, IPsec SAs are negotiated on behalf of 351 services such as IPsec AH or ESP. IPsec uses a different shared key 352 than does IKE. The IPsec shared key can be derived by using 353 Diffie-Hellman again or by refreshing the shared secret derived from 354 the original Diffie-Hellman exchange that generated the IKE SA by 355 hashing it with nonces. After this step is complete, the IPsec SAs 356 are established. Now the data traffic can be exchanged with the 357 negotiated IPsec parameters. The completion of Phase 2 is called an 358 IPsec SA. 360 3. Document Scope 362 The primary focus of this document is to establish useful performance 363 testing terminology for IPsec devices that support IKEv1. We want to 364 constrain the terminology specified in this document to meet the 365 requirements of the Methodology for Benchmarking IPSec Devices 366 documented test methodologies. The testing will be constrained to 367 devices acting as IPsec gateways and will pertain to both IPsec 368 tunnel and transport mode. 370 Any testing involving interoperability and/or conformance issues, 371 L2TP, GRE, 2547 (MPLS VPNs), multicast, and anything that does not 372 specifically relate to the establishment and tearing down of IPsec 373 tunnels is specifically out of scope. It is assumed that all relevant 374 networking parameters that facilitate in the running of these tests 375 are pre-configured (this includes at a minimum ARP caches and routing 376 tables). This document will encompass updates to AH, ESP and NAT 377 Traversal. 379 4. Definition Format 381 The definition format utilized by this document is described in 382 [RFC1242], Section 2. 384 Term to be defined. 386 Definition: 388 The specific definition for the term. 390 Discussion: 392 A brief discussion of the term, its application, or other 393 information that would build understanding. 395 Issues: 397 List of issues or conditions that affect this term. This field can 398 present items the may impact the term's related methodology or 399 otherwise restrict its measurement procedures. 401 [Measurement units:] 403 Units used to record measurements of this term. This field is 404 mandatory where applicable. This field is optional in this 405 document. 407 [See Also:] 409 List of other terms that are relevant to the discussion of this 410 term. This field is optional in this document. 412 5. Key Words to Reflect Requirements 414 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 415 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 416 document are to be interpreted as described in RFC 2119. RFC 2119 417 defines the use of these key words to help make the intent of 418 standards track documents as clear as possible. While this document 419 uses these keywords, this document is not a standards track document. 421 6. Existing Definitions 423 It is recommended that readers consult [RFC1242], [RFC2544] and 424 [RFC2285] before making use of this document. These and other IETF 425 Benchmarking Methodology Working Group (BMWG) router and switch 426 documents contain several existing terms relevant to benchmarking the 427 performance of IPsec devices. The conceptual framework established in 428 these earlier RFCs will be evident in this document. 430 This document also draws on existing terminology defined in other 431 BMWG documents. Examples include, but are not limited to: 433 Throughput [RFC 1242, section 3.17] 434 Latency [RFC 1242, section 3.8] 435 Frame Loss Rate [RFC 1242, section 3.6] 436 Forwarding Rates [RFC 2285, section 3.6] 437 Loads [RFC 2285, section 3.5] 439 Note: "DUT/SUT" refers to a metric that may be applicable to a DUT 440 (Device Under Test) or an SUT (System Under Test). 442 7. Term Definitions 444 7.1 Tunnel 446 The term "tunnel" is often used in a variety of contexts. To avoid 447 any discrepancies, in this document we define the following 448 distinctions between the word "tunnel": 450 "IKE Tunnel": (ISAKMP/IKE SA, IKE Phase 1 SA, Phase 1 SA) One simplex 451 Phase 1 IKE SA, which is sometimes is also referred to as ISAKMP or 452 IKE SA, IKE Phase 1 SA, or Phase 1 SA. An IKE Tunnel between IPSec 453 devices facilitates a mechanism for secure negotiation of Phase 1 454 properties and 2 SA's needed for protected data transport. 456 "IPsec SA": (IPsec SA, IKE Phase 2 SA) One simplex IKE Phase 2 SA, 457 which is also referred to as an IPsec SA or IKE Phase 2 SA. 459 "IPsec Tunnel": In the case of simplex communication, a single phase 460 2 SA. In the more likely case where bidirectional communication is 461 needed it is a pair of Phase 2 SA's, one for each direction. Unless 462 stated otherwise, bidirectional communication is always assumed. The 463 IPSec Tunnel will protect the data traffic flowing between IPSec 464 devices. 466 "Tunnel": The combination of one IKE Tunnel and one IPsec Tunnel i.e. 467 a single Phase 1 SA and a pair of Phase 2 SA's (for bidirectional 468 communication). 470 7.1.1 Configured Tunnel 472 Definition: 474 A tunnel that is present in the IPSec device's configuration but 475 does not have any SA's in the SADB. 477 Discussion: 479 Several steps are required before a Tunnel can be used to actually 480 trasport data. The very first step would be to configure the 481 tunnel in the IPsec device. In that way packet classification can 482 make a decision if it is required to start negotiating SA's. At 483 this time there are no SA's associated with the Tunnel. 485 Issues: 487 N/A 489 See Also: 491 Tunnel, Established Tunnel, Active Tunnel, Terminated Tunnel 493 7.1.2 Established Tunnel 495 Definition: 497 A Tunnel that has completed Phase 1 and Phase 2 SA negotiations 498 but is otherwise idle. 500 Discussion: 502 A second step needed to ensure that a Tunnel can transport data is 503 the Phase 1 and Phase 2 negotiation phase. After the packet 504 classification process has asserted that a packet requires 505 security services, the negotation is started to obtain both Phase 506 1 and Phase 2 SA's. After this is completed the tunnel is called 507 'Established'. Note that at this time there is still no traffic 508 flowing through the Tunnel. 510 Issues: 512 In the case of manually keyed tunnels, there is no distinction 513 between a Configured Tunnel or an Established Tunnel since there 514 is no negotiation required with these type of Tunnels and the 515 Tunnel is Established at time of Configuration since all keying 516 information is known at that point. 518 See Also: 520 Tunnel, Configured Tunnel, Active Tunnel, Terminated Tunnel 522 7.1.3 Active Tunnel 523 Definition: 525 A tunnel that has completed Phase 1 and Phase 2 SA negotiations 526 and is transmitting data. 528 Discussion: 530 When a Tunnel is Established it is ready to transport data 531 traffic, and we call the tunnel 'Active'. 533 Issues: 535 N/A 537 See Also: 539 Tunnel, Configured Tunnel, Established Tunnel, Terminated Tunnel 541 7.1.4 Terminated Tunnel 543 Definition: 545 A tunnel that has relinquished all it's SA's and is not 546 transmitting data anymore. 548 Discussion: 550 At the point where it is no longer required to provide security 551 services between IPsec devices, first the Phase 2 SA's are 552 released after which the Phase 1 SA is deleted and the Tunnel is 553 no longer. After all resources (SA's) are (in most cases 554 volountary released) the Tunnel returns to a 'Configured' state. 556 Issues: 558 Note that manually keyed tunnels never can be in a Terminated 559 state. The only way to prevent data forwarding over a manually 560 keyed tunnel is to deconfigure the Tunnel. 562 See Also: 564 Tunnel, Configured Tunnel, Established Tunnel, Active Tunnel 566 7.2 IPsec 567 Definition: 569 IPsec or IP Security protocol suite which comprises a set of 570 standards used to provide security services at the IP layer. 572 Discussion: 574 IPsec is a large framework of protocols that offer authentication, 575 authenticity and encryption services to the IP and/or upper layer 576 protocols. The major components of the protocol suite are IKE, 577 used for key exchanges, and IPsec protocols such as AH and ESP, 578 which use the exchanged keys to protect payload traffic. 580 Issues: 582 N/A 584 See Also: 586 IPsec Device, IKE, ISAKMP, ESP, AH 588 7.3 IPsec Device 590 Definition: 592 Any implementation that has the ability to process data flows 593 according to the IPsec protocol suite specifications. 595 Discussion: 597 Implementations can be grouped by 'external' properties (e.g. 598 software vs. hardware implementations) but more important is the 599 subtle differences that implementations may have with relation to 600 the IPsec Protocol Suite. Not all implementations will cover all 601 RFC's that encompass the IPsec Protocol Suite, but the majority 602 will support a large subset of features described in the suite, 603 nor will all implementations utilize all of the cryptographic 604 functions listed in the RFCs. 606 In that context, any implementation, that supports basic IP layer 607 security services as described in the IPsec protocol suite shall 608 be called an IPsec Device. 610 Issues: 612 Due to the fragmented nature of the IPsec Protocol Suite RFC's, it 613 is possible that IPsec implementations will not be able to 614 interoperate. Therefore it is important to know which features and 615 options are implemented in the IPsec Device. 617 See Also: 619 IPsec 621 7.3.1 Initiator 623 Definition: 625 IPsec devices which start the negotiation of IKE Phase 1 or IKE 626 Phase 2 tunnels. 628 Discussion: 630 When a traffic flow is offered at an IPSec device and it is 631 determined that the flow must be protected, but there is no tunnel 632 yet, it is the responsibility of the IPsec device to start a 633 negotiation process. This process will establish an IKE Phase 1 SA 634 and one or more IKE phase 2 SA's, eventually resulting in secured 635 data transport. The device that takes the action to start this 636 negotiation process will be called an Initiator. Note that an IKE 637 Phase 1 initiator, does not necessarily become an IKE Phase 2 638 initiator. 640 Issues: 642 IPsec devices/implementations can always be both an initiator as 643 well as a responder. The distinction is useful from a test 644 perspective. 646 See Also: 648 Responder, IKE, IPsec 650 7.3.2 Responder 652 Definition: 654 IPsec devices which reply to the incoming initiators IKE Phase 1 655 or Phase 2 tunnel requests and process these messages in order to 656 establish a tunnel. 658 Discussion: 660 When an initiator attempts to establish SAs with another IPsec 661 device, this peer will need to evaluate the proposals made by the 662 initiator and either accept or deny them. In the former case, the 663 traffic flow will be decrypted according to the negotiated 664 parameters. Such a device will be called a Responder. 666 Issues: 668 IPsec devices/implementations can usually be both an initiator as 669 well as a responder. The distinction is useful from a test 670 perspective. 672 See Also: 674 Initiator, IKE 676 7.3.3 IPsec Client 678 Definition: 680 IPsec Devices that will only act as an Initiator. 682 Discussion: 684 In some situations it is not needed or prefered to have an IPsec 685 device respond to an inbound tunnel request. In the case of e.g. 686 road warriors or home office scenarios the only property needed 687 from the IPsec device is the ability to securely connect to a 688 remote private network. The IPsec Client will set up one or more 689 Tunnels to an IPSec Server on the network that needs to be 690 accessed and to provide the required security services. IPsec 691 clients are generally used to connect remote users in a secure 692 fashion over the Internet to a private network. 694 Issues: 696 N/A 698 See Also: 700 IPsec device, IPsec Server, Initiator, Responder 702 7.3.4 IPsec Server 704 Definition: 706 IPSec Devices that can both act as an Initiator as well as a 707 Responder. 709 Discussion: 711 IPSec Servers are mostly positioned at private network edges and 712 provide several functions : 714 Responds to tunnel setup request from IPSec Clients. 716 Responds to tunnel setup request from other IPSec devices/ 717 Initiators. 719 Initiate tunnels to other IPSec servers inside or outside the 720 private network. 722 Issues: 724 IPsec Servers are also sometimes referred to as 'concentrators'. 726 See Also: 728 IPsec Device, IPsec Client, Initiator, Responder 730 7.4 ISAKMP 732 Definition: 734 The Internet Security Association and Key Management Protocol, 735 which provides a framework for authentication and key exchange but 736 does not define them. ISAKMP is designed to be key exchange 737 independent; it is designed to support many different key 738 exchanges. ISAKMP is defined in [RFC2407]. 740 Discussion: 742 Though ISAKMP is only a framework for the IPsec standard key 743 management protocol, it is often misused and interchanged with the 744 term 'IKE', which is an implementation of ISAKMP. The term ISAKMP 745 SA is used by some vendors while others use IKE SA. Both refer to 746 IKE Phase 1 SA. 748 Issues: 750 N/A 752 See Also: 754 IKE 756 7.5 IKE 758 Definition: 760 A hybrid protocol, defined in [RFC2409], from the following 3 761 protocols: 763 * ISAKMP (Internet Security Association and Key Management 764 Protocol), which provides a framework for authentication and 765 key exchange but does not define them. ISAKMP is designed to be 766 key exchange independent; it is designed to support many 767 different key exchanges. 769 * Oakley, which describes a series of key exchanges, called 770 modes, and details the services provided by each (for example, 771 perfect forward secrecy for keys, identity protection, and 772 authentication). [RFC2412] 774 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 775 describes a versatile key exchange technique that provides 776 anonymity, reputability, and quick key refreshment. 778 Discussion: 780 Note that IKE is an optional protocol within the IPsec framework 781 and that tunnels also can be manually keyed resulting in hardwired 782 SA's as configured by the administrator. 784 Issues: 786 During the first IPsec deployment experiences, ambiguities were 787 found in the IKEv1 specification, which lead to interoperability 788 problems. To resolve these issues, IKEv1 is being updated by 789 IKEv2. 791 See Also: 793 ISAKMP, IPsec 795 7.6 Security Association (SA) 797 Definition: 799 A simplex (unidirectional) logical connection, created for 800 security purposes. All traffic traversing an SA is provided the 801 same security processing. In IPsec, an SA is an Internet layer 802 abstraction implemented through the use of AH or ESP. [RFC2401] 804 Discussion: 806 A set of policy and key(s) used to protect information. It is a 807 negotiation agreement between two IPsec devices, specifically the 808 Initiator and Responder. 810 Issues: 812 N/A 814 See Also: 816 Initiator, Responder 818 7.7 IKE Phase 1 820 Definition: 822 The shared policy and key(s) used by negotiating peers to set up a 823 secure authenticated "control channel" for further IKE 824 communications. 826 Discussion: 828 Note that IKE is an optional protocol within the IPsec framework 829 and keys can also be manually configured. 831 Issues: 833 In other documents can be referenced as ISAKMP SA or IKE SA. 835 See Also: 837 IKE, ISAKMP 839 7.7.1 Phase 1 Main Mode 841 Definition: 843 Main Mode is an instantiation of the ISAKMP Identity Protect 844 Exchange, defined in [RFC2409]. Upon successful completion it 845 results in the establishment of an IKE Phase 1 SA. 847 Discussion: 849 IKE Main Mode use 3 distinct message pairs, for a total of 6 850 messages. The first two messages negotiate policy; the next two 851 represent Diffie-Hellman public values and ancillary data (e.g. 852 nonces); and the last two messages authenticate the Diffie-Hellman 853 Exchange. The authentication method negotiated as part of the 854 initial IKE Phase 1 influence the composition of the payloads but 855 not their purpose. 857 Issues: 859 N/A 861 See Also: 863 ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 865 7.7.2 Phase 1 Aggressive Mode 867 Definition: 869 Aggressive Mode is an instantiation of the ISAKMP Aggressive 870 Exchange, defined in [RFC2409]. Upon successful completion it 871 results in the establishment of an IKE Phase 1 SA. 873 Discussion: 875 IKE Aggressive Mode uses 3 messages. The first two messages 876 negotiate policy, exchange Diffie-Hellman public values and 877 ancillary data necessary for the exchange, and identities. In 878 addition the second message authenticates the Responder. The third 879 message authenticates the Initiator and provides proof of 880 participation in the exchange. 882 Issues: 884 For IKEv1 the standard specifies that all implementations use both 885 main and agressive mode, however, it is common to use only main 886 mode. 888 See Also: 890 ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 892 7.8 IKE Phase 2 894 Definition: 896 Protocol which upon successful completion establishes the shared 897 keys used by negotiating peers to set up a secure "data channel" 898 for IPsec. 900 Discussion: 902 The main purpose of Phase 2 is to produce the key for the IPsec 903 tunnel. Phase 2 is also used to regenerate the key being used for 904 IPsec (called "rekeying"), as well as for exchanging informational 905 messages. 907 Issues: 909 In other documents also referenced as IPsec SA. 911 See Also: 913 IKE Phase 1, ISAKMP, IKE 915 7.8.1 Phase 2 Quick Mode 917 Definition: 919 A SA negotiation and an exchange of nonces that provide replay 920 protection. 922 Discussion: 924 Quick Mode is not a complete exchange itself (it is bound to a 925 phase 1 exchange), but is used as part of the SA negotiation 926 process (phase 2) to derive keying material and negotiate shared 927 policy for non-ISAKMP SA's. The ISAKMP SA protects the information 928 exchanged along with Quick Mode, i.e. all payloads except the 929 ISAKMP header are encrypted. Also, an optional Key Exchange 930 payload can be exchanged to allow for an additional Diffie-Hellman 931 exchange, PFS and exponentiation per Quick Mode. 933 Issues: 935 N/A 937 See Also: 939 ISAKMP, IKE, IKE Phase 2 941 7.8.2 IPsec Tunnel 943 Definition: 945 A bidirectional IPsec SA which is set up as part of IKE phase 2. 946 It creates the secure data exchange channel. 948 Discussion: 950 Manually keyed IPsec tunnels differ from tunnels that are 951 negotiated by IKE in that there is no setup time for them, which 952 would have an effect on tunnel setup rate. For this reason some 953 metrics will be eliminated from the test methodology matrix, 954 specific to manually keyed IPsec tunnels, i.e. Phase 1 Setup Rate. 956 Issues: 958 N/A 960 See Also: 962 IPsec, IKE, IKE Phase 2 964 7.9 Iterated Tunnels 966 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 967 The bundles are divided into two major groups : 969 7.9.1 Nested Tunnels 971 Definition: 973 An SA bundle consisting of two or more 'tunnel mode' SA's. 975 Discussion: 977 The process of nesting tunnels can theoretically be repeated 978 multiple times (for example, tunnels can be many levels deep), but 979 for all practical purposes, most implementations limit the level 980 of nesting. Nested tunnels can use a mix of AH and ESP 981 encapsulated traffic. 983 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 984 | | | | 985 | | | | 986 | +----{SA1 (ESP tunnel)}----+ | 987 | | 988 +--------------{SA2 (AH tunnel)}---------------+ 990 In the IP Cloud a packet would have a format like this : 991 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 993 Nested tunnels can be deployed to provide additional security on 994 already secured traffic. A typical example of this would be that 995 the inner gateways (GW2 and GW3) are securing traffic between two 996 branch offices and the outer gateways (GW1 & GW4) add an 997 additional layer of security between departments within those 998 branch offices. 1000 Issues: 1002 N/A 1004 See Also: 1006 Transport Adjacency, IPsec Tunnel 1008 7.9.2 Transport Adjacency 1010 Definition: 1012 An SA bundle consisting of two or more transport mode SA's. 1014 Discussion: 1016 Transport adjacency is a form of tunnel nesting. In this case two 1017 or more transport mode IPsec tunnels are set side by side to 1018 enhance applied security properties. 1020 Transport adjacency can be used with a mix of AH and ESP tunnels 1021 although some combinations are not preferred. If AH and ESP are 1022 mixed, the ESP tunnel should always encapsulate the AH tunnel. The 1023 reverse combination is a valid combination but doesn't make 1024 cryptographical sense. 1026 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1027 | | | | 1028 | | | | 1029 | +------{SA1 (ESP transport)}--------+ | 1030 | | 1031 +-------------{SA2 (AH transport)}--------------+ 1033 In the IP Cloud a packet would have a format like this : 1034 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 1036 Issues: 1038 This is rarely used. 1040 See Also: 1042 Nested Tunnels, IPsec Tunnel 1044 7.10 Transform protocols 1046 Definition: 1048 Encryption and authentication algorithms that provide 1049 cryptograhical services to the IPsec Protocols. 1051 Discussion: 1053 Some algorithms run significantly slower than others. For example, 1054 TripleDES encryption is one third as fast as DES encryption. 1056 Issues: 1058 N/A 1060 See Also: 1062 Authentication protocols, Encryption protocols 1064 7.10.1 Authentication Protocols 1066 Definition: 1068 Algorithms which provide data integrity and data source 1069 authentication. 1071 Discussion: 1073 Authentication protocols provide no confidentiality. Commonly used 1074 authentication algorithms/protocols are: 1076 * MD5-HMAC 1077 * SHA-HMAC 1078 * AES-HMAC 1080 Issues: 1082 SHA-HMAC is thought to be more secure than MD5-HMAC and is often 1083 used. AES-HMAC is still fairly new and not in common use yet. 1085 See Also: 1087 Transform protocols, Encryption protocols 1089 7.10.2 Encryption Protocols 1091 Definition: 1093 Algorithms which provide data confidentiality. 1095 Discussion: 1097 Encryption protocols provide no authentication. Commonly used 1098 encryption algorithms/protocols are: 1100 * NULL encryption 1101 * DES-CBC 1102 * 3DES-CBC 1103 * AES-CBC 1104 Issues: 1106 Null option is a valid encryption mechanism although it reverts to 1107 use of IPsec back to message authenticity but only for upper layer 1108 protocols, and is commonly used. 1110 DES has been officially deprecated by NIST, though it is still 1111 mandated RFC and is still commonly implemented and used due to 1112 it's speed advantage over 3DES. 1114 See Also: 1116 Transform protocols, Authentication protocols 1118 7.11 IPSec Protocols 1120 Definition: 1122 A suite of protocols which provide a framework of open standards 1123 that provides data confidentiality, data integrity, and data 1124 authenticity between participating peers at the IP layer. The 1125 IPsec protocol suite set of standards is documented in RFC's 2401 1126 through 2412 and RFC 2451. 1128 Discussion: 1130 The IPsec Protocol suite is modular and forward compatible. The 1131 protocols that comprise the IPsec protocol suite can be replaced 1132 with new versions of those protocols as the older versions become 1133 obsolete. For example, IKEv2 will soon replace IKEv1. 1135 Issues: 1137 N/A 1139 See Also: 1141 AH, ESP 1143 7.11.1 Authentication Header (AH) 1145 Definition: 1147 Provides authentication and data integrity (including replay 1148 protection) security services [RFC2402]. 1150 Discussion: 1152 The AH protocol supports both modes of operation; tunnel mode and 1153 transport mode. If AH is employed in tunnel mode, portions of the 1154 outer IP header are given protection, as well as all of the 1155 tunneled IP packet (that is, all of the inner IP header is 1156 protected as are the higher-layer protocols). In the case of AH in 1157 transport mode, all upper-layer information is protected, and all 1158 fields in the IPv4 header excluding the fields typically are 1159 modified in transit. 1161 Original IPv4 packet : 1162 [IP ORIG][L4 HDR][PAYLOAD] 1163 In transport mode : 1164 [IP ORIG][AH][L4 HDR][PAYLOAD] 1165 In tunnel mode : 1166 [IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD] 1168 Issues: 1170 AH is rarely used/implemented. 1172 See Also: 1174 Transform protocols, IPsec protocols, Encapsulated Security 1175 Payload 1177 7.11.2 Encapsulated Security Payload (ESP) 1179 Definition: 1181 Provides three essential components needed for secure data 1182 exchange: authentication, integrity (including replay protection) 1183 and confidentiality [RFC2406]. 1185 Discussion: 1187 The ESP protocol supports both modes of operation; tunnel mode and 1188 transport mode. If ESP is employed in tunnel mode, the protection 1189 is afforded only to the tunneled packet, not to the outer header 1190 In the case of ESP in transport mode, security services are 1191 provided only for the higher-layer protocols, not for the IP 1192 header. 1194 Original IPv4 packet : 1195 [IP ORIG][L4 HDR][PAYLOAD] 1196 In transport mode : 1197 [IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] 1198 In tunnel mode : 1199 [IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] 1201 Issues: 1203 N/A 1205 See Also: 1207 Transform protocols, IPsec protocols, Authentication Header 1209 7.12 Selectors 1211 Definition: 1213 A criteria used by a classification mechanism required to classify 1214 traffic flows when IPsec is used to protect traffic between 1215 networks which are proxied between two or more participating 1216 peers. After classification, a decision can be made if the traffic 1217 needs to be encrypted/decrypted and how this should be done. 1218 Selectors classify specific IP packets that require IPsec 1219 processing. Selectors also define those packets that must be 1220 discarded or passed along without modification. These are flexible 1221 objects that can match on source and destination addresses, range 1222 of IP addresses, wildcard addresses, different protocols, and 1223 different port numbers (like FTP) within a protocol. 1225 Discussion: 1227 The selectors are a set of fields that will be extracted from the 1228 network and transport layer headers that provide the ability to 1229 classify the traffic flow and later associate it with an SA. 1231 Issues: 1233 Both sides must agree exactly on both the networks being 1234 protected, and they both must agree on how to describe the 1235 networks (range, subnet, addresses). This is a common point of 1236 non-interoperability. 1238 7.13 NAT Traversal (NAT-T) 1240 Definition: 1242 The capability to support IPsec functionality in the presence of 1243 NAT devices. 1245 Discussion: 1247 NAT-Traversal requires some modifications to IKE. Specifically, in 1248 phase 1, it requires detecting if the other end supports 1249 NAT-Traversal, and detecting if there are one or more NAT 1250 instances along the path from host to host. In IKE Quick Mode, 1251 there is a need to negotiate the use of UDP encapsulated IPsec 1252 packets. 1254 NAT-T also describes how to transmit the original source and 1255 destination addresses to the other end if needed. The original 1256 source and destination addresses are used in transport mode to 1257 incrementally update the TCP/IP checksums so that they will match 1258 after the NAT transform (The NAT cannot do this, because the TCP/ 1259 IP checksum is inside the UDP encapsulated IPsec packet). 1261 Issues: 1263 N/A 1265 See Also: 1267 IKE 1269 7.14 IP Compression 1271 Definition: 1273 A mechanism as defined in [RFC2393] that reduces the size of the 1274 payload that needs to be encrypted. 1276 Discussion: 1278 IP payload compression is a protocol to reduce the size of IP 1279 datagrams. This protocol will increase the overall communication 1280 performance between a pair of communicating hosts/gateways 1281 ("nodes") by compressing the datagrams, provided the nodes have 1282 sufficient computation power, through either CPU capacity or a 1283 compression coprocessor, and the communication is over slow or 1284 congested links. 1286 IP payload compression is especially useful when encryption is 1287 applied to IP datagrams. Encrypting the IP datagram causes the 1288 data to be random in nature, rendering compression at lower 1289 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1290 ineffective. If both compression and encryption are required, 1291 compression must be applied before encryption. 1293 Issues: 1295 N/A 1297 7.15 Security Context 1299 Definition: 1301 A security context is a collection of security parameters that 1302 describe the characteristics of the path that a tunnel will take, 1303 all of the tunnel parameters and the effects it has on the 1304 underlying protected traffic. Security Context encompasses 1305 protocol suite and security policy(ies). 1307 Discussion: 1309 In order to fairly compare multiple IPsec devices it is imperative 1310 that an accurate overview is given of all security parameters that 1311 were used to establish tunnels and to secure the traffic between 1312 protected networks. Security Context is not a metric; it is 1313 included to accurately reflect the test environment variables when 1314 reporting the methodology results. To avoid listing too much 1315 information when reporting metrics, we have divided the security 1316 context into an IKE context and an IPsec context. 1318 When merely discussing the behavior of traffic flows through IPsec 1319 devices, an IPsec context MUST be provided. In other cases the 1320 scope of a discussion or report may focus on a more broad set of 1321 behavioral characteristics of the IPsec device, the both and IPsec 1322 and an IKE context MUST be provided. 1324 The IPsec context MUST consist of the following elements: 1326 * Number of IPsec tunnels 1328 * IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio) 1330 * IPsec protocol 1332 * IPsec mode (tunnel or transport) 1333 * Authentication protocol used by IPsec 1335 * Encryption protocol used by IPsec (if applicable) 1337 * IPsec SA lifetime (traffic and time based) 1339 The IPsec Context MAY also list: 1341 * Selectors 1343 * Fragmentation handling 1345 The IKE Context MUST consist of the following elements: 1347 * Number of IKE tunnels. 1349 * Authentication protocol used by IKE 1351 * Encryption protocol used by IKE 1353 * Key exchange mechanism (pre-shared key, certificate authority, 1354 etc ...) 1356 * Key size (if applicable) 1358 * Diffie-Hellman group 1360 * IKE SA lifetime (time based) 1362 * Keepalive, heartbeat or DPD values [DPD] 1364 * IP Compression [RFC2393] 1366 * PFS Diffie-Hellman group 1368 The IKE context MAY also list: 1370 * Phase 1 mode (main or aggressive) 1372 * Available bandwidth and latency to Certificate Authority server 1373 (if applicable) 1375 Issues: 1377 A Security Context will be an important element in describing the 1378 environment where protected traffic is traveling through. 1380 See Also: 1382 IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, 1383 Selectors, IPsec Tunnel 1385 8. Performance Metrics 1387 8.1 Tunnels Per Second (TPS) 1389 Definition: 1391 Tunnels Per Second; the measurement unit for the Tunnel Setup Rate 1392 tests. The rate that tunnels are established per second. 1394 Discussion: 1396 According to rfc 2401 two tunnels cannot be established between 1397 the same gateways with the same selectors. This is to prevent 1398 overlapping tunnels. If overlapping tunnels are attempted, the 1399 error will take longer than if the tunnel setup was successful. 1400 For this reason, a unique pair of selector sets are required for 1401 TPS testing. 1403 Issues: 1405 A unique pair of selector sets are required for TPS testing. 1407 See Also: 1409 Tunnel Setup Rate Behavior; Tunnel Setup Rate, IKE Setup Rate, 1410 IPsec Setup Rate 1412 8.2 Tunnel Rekeys Per Seconds (TRPS) 1414 Definition: 1416 A metric that quantifies the number of tunnel rekey's per seconds 1417 a DUT can correctly process. 1419 Discussion: 1421 This metric will be will be primary used with Tunnel Rekey 1422 behavior tests. 1424 TRPS will provide a metric used to see system behavior under 1425 stressful conditions where large volumes of tunnels are being 1426 rekeyed at the same time or in a short timespan. 1428 Issues: 1430 N/A 1432 See Also: 1434 Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate 1436 8.3 Tunnel Attempts Per Second (TAPS) 1438 Definition: 1440 A metric that quantifies the number of valid or invalid tunnel 1441 (both Phase 1 or Phase 2) establishment requests per second. 1443 Discussion: 1445 This metric can be used to measure IKE DOS Resilience behavior 1446 test. 1448 TAPS provides an important metric to validate the stability of a 1449 platform, if stressed with valid (large number of IPsec tunnel 1450 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1451 any style) tunnel establishment requests. 1453 Issues: 1455 If the TAPS increases, the TPS usually decreases, due to burdening 1456 of the DUT with the DOS attack traffic. 1458 9. Test Definitions 1460 9.1 Framesizes 1462 9.1.1 Layer3 clear framesize 1464 Definition: 1466 The total size of the unencrypted L3 PDU. 1468 Discussion: 1470 In relation to IPsec this is the size of the IP header and it�s 1471 payload. It SHALL NOT include any encapsulations that MAY be 1472 applied before the PDU is processed for encryption. 1474 For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload. 1476 Measurement Units: 1478 Bytes 1480 Issues: 1482 N/A 1484 See Also: 1486 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1487 Encrypted Framesize. 1489 9.1.2 Layer3 encrypted framesize 1491 Definition: 1493 The total size of the encrypted L3 PDU. 1495 Discussion: 1497 The size of the IP packet and it�s payload after encapsulations 1498 MAY be applied and the PDU is being processed by the transform. 1500 For example, after a tunnel mode ESP 3DES/SHA1 transform has been 1501 applied an unencrypted or clear layer3 framesize of 46 bytes 1502 Becomes 96 bytes: 1504 20 bytes outer IP header (tunnel mode) 1505 4 bytes SPI (ESP header) 1506 4 bytes Sequence (ESP Header) 1507 8 bytes IV (IOS ESP-3DES) 1508 46 bytes payload 1509 0 bytes pad (ESP-3DES 64 bit) 1510 1 byte Pad length (ESP Trailer) 1511 1 byte Next Header (ESP Trailer) 1512 12 bytes ESP-HMAC SHA1 96 digest 1513 Measurement Units: 1515 Bytes 1517 Issues: 1519 N/A 1521 See Also: 1523 Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted 1524 Framesize. 1526 9.1.3 Layer2 clear framesize 1528 Definition: 1530 The total size of the unencrypted L2 PDU. 1532 Discussion: 1534 This is the Layer 3 clear framesize plus all the layer2 overhead. 1535 In the case of Ethernet this would be 18 bytes. 1537 For example, a 46 byte Layer3 clear framesize packet would become 1538 64 Bytes after Ethernet Layer2 overhead is added: 1540 6 bytes destination mac address 1541 6 bytes source mac address 1542 2 bytes length/type field 1543 46 bytes layer3 (IP) payload 1544 4 bytes FCS 1546 Measurement Units: 1548 Bytes 1550 Issues: 1552 If it is not mentioned explicitly what kind of framesize is used, 1553 the layer2 clear framesize will be the default. 1555 See Also: 1557 Layer3 clear framesize, Layer2 encrypted framesize, Layer2 1558 encrypted framesize. 1560 9.1.4 Layer2 encrypted framesize 1562 Definition: 1564 The total size of the encrypted L2 PDU. 1566 Discussion: 1568 This is the Layer 3 encrypted framesize plus all the layer2 1569 overhead. In the case of Ethernet this would be 18 bytes. 1571 For example, a 96 byte Layer3 encrypted framesize packet would 1572 become 114 bytes after Ethernet Layer2 overhead is added: 1574 6 bytes destination mac address 1575 6 bytes source mac address 1576 2 bytes length/type field 1577 96 bytes layer3 (IPsec) payload 1578 4 bytes FCS 1580 Measurement Units: 1582 Bytes 1584 Issues: 1586 N/A 1588 See Also: 1590 Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear 1591 Framesize 1593 9.2 Internet Mix Traffic (IMIX) 1595 Definition: 1597 A traffic pattern consisting of a preset mixture of framesizes 1598 used to emulate real-world traffic scenarios in a testing 1599 environment. 1601 Discussion: 1603 IMIX traffic patterns can be used to measure different forwarding 1604 behaviors of the IPsec device with pseudo live traffic. 1606 Several facilities have collected and reported traffic 1607 distribution by monitoring live Internet links. The study 1608 concluded that in a simulation environment, a small mix of packets 1609 in a preset ratio can resemble to a certain degree the live 1610 traffic that was monitored during the study. One of the mixes is 1611 called (simple) and consists of 7 parts 64 byte packets, 4 parts 1612 570 byte packets and 1 1518 byte packet. 1614 Issues: 1616 The ratio of frame sizes sent and traffic distribution to be 1617 determined by the test methodology. 1619 9.3 Throughput 1621 9.3.1 IPsec Tunnel Throughput 1623 Definition: 1625 The forwarding rate through an IKE/IPsec tunnel at which none of 1626 the offered frames are dropped by the device under test. 1628 Discussion: 1630 The IPsec Tunnel Throughput is almost identically defined as 1631 Throughput in [RFC1242], section 3.17. The only difference is that 1632 the throughput is measured with a traffic flow getting encrypted 1633 and decrypted by an IPsec device. The Tunnel Throughput is an 1634 end-to-end measurement and is intended to characterize end-user 1635 forwarding behavior. 1637 The metric can be represented in two variants depending on where 1638 measurement is taken in the SUT. One can look at throughput from a 1639 cleartext point of view i.e. find the forwarding rate where 1640 clearpackets no longer get dropped. This forwarding rate can be 1641 recalculated with an encrypted framesize to represent the 1642 encryption forwarding rate. The latter is the preferred method of 1643 representation. 1645 Measurement Units: 1647 Packets per seconds (pps), Mbps 1649 Issues: 1651 N/A 1653 See Also: 1655 IPsec Encryption Throughput, IPsec Decryption Throughput 1657 9.3.2 IPsec Encryption Throughput 1659 Definition: 1661 The maximum encryption rate through an IPsec tunnel at which none 1662 of the offered cleartext frames are dropped by the device under 1663 test. 1665 Discussion: 1667 Since encryption throughput is not necessarily equal to the 1668 decryption throughput, both of the forwarding rates must be 1669 measured independently. The independent forwarding rates have to 1670 measured with the help of an IPsec aware test device that can 1671 originate and terminate IPsec and IKE tunnels. As defined in 1672 [RFC1242], measurements should be taken with an assortment of 1673 frame sizes. 1675 Measurement Units: 1677 Packets per seconds (pps), Mbps 1679 Issues: 1681 N/A 1683 See Also: 1685 IPsec Tunnel Throughput, IPsec Decryption Throughput 1687 9.3.3 IPsec Decryption Throughput 1689 Definition: 1691 The maximum decryption rate through an IPsec tunnel at which none 1692 of the offered encrypted frames are dropped by the device under 1693 test. 1695 Discussion: 1697 Since encryption throughput is not necessarily equal to the 1698 decryption throughput, both of the forwarding rates must be 1699 measured independently. 1701 The independent forwarding rates have to be measured with the help 1702 of an IPsec aware test device that can originate and terminate 1703 IPsec and IKE tunnels. As defined in [RFC1242], measurements 1704 should be taken with an assortment of frame sizes. 1706 Measurement Units: 1708 Packets per seconds (pps), Mbps 1710 Issues: 1712 Recommended test frame sizes will be addressed in future 1713 methodology document. 1715 See Also: 1717 IPsec Tunnel Throughput, IPsec Encryption Throughput 1719 9.4 Latency 1721 9.4.1 Tunnel Latency 1723 Definition: 1725 Tunnel Latency is the delay introduced when sending traffic 1726 through an established IPsec tunnel between two interconnected 1727 IPsec devices. 1729 Discussion: 1731 The Tunnel Latency is the time interval starting when the end of 1732 the first bit of the cleartext frame reaches the input interface 1733 of the encrypting router, and ending when the start of the first 1734 bit of the cleartext frame is seen on the output interface of the 1735 decrypting router. 1737 Measurement Units: 1739 Time units with enough precision to reflect latency measurement. 1741 Issues: 1743 N/A 1745 See Also: 1747 IPsec Tunnel Encryption Latency, IPsec Tunnel Decryption Latency 1749 9.4.2 IPsec Tunnel Encryption Latency 1751 Definition: 1753 The IPsec Tunnel Encryption Latency is the time interval starting 1754 when the end of the first bit of the cleartext frame reaches the 1755 input interface, through an IPsec tunnel, and ending when the 1756 start of the first bit of the encrypted output frame is seen on 1757 the output interface. 1759 Discussion: 1761 IPsec Tunnel Encryption latency is the latency introduced when 1762 encrypting traffic through an IPsec tunnel. 1764 Like encryption/decryption throughput, it is not always the case 1765 that encryption latency equals the decryption latency. Therefore a 1766 distinction between the two has to be made in order to get a more 1767 accurate view of where the latency is the most pronounced. 1769 The independent encryption/decryption latencies have to be 1770 measured with the help of an IPsec aware test device that can 1771 originate and terminate IPsec and IKE tunnels. As defined in 1772 [RFC1242], measurements should be taken with an assortment of 1773 frame sizes. 1775 Measurement Units: 1777 Time units with enough precision to reflect latency measurement. 1779 Issues: 1781 N/A 1783 See Also: 1785 IPsec Tunnel Decryption Latency 1787 9.4.3 IPsec Tunnel Decryption Latency 1789 Definition: 1791 The IPsec Tunnel decryption Latency is the time interval starting 1792 when the end of the first bit of the encrypted frame reaches the 1793 input interface, through an IPsec tunnel, and ending when the 1794 start of the first bit of the decrypted output frame is seen on 1795 the output interface. 1797 Discussion: 1799 IPsec Tunnel decryption latency is the latency introduced when 1800 decrypting traffic through an IPsec tunnel. Like encryption/ 1801 decryption throughput, it is not always the case that encryption 1802 latency equals the decryption latency. Therefore a distinction 1803 between the two has to be made in order to get a more accurate 1804 view of where the latency is the most pronounced. 1806 The independent encryption/decryption latencies have to be 1807 measured with the help of an IPsec aware test device that can 1808 originate and terminate IPsec and IKE tunnels. As defined in 1809 [RFC1242], measurements should be taken with an assortment of 1810 frame sizes. 1812 Measurement Units: 1814 Time units with enough precision to reflect latency measurement. 1816 Issues: 1818 N/A 1820 See Also: 1822 IPsec Tunnel Encryption Latency 1824 9.4.4 Time To First Packet 1826 Definition: 1828 The Time To First Packet (TTFP) is the time required process an 1829 cleartext packet when no tunnel is present. 1831 Discussion: 1833 The TTFP addresses the issue of responsiveness of an IPsec device 1834 by looking how long it take to transmit a packet over a not yet 1835 established tunnel path. The TTFP MUST include the time to set up 1836 the tunnel, triggered by the traffic flow (both phase 1 and phase 1837 2 setup times are included) and the time it takes to encrypt and 1838 decrypt the packet on a corresponding peer. 1840 It must be noted that it is highly unlikely that the first packet 1841 of the traffic flow will be the packet that will be used to 1842 measure the TTFP. There MAY be several protocol layers in the 1843 stack before the tunnel is formed and the traffic is forwarded, 1844 hence several packets COULD be lost during negotiation, for 1845 example, ARP and/or IKE. 1847 Measurement Units: 1849 Time units with enough precision to reflect a TTFP measurement. 1851 Issues: 1853 N/A 1855 9.5 Frame Loss Rate 1857 9.5.1 Tunnel Frame Loss Rate 1859 Definition: 1861 Percentage of cleartext frames that should have been forwarded 1862 through an IPsec tunnel under steady state (constant) load but 1863 were dropped. 1865 Discussion: 1867 DUT's will always have an inherent forwarding limitation. This 1868 will be more pronounced when IPsec is employed on the DUT. The 1869 instant that a Tunnel is established and offered traffic that will 1870 flow through that tunnel at a constant rate, the possibility 1871 exists that either the offerred traffic rate at the tunnel is too 1872 high to be transported. This traffic may not be successful through 1873 the IPsec tunnel and not all cleartext packets will traverse an 1874 established tunnel between two interconnected IPsec devices. In 1875 that case, some percentage of the traffic will be dropped. This 1876 drop percentage is called the Tunnel Frame Loss Rate. 1878 Measurement Units: 1880 Percent (%) 1882 Issues: 1884 N/A 1886 See Also: 1888 IPsec Tunnel Encryption Frame Loss Rate, IPsec Tunnel Decryption 1889 Frame Loss Rate 1891 9.5.2 IPsec Tunnel Encryption Frame Loss Rate 1893 Definition: 1895 Percentage of cleartext frames that should have been encrypted 1896 through an IPsec tunnel under steady state (constant) load but 1897 were dropped. 1899 Discussion: 1901 DUT's will always have an inherent forwarding limitation. This 1902 will be more pronounced when IPsec is employed on the DUT. The 1903 moment that a Tunnel is established and traffic is offered at a 1904 given rate that will flow through that tunnel, there is a 1905 possibility that the offered traffic rate at the tunnel is too 1906 high to be transported through the IPsec tunnel and not all 1907 cleartext packets will get encrypted. In that case, some 1908 percentage of the cleartext traffic will be dropped. This drop 1909 percentage is called the IPsec Tunnel Encryption Frame Loss Rate. 1911 Measurement Units: 1913 Percent (%) 1915 Issues: 1917 N/A 1919 See Also: 1921 IPsec Tunnel Decryption Frame Loss Rate 1923 9.5.3 IPsec Tunnel Decryption Frame Loss Rate 1925 Definition: 1927 Percentage of encrypted frames that should have been decrypted 1928 through an IPsec tunnel under steady state (constant) load but 1929 were dropped. 1931 Discussion: 1933 A DUT will also have an inherent forwarding limitation when 1934 decrypting packets. When established tunnel encrypted traffic is 1935 offered at a costant load, there might be a possibility that the 1936 IPsec Device that needs to decrypt the traffic will not be able to 1937 perfom this action on all of the packets due to limitations of the 1938 decryption performance. The percentage of encrypted frames that 1939 would get dropped under these conditions is called the IPsec 1940 Tunnel Decryption Frame Loss Rate. 1942 Measurement Units: 1944 Percent (%) 1946 Issues: 1948 N/A 1950 See Also: 1952 IPsec Tunnel Encryption Frame Loss Rate 1954 9.6 Back-to-back Frames 1956 9.6.1 Tunnel Back-to-back Frames 1958 Definition: 1960 A burst of cleartext frames, offered at a constant load that can 1961 be sent through an IPsec tunnel without losing a single frame. 1963 Discussion: 1965 Tunnel back-to-back frames is the measure of the maximum burst 1966 size of cleartext frames that can be sent through an established 1967 tunnel between two interconnected IPsec devices. 1969 Measurement Units: 1971 Number of N-octet frames in burst. 1973 Issues: 1975 Recommended test frame sizes will be addressed in future 1976 methodology document. 1978 See Also: 1980 Encryption Back-to-back frames, Decryption Back-to-back frames 1982 9.6.2 Encryption Back-to-back Frames 1984 Definition: 1986 A burst of cleartext frames, offered at a constant load that can 1987 be sent through an IPsec tunnel without losing a single encrypted 1988 frame. 1990 Discussion: 1992 Encryption back-to-back frames is the measure of the maximum burst 1993 size that a device can handle for encrypting traffic that it 1994 receives as plaintext. Since it is not necessarily the case that 1995 the maximum burst size a DUT can handle for encryption is equal to 1996 the maximum burst size a DUT can handle for decryption, both of 1997 these capabilities must be measured independently. The encryption 1998 back-to-back frame measurement has to be measured with the help of 1999 an IPsec aware test device that can decrypt the traffic to 2000 determine the validity of the encrypted frames. 2002 Measurement Units: 2004 Number of N-octet frames in burst. 2006 Issues: 2008 Recommended test frame sizes will be addressed in future 2009 methodology document. 2011 See Also: 2013 Decryption Back-to-back frames 2015 9.6.3 Decryption Back-to-back Frames 2017 Definition: 2019 The number of encrypted frames, offered at a constant load, that 2020 can be sent through an IPsec tunnel without losing a single 2021 cleartext frame. 2023 Discussion: 2025 Decryption back-to-back frames is the measure of the maximum burst 2026 size that a device can handle for decrypting traffic that it 2027 receives as encrypted traffic. Since it is not necessarily the 2028 case that the maximum burst size a DUT can handle for decryption 2029 is equal to the maximum burst size a DUT can handle for 2030 encryption, both of these capabilities must be measured 2031 independently. The decryption back-to-back frame measurement has 2032 to be measured with the help of an IPsec aware test device that 2033 can determine the validity of the decrypted frames. 2035 Measurement Units: 2037 Number of N-octet frames in burst. 2039 Issues: 2041 Recommended test frame sizes will be addressed in future 2042 methodology document. 2044 See Also: 2046 Encryption back-to-back frames 2048 9.7 Maximum Number of Tunnels 2050 9.7.1 Maximum Configured Tunnels (MCT) 2052 Definition: 2054 Maximum number of tunnels that can be configured on an IPsec 2055 device. 2057 Discussion: 2059 Every implementation will have a limitation on the number of 2060 tunnels that can be configured. Most implementation will allow an 2061 operator to configure more tunnels then actually can be 2062 established. 2064 Measurement Units: 2066 Tunnels 2068 See Also: 2070 Configured Tunnel 2072 9.7.2 Maximum Active Tunnels (MAT) 2074 Definition: 2076 Maximum number of active tunnels that can be maintained on an 2077 IPsec device. 2079 Discussion: 2081 Although a number of tunnels may be configured on the IPsec 2082 device, this will not automatically mean that all of these tunnels 2083 can be established and can pass traffic. Each of the tunnels that 2084 need to pass traffic have to be active tunnels. 2086 Measurement Units: 2088 Tunnels 2090 See Also: 2092 Active Tunnel 2094 9.8 Tunnel Setup Rate Behavior 2096 9.8.1 Tunnel Setup Rate 2098 Definition: 2100 The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second 2101 that an IPsec device can successfully establish. 2103 Discussion: 2105 The tunnel setup rate SHOULD be measured at varying number of 2106 tunnels on the DUT. Several factors may influence Tunnel Setup 2107 Rate, such as: TAPS rate, Background Load on crypto link (clear 2108 traffic), Already established tunnels, Authentication method: 2109 pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used 2110 (when using RSA/DSS) 2112 Measurement Units: 2114 Tunnels Per Second (TPS) 2116 Issues: 2118 N/A 2120 See Also: 2122 IKE Setup Rate, IPsec Setup Rate 2124 9.8.2 IKE Setup Rate 2126 Definition: 2128 The maximum number of IKE tunnels per second that an IPsec device 2129 can be observed to successfully establish. 2131 Discussion: 2133 The tunnel setup rate SHOULD be measured at varying number of 2134 tunnels on the DUT. 2136 Measurement Units: 2138 Tunnels Per Second (TPS) 2140 Issues: 2142 N/A 2144 See Also: 2146 Tunnel Setup Rate, IPsec Setup Rate 2148 9.8.3 IPsec Setup Rate 2150 Definition: 2152 The maximum number of IPsec tunnels per second that a IPsec device 2153 can be observed to successfully establish. 2155 Discussion: 2157 The tunnel setup rate SHOULD be measured at varying number of 2158 tunnels on the DUT. 2160 Measurement Units: 2162 Tunnels Per Second (TPS) 2164 Issues: 2166 N/A 2168 See Also: 2170 Tunnel Rekey 2172 9.9 Tunnel Rekey 2174 9.9.1 Phase 1 Rekey Rate 2176 Definition: 2178 The interval necessary for a particular Phase 1 to re-establish 2179 after the previous Phase 1 lifetime (hard or soft) has expired. 2181 Discussion: 2183 Although many implementations will usually derive new keying 2184 material before the old keys expire, there may still be a period 2185 of time where frames get dropped before the phase 1 and subsequent 2186 phase 2 tunnels are successfully (re)established. To measure the 2187 phase 1 rekey rate, the measurement will require an IPsec aware 2188 test device to act as a responder when negotiating the new phase 1 2189 key. 2191 Measurement Units: 2193 Time units with enough precision to reflect rekey rate 2194 measurement. 2196 Issues: 2198 N/A 2200 See Also: 2202 Phase 2 Rekey Rate 2204 9.9.2 Phase 2 Rekey Rate 2206 Definition: 2208 The interval necessary for a particular Phase 2 to re-establish 2209 after the previous Phase 2 lifetime (hard or soft) has expired. 2211 Discussion: 2213 The test methodology report must specify if PFS is enabled in 2214 reported security context. 2216 Measurement Units: 2218 Time units with enough precision to reflect rekey rate 2219 measurement. 2221 Issues: 2223 N/A 2225 See Also: 2227 Phase 1 Rekey Rate 2229 9.10 Tunnel Failover Time (TFT) 2231 Definition: 2233 Time required to recover all tunnels on a stanby IPsec device, 2234 after a catastrophic failure occurs on the active IPsec device. 2236 Discussion: 2238 Recovery time required to re-establish all tunnels and reroute all 2239 traffic on a standby node or other failsafe system after a failure 2240 has occurred. Failure can include but are not limited to a 2241 catastrophic IPsec Device failure, a encryption engine failure, 2242 link outage. The recovery time is delta between the point of 2243 failure and the time the first packet is seen on the last restored 2244 tunnel on the backup device. 2246 Measurement Units: 2248 Time units with enough precision to reflect Tunnel Failover Time. 2250 Issues: 2252 N/A 2254 10. IKE DOS Resilience Rate 2256 Definition: 2258 The IKE Denial Of Service (DOS) Resilience Rate provides a rate of 2259 invalid or mismatching IKE tunnels setup attempts at which it is 2260 no longer possible to set up a valid IKE tunnel. 2262 Discussion: 2264 The IKE DOS Resilience Rate will provide a metric to how robust 2265 and hardened an IPsec device is against malicious attempts to set 2266 up a tunnel. 2268 IKE DOS attacks can pose themselves in various forms and do not 2269 necessarily have to have a malicious background. It is sufficient 2270 to make a typographical error in a shared secret in an IPsec 2271 aggregation device to be susceptible to a large number of IKE 2272 attempts that need to be turned down. Due to the intense 2273 computational nature of an IKE exchange every single IKE tunnel 2274 attempt that has to be denied will take a non-negligible time an a 2275 CPU in the IPsec device. 2277 Depending on how many of these messages have to be processed, a 2278 system might end up in a state that it is only doing key exchanges 2279 and burdening the CPU for any other processes that might be 2280 running in the IPsec device. At this point it will be no longer 2281 possible to process a valid IKE tunnel setup request and thus IKE 2282 DOS is in effect. 2284 Measurement Units: 2286 Tunnel Attempts Per Seconds (TAPS) 2288 Issues: 2290 N/A 2292 11. Security Considerations 2294 As this document is solely for the purpose of providing test 2295 benchmarking terminology and describes neither a protocol nor a 2296 protocol's implementation; there are no security considerations 2297 associated with this document. 2299 12. Acknowledgements 2301 The authors would like to acknowledge the following individual for 2302 their help and participation of the compilation and editing of this 2303 document: Debby Stopp, Ixia. 2305 13. Contributors 2307 The authors would like to acknowledge the following individual for 2308 their significant help, guidance, and contributions to this document: 2309 Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. 2311 Normative References 2313 [RFC1242] Bradner, S., "Benchmarking terminology for network 2314 interconnection devices", RFC 1242, July 1991. 2316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2317 Requirement Levels", BCP 14, RFC 2119, March 1997. 2319 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2320 Switching Devices", RFC 2285, February 1998. 2322 [RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP 2323 Payload Compression Protocol (IPComp)", RFC 2393, December 2324 1998. 2326 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2327 Internet Protocol", RFC 2401, November 1998. 2329 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2330 2402, November 1998. 2332 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2333 ESP and AH", RFC 2403, November 1998. 2335 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2336 ESP and AH", RFC 2404, November 1998. 2338 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 2339 Algorithm With Explicit IV", RFC 2405, November 1998. 2341 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2342 Payload (ESP)", RFC 2406, November 1998. 2344 [RFC2407] Piper, D., "The Internet IP Security Domain of 2345 Interpretation for ISAKMP", RFC 2407, November 1998. 2347 [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet 2348 Security Association and Key Management Protocol 2349 (ISAKMP)", RFC 2408, November 1998. 2351 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2352 (IKE)", RFC 2409, November 1998. 2354 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2355 Its Use With IPsec", RFC 2410, November 1998. 2357 [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 2358 Document Roadmap", RFC 2411, November 1998. 2360 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2361 2412, November 1998. 2363 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2364 Algorithms", RFC 2451, November 1998. 2366 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 2367 Network Interconnect Devices", RFC 2544, March 1999. 2369 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 2370 1999. 2372 [I-D.ietf-ipsec-ikev2] 2373 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2374 draft-ietf-ipsec-ikev2-11 (work in progress), October 2375 2003. 2377 [I-D.ietf-ipsec-nat-t-ike] 2378 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 2379 draft-ietf-ipsec-nat-t-ike-07 (work in progress), 2380 September 2003. 2382 [I-D.ietf-ipsec-udp-encaps] 2383 Huttunen, A., "UDP Encapsulation of IPsec Packets", 2384 draft-ietf-ipsec-udp-encaps-06 (work in progress), January 2385 2003. 2387 [I-D.ietf-ipsec-nat-reqts] 2388 Aboba, B. and W. Dixon, "IPsec-NAT Compatibility 2389 Requirements", draft-ietf-ipsec-nat-reqts-06 (work in 2390 progress), October 2003. 2392 [I-D.ietf-ipsec-properties] 2393 Krywaniuk, A., "Security Properties of the IPsec Protocol 2394 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2395 July 2002. 2397 [FIPS.186-1.1998] 2398 National Institute of Standards and Technology, "Digital 2399 Signature Standard", FIPS PUB 186-1, December 1998, 2400 . 2402 Informative References 2404 [Designing Network Security] 2405 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2406 Published: May 07, 1999; Copyright: 1999, 1999. 2408 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2409 Mechanism for Internet", from IEEE Proceedings of the 2410 1996 Symposium on Network and Distributed Systems 2411 Security, URI http://www.research.ibm.com/security/ 2412 skeme.ps, 1996. 2414 [DPD] "DPD draft-ietf-ipsec-dpd-02", , URI http://www.ietf.org/ 2415 internet-drafts/draft-ietf-ipsec-dpd-02.txt. 2417 Authors' Addresses 2419 Michele Bustos 2420 IXIA 2421 26601 W. Agoura Rd. 2422 Calabasas, CA 91302 2423 US 2425 Phone: +1 (818)444-3244 2426 EMail: mbustos@ixiacom.com 2427 Tim Van Herck 2428 Cisco Systems, Inc. 2429 170 West Tasman Drive 2430 San Jose, CA 95134-1706 2431 US 2433 Phone: +1 (408)527-2461 2434 EMail: herckt@cisco.com 2436 Merike Kaeo 2437 Merike, Inc. 2438 123 Ross Street 2439 Santa Cruz, CA 95060 2440 US 2442 Phone: +1 (831)818-4864 2443 EMail: kaeo@merike.com 2445 Intellectual Property Statement 2447 The IETF takes no position regarding the validity or scope of any 2448 intellectual property or other rights that might be claimed to 2449 pertain to the implementation or use of the technology described in 2450 this document or the extent to which any license under such rights 2451 might or might not be available; neither does it represent that it 2452 has made any effort to identify any such rights. Information on the 2453 IETF's procedures with respect to rights in standards-track and 2454 standards-related documentation can be found in BCP-11. Copies of 2455 claims of rights made available for publication and any assurances of 2456 licenses to be made available, or the result of an attempt made to 2457 obtain a general license or permission for the use of such 2458 proprietary rights by implementors or users of this specification can 2459 be obtained from the IETF Secretariat. 2461 The IETF invites any interested party to bring to its attention any 2462 copyrights, patents or patent applications, or other proprietary 2463 rights which may cover technology that may be required to practice 2464 this standard. Please address the information to the IETF Executive 2465 Director. 2467 Full Copyright Statement 2469 Copyright (C) The Internet Society (2003). All Rights Reserved. 2471 This document and translations of it may be copied and furnished to 2472 others, and derivative works that comment on or otherwise explain it 2473 or assist in its implementation may be prepared, copied, published 2474 and distributed, in whole or in part, without restriction of any 2475 kind, provided that the above copyright notice and this paragraph are 2476 included on all such copies and derivative works. However, this 2477 document itself may not be modified in any way, such as by removing 2478 the copyright notice or references to the Internet Society or other 2479 Internet organizations, except as needed for the purpose of 2480 developing Internet standards in which case the procedures for 2481 copyrights defined in the Internet Standards process must be 2482 followed, or as required to translate it into languages other than 2483 English. 2485 The limited permissions granted above are perpetual and will not be 2486 revoked by the Internet Society or its successors or assignees. 2488 This document and the information contained herein is provided on an 2489 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2490 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2491 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2492 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2493 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2495 Acknowledgment 2497 Funding for the RFC Editor function is currently provided by the 2498 Internet Society.