idnits 2.17.1 draft-ietf-bmwg-ipsec-term-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2512. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** The abstract seems to contain references ([RFC2285], [RFC1242], [RFC2544]), 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 (November 2005) is 6736 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 1062, but not defined == Missing Reference: 'GW2' is mentioned on line 1062, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 1062, but not defined == Missing Reference: 'GW3' is mentioned on line 1062, but not defined == Missing Reference: 'GW4' is mentioned on line 1062, but not defined == Missing Reference: 'ESP' is mentioned on line 1070, but not defined == Missing Reference: 'AH' is mentioned on line 1070, but not defined == Missing Reference: 'IP' is mentioned on line 1070, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 1070, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 1070, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 1070, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1323, but not defined == Unused Reference: 'RFC2119' is defined on line 2362, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 2378, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 2381, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 2384, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 2400, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 2403, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 2430, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2440, 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) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-dpd (ref. 'I-D.ietf-ipsec-dpd') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipsec-properties' Summary: 19 errors (**), 0 flaws (~~), 22 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group M. Kaeo 3 Internet-Draft Double Shot Security 4 Expires: May 5, 2006 T. Van Herck 5 Cisco Systems 6 M. Bustos 7 IXIA 8 November 2005 10 Terminology for Benchmarking IPsec Devices 11 draft-ietf-bmwg-ipsec-term-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 5, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This purpose of this document is to define terminology specific to 45 measuring the performance of IPsec devices. It builds upon the 46 tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF 47 Benchmarking Methodology Working Group (BMWG) documents used for 48 benchmarking routers and switches. This document seeks to extend 49 these efforts specific to the IPsec paradigm. The BMWG produces two 50 major classes of documents: Benchmarking Terminology documents and 51 Benchmarking Methodology documents. The Terminology documents 52 present the benchmarks and other related terms. The Methodology 53 documents define the procedures required to collect the benchmarks 54 cited in the corresponding Terminology documents. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7 61 2.1.1. Security Associations . . . . . . . . . . . . . . . . 7 62 2.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 7 63 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10 66 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 11 67 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13 72 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 14 73 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 14 74 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 15 75 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15 76 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 16 77 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17 79 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 18 80 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 18 81 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 19 82 7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 20 83 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 20 85 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 21 86 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 22 87 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 22 88 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23 89 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 23 90 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 24 91 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 25 92 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 25 93 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 26 94 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 27 95 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 27 96 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 28 97 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 29 98 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 30 99 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 30 100 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 33 102 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 103 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 34 104 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 34 105 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 35 106 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 35 107 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 108 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 10.1.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . 36 110 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 37 111 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 37 112 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 37 113 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 38 114 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 38 115 10.2.4. IPsec Fragmentation Throughput . . . . . . . . . . . . 39 116 10.2.5. IPsec Reassembly Throughput . . . . . . . . . . . . . 40 117 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 40 118 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 40 119 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 41 120 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 42 121 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 42 122 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 43 123 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 43 124 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 44 125 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 44 126 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 45 127 10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 46 128 10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 46 129 10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 46 130 10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 47 131 10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 48 132 10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 48 133 10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 49 134 10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 49 135 10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 50 136 10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 50 137 10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 51 138 10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 51 139 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 140 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 141 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52 142 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 143 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 144 14.2. Informative References . . . . . . . . . . . . . . . . . . 54 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 146 Intellectual Property and Copyright Statements . . . . . . . . . . 57 148 1. Introduction 150 Despite the need to secure communications over a public medium there 151 is no standard method of performance measurement nor a standard in 152 the terminology used to develop such hardware and software solutions. 153 This results in varied implementations which challenge 154 interoperability and direct performance comparisons. Standardized 155 IPsec terminology and performance test methodologies will enable 156 users to determine if the IPsec device they select will withstand 157 loads of secured traffic that meet their requirements. 159 To appropriately define the parameters and scope of this document, 160 this section will give a brief overview of the IPsec standard: 162 2. IPsec Fundamentals 164 IPsec is a framework of open standards that provides data 165 confidentiality, data integrity, and data origin authenticity between 166 participating peers. IPsec provides these security services at the 167 IP layer. IPsec uses IKE to handle negotiation of protocols and 168 algorithms based on local policy, and to generate the encryption and 169 authentication keys to be used. IPsec can be used to protect one or 170 more data flows between a pair of hosts, between a pair of security 171 gateways, or between a security gateway and a host. The IPsec 172 protocol suite set of standards is documented in RFC's [RFC2401] 173 through [RFC2412] and [RFC2451]. The reader is assumed to be 174 familiar with these documents. Some Internet Drafts supersede these 175 RFC's and will be taken into consideration. 177 IPsec itself defines the following: 179 Authentication Header (AH): A security protocol, defined in 180 [RFC2402], which provides data authentication and optional anti- 181 replay services. AH ensures the integrity and data origin 182 authentication of the IP datagram as well as the invariant fields in 183 the outer IP header. 185 Encapsulating Security Payload (ESP): A security protocol, defined in 186 [RFC2406], which provides confidentiality, data origin 187 authentication, connectionless integrity, an anti-replay service and 188 limited traffic flow confidentiality. The set of services provided 189 depends on options selected at the time of Security Association (SA) 190 establishment and on the location of the implementation in a network 191 topology. ESP authenticates only headers and data after the IP 192 header. 194 Internet Key Exchange (IKE): A hybrid protocol which implements 195 Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP 196 framework. While IKE can be used with other protocols, its initial 197 implementation is with the IPsec protocol. IKE provides 198 authentication of the IPsec peers, negotiates IPsec security 199 associations, and establishes IPsec keys. 201 The AH and ESP protocols each support two modes of operation: 202 transport mode and tunnel mode. In transport mode, two hosts provide 203 protection primarily for upper-layer protocols. The cryptographic 204 endpoints (where the encryption and decryption take place) are the 205 source and destination of the data packet. In IPv4, a transport mode 206 security protocol header appears immediately after the IP header and 207 before any higher-layer protocols (such as TCP or UDP). In IPv6, the 208 security protocol header appears after the base IP header and 209 selected extension headers. It may appear before or after 210 destination options but must appear before next layer protocols 211 (e.g., TCP, UDP, SCTP) 213 In the case of AH in transport mode, security services are provided 214 to selected portions of the IP header preceding the AH header, 215 selected portions of extension headers, and selected options 216 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 217 IPv6 Destination extension headers). Any fields in these headers/ 218 extension headers which are modified in transit are set to 0 before 219 applying the authentication algorithm. If a field is mutable, but 220 its value at the receiving IPsec peer is predictable, then that value 221 is inserted into the field before applying the cryptographic 222 algorithm. 224 In the case of ESP in transport mode, security services are provide 225 only for the higher-layer protocols, not for the IP header or any 226 extension headers preceding the ESP header. 228 A tunnel is a vehicle for encapsulating packets inside a protocol 229 that is understood at the entry and exit points of a given network. 230 These entry and exit points are defined as tunnel interfaces. 232 Both the AH and ESP protocols can be used in tunnel mode for data 233 packet endpoints as well as by intermediate security gateways. In 234 tunnel mode, there is an "outer" IP header that specifies the IPsec 235 processing destination, plus an "inner" IP header that specifies the 236 ultimate destination for the packet. The source address in the outer 237 IP header is the initiating cryptographic endpoint; the source 238 address in the inner header is the true source address of the packet. 239 The security protocol header appears after the outer IP header and 240 before the inner IP header. 242 If AH is employed in tunnel mode, portions of the new outer IP header 243 are given protection (those same fields as for transport mode, 244 described earlier in this section), as well as all of the tunneled IP 245 packet (that is, all of the inner IP header is protected as are the 246 higher-layer protocols). If ESP is employed, the protection is 247 afforded only to the tunneled packet, not to the new outer IP header. 249 2.1. IPsec Operation 251 2.1.1. Security Associations 253 The concept of a Security Association (SA) is fundamental to IPsec. 254 An SA is a relationship between two or more entities that describes 255 how the entities will use security services to communicate. The SA 256 includes: an encryption algorithm, an authentication algorithm and a 257 shared session key. 259 Because an SA is unidirectional, two SA's (one in each direction) are 260 required to secure typical, bidirectional communication between two 261 entities. The security services associated with an SA can be used 262 for AH or ESP, but not for both. If both AH and ESP protection is 263 applied to a traffic stream, two (or more) SA's are created for each 264 direction to protect the traffic stream. 266 The SA is uniquely identified by the Security Parameter Index (SPI) 267 [RFC2406]. When a system sends a packet that requires IPsec 268 protection, it looks up the SA in its database and applies the 269 specified processing and security protocol (AH/ESP), inserting the 270 SPI from the SA into the IPsec header. When the IPsec peer receives 271 the packet, it looks up the SA in its database by destination 272 address, protocol, and SPI and then processes the packet as required. 274 2.1.2. Key Management 276 IPsec uses cryptographic keys for authentication, integrity and 277 encryption services. Both manual provisioning and automatic 278 distribution of keys is supported. IKE is specified as the public- 279 key-based approach for automatic key management. 281 IKE authenticates each peer involved in IPsec, negotiates the 282 security policy, and handles the exchange of session keys. IKE is a 283 hybrid protocol, combining parts of the following protocols to 284 negotiate and derive keying material for SA's in a secure and 285 authenticated manner: 287 1. ISAKMP [RFC2408] (Internet Security Association and Key 288 Management Protocol), which provides a framework for 289 authentication and key exchange but does not define them. ISAKMP 290 is designed to be key exchange independent; it is designed to 291 support many different key exchanges. 293 2. Oakley [RFC2412], which describes a series of key exchanges, 294 called modes, and details the services provided by each (for 295 example, perfect forward secrecy for keys, identity protection, 296 and authentication). 298 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 299 describes a versatile key exchange technique that provides 300 anonymity, reputability, and quick key refreshment. 302 IKE creates an authenticated, secure tunnel between two entities and 303 then negotiates the security association for IPsec. This is 304 performed in two phases. 306 In Phase 1, the two unidirectional SA's establish a secure, 307 authenticated channel with which to communicate. Phase 1 has two 308 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 309 provides identity protection. When identity protection is not 310 needed, Aggressive Mode can be used. The completion of Phase 1 is 311 called an IKE SA. 313 The following attributes are used by IKE and are negotiated as part 314 of the IKE SA: 316 o Encryption algorithm. 318 o Hash algorithm. 320 o Authentication method (digital signature, public-key encryption or 321 pre-shared key). 323 o Diffie-Hellman group information. 325 After the attributes are negotiated, both parties must be 326 authenticated to each other. IKE supports multiple authentication 327 methods. The following mechanisms are generally implemented: 329 o Pre-shared keys: The same key is pre-installed on each host. IKE 330 peers authenticate each other by computing and sending a keyed 331 hash of data that includes the pre-shared key. If the receiving 332 peer can independently create the same hash using its preshared 333 key, it knows that both parties must share the same secret, and 334 thus the other party is authenticated. 336 o Public key cryptography: Each party generates a pseudo-random 337 number (a nonce) and encrypts it and its ID using the other 338 party's public key. The ability for each party to compute a keyed 339 hash containing the other peer's nonce and ID, decrypted with the 340 local private key, authenticates the parties to each other. This 341 method does not provide nonrepudiation; either side of the 342 exchange could plausibly deny that it took part in the exchange. 344 o Digital signature: Each device digitally signs a set of data and 345 sends it to the other party. This method is similar to the 346 public-key cryptography approach except that it provides 347 nonrepudiation. 349 Note that both digital signature and public-key cryptography require 350 the use of digital certificates to validate the public/private key 351 mapping. IKE allows the certificate to be accessed independently or 352 by having the two devices explicitly exchange certificates as part of 353 IKE. Both parties must have a shared session key to encrypt the IKE 354 tunnel. The Diffie-Hellman protocol is used to agree on a common 355 session key. 357 In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's 358 will be called IPsec SA's. These IPsec SA's use a different shared 359 key than that used for the IKE_SA. The IPsec SA shared key can be 360 derived by using Diffie-Hellman again or by refreshing the shared key 361 derived from the original Diffie-Hellman exchange that generated the 362 IKE_SA by hashing it with nonces. Once the shared key is derived and 363 additional communication parameters are negotiated, the IPsec SA's 364 are established and traffic can be exchanged using the negotiated 365 parameters. 367 3. Document Scope 369 The primary focus of this document is to establish useful performance 370 testing terminology for IPsec devices that support manual keying and 371 IKEv1. We want to constrain the terminology specified in this 372 document to meet the requirements of the Methodology for Benchmarking 373 IPsec Devices documented test methodologies. 375 Both IPv4 and IPv6 addressing will be taken into consideration. 377 The testing will be constrained to: 379 o Devices acting as IPsec gateways whose tests will pertain to both 380 IPsec tunnel and transport mode. 382 o Devices acting as IPsec end-hosts whose tests will pertain to both 383 IPsec tunnel and transport mode. 385 Any testing involving interoperability and/or conformance issues, 386 L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and 387 anything that does not specifically relate to the establishment and 388 tearing down of IPsec tunnels is specifically out of scope. It is 389 assumed that all relevant networking parameters that facilitate in 390 the running of these tests are pre-configured (this includes at a 391 minimum ARP caches, routing tables, neighbor tables, etc ...). 393 4. Definition Format 395 The definition format utilized by this document is described in 396 [RFC1242], Section 2. 398 Term to be defined. 400 Definition: 402 The specific definition for the term. 404 Discussion: 406 A brief discussion of the term, its application, or other 407 information that would build understanding. 409 Issues: 411 List of issues or conditions that affect this term. This field 412 can present items the may impact the term's related methodology or 413 otherwise restrict its measurement procedures. 415 [Measurement units:] 417 Units used to record measurements of this term. This field is 418 mandatory where applicable. This field is optional in this 419 document. 421 [See Also:] 423 List of other terms that are relevant to the discussion of this 424 term. This field is optional in this document. 426 5. Key Words to Reflect Requirements 428 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 429 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 430 document are to be interpreted as described in RFC 2119. RFC 2119 431 defines the use of these key words to help make the intent of 432 standards track documents as clear as possible. While this document 433 uses these keywords, this document is not a standards track document. 435 6. Existing Benchmark Definitions 437 It is recommended that readers consult [RFC1242], [RFC2544] and 438 [RFC2285] before making use of this document. These and other IETF 439 Benchmarking Methodology Working Group (BMWG) router and switch 440 documents contain several existing terms relevant to benchmarking the 441 performance of IPsec devices. The conceptual framework established 442 in these earlier RFC's will be evident in this document. 444 This document also draws on existing terminology defined in other 445 BMWG documents. Examples include, but are not limited to: 447 Throughput [RFC 1242, section 3.17] 448 Latency [RFC 1242, section 3.8] 449 Frame Loss Rate [RFC 1242, section 3.6] 450 Forwarding Rates [RFC 2285, section 3.6] 451 Loads [RFC 2285, section 3.5] 453 7. Definitions 455 7.1. IPsec 457 Definition: 459 IPsec or IP Security protocol suite which comprises a set of 460 standards used to provide security services at the IP layer. 462 Discussion: 464 IPsec is a framework of protocols that offer authentication, 465 integrity and encryption services to the IP and/or upper layer 466 protocols. The major components of the protocol suite are IKE, 467 used for key exchanges, and IPsec protocols such as AH and ESP, 468 which use the exchanged keys to protect payload traffic. 470 Issues: 472 N/A 474 See Also: 476 IPsec Device, IKE, ISAKMP, ESP, AH 478 7.2. ISAKMP 480 Definition: 482 The Internet Security Association and Key Management Protocol, 483 which provides a framework for authentication and key exchange but 484 does not define them. ISAKMP is designed to be key exchange 485 independent; it is designed to support many different key 486 exchanges. ISAKMP is defined in [RFC2407]. 488 Discussion: 490 Though ISAKMP is only a framework for the IPsec standard key 491 management protocol, it is often misused and interchanged with the 492 term 'IKE', which is an implementation of ISAKMP. 494 Issues: 496 When implementations refer to the term 'ISAKMP SA', it refers to 497 an IKE Phase 1 SA. 499 See Also: 501 IKE, Security Association 503 7.3. IKE 505 Definition: 507 A hybrid key management protocol that provides authentication of 508 the IPsec peers, negotiates IPsec SAs and establishes IPsec keys. 510 Discussion: 512 A hybrid protocol, defined in [RFC2409], from the following 3 513 protocols: 515 * ISAKMP (Internet Security Association and Key Management 516 Protocol), which provides a framework for authentication and 517 key exchange but does not define them. ISAKMP is designed to 518 be key exchange independent; it is designed to support many 519 different key exchanges. 521 * Oakley, which describes a series of key exchanges, called 522 modes, and details the services provided by each (for example, 523 perfect forward secrecy for keys, identity protection, and 524 authentication). [RFC2412] 526 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 527 describes a versatile key exchange technique that provides 528 anonymity, reputability, and quick key refreshment. 530 Note that IKE is an optional protocol within the IPsec framework. 531 IPsec SAs may also be manually configured. Manual keying is the 532 most basic mechanism to establish IPsec SAs between two IPsec 533 devices. However, it is not a scalable solution and often 534 manually configured keys are not changed on a periodic basis which 535 reduces the level of protection since the keys are effectively 536 static and as a result are more prone to various attacks. When 537 IKE is employed as a key management protocol, the keys are 538 automatically renegotiated on a user-defined basis (time and/or 539 traffic volume based) as part of the IKE rekeying mechanism. 541 Issues: 543 During the first IPsec deployment experiences, ambiguities were 544 found in the IKEv1 specification, which lead to interoperability 545 problems. To resolve these issues, IKEv1 is being updated by 546 IKEv2. 548 See Also: 550 ISAKMP, IPsec, Security Association 552 7.3.1. IKE Phase 1 554 Definition: 556 The shared policy and key(s) used by negotiating peers to 557 establish a secure authenticated "control channel" for further IKE 558 communications. 560 Discussion: 562 The IPsec framework mandates that SPI's are used to secure payload 563 traffic. If IKE is employed all SPI information will be exchanged 564 between the IPsec devices. This has to be done in a secure 565 fashion and for that reason IKE will set up a secure "control 566 channel" over which it can exchange this information. 568 Note that IKE is an optional protocol within the IPsec framework 569 and that SPI information can also be manually configured. 571 Issues: 573 In some documents often referenced as ISAKMP SA or IKE SA. 575 See Also: 577 IKE, ISAKMP 579 7.3.2. IKE Phase 1 Main Mode 581 Definition: 583 Main Mode is an instantiation of the ISAKMP Identity Protect 584 Exchange, defined in [RFC2409]. Upon successful completion it 585 results in the establishment of an IKE Phase 1 SA. 587 Discussion: 589 IKE Main Mode use 3 distinct message pairs, for a total of 6 590 messages. The first two messages negotiate policy; the next two 591 represent Diffie-Hellman public values and ancillary data (e.g. 592 nonces); and the last two messages authenticate the Diffie-Hellman 593 Exchange. The authentication method negotiated as part of the 594 initial IKE Phase 1 influence the composition of the payloads but 595 not their purpose. 597 Issues: 599 N/A 601 See Also: 603 ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 605 7.3.3. IKE Phase 1 Aggressive Mode 607 Definition: 609 Aggressive Mode is an instantiation of the ISAKMP Aggressive 610 Exchange, defined in [RFC2409]. Upon successful completion it 611 results in the establishment of an IKE Phase 1 SA. 613 Discussion: 615 IKE Aggressive Mode uses 3 messages. The first two messages 616 negotiate policy, exchange Diffie-Hellman public values and 617 ancillary data necessary for the exchange, and identities. In 618 addition the second message authenticates the Responder. The 619 third message authenticates the Initiator and provides proof of 620 participation in the exchange. 622 Issues: 624 For IKEv1 the standard specifies that all implementations use both 625 main and agressive mode, however, it is common to use only main 626 mode. 628 See Also: 630 ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 632 7.3.4. IKE Phase 2 634 Definition: 636 ISAKMP phase which upon successful completion establishes the 637 shared keys used by the negotiating peers to set up a secure "data 638 channel" for IPsec. 640 Discussion: 642 The main purpose of Phase 2 is to produce the key for the IPsec 643 tunnel. Phase 2 is also used for exchanging informational 644 messages. 646 Issues: 648 In other documents also referenced as IPsec SA. 650 See Also: 652 IKE Phase 1, ISAKMP, IKE 654 7.3.5. Phase 2 Quick Mode 656 Definition: 658 Quick Mode is an instanciation of IKE Phase 2. After successful 659 completion it will result in one or typically two or more IPsec 660 SA's 662 Discussion: 664 Quick Mode is used to negotiate the SA's and keys that will be 665 used to protect the user data. Three different messages are 666 exchanged, which are protected by the security parameters 667 negotiated by the IKE phase 1 exchange. An additional Diffie- 668 Hellman exchange may be performed if PFS (Perfect Forward Secrecy) 669 is enabled. 671 Issues: 673 N/A 675 See Also: 677 ISAKMP, IKE, IKE Phase 2 679 7.4. Security Association (SA) 681 Definition: 683 A set of policy and key(s) used to protect traffic flows that 684 require authentication and/or encryption services. It is a 685 negotiation agreement between two IPsec devices, specifically the 686 Initiator and Responder. 688 Discussion: 690 A simplex (unidirectional) logical connection that links a traffic 691 flow to a set of security parameters. All traffic traversing an 692 SA is provided the same security processing and will be subjected 693 to a common set of encryption and/or authentication algorithms. 694 In IPsec, an SA is an Internet layer abstraction implemented 695 through the use of AH or ESP as defined in [RFC2401]. 697 Issues: 699 N/A 701 See Also: 703 Initiator, Responder 705 7.5. Selectors 707 Definition: 709 A mechanism used for the classification of traffic flows that 710 require authentication and/or encryption services. 712 Discussion: 714 The selectors are a set of fields that will be extracted from the 715 network and transport layer headers that provide the ability to 716 classify the traffic flow and associate it with an SA. 718 After classification, a decision can be made if the traffic needs 719 to be encrypted/decrypted and how this should be done depending on 720 the SA linked to the traffic flow. Simply put, selectors classify 721 IP packets that require IPsec processing and those packets that 722 must be passed along without any intervention of the IPsec 723 framework. 725 Selectors are flexible objects that can match on ranges of source 726 and destination addresses and ranges of source and destination 727 ports. 729 Issues: 731 Both sides must agree exactly on both the networks being 732 protected, and they both must agree on how to describe the 733 networks (range, subnet, addresses). This is a common point of 734 non-interoperability. 736 7.6. IPsec Device 738 Definition: 740 Any implementation that has the ability to process data flows 741 according to the IPsec protocol suite specifications. 743 Discussion: 745 Implementations can be grouped by 'external' properties (e.g. 746 software vs. hardware implementations) but more important is the 747 subtle differences that implementations may have with relation to 748 the IPsec Protocol Suite. Not all implementations will cover all 749 RFC's that encompass the IPsec Protocol Suite, but the majority 750 will support a large subset of features described in the suite, 751 nor will all implementations utilize all of the cryptographic 752 functions listed in the RFC's. 754 In that context, any implementation, that supports basic IP layer 755 security services as described in the IPsec protocol suite shall 756 be called an IPsec Device. 758 Issues: 760 Due to the fragmented nature of the IPsec Protocol Suite RFC's, it 761 is possible that IPsec implementations will not be able to 762 interoperate. Therefore it is important to know which features 763 and options are implemented in the IPsec Device. 765 See Also: 767 IPsec 769 7.6.1. Initiator 771 Definition: 773 An IPsec device which starts the negotiation of IKE Phase 1 and 774 IKE Phase 2 SAs. 776 Discussion: 778 When a traffic flow is offered at an IPsec device and it is 779 determined that the flow must be protected, but there is no IPsec 780 tunnel to send the traffic through, it is the responsibility of 781 the IPsec device to start a negotiation process that will 782 instantiate the IPsec tunnel. This process will establish an IKE 783 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 784 eventually resulting in secured data transport. The device that 785 takes the action to start this negotiation process will be called 786 an Initiator. 788 Issues: 790 IPsec devices/implementations can be both an initiator as well as 791 a responder. The distinction is useful from a test perspective. 793 See Also: 795 Responder, IKE, IPsec 797 7.6.2. Responder 798 Definition: 800 An IPsec device which replies to incoming IKE Phase 1 and IKE 801 Phase 2 requests and processes these messages in order to 802 establish an IPsec tunnel. 804 Discussion: 806 When an initiator attempts to establish SA's with another IPsec 807 device, this peer will need to evaluate the proposals made by the 808 initiator and either accept or deny them. In the former case, the 809 traffic flow will be decrypted according to the negotiated 810 parameters. Such a device will be called a Responder. 812 Issues: 814 IPsec devices/implementations can usually be both an initiator as 815 well as a responder. The distinction is useful from a test 816 perspective. 818 See Also: 820 Initiator, IKE 822 7.6.3. IPsec Client 824 Definition: 826 IPsec Devices that will only act as an Initiator. 828 Discussion: 830 In some situations it is not needed or prefered to have an IPsec 831 device respond to an inbound IKE SA or IPsec SA request. In the 832 case of e.g. road warriors or home office scenarios the only 833 property needed from the IPsec device is the ability to securely 834 connect to a remote private network. The IPsec Client will 835 initiate one or more IPsec tunnels to an IPsec Server on the 836 network that needs to be accessed and to provide the required 837 security services. An IPsec client will silently drop and ignore 838 any inbound IPsec tunnel requests. IPsec clients are generally 839 used to connect remote users in a secure fashion over the Internet 840 to a private network. 842 Issues: 844 N/A 846 See Also: 848 IPsec device, IPsec Server, Initiator, Responder 850 7.6.4. IPsec Server 852 Definition: 854 IPsec Devices that can both act as an Initiator as well as a 855 Responder. 857 Discussion: 859 IPsec Servers are mostly positioned at private network edges and 860 provide several functions: 862 * Responds to IPsec tunnel setup request from IPsec Clients. 864 * Responds to IPsec tunnel setup request from other IPsec devices 865 (Initiators). 867 * Initiate IPsec tunnels to other IPsec servers inside or outside 868 the private network. 870 Issues: 872 IPsec Servers are also sometimes referred to as 'VPN 873 Concentrators'. 875 See Also: 877 IPsec Device, IPsec Client, Initiator, Responder 879 7.7. Tunnels 881 The term "tunnel" is often used in a variety of contexts. To avoid 882 any discrepancies, in this document, the following distinctions have 883 been defined: 885 7.7.1. IPsec Tunnel 887 Definition: 889 The combination of an IKE Phase 1 SA and a pair of IKE Phase 2 890 SA's. 892 Discussion: 894 An IPsec Tunnel will be defined as a single (1) Phase 1 SA and a 895 pair (2) Phase 2 SA's. This construct will allow bidirectional 896 traffic to be passed between two IPsec Devices where the traffic 897 can benefit form the services offered in the IPsec framework. 899 Issues: 901 Since it is implied that a Phase 1 SA is used, an IPsec Tunnel 902 will be by definition a dynamically negotiated secured link. If 903 manual keying is used to enable secure data transport, then this 904 link will merely be referred to as a pair of IPsec SA's. 906 It is very likely that more then one pair of Phase 2 SA's are 907 associated with a single Phase 1 SA. Also in this case, the IPsec 908 Tunnel definition WILL NOT apply. Instead the ratio between Phase 909 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella 910 term of "IPsec Tunnel" MUST NOT be used in this context. 912 See Also: 914 IKE Phase 1, IKE Phase 2 916 7.7.2. Configured Tunnel 918 Definition: 920 An IPsec tunnel or a pair of IPsec SAs in the case of manual 921 keying that is provisioned in the IPsec device's configuration. 923 Discussion: 925 Several steps are required before IPsec can be used to actually 926 transport traffic. The very first step is to configure the IPsec 927 Tunnel (or IPsec SAs in the case of manual keying) in the IPsec 928 device. When using IKE there are no SA's associated with the 929 IPsec Tunnel and no traffic is going through the IPsec device that 930 matches the Selectors, which would instantiate the IPsec Tunnel. 931 When using either manual keying or IKE, a configured tunnel will 932 not have a populated SADB. 934 Issues: 936 When using IKE, a configured tunnel will not have any SAs while 937 with manual keying, the SAs will have simply been configured but 938 not populated in the SADB. 940 See Also: 942 IPsec Tunnel, Established Tunnel, Active Tunnel 944 7.7.3. Established Tunnel 946 Definition: 948 An IPsec device that has a populated SADB and is ready to provide 949 security services to the appropriate traffic. 951 Discussion: 953 When using IKE, a second step needed to ensure that an IPsec 954 Tunnel can transport data is to complete the Phase 1 and Phase 2 955 negotiations. After the packet classification process has 956 asserted that a packet requires security services, the negotation 957 is started to obtain both Phase 1 and Phase 2 SAs. After this is 958 completed and the SADB is populated, the IPsec Tunnel is called 959 'Established'. Note that at this time there is still no traffic 960 flowing through the IPsec Tunnel. Just enough packet(s) have been 961 sent to the IPsec device that matched the selectors and triggered 962 the IPsec Tunnel setup to result in a populated SADB. In the case 963 of manual keying, populating the SADB is accomplished by a 964 separate administrative command. 966 Issues: 968 N/A 970 See Also: 972 IPsec Tunnel, Configured Tunnel, Active Tunnel 974 7.7.4. Active Tunnel 976 Definition: 978 An IPsec device that is forwarding secured data. 980 Discussion: 982 When a Tunnel is Established and it is transporting traffic that 983 is authenticated and/or encrypted, the tunnel is called 'Active'. 985 Issues: 987 The distinction between an Active Tunnel and Configured/ 988 Established Tunnel is made in the context of manual keyed Tunnels. 989 In this case it would be possible to have an Established tunnel on 990 an IPsec device which has no counterpart on it's corresponding 991 peer. This will lead to encrypted traffic flows which will be 992 discarded on the receiving peer. Only if both peers have an 993 Established Tunnel that shows evidence of traffic transport, it 994 may be called an Active Tunnel. 996 See Also: 998 IPsec Tunnel, Configured Tunnel, Established Tunnel 1000 7.8. Iterated Tunnels 1002 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 1003 The bundles are divided into two major groups : 1005 7.8.1. Nested Tunnels 1007 Definition: 1009 An SA bundle consisting of two or more 'tunnel mode' SA's. 1011 Discussion: 1013 The process of nesting tunnels can theoretically be repeated 1014 multiple times (for example, tunnels can be many levels deep), but 1015 for all practical purposes, most implementations limit the level 1016 of nesting. Nested tunnels can use a mix of AH and ESP 1017 encapsulated traffic. 1019 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1020 | | | | 1021 | | | | 1022 | +----{SA1 (ESP tunnel)}----+ | 1023 | | 1024 +--------------{SA2 (AH tunnel)}---------------+ 1026 In the IP Cloud a packet would have a format like this : 1027 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 1029 Nested tunnels can be deployed to provide additional security on 1030 already secured traffic. A typical example of this would be that 1031 the inner gateways (GW2 and GW3) are securing traffic between two 1032 branch offices and the outer gateways (GW1 & GW4) add an 1033 additional layer of security between departments within those 1034 branch offices. 1036 Issues: 1038 N/A 1040 See Also: 1042 Transport Adjacency, IPsec Tunnel 1044 7.8.2. Transport Adjacency 1046 Definition: 1048 An SA bundle consisting of two or more transport mode SA's. 1050 Discussion: 1052 Transport adjacency is a form of tunnel nesting. In this case two 1053 or more transport mode IPsec tunnels are set side by side to 1054 enhance applied security properties. 1056 Transport adjacency can be used with a mix of AH and ESP tunnels 1057 although some combinations are not preferred. If AH and ESP are 1058 mixed, the ESP tunnel should always encapsulate the AH tunnel. 1059 The reverse combination is a valid combination but doesn't make 1060 cryptographical sense. 1062 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1063 | | | | 1064 | | | | 1065 | +------{SA1 (ESP transport)}--------+ | 1066 | | 1067 +-------------{SA2 (AH transport)}--------------+ 1069 In the IP Cloud a packet would have a format like this : 1070 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 1072 Issues: 1074 This is rarely used in the way it is depicted. It is more common, 1075 but still not likely, that SA's are established from different 1076 gateways as depicted in the Nested Tunnels figure. The packet 1077 format in the IP Cloud would remain unchanged. 1079 See Also: 1081 Nested Tunnels, IPsec Tunnel 1083 7.9. Transform protocols 1085 Definition: 1087 Encryption and authentication algorithms that provide cryptograhic 1088 services to the IPsec Protocols. 1090 Discussion: 1092 Some algorithms run significantly slower than others. A decision 1093 for which algorithm to use is usually based on the tradeoff 1094 between performance and security strength. For example, 3DES 1095 encryption is generally slower then DES encryption. 1097 Issues: 1099 N/A 1101 See Also: 1103 Authentication protocols, Encryption protocols 1105 7.9.1. Authentication Protocols 1107 Definition: 1109 Algorithms which provide data integrity and data source 1110 authentication. 1112 Discussion: 1114 Authentication protocols provide no confidentiality. Commonly 1115 used authentication algorithms/protocols are: 1117 * MD5-HMAC 1118 * SHA-HMAC 1119 * AES-HMAC 1121 Issues: 1123 N/A 1125 See Also: 1127 Transform protocols, Encryption protocols 1129 7.9.2. Encryption Protocols 1131 Definition: 1133 Algorithms which provide data confidentiality. 1135 Discussion: 1137 Encryption protocols provide no authentication. Commonly used 1138 encryption algorithms/protocols are: 1140 * NULL encryption 1141 * DES-CBC 1142 * 3DES-CBC 1143 * AES-CBC 1145 Issues: 1147 The null-encryption option is a valid encryption mechanism to 1148 provide an alternative to using AH. There is no confidentiality 1149 protection with null-encryption. Note also that when using ESP 1150 null-encryption the authentication and integrity services only 1151 apply for the upper layer protocols and not for the IP header 1152 itself. 1154 DES has been officially deprecated by NIST, though it is still 1155 mandated by the IPsec framework and is still commonly implemented 1156 and used due to it's speed advantage over 3DES. AES will be the 1157 successor of 3DES due to its superior encryption and performance 1158 advantage. 1160 See Also: 1162 Transform protocols, Authentication protocols 1164 7.10. IPsec Protocols 1166 Definition: 1168 A suite of protocols which provide a framework of open standards 1169 that provides data origin confidentiality, data integrity, and 1170 data origin authenticity between participating peers at the IP 1171 layer. The IPsec protocol suite set of standards is documented in 1172 [RFC2401] through [RFC2412] and [RFC2451]. 1174 Discussion: 1176 The IPsec Protocol suite is modular and forward compatible. The 1177 protocols that comprise the IPsec protocol suite can be replaced 1178 with new versions of those protocols as the older versions become 1179 obsolete. For example, IKEv2 will soon replace IKEv1. 1181 Issues: 1183 N/A 1185 See Also: 1187 AH, ESP 1189 7.10.1. Authentication Header (AH) 1191 Definition: 1193 Provides data origin authentication and data integrity (including 1194 replay protection) security services as defined in [RFC2402]. 1196 Discussion: 1198 The AH protocol supports two modes of operation i.e. tunnel mode 1199 and transport mode. 1201 In transport mode, AH is inserted after the IP header and before a 1202 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any 1203 other IPsec headers that have already been inserted. In the 1204 context of IPv4, this calls for placing AH after the IP header 1205 (and any options that it contains), but before the next layer 1206 protocol. In the IPv6 context, AH is viewed as an end-to-end 1207 payload, and thus should appear after hop-by-hop, routing, and 1208 fragmentation extension headers. The destination options 1209 extension header(s) could appear before or after or both before 1210 and after the AH header depending on the semantics desired. 1212 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1213 source and destination addresses, while an "outer" IP header 1214 contains the addresses of the IPsec "peers," e.g., addresses of 1215 security gateways. In tunnel mode, AH protects the entire inner 1216 IP packet, including the entire inner IP header. The position of 1217 AH in tunnel mode, relative to the outer IP header, is the same as 1218 for AH in transport mode. 1220 Issues: 1222 AH is rarely used to secure traffic over the Internet. 1224 See Also: 1226 Transform protocols, IPsec protocols, Encapsulated Security 1227 Payload 1229 7.10.2. Encapsulated Security Payload (ESP) 1231 Definition: 1233 Provides data origin authentication, data integrity (including 1234 replay protection) and data confidentiality as defined in 1235 [RFC2406]. 1237 Discussion: 1239 The ESP protocol supports two modes of operation i.e. tunnel mode 1240 and transport mode. 1242 In transport mode, ESP is inserted after the IP header and before 1243 a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context 1244 of IPv4, this translates to placing ESP after the IP header (and 1245 any options that it contains), but before the next layer protocol. 1246 In the IPv6 context, ESP is viewed as an end-to-end payload, and 1247 thus should appear after hop-by-hop, routing, and fragmentation 1248 extension headers. Destination options extension header(s) could 1249 appear before, after, or both before and after the ESP header 1250 depending on the semantics desired. However, since ESP protects 1251 only fields after the ESP header, it generally will be desirable 1252 to place the destination options header(s) after the ESP header. 1254 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1255 source and destination addresses, while an "outer" IP header 1256 contains the addresses of the IPsec "peers", e.g., addresses of 1257 security gateways. Mixed inner and outer IP versions are allowed, 1258 i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP 1259 protects the entire inner IP packet, including the entire inner IP 1260 header. The position of ESP in tunnel mode, relative to the outer 1261 IP header, is the same as for ESP in transport mode. 1263 Issues: 1265 N/A 1267 See Also: 1269 Transform protocols, IPsec protocols, Authentication Header 1271 7.11. NAT Traversal (NAT-T) 1273 Definition: 1275 The capability to support IPsec functionality in the presence of 1276 NAT devices. 1278 Discussion: 1280 NAT-Traversal requires some modifications to IKE as defined in 1281 [RFC3947]. Specifically, in phase 1, it requires detecting if the 1282 other end supports NAT-Traversal, and detecting if there are one 1283 or more NAT instances along the path from host to host. In IKE 1284 Quick Mode, there is a need to negotiate the use of UDP 1285 encapsulated IPsec packets. 1287 NAT-T also describes how to transmit the original source and 1288 destination addresses to the corresponding IPsec Device. The 1289 original source and destination addresses are used in transport 1290 mode to incrementally update the TCP/IP checksums so that they 1291 will match after the NAT transform (The NAT cannot do this, 1292 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1293 packet). 1295 Issues: 1297 N/A 1299 See Also: 1301 IKE, ISAKMP, IPsec Device 1303 7.12. IP Compression 1305 Definition: 1307 A mechanism as defined in [RFC2393] that reduces the size of the 1308 payload that needs to be encrypted. 1310 Discussion: 1312 IP payload compression is a protocol to reduce the size of IP 1313 datagrams. This protocol will increase the overall communication 1314 performance between a pair of communicating hosts/gateways 1315 ("nodes") by compressing the datagrams, provided the nodes have 1316 sufficient computation power, through either CPU capacity or a 1317 compression coprocessor, and the communication is over slow or 1318 congested links. 1320 IP payload compression is especially useful when encryption is 1321 applied to IP datagrams. Encrypting the IP datagram causes the 1322 data to be random in nature, rendering compression at lower 1323 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1324 ineffective. If both compression and encryption are required, 1325 compression must be applied before encryption. 1327 Issues: 1329 N/A 1331 See Also: 1333 IKE, ISAKMP, IPsec Device 1335 7.13. Security Context 1337 Definition: 1339 A security context is a collection of security parameters that 1340 describe the characteristics of the path that an IPsec Tunnel will 1341 take, all of the IPsec Tunnel parameters and the effects it has on 1342 the underlying protected traffic. Security Context encompasses 1343 protocol suite and security policy. 1345 Discussion: 1347 In order to fairly compare multiple IPsec devices it is imperative 1348 that an accurate overview is given of all security parameters that 1349 were used to establish the IPsec Tunnels or manually created SAs 1350 and to secure the traffic between protected networks. Security 1351 Context is not a metric; it is included to accurately reflect the 1352 test environment variables when reporting the methodology results. 1353 To avoid listing too much information when reporting metrics, we 1354 have divided the security context into an IKE context and an IPsec 1355 context. 1357 When merely discussing the behavior of traffic flows through IPsec 1358 devices, an IPsec context MUST be provided. In other cases the 1359 scope of a discussion or report may focus on a more broad set of 1360 behavioral characteristics of the IPsec device, in which case both 1361 an IPsec and an IKE context MUST be provided. 1363 The IPsec context MUST consist of the following elements: 1365 * Manual Keyed Tunnels versus IKE negotiated Tunnels 1367 * Number of IPsec Tunnels or IPsec SA's 1369 * IPsec protocol (AH or ESP) 1371 * IPsec protocol mode (tunnel or transport) 1373 * Authentication algorithm used by AH/ESP 1375 * Encryption algoritm used ESP (if applicable) 1377 * IPsec SA lifetime (traffic and time based) 1379 The IPsec Context MAY also list: 1381 * Selectors 1383 * Fragmentation handling 1385 The IKE Context MUST consist of the following elements: 1387 * Number of IPsec Tunnels. 1389 + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable) 1391 + IKE Phase 1 parameters 1392 - Authentication algorithm 1394 - Encryption algorithm 1396 - DH-Group 1398 - SA lifetime (traffic and time based) 1400 - Authentication mechanism (pre-shared key, RSA-sig, 1401 certificate, etc) 1403 + IKE Phase 2 parameters 1405 - IPsec protocol (part of IPsec context) 1407 - IPsec protocol mode (part of IPsec context) 1409 - Authentication algorithm (part of IPsec context) 1411 - Encryption algorithm (part of IPsec context) 1413 - DH-Group 1415 - PFS used 1417 - SA Lifetime (part of IPsec context) 1419 * Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd] 1421 * IP Compression [RFC2393] 1423 The IKE context MAY also list: 1425 * Phase 1 mode (main or aggressive) 1427 * Available bandwidth and latency to Certificate Authority server 1428 (if applicable) 1430 Issues: 1432 A Security Context will be an important element in describing the 1433 environment where protected traffic is traveling through. 1435 See Also: 1437 IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, 1438 Selectors, IPsec Tunnel 1440 8. Framesizes 1442 8.1. Layer3 clear framesize 1444 Definition: 1446 The total size of the unencrypted L3 PDU. 1448 Discussion: 1450 In relation to IPsec this is the size of the IP header and its 1451 payload. It SHALL NOT include any encapsulations that MAY be 1452 applied before the PDU is processed for encryption. 1454 IPv4 example: 46 bytes PDU = 20 bytes IP header + 26 bytes 1455 payload. 1457 Measurement Units: 1459 Bytes 1461 Issues: 1463 N/A 1465 See Also: 1467 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1468 Encrypted Framesize. 1470 8.2. Layer3 encrypted framesize 1472 Definition: 1474 The total size of the encrypted L3 PDU. 1476 Discussion: 1478 The size of the IP packet and its payload after encapsulations MAY 1479 be applied and the PDU is being processed by the transform. 1481 For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform 1482 has been applied an unencrypted or clear layer3 framesize of 46 1483 bytes Becomes 96 bytes: 1485 20 bytes outer IP header (tunnel mode) 1486 4 bytes SPI (ESP header) 1487 4 bytes Sequence (ESP Header) 1488 8 bytes IV (IOS ESP-3DES) 1489 46 bytes payload 1490 0 bytes pad (ESP-3DES 64 bit) 1491 1 byte Pad length (ESP Trailer) 1492 1 byte Next Header (ESP Trailer) 1493 12 bytes ESP-HMAC SHA1 96 digest 1495 Measurement Units: 1497 Bytes 1499 Issues: 1501 N/A 1503 See Also: 1505 Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted 1506 Framesize. 1508 9. Performance Metrics 1510 9.1. IPsec Tunnels Per Second (TPS) 1512 Definition: 1514 The measurement unit for the IPsec Tunnel Setup Rate tests. The 1515 rate at which IPsec Tunnels are established per second. 1517 Discussion: 1519 According to [RFC2401] two IPsec Tunnels cannot be established 1520 between the same gateways with the same selectors. This is to 1521 prevent overlapping IPsec Tunnels. If overlapping IPsec Tunnels 1522 are attempted, the error will cause the IPsec Tunnel setup time to 1523 take longer than if the IPsec Tunnel setup was successful. For 1524 this reason, a unique pair of selector sets are required for IPsec 1525 Tunnel Setup Rate testing. 1527 Issues: 1529 A unique pair of selector sets are required for TPS testing. 1531 See Also: 1533 IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, IKE 1534 Setup Rate, IPsec Setup Rate 1536 9.2. Tunnel Rekeys Per Seconds (TRPS) 1538 Definition: 1540 A metric that quantifies the number of IKE Phase 1 or Phase 2 1541 rekeys per seconds a DUT can correctly process. 1543 Discussion: 1545 This metric will be will be primary used with Tunnel Rekey 1546 behavior tests. 1548 TRPS will provide a metric used to see system behavior under 1549 stressful conditions where large volumes of SA's are being rekeyed 1550 at the same time or in a short timespan. 1552 Issues: 1554 N/A 1556 See Also: 1558 Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey Rate 1560 9.3. IPsec Tunnel Attempts Per Second (TAPS) 1562 Definition: 1564 A metric that quantifies the number of successful and unsuccessful 1565 IPsec Tunnel establishment requests per second. 1567 Discussion: 1569 This metric can be used to measure IKE DOS Resilience behavior 1570 test. 1572 TAPS provides an important metric to validate the stability of an 1573 IPsec device, if stressed with valid (large number of IPsec tunnel 1574 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1575 any style) tunnel establishment requests. IPsec Tunnel setups 1576 offered to an IPsec devices can either fail due to lack of 1577 resources in the IPsec device to process all the requests or due 1578 to an IKE DOS attack (usually the former is a result of the 1579 latter). 1581 Issues: 1583 If the TAPS increases, the TPS usually decreases, due to burdening 1584 of the DUT with the DOS attack traffic. 1586 See Also: 1588 N/A 1590 10. Test Definitions 1592 10.1. Capacity 1594 10.1.1. IKE SA Capacity 1596 Definition: 1598 The maximum number of IKE SA's that can be sustained on an IPsec 1599 Device. 1601 Discussion: 1603 TBD 1605 Measurement Units: 1607 IKE SA's 1609 Issues: 1611 N/A 1613 See Also: 1615 N/A 1617 10.1.2. IPsec SA Capacity 1619 Definition: 1621 The maximum number of IPsec SA's that can be sustained on an IPsec 1622 Device. 1624 Discussion: 1626 TBD 1628 Measurement Units: 1630 IPsec SA's 1632 Issues: 1634 N/A 1636 See Also: 1638 N/A 1640 10.2. Throughput 1642 10.2.1. IPsec Throughput 1644 Definition: 1646 The maximum rate through an Active Tunnel at which none of the 1647 offered frames are dropped by the device under test. 1649 Discussion: 1651 The IPsec Throughput is almost identically defined as Throughput 1652 in [RFC1242], section 3.17. The only difference is that the 1653 throughput is measured with a traffic flow getting encrypted and 1654 decrypted by an IPsec device. IPsec Throughput is an end-to-end 1655 measurement. 1657 The metric can be represented in two variantions depending on 1658 where measurement is taken in the SUT. One can look at throughput 1659 from a cleartext point of view i.e. find the maximum rate where 1660 clearpackets no longer get dropped. This resulting rate can be 1661 recalculated with an encrypted framesize to represent the 1662 encryption throughput rate. The latter is the preferred method of 1663 representation and shall be called the IPsec Throughput. 1665 Measurement Units: 1667 Packets per seconds (pps) 1669 Issues: 1671 N/A 1673 See Also: 1675 IPsec Encryption Throughput, IPsec Decryption Throughput 1677 10.2.2. IPsec Encryption Throughput 1679 Definition: 1681 The maximum encryption rate through an Active Tunnel at which none 1682 of the offered cleartext frames are dropped by the device under 1683 test. 1685 Discussion: 1687 Since encryption throughput is not necessarily equal to the 1688 decryption throughput, both of the forwarding rates must be 1689 measured independently. The independent forwarding rates have to 1690 measured with the help of an IPsec aware test device that can 1691 originate and terminate IPsec and IKE SA. As defined in 1692 [RFC1242], measurements should be taken with an assortment of 1693 frame sizes. 1695 Measurement Units: 1697 Packets per seconds (pps) 1699 Issues: 1701 N/A 1703 See Also: 1705 IPsec Throughput, IPsec Decryption Throughput 1707 10.2.3. IPsec Decryption Throughput 1709 Definition: 1711 The maximum decryption rate through an Active Tunnel at which none 1712 of the offered encrypted frames are dropped by the device under 1713 test. 1715 Discussion: 1717 Since encryption throughput is not necessarily equal to the 1718 decryption throughput, both of the forwarding rates must be 1719 measured independently. 1721 The independent forwarding rates have to be measured with the help 1722 of an IPsec aware test device that can originate and terminate 1723 IPsec and IKE SA. As defined in [RFC1242], measurements should be 1724 taken with an assortment of frame sizes. 1726 Measurement Units: 1728 Packets per seconds (pps) 1730 Issues: 1732 Recommended test frame sizes will be addressed in future 1733 methodology document. 1735 See Also: 1737 IPsec Throughput, IPsec Encryption Throughput 1739 10.2.4. IPsec Fragmentation Throughput 1741 Definition: 1743 The maximum rate through an Active Tunnel at which none of the 1744 offered frames ,which require fragmentation after applying the 1745 transform overhead, are dropped by the device under test. 1747 Discussion: 1749 TBD 1751 Measurement Units: 1753 Packets per seconds (pps) 1755 Issues: 1757 N/A 1759 See Also: 1761 N/A 1763 10.2.5. IPsec Reassembly Throughput 1765 Definition: 1767 The maximum rate through an Active Tunnel at which none of the 1768 offered fragmented frames are dropped by the device under test. 1770 Discussion: 1772 TBD 1774 Measurement Units: 1776 Packets per seconds (pps) 1778 Issues: 1780 N/A 1782 See Also: 1784 N/A 1786 10.3. Latency 1788 10.3.1. IPsec Latency 1790 Definition: 1792 Time required to propagate a cleartext frame from the input 1793 interface of an initiator, through an Active Tunnel, to the output 1794 interface of the responder. 1796 Discussion: 1798 The IPsec Latency is the time interval starting when the end of 1799 the first bit of the cleartext frame reaches the input interface 1800 of the initiator and ending when the start of the first bit of the 1801 same cleartext frame is detected on the output interface of the 1802 responder. The frame has passed through an Active Tunnel between 1803 an initiator and a responder and has been through an encryption 1804 and decryption cycle. 1806 Measurement Units: 1808 Time units with enough precision to reflect latency measurement. 1810 Issues: 1812 N/A 1814 See Also: 1816 IPsec Encryption Latency, IPsec Decryption Latency 1818 10.3.2. IPsec Encryption Latency 1820 Definition: 1822 The IPsec Encryption Latency is the time interval starting when 1823 the end of the first bit of the cleartext frame reaches the input 1824 interface, through an Active Tunnel, and ending when the start of 1825 the first bit of the encrypted output frame is seen on the output 1826 interface. 1828 Discussion: 1830 IPsec Encryption Latency is the latency introduced when encrypting 1831 traffic through an IPsec tunnel. 1833 Like encryption/decryption throughput, it is not always the case 1834 that encryption latency equals the decryption latency. Therefore 1835 a distinction between the two has to be made in order to get a 1836 more accurate view of where the latency is the most pronounced. 1838 The independent encryption/decryption latencies have to be 1839 measured with the help of an IPsec aware test device that can 1840 originate and terminate IPsec and IKE SA. As defined in 1841 [RFC1242], measurements should be taken with an assortment of 1842 frame sizes. 1844 Measurement Units: 1846 Time units with enough precision to reflect latency measurement. 1848 Issues: 1850 N/A 1852 See Also: 1854 IPsec Latency, IPsec Decryption Latency 1856 10.3.3. IPsec Decryption Latency 1858 Definition: 1860 The IPsec decryption Latency is the time interval starting when 1861 the end of the first bit of the encrypted frame reaches the input 1862 interface, through an Active Tunnel, and ending when the start of 1863 the first bit of the decrypted output frame is seen on the output 1864 interface. 1866 Discussion: 1868 IPsec Decryption Latency is the latency introduced when decrypting 1869 traffic through an Active Tunnel. Like encryption/decryption 1870 throughput, it is not always the case that encryption latency 1871 equals the decryption latency. Therefore a distinction between 1872 the two has to be made in order to get a more accurate view of 1873 where the latency is the most pronounced. 1875 The independent encryption/decryption latencies have to be 1876 measured with the help of an IPsec aware test device that can 1877 originate and terminate IPsec and IKE SA's. As defined in 1878 [RFC1242], measurements should be taken with an assortment of 1879 frame sizes. 1881 Measurement Units: 1883 Time units with enough precision to reflect latency measurement. 1885 Issues: 1887 N/A 1889 See Also: 1891 IPsec Latency, IPsec Encryption Latency 1893 10.3.4. Time To First Packet 1895 Definition: 1897 The Time To First Packet (TTFP) is the time required to process a 1898 cleartext packet from a traffic stream that requires encryption 1899 services when no IPsec Tunnel is present. 1901 Discussion: 1903 The Time To First Packet addresses the issue of responsiveness of 1904 an IPsec device by looking how long it takes to transmit a packet 1905 over Configured Tunnel. The Time To First Packet MUST include the 1906 time to set up the established tunnel, triggered by the traffic 1907 flow (both phase 1 and phase 2 setup times SHALL be included) and 1908 the time it takes to encrypt and decrypt the packet on a 1909 corresponding peer. In short it is the IPsec Tunnel setup time 1910 plus the propagation delay of the packet through the Active 1911 Tunnel. 1913 It must be noted that it is highly unlikely that the first packet 1914 of the traffic flow will be the packet that will be used to 1915 measure the TTFP. There MAY be several protocol layers in the 1916 stack before the tunnel is formed and the traffic is forwarded, 1917 hence several packets COULD be lost during negotiation, for 1918 example, ARP and/or IKE. 1920 Measurement Units: 1922 Time units with enough precision to reflect a TTFP measurement. 1924 Issues: 1926 Only relevant when using IKE for tunnel negotiation. 1928 10.4. Frame Loss 1930 10.4.1. IPsec Frame Loss 1932 Definition: 1934 Percentage of cleartext frames that should have been forwarded 1935 through an Active Tunnel under steady state (constant) load but 1936 were dropped before encryption or after decryption. 1938 Discussion: 1940 The IPsec Frame Loss is almost identically defined as Frame Loss 1941 Rate in [RFC1242], section 3.6. The only difference is that the 1942 IPsec Frame Loss is measured with a traffic flow getting encrypted 1943 and decrypted by an IPsec Device. IPsec Frame Loss is an end-to- 1944 end measurement. 1946 Measurement Units: 1948 Percent (%) 1950 Issues: 1952 N/A 1954 See Also: 1956 IPsec Encryption Frame Loss, IPsec Decryption Frame Loss 1958 10.4.2. IPsec Encryption Frame Loss 1960 Definition: 1962 Percentage of cleartext frames that should have been encrypted 1963 through an Active Tunnel under steady state (constant) load but 1964 were dropped. 1966 Discussion: 1968 A DUT will always have an inherent forwarding limitation. This 1969 will be more pronounced when IPsec is employed on the DUT. There 1970 is a possibility that the offered traffic rate at the Active 1971 Tunnel is too high to be transported through the Active Tunnel and 1972 not all cleartext packets will get encrypted. In that case, some 1973 percentage of the cleartext traffic will be dropped. This drop 1974 percentage is called the IPsec Encryption Frame Loss. 1976 Measurement Units: 1978 Percent (%) 1980 Issues: 1982 N/A 1984 See Also: 1986 IPsec Frame Loss, IPsec Decryption Frame Loss 1988 10.4.3. IPsec Decryption Frame Loss 1990 Definition: 1992 Percentage of encrypted frames that should have been decrypted 1993 through an Active Tunnel under steady state (constant) load but 1994 were dropped. 1996 Discussion: 1998 A DUT will also have an inherent forwarding limitation when 1999 decrypting packets. When Active Tunnel encrypted traffic is 2000 offered at a costant load, there might be a possibility that the 2001 IPsec Device that needs to decrypt the traffic will not be able to 2002 perfom this action on all of the packets due to limitations of the 2003 decryption performance. The percentage of encrypted frames that 2004 would get dropped under these conditions is called the IPsec 2005 Decryption Frame Loss. 2007 Measurement Units: 2009 Percent (%) 2011 Issues: 2013 N/A 2015 See Also: 2017 IPsec Frame Loss, IPsec Encryption Frame Loss 2019 10.4.4. IKE Phase 2 Rekey Frame Loss 2021 Definition: 2023 Number of frames dropped as a result of an inefficient IKE Phase 2 2024 rekey. 2026 Discussion: 2028 Normal operation of an IPsec Device would require that a rekey 2029 does not create temporary IPsec Frame Loss of a traffic stream 2030 that is protected by the IKE Phase 2 SA's (i.e. IPsec SA's). 2031 Nevertheless there can be situations where IPsec Frame Loss occurs 2032 during this rekey process. 2034 This metric should be ideally zero but this may not be the case on 2035 IPsec Devices where IPsec funtionality is not a core feature. 2037 Measurement Units: 2039 Number of N-octet frames 2041 Issues: 2043 N/A 2045 See Also: 2047 IKE Phase 2 Rekey Rate 2049 10.5. Back-to-back Frames 2051 10.5.1. IPsec Back-to-back Frames 2053 Definition: 2055 A burst of cleartext frames, offered at a constant load that can 2056 be sent through an Active Tunnel without losing a single cleartext 2057 frame after decryption. 2059 Discussion: 2061 The IPsec Back-to-back Frames is almost identically defined as 2062 Back-to-back in [RFC1242], section 3.1. The only difference is 2063 that the IPsec Back-to-back Frames is measured with a traffic flow 2064 getting encrypted and decrypted by an IPsec Device. IPsec Back- 2065 to-back Frames is an end-to-end measurement. 2067 Measurement Units: 2069 Number of N-octet frames in burst. 2071 Issues: 2073 Recommended test frame sizes will be addressed in methodology 2074 document. 2076 See Also: 2078 IPsec Encryption Back-to-back frames, IPsec Decryption Back-to- 2079 back frames 2081 10.5.2. IPsec Encryption Back-to-back Frames 2082 Definition: 2084 A burst of cleartext frames, offered at a constant load that can 2085 be sent through an Active Tunnel without losing a single encrypted 2086 frame. 2088 Discussion: 2090 IPsec Encryption back-to-back frames is the measure of the maximum 2091 burst size that an IPsec Device can handle for encrypting traffic 2092 that it receives as plaintext. Since it is not necessarily the 2093 case that the maximum burst size a DUT can handle for encryption 2094 is equal to the maximum burst size a DUT can handle for 2095 decryption, both of these capabilities must be measured 2096 independently. The IPsec Encryption Back-to-back frame 2097 measurement has to be measured with the help of an IPsec aware 2098 test device that can decrypt the traffic to determine the validity 2099 of the encrypted frames. 2101 Measurement Units: 2103 Number of N-octet frames in burst. 2105 Issues: 2107 Recommended test frame sizes will be addressed in future 2108 methodology document. 2110 See Also: 2112 IPsec Back-to-back frames, IPsec Decryption Back-to-back frames 2114 10.5.3. IPsec Decryption Back-to-back Frames 2116 Definition: 2118 The number of encrypted frames, offered at a constant load, that 2119 can be sent through an Active Tunnel without losing a single 2120 cleartext frame. 2122 Discussion: 2124 IPsec Decryption Back-to-back frames is the measure of the maximum 2125 burst size that an IPsec Device can handle for decrypting traffic 2126 that it receives as encrypted traffic. Since it is not 2127 necessarily the case that the maximum burst size a DUT can handle 2128 for decryption is equal to the maximum burst size a DUT can handle 2129 for encryption, both of these capabilities must be measured 2130 independently. The IPsec Decryption Back-to-back frame 2131 measurement has to be measured with the help of an IPsec aware 2132 test device that can determine the validity of the decrypted 2133 frames. 2135 Measurement Units: 2137 Number of N-octet frames in burst. 2139 Issues: 2141 Recommended test frame sizes will be addressed in methodology 2142 document. 2144 See Also: 2146 IPsec Back-to-back frames, IPsec Encryption back-to-back frames 2148 10.6. Tunnel Setup Behavior 2150 10.6.1. IPsec Tunnel Setup Rate 2152 Definition: 2154 The maximum number of IPsec Tunnels per second that an IPsec 2155 Device can successfully establish. 2157 Discussion: 2159 The Tunnel Setup Rate SHOULD be measured at varying number of 2160 IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the DUT. 2161 Several factors may influence Tunnel Setup Rate, such as: TAPS 2162 rate, Background cleartext traffic load on the secure interface, 2163 Already established IPsec Tunnels, Authentication method such as 2164 pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used 2165 (when using RSA/DSS). 2167 Measurement Units: 2169 Tunnels Per Second (TPS) 2171 Issues: 2173 N/A 2175 See Also: 2177 IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel Rekey 2178 Behavior 2180 10.6.2. IKE Phase 1 Setup Rate 2182 Definition: 2184 The maximum number of sucessful IKE Phase 1 SA's per second that 2185 an IPsec Device can establish. 2187 Discussion: 2189 The Phase 1 Setup Rate is a portion of the IPsec Tunnel Setup 2190 Rate. In the process of establishing an IPsec Tunnel, it is 2191 interesting to know what the limiting factor of the IKE Finite 2192 State Machine (FSM) is i.e. is it limited by the Phase 1 2193 processing delays or rather by the Phase 2 processing delays. 2195 Measurement Units: 2197 Tunnels Per Second (TPS) 2199 Issues: 2201 N/A 2203 See Also: 2205 IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel 2206 Rekey Behavior 2208 10.6.3. IKE Phase 2 Setup Rate 2210 Definition: 2212 The maximum number of successfully IKE Phase 2 SA's per second 2213 that an IPsec Device can Only relevant when using IKE establish. 2215 Discussion: 2217 The IKE Phase 2 Setup Rate is a portion of the IPsec Tunnel Setup 2218 Rate. For identical reasons why it is required to quantify the 2219 IKE Phase 1 Setup Rate, it is a good practice to know the 2220 processing delays involved in setting up an IKE Phase 2 SA for 2221 each direction of the protected traffic flow. 2223 IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of 2224 two IKE Phase 2 SA's. 2226 Note that once you have the IPsec Tunnel Setup Rate and either the 2227 IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can 2228 extrapolate the unmeasured metric. It is however highly 2229 RECOMMENDED to measure all three metrics. 2231 Measurement Units: 2233 Tunnels Per Second (TPS) 2235 Issues: 2237 N/A 2239 See Also: 2241 IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec Tunnel 2242 Rekey Behavior 2244 10.7. IPsec Tunnel Rekey Behavior 2246 10.7.1. IKE Phase 1 Rekey Rate 2248 Definition: 2250 The number of IKE Phase 1 SA's that can be succesfully re- 2251 establish per second. 2253 Discussion: 2255 Although the IKE Phase 1 Rekey Rate has less impact on the 2256 forwarding behavior of traffic that requires security services 2257 then the IKE Phase 2 Rekey Rate, it can pose a large burden on the 2258 CPU or network processor of the IPsec Device. Due to the highly 2259 computational nature of a Phase 1 exchange, it may impact the 2260 stability of Active Tunnels in the network when the IPsec Device 2261 fails to properly rekey an IKE Phase 1 SA. 2263 Measurement Units: 2265 Tunnel Rekeys per second (TRPS) 2267 Issues: 2269 N/A 2271 See Also: 2273 IKE Phase 2 Rekey Rate 2275 10.7.2. IKE Phase 2 Rekey Rate 2277 Definition: 2279 The number of IKE Phase 2 SA's that can be succesfully re- 2280 negotiated per second. 2282 Discussion: 2284 Although many implementations will usually derive new keying 2285 material before the old keys expire, there may still be a period 2286 of time where frames get dropped before the IKE Phase 2 tunnels 2287 are successfully re-established. There may also be some packet 2288 loss introduced when the handover of traffic is done from the 2289 expired IPsec SA's to the newly negotiated IPsec SA's. To measure 2290 the IKE Phase 2 rekey rate, the measurement will require an IPsec 2291 aware test device to act as a responder when negotiating the new 2292 IKE Phase 2 keying material. 2294 The test methodology report must specify if PFS is enabled in 2295 reported security context. 2297 Measurement Units: 2299 Tunnel Rekeys per second (TRPS) 2301 Issues: 2303 N/A 2305 See Also: 2307 IKE Phase 1 Rekey Rate 2309 10.8. IPsec Tunnel Failover Time 2311 Definition: 2313 Time required to recover all IPsec Tunnels on a stanby IPsec 2314 Device, after a catastrophic failure occurs on the active IPsec 2315 Device. 2317 Discussion: 2319 Recovery time required to re-establish all IPsec Tunnels and 2320 reroute all traffic on a standby node or other failsafe system 2321 after a failure has occurred in the DUT/SUT. Failure can include 2322 but are not limited to a catastrophic IPsec Device failure, a 2323 encryption engine failure, link outage. The recovery time is 2324 delta between the point of failure and the time the first packet 2325 is seen on the last restored IPsec Tunnel on the backup device. 2327 Measurement Units: 2329 Time units with enough precision to reflect IPsec Tunnel Failover 2330 Time. 2332 Issues: 2334 N/A 2336 11. Security Considerations 2338 As this document is solely for the purpose of providing test 2339 benchmarking terminology and describes neither a protocol nor a 2340 protocol's implementation; there are no security considerations 2341 associated with this document. 2343 12. Acknowledgements 2345 The authors would like to acknowledge the following individual for 2346 their help and participation of the compilation and editing of this 2347 document: Debby Stopp, Ixia. 2349 13. Contributors 2351 The authors would like to acknowledge the following individual for 2352 their significant help, guidance, and contributions to this document: 2353 Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. 2355 14. References 2357 14.1. Normative References 2359 [RFC1242] Bradner, S., "Benchmarking terminology for network 2360 interconnection devices", RFC 1242, July 1991. 2362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2363 Requirement Levels", BCP 14, RFC 2119, March 1997. 2365 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2366 Switching Devices", RFC 2285, February 1998. 2368 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 2369 Payload Compression Protocol (IPComp)", RFC 2393, 2370 December 1998. 2372 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2373 Internet Protocol", RFC 2401, November 1998. 2375 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 2376 RFC 2402, November 1998. 2378 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2379 ESP and AH", RFC 2403, November 1998. 2381 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2382 ESP and AH", RFC 2404, November 1998. 2384 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 2385 Algorithm With Explicit IV", RFC 2405, November 1998. 2387 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2388 Payload (ESP)", RFC 2406, November 1998. 2390 [RFC2407] Piper, D., "The Internet IP Security Domain of 2391 Interpretation for ISAKMP", RFC 2407, November 1998. 2393 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 2394 Security Association and Key Management Protocol 2395 (ISAKMP)", RFC 2408, November 1998. 2397 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2398 (IKE)", RFC 2409, November 1998. 2400 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2401 Its Use With IPsec", RFC 2410, November 1998. 2403 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 2404 Document Roadmap", RFC 2411, November 1998. 2406 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 2407 RFC 2412, November 1998. 2409 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2410 Algorithms", RFC 2451, November 1998. 2412 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 2413 Network Interconnect Devices", RFC 2544, March 1999. 2415 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 2416 March 1999. 2418 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 2419 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 2420 RFC 2661, August 1999. 2422 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2423 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2424 March 2000. 2426 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 2427 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 2428 January 2005. 2430 [I-D.ietf-ipsec-ikev2] 2431 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2432 draft-ietf-ipsec-ikev2-17 (work in progress), 2433 October 2004. 2435 [I-D.ietf-ipsec-dpd] 2436 Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- 2437 Based Method of Detecting Dead IKE Peers", 2438 draft-ietf-ipsec-dpd-04 (work in progress), October 2003. 2440 [I-D.ietf-ipsec-properties] 2441 Krywaniuk, A., "Security Properties of the IPsec Protocol 2442 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2443 July 2002. 2445 [FIPS.186-1.1998] 2446 National Institute of Standards and Technology, "Digital 2447 Signature Standard", FIPS PUB 186-1, December 1998, 2448 . 2450 14.2. Informative References 2452 [Designing Network Security] 2453 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2454 Published: May 07, 1999; Copyright: 1999, 1999. 2456 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2457 Mechanism for Internet", from IEEE Proceedings of the 2458 1996 Symposium on Network and Distributed Systems 2459 Security, 2460 URI http://www.research.ibm.com/security/skeme.ps, 1996. 2462 Authors' Addresses 2464 Merike Kaeo 2465 Double Shot Security 2466 520 Washington Blvd #363 2467 Marina Del Rey, CA 90292 2468 US 2470 Phone: +1 (310)866-0165 2471 Email: kaeo@merike.com 2473 Tim Van Herck 2474 Cisco Systems 2475 170 West Tasman Drive 2476 San Jose, CA 95134-1706 2477 US 2479 Email: herckt@cisco.com 2481 Michele Bustos 2482 IXIA 2483 26601 W. Agoura Rd. 2484 Calabasas, CA 91302 2485 US 2487 Phone: +1 (818)444-3244 2488 Email: mbustos@ixiacom.com 2490 Intellectual Property Statement 2492 The IETF takes no position regarding the validity or scope of any 2493 Intellectual Property Rights or other rights that might be claimed to 2494 pertain to the implementation or use of the technology described in 2495 this document or the extent to which any license under such rights 2496 might or might not be available; nor does it represent that it has 2497 made any independent effort to identify any such rights. Information 2498 on the procedures with respect to rights in RFC documents can be 2499 found in BCP 78 and BCP 79. 2501 Copies of IPR disclosures made to the IETF Secretariat and any 2502 assurances of licenses to be made available, or the result of an 2503 attempt made to obtain a general license or permission for the use of 2504 such proprietary rights by implementers or users of this 2505 specification can be obtained from the IETF on-line IPR repository at 2506 http://www.ietf.org/ipr. 2508 The IETF invites any interested party to bring to its attention any 2509 copyrights, patents or patent applications, or other proprietary 2510 rights that may cover technology that may be required to implement 2511 this standard. Please address the information to the IETF at 2512 ietf-ipr@ietf.org. 2514 Disclaimer of Validity 2516 This document and the information contained herein are provided on an 2517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2519 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2520 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2521 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2524 Copyright Statement 2526 Copyright (C) The Internet Society (2005). This document is subject 2527 to the rights, licenses and restrictions contained in BCP 78, and 2528 except as set forth therein, the authors retain all their rights. 2530 Acknowledgment 2532 Funding for the RFC Editor function is currently provided by the 2533 Internet Society.