idnits 2.17.1 draft-ietf-bmwg-ipsec-term-08.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 2514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2504. ** 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 (March 5, 2006) is 6626 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 1060, but not defined == Missing Reference: 'GW2' is mentioned on line 1060, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 1060, but not defined == Missing Reference: 'GW3' is mentioned on line 1060, but not defined == Missing Reference: 'GW4' is mentioned on line 1060, but not defined == Missing Reference: 'ESP' is mentioned on line 1068, but not defined == Missing Reference: 'AH' is mentioned on line 1068, but not defined == Missing Reference: 'IP' is mentioned on line 1068, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 1068, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 1068, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 1068, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1321, but not defined == Unused Reference: 'RFC2119' is defined on line 2354, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 2370, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 2373, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 2376, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 2392, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2432, 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: September 6, 2006 T. Van Herck 5 Cisco Systems 6 M. Bustos 7 IXIA 8 March 5, 2006 10 Terminology for Benchmarking IPsec Devices 11 draft-ietf-bmwg-ipsec-term-08 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 September 6, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . 39 115 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 40 116 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 40 117 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 41 118 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 41 119 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 42 120 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 43 121 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 43 122 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 44 123 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 44 124 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 45 125 10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 46 126 10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 46 127 10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 46 128 10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 47 129 10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 48 130 10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 48 131 10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 49 132 10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 49 133 10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 50 134 10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 50 135 10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 51 136 10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 51 137 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 139 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52 140 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 141 14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 142 14.2. Informative References . . . . . . . . . . . . . . . . . . 54 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 144 Intellectual Property and Copyright Statements . . . . . . . . . . 57 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 and software solutions. 151 This results in varied implementations which challenge 152 interoperability and direct performance comparisons. Standardized 153 IPsec terminology and performance test methodologies will enable 154 users to determine if the IPsec device they select will withstand 155 loads of secured traffic that meet their requirements. 157 To appropriately define the parameters and scope of this document, 158 this section will give a brief overview of the IPsec standard: 160 2. IPsec Fundamentals 162 IPsec is a framework of open standards that provides data 163 confidentiality, data integrity, and data origin authenticity between 164 participating peers. IPsec provides these security services at the 165 IP layer. IPsec uses IKE to handle negotiation of protocols and 166 algorithms based on local policy, and to generate the encryption and 167 authentication keys to be used. IPsec can be used to protect one or 168 more data flows between a pair of hosts, between a pair of security 169 gateways, or between a security gateway and a host. The IPsec 170 protocol suite set of standards is documented in RFC's [RFC2401] 171 through [RFC2412] and [RFC2451]. The reader is assumed to be 172 familiar with these documents. Some Internet Drafts supersede these 173 RFC's and will be taken into consideration. 175 IPsec itself defines the following: 177 Authentication Header (AH): A security protocol, defined in 178 [RFC2402], which provides data authentication and optional anti- 179 replay services. AH ensures the integrity and data origin 180 authentication of the IP datagram as well as the invariant fields in 181 the outer IP header. 183 Encapsulating Security Payload (ESP): A security protocol, defined in 184 [RFC2406], which provides confidentiality, data origin 185 authentication, connectionless integrity, an anti-replay service and 186 limited traffic flow confidentiality. The set of services provided 187 depends on options selected at the time of Security Association (SA) 188 establishment and on the location of the implementation in a network 189 topology. ESP authenticates only headers and data after the IP 190 header. 192 Internet Key Exchange (IKE): A hybrid protocol which implements 193 Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP 194 framework. While IKE can be used with other protocols, its initial 195 implementation is with the IPsec protocol. IKE provides 196 authentication of the IPsec peers, negotiates IPsec security 197 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). In IPv6, the 206 security protocol header appears after the base IP header and 207 selected extension headers. It may appear before or after 208 destination options but must appear before next layer protocols 209 (e.g., TCP, UDP, SCTP) 211 In the case of AH in transport mode, security services are provided 212 to selected portions of the IP header preceding the AH header, 213 selected portions of extension headers, and selected options 214 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 215 IPv6 Destination extension headers). Any fields in these headers/ 216 extension headers which are modified in transit are set to 0 before 217 applying the authentication algorithm. If a field is mutable, but 218 its value at the receiving IPsec peer is predictable, then that value 219 is inserted into the field before applying the cryptographic 220 algorithm. 222 In the case of ESP in transport mode, security services are provide 223 only for the higher-layer protocols, not for the IP header or any 224 extension headers preceding the ESP header. 226 A tunnel is a vehicle for encapsulating packets inside a protocol 227 that is understood at the entry and exit points of a given network. 228 These entry and exit points are defined as tunnel interfaces. 230 Both the AH and ESP protocols can be used in tunnel mode for data 231 packet endpoints as well as by intermediate security gateways. In 232 tunnel mode, there is an "outer" IP header that specifies the IPsec 233 processing destination, plus an "inner" IP header that specifies the 234 ultimate destination for the packet. The source address in the outer 235 IP header is the initiating cryptographic endpoint; the source 236 address in the inner header is the true source address of the packet. 237 The security protocol header appears after the outer IP header and 238 before the inner IP header. 240 If AH is employed in tunnel mode, portions of the new outer IP header 241 are given protection (those same fields as for transport mode, 242 described earlier in this section), as well as all of the tunneled IP 243 packet (that is, all of the inner IP header is protected as are the 244 higher-layer protocols). If ESP is employed, the protection is 245 afforded only to the tunneled packet, not to the new outer IP header. 247 2.1. IPsec Operation 249 2.1.1. Security Associations 251 The concept of a Security Association (SA) is fundamental to IPsec. 252 An SA is a relationship between two or more entities that describes 253 how the entities will use security services to communicate. The SA 254 includes: an encryption algorithm, an authentication algorithm and a 255 shared session key. 257 Because an SA is unidirectional, two SA's (one in each direction) are 258 required to secure typical, bidirectional communication between two 259 entities. The security services associated with an SA can be used 260 for AH or ESP, but not for both. If both AH and ESP protection is 261 applied to a traffic stream, two (or more) SA's are created for each 262 direction to protect the traffic stream. 264 The SA is uniquely identified by the Security Parameter Index (SPI) 265 [RFC2406]. When a system sends a packet that requires IPsec 266 protection, it looks up the SA in its database and applies the 267 specified processing and security protocol (AH/ESP), inserting the 268 SPI from the SA into the IPsec header. When the IPsec peer receives 269 the packet, it looks up the SA in its database by destination 270 address, protocol, and SPI and then processes the packet as required. 272 2.1.2. Key Management 274 IPsec uses cryptographic keys for authentication, integrity and 275 encryption services. Both manual provisioning and automatic 276 distribution of keys is supported. IKE is specified as the public- 277 key-based approach for automatic key management. 279 IKE authenticates each peer involved in IPsec, negotiates the 280 security policy, and handles the exchange of session keys. IKE is a 281 hybrid protocol, combining parts of the following protocols to 282 negotiate and derive keying material for SA's in a secure and 283 authenticated manner: 285 1. ISAKMP [RFC2408] (Internet Security Association and Key 286 Management Protocol), which provides a framework for 287 authentication and key exchange but does not define them. ISAKMP 288 is designed to be key exchange independent; it is designed to 289 support many different key exchanges. 291 2. Oakley [RFC2412], which describes a series of key exchanges, 292 called modes, and details the services provided by each (for 293 example, perfect forward secrecy for keys, identity protection, 294 and authentication). 296 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 297 describes a versatile key exchange technique that provides 298 anonymity, reputability, and quick key refreshment. 300 IKE creates an authenticated, secure tunnel between two entities and 301 then negotiates the security association for IPsec. This is 302 performed in two phases. 304 In Phase 1, the two unidirectional SA's establish a secure, 305 authenticated channel with which to communicate. Phase 1 has two 306 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 307 provides identity protection. When identity protection is not 308 needed, Aggressive Mode can be used. The completion of Phase 1 is 309 called an IKE SA. 311 The following attributes are used by IKE and are negotiated as part 312 of the IKE SA: 314 o Encryption algorithm. 316 o Hash algorithm. 318 o Authentication method (digital signature, public-key encryption or 319 pre-shared key). 321 o Diffie-Hellman group information. 323 After the attributes are negotiated, both parties must be 324 authenticated to each other. IKE supports multiple authentication 325 methods. The following mechanisms are generally implemented: 327 o Pre-shared keys: The same key is pre-installed on each host. IKE 328 peers authenticate each other by computing and sending a keyed 329 hash of data that includes the pre-shared key. If the receiving 330 peer can independently create the same hash using its preshared 331 key, it knows that both parties must share the same secret, and 332 thus the other party is authenticated. 334 o Public key cryptography: Each party generates a pseudo-random 335 number (a nonce) and encrypts it and its ID using the other 336 party's public key. The ability for each party to compute a keyed 337 hash containing the other peer's nonce and ID, decrypted with the 338 local private key, authenticates the parties to each other. This 339 method does not provide nonrepudiation; either side of the 340 exchange could plausibly deny that it took part in the exchange. 342 o Digital signature: Each device digitally signs a set of data and 343 sends it to the other party. This method is similar to the 344 public-key cryptography approach except that it provides 345 nonrepudiation. 347 Note that both digital signature and public-key cryptography require 348 the use of digital certificates to validate the public/private key 349 mapping. IKE allows the certificate to be accessed independently or 350 by having the two devices explicitly exchange certificates as part of 351 IKE. Both parties must have a shared session key to encrypt the IKE 352 tunnel. The Diffie-Hellman protocol is used to agree on a common 353 session key. 355 In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's 356 will be called IPsec SA's. These IPsec SA's use a different shared 357 key than that used for the IKE_SA. The IPsec SA shared key can be 358 derived by using Diffie-Hellman again or by refreshing the shared key 359 derived from the original Diffie-Hellman exchange that generated the 360 IKE_SA by hashing it with nonces. Once the shared key is derived and 361 additional communication parameters are negotiated, the IPsec SA's 362 are established and traffic can be exchanged using the negotiated 363 parameters. 365 3. Document Scope 367 The primary focus of this document is to establish useful performance 368 testing terminology for IPsec devices that support manual keying and 369 IKEv1. We want to constrain the terminology specified in this 370 document to meet the requirements of the Methodology for Benchmarking 371 IPsec Devices documented test methodologies. 373 Both IPv4 and IPv6 addressing will be taken into consideration. 375 The testing will be constrained to: 377 o Devices acting as IPsec gateways whose tests will pertain to both 378 IPsec tunnel and transport mode. 380 o Devices acting as IPsec end-hosts whose tests will pertain to both 381 IPsec tunnel and transport mode. 383 Any testing involving interoperability and/or conformance issues, 384 L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and 385 anything that does not specifically relate to the establishment and 386 tearing down of IPsec tunnels is specifically out of scope. It is 387 assumed that all relevant networking parameters that facilitate in 388 the running of these tests are pre-configured (this includes at a 389 minimum ARP caches, routing tables, neighbor tables, etc ...). 391 4. Definition Format 393 The definition format utilized by this document is described in 394 [RFC1242], Section 2. 396 Term to be defined. 398 Definition: 400 The specific definition for the term. 402 Discussion: 404 A brief discussion of the term, its application, or other 405 information that would build understanding. 407 Issues: 409 List of issues or conditions that affect this term. This field 410 can present items the may impact the term's related methodology or 411 otherwise restrict its measurement procedures. 413 [Measurement units:] 415 Units used to record measurements of this term. This field is 416 mandatory where applicable. This field is optional in this 417 document. 419 [See Also:] 421 List of other terms that are relevant to the discussion of this 422 term. This field is optional in this document. 424 5. Key Words to Reflect Requirements 426 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 427 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 428 document are to be interpreted as described in RFC 2119. RFC 2119 429 defines the use of these key words to help make the intent of 430 standards track documents as clear as possible. While this document 431 uses these keywords, this document is not a standards track document. 433 6. Existing Benchmark Definitions 435 It is recommended that readers consult [RFC1242], [RFC2544] and 436 [RFC2285] before making use of this document. These and other IETF 437 Benchmarking Methodology Working Group (BMWG) router and switch 438 documents contain several existing terms relevant to benchmarking the 439 performance of IPsec devices. The conceptual framework established 440 in these earlier RFC's will be evident in this document. 442 This document also draws on existing terminology defined in other 443 BMWG documents. Examples include, but are not limited to: 445 Throughput [RFC 1242, section 3.17] 446 Latency [RFC 1242, section 3.8] 447 Frame Loss Rate [RFC 1242, section 3.6] 448 Forwarding Rates [RFC 2285, section 3.6] 449 Loads [RFC 2285, section 3.5] 451 7. Definitions 453 7.1. IPsec 455 Definition: 457 IPsec or IP Security protocol suite which comprises a set of 458 standards used to provide security services at the IP layer. 460 Discussion: 462 IPsec is a framework of protocols that offer authentication, 463 integrity and encryption services to the IP and/or upper layer 464 protocols. The major components of the protocol suite are IKE, 465 used for key exchanges, and IPsec protocols such as AH and ESP, 466 which use the exchanged keys to protect payload traffic. 468 Issues: 470 N/A 472 See Also: 474 IPsec Device, IKE, ISAKMP, ESP, AH 476 7.2. ISAKMP 478 Definition: 480 The Internet Security Association and Key Management Protocol, 481 which provides a framework for authentication and key exchange but 482 does not define them. ISAKMP is designed to be key exchange 483 independent; it is designed to support many different key 484 exchanges. ISAKMP is defined in [RFC2407]. 486 Discussion: 488 Though ISAKMP is only a framework for the IPsec standard key 489 management protocol, it is often misused and interchanged with the 490 term 'IKE', which is an implementation of ISAKMP. 492 Issues: 494 When implementations refer to the term 'ISAKMP SA', it refers to 495 an IKE Phase 1 SA. 497 See Also: 499 IKE, Security Association 501 7.3. IKE 503 Definition: 505 A hybrid key management protocol that provides authentication of 506 the IPsec peers, negotiates IPsec SAs and establishes IPsec keys. 508 Discussion: 510 A hybrid protocol, defined in [RFC2409], from the following 3 511 protocols: 513 * ISAKMP (Internet Security Association and Key Management 514 Protocol), which provides a framework for authentication and 515 key exchange but does not define them. ISAKMP is designed to 516 be key exchange independent; it is designed to support many 517 different key exchanges. 519 * Oakley, which describes a series of key exchanges, called 520 modes, and details the services provided by each (for example, 521 perfect forward secrecy for keys, identity protection, and 522 authentication). [RFC2412] 524 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 525 describes a versatile key exchange technique that provides 526 anonymity, reputability, and quick key refreshment. 528 Note that IKE is an optional protocol within the IPsec framework. 529 IPsec SAs may also be manually configured. Manual keying is the 530 most basic mechanism to establish IPsec SAs between two IPsec 531 devices. However, it is not a scalable solution and often 532 manually configured keys are not changed on a periodic basis which 533 reduces the level of protection since the keys are effectively 534 static and as a result are more prone to various attacks. When 535 IKE is employed as a key management protocol, the keys are 536 automatically renegotiated on a user-defined basis (time and/or 537 traffic volume based) as part of the IKE rekeying mechanism. 539 Issues: 541 During the first IPsec deployment experiences, ambiguities were 542 found in the IKEv1 specification, which lead to interoperability 543 problems. To resolve these issues, IKEv1 is being updated by 544 IKEv2. 546 See Also: 548 ISAKMP, IPsec, Security Association 550 7.3.1. IKE Phase 1 552 Definition: 554 The shared policy and key(s) used by negotiating peers to 555 establish a secure authenticated "control channel" for further IKE 556 communications. 558 Discussion: 560 The IPsec framework mandates that SPI's are used to secure payload 561 traffic. If IKE is employed all SPI information will be exchanged 562 between the IPsec devices. This has to be done in a secure 563 fashion and for that reason IKE will set up a secure "control 564 channel" over which it can exchange this information. 566 Note that IKE is an optional protocol within the IPsec framework 567 and that SPI information can also be manually configured. 569 Issues: 571 In some documents often referenced as ISAKMP SA or IKE SA. 573 See Also: 575 IKE, ISAKMP 577 7.3.2. IKE Phase 1 Main Mode 579 Definition: 581 Main Mode is an instantiation of the ISAKMP Identity Protect 582 Exchange, defined in [RFC2409]. Upon successful completion it 583 results in the establishment of an IKE Phase 1 SA. 585 Discussion: 587 IKE Main Mode use 3 distinct message pairs, for a total of 6 588 messages. The first two messages negotiate policy; the next two 589 represent Diffie-Hellman public values and ancillary data (e.g. 590 nonces); and the last two messages authenticate the Diffie-Hellman 591 Exchange. The authentication method negotiated as part of the 592 initial IKE Phase 1 influence the composition of the payloads but 593 not their purpose. 595 Issues: 597 N/A 599 See Also: 601 ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 603 7.3.3. IKE Phase 1 Aggressive Mode 605 Definition: 607 Aggressive Mode is an instantiation of the ISAKMP Aggressive 608 Exchange, defined in [RFC2409]. Upon successful completion it 609 results in the establishment of an IKE Phase 1 SA. 611 Discussion: 613 IKE Aggressive Mode uses 3 messages. The first two messages 614 negotiate policy, exchange Diffie-Hellman public values and 615 ancillary data necessary for the exchange, and identities. In 616 addition the second message authenticates the Responder. The 617 third message authenticates the Initiator and provides proof of 618 participation in the exchange. 620 Issues: 622 For IKEv1 the standard specifies that all implementations use both 623 main and agressive mode, however, it is common to use only main 624 mode. 626 See Also: 628 ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 630 7.3.4. IKE Phase 2 632 Definition: 634 ISAKMP phase which upon successful completion establishes the 635 shared keys used by the negotiating peers to set up a secure "data 636 channel" for IPsec. 638 Discussion: 640 The main purpose of Phase 2 is to produce the key for the IPsec 641 tunnel. Phase 2 is also used for exchanging informational 642 messages. 644 Issues: 646 In other documents also referenced as IPsec SA. 648 See Also: 650 IKE Phase 1, ISAKMP, IKE 652 7.3.5. Phase 2 Quick Mode 654 Definition: 656 Quick Mode is an instanciation of IKE Phase 2. After successful 657 completion it will result in one or typically two or more IPsec 658 SA's 660 Discussion: 662 Quick Mode is used to negotiate the SA's and keys that will be 663 used to protect the user data. Three different messages are 664 exchanged, which are protected by the security parameters 665 negotiated by the IKE phase 1 exchange. An additional Diffie- 666 Hellman exchange may be performed if PFS (Perfect Forward Secrecy) 667 is enabled. 669 Issues: 671 N/A 673 See Also: 675 ISAKMP, IKE, IKE Phase 2 677 7.4. Security Association (SA) 679 Definition: 681 A set of policy and key(s) used to protect traffic flows that 682 require authentication and/or encryption services. It is a 683 negotiation agreement between two IPsec devices, specifically the 684 Initiator and Responder. 686 Discussion: 688 A simplex (unidirectional) logical connection that links a traffic 689 flow to a set of security parameters. All traffic traversing an 690 SA is provided the same security processing and will be subjected 691 to a common set of encryption and/or authentication algorithms. 692 In IPsec, an SA is an Internet layer abstraction implemented 693 through the use of AH or ESP as defined in [RFC2401]. 695 Issues: 697 N/A 699 See Also: 701 Initiator, Responder 703 7.5. Selectors 705 Definition: 707 A mechanism used for the classification of traffic flows that 708 require authentication and/or encryption services. 710 Discussion: 712 The selectors are a set of fields that will be extracted from the 713 network and transport layer headers that provide the ability to 714 classify the traffic flow and associate it with an SA. 716 After classification, a decision can be made if the traffic needs 717 to be encrypted/decrypted and how this should be done depending on 718 the SA linked to the traffic flow. Simply put, selectors classify 719 IP packets that require IPsec processing and those packets that 720 must be passed along without any intervention of the IPsec 721 framework. 723 Selectors are flexible objects that can match on ranges of source 724 and destination addresses and ranges of source and destination 725 ports. 727 Issues: 729 Both sides must agree exactly on both the networks being 730 protected, and they both must agree on how to describe the 731 networks (range, subnet, addresses). This is a common point of 732 non-interoperability. 734 7.6. IPsec Device 736 Definition: 738 Any implementation that has the ability to process data flows 739 according to the IPsec protocol suite specifications. 741 Discussion: 743 Implementations can be grouped by 'external' properties (e.g. 744 software vs. hardware implementations) but more important is the 745 subtle differences that implementations may have with relation to 746 the IPsec Protocol Suite. Not all implementations will cover all 747 RFC's that encompass the IPsec Protocol Suite, but the majority 748 will support a large subset of features described in the suite, 749 nor will all implementations utilize all of the cryptographic 750 functions listed in the RFC's. 752 In that context, any implementation, that supports basic IP layer 753 security services as described in the IPsec protocol suite shall 754 be called an IPsec Device. 756 Issues: 758 Due to the fragmented nature of the IPsec Protocol Suite RFC's, it 759 is possible that IPsec implementations will not be able to 760 interoperate. Therefore it is important to know which features 761 and options are implemented in the IPsec Device. 763 See Also: 765 IPsec 767 7.6.1. Initiator 769 Definition: 771 An IPsec device which starts the negotiation of IKE Phase 1 and 772 IKE Phase 2 SAs. 774 Discussion: 776 When a traffic flow is offered at an IPsec device and it is 777 determined that the flow must be protected, but there is no IPsec 778 tunnel to send the traffic through, it is the responsibility of 779 the IPsec device to start a negotiation process that will 780 instantiate the IPsec tunnel. This process will establish an IKE 781 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 782 eventually resulting in secured data transport. The device that 783 takes the action to start this negotiation process will be called 784 an Initiator. 786 Issues: 788 IPsec devices/implementations can be both an initiator as well as 789 a responder. The distinction is useful from a test perspective. 791 See Also: 793 Responder, IKE, IPsec 795 7.6.2. Responder 796 Definition: 798 An IPsec device which replies to incoming IKE Phase 1 and IKE 799 Phase 2 requests and processes these messages in order to 800 establish an IPsec tunnel. 802 Discussion: 804 When an initiator attempts to establish SA's with another IPsec 805 device, this peer will need to evaluate the proposals made by the 806 initiator and either accept or deny them. In the former case, the 807 traffic flow will be decrypted according to the negotiated 808 parameters. Such a device will be called a Responder. 810 Issues: 812 IPsec devices/implementations can usually be both an initiator as 813 well as a responder. The distinction is useful from a test 814 perspective. 816 See Also: 818 Initiator, IKE 820 7.6.3. IPsec Client 822 Definition: 824 IPsec Devices that will only act as an Initiator. 826 Discussion: 828 In some situations it is not needed or prefered to have an IPsec 829 device respond to an inbound IKE SA or IPsec SA request. In the 830 case of e.g. road warriors or home office scenarios the only 831 property needed from the IPsec device is the ability to securely 832 connect to a remote private network. The IPsec Client will 833 initiate one or more IPsec tunnels to an IPsec Server on the 834 network that needs to be accessed and to provide the required 835 security services. An IPsec client will silently drop and ignore 836 any inbound IPsec tunnel requests. IPsec clients are generally 837 used to connect remote users in a secure fashion over the Internet 838 to a private network. 840 Issues: 842 N/A 844 See Also: 846 IPsec device, IPsec Server, Initiator, Responder 848 7.6.4. IPsec Server 850 Definition: 852 IPsec Devices that can both act as an Initiator as well as a 853 Responder. 855 Discussion: 857 IPsec Servers are mostly positioned at private network edges and 858 provide several functions: 860 * Responds to IPsec tunnel setup request from IPsec Clients. 862 * Responds to IPsec tunnel setup request from other IPsec devices 863 (Initiators). 865 * Initiate IPsec tunnels to other IPsec servers inside or outside 866 the private network. 868 Issues: 870 IPsec Servers are also sometimes referred to as 'VPN 871 Concentrators'. 873 See Also: 875 IPsec Device, IPsec Client, Initiator, Responder 877 7.7. Tunnels 879 The term "tunnel" is often used in a variety of contexts. To avoid 880 any discrepancies, in this document, the following distinctions have 881 been defined: 883 7.7.1. IPsec Tunnel 885 Definition: 887 The combination of an IKE Phase 1 SA and a pair of IKE Phase 2 888 SA's. 890 Discussion: 892 An IPsec Tunnel will be defined as a single (1) Phase 1 SA and a 893 pair (2) Phase 2 SA's. This construct will allow bidirectional 894 traffic to be passed between two IPsec Devices where the traffic 895 can benefit form the services offered in the IPsec framework. 897 Issues: 899 Since it is implied that a Phase 1 SA is used, an IPsec Tunnel 900 will be by definition a dynamically negotiated secured link. If 901 manual keying is used to enable secure data transport, then this 902 link will merely be referred to as a pair of IPsec SA's. 904 It is very likely that more then one pair of Phase 2 SA's are 905 associated with a single Phase 1 SA. Also in this case, the IPsec 906 Tunnel definition WILL NOT apply. Instead the ratio between Phase 907 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella 908 term of "IPsec Tunnel" MUST NOT be used in this context. 910 See Also: 912 IKE Phase 1, IKE Phase 2 914 7.7.2. Configured Tunnel 916 Definition: 918 An IPsec tunnel or a pair of IPsec SAs in the case of manual 919 keying that is provisioned in the IPsec device's configuration. 921 Discussion: 923 Several steps are required before IPsec can be used to actually 924 transport traffic. The very first step is to configure the IPsec 925 Tunnel (or IPsec SAs in the case of manual keying) in the IPsec 926 device. When using IKE there are no SA's associated with the 927 IPsec Tunnel and no traffic is going through the IPsec device that 928 matches the Selectors, which would instantiate the IPsec Tunnel. 929 When using either manual keying or IKE, a configured tunnel will 930 not have a populated SADB. 932 Issues: 934 When using IKE, a configured tunnel will not have any SAs while 935 with manual keying, the SAs will have simply been configured but 936 not populated in the SADB. 938 See Also: 940 IPsec Tunnel, Established Tunnel, Active Tunnel 942 7.7.3. Established Tunnel 944 Definition: 946 An IPsec device that has a populated SADB and is ready to provide 947 security services to the appropriate traffic. 949 Discussion: 951 When using IKE, a second step needed to ensure that an IPsec 952 Tunnel can transport data is to complete the Phase 1 and Phase 2 953 negotiations. After the packet classification process has 954 asserted that a packet requires security services, the negotation 955 is started to obtain both Phase 1 and Phase 2 SAs. After this is 956 completed and the SADB is populated, the IPsec Tunnel is called 957 'Established'. Note that at this time there is still no traffic 958 flowing through the IPsec Tunnel. Just enough packet(s) have been 959 sent to the IPsec device that matched the selectors and triggered 960 the IPsec Tunnel setup to result in a populated SADB. In the case 961 of manual keying, populating the SADB is accomplished by a 962 separate administrative command. 964 Issues: 966 N/A 968 See Also: 970 IPsec Tunnel, Configured Tunnel, Active Tunnel 972 7.7.4. Active Tunnel 974 Definition: 976 An IPsec device that is forwarding secured data. 978 Discussion: 980 When a Tunnel is Established and it is transporting traffic that 981 is authenticated and/or encrypted, the tunnel is called 'Active'. 983 Issues: 985 The distinction between an Active Tunnel and Configured/ 986 Established Tunnel is made in the context of manual keyed Tunnels. 987 In this case it would be possible to have an Established tunnel on 988 an IPsec device which has no counterpart on it's corresponding 989 peer. This will lead to encrypted traffic flows which will be 990 discarded on the receiving peer. Only if both peers have an 991 Established Tunnel that shows evidence of traffic transport, it 992 may be called an Active Tunnel. 994 See Also: 996 IPsec Tunnel, Configured Tunnel, Established Tunnel 998 7.8. Iterated Tunnels 1000 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 1001 The bundles are divided into two major groups : 1003 7.8.1. Nested Tunnels 1005 Definition: 1007 An SA bundle consisting of two or more 'tunnel mode' SA's. 1009 Discussion: 1011 The process of nesting tunnels can theoretically be repeated 1012 multiple times (for example, tunnels can be many levels deep), but 1013 for all practical purposes, most implementations limit the level 1014 of nesting. Nested tunnels can use a mix of AH and ESP 1015 encapsulated traffic. 1017 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1018 | | | | 1019 | | | | 1020 | +----{SA1 (ESP tunnel)}----+ | 1021 | | 1022 +--------------{SA2 (AH tunnel)}---------------+ 1024 In the IP Cloud a packet would have a format like this : 1025 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 1027 Nested tunnels can be deployed to provide additional security on 1028 already secured traffic. A typical example of this would be that 1029 the inner gateways (GW2 and GW3) are securing traffic between two 1030 branch offices and the outer gateways (GW1 & GW4) add an 1031 additional layer of security between departments within those 1032 branch offices. 1034 Issues: 1036 N/A 1038 See Also: 1040 Transport Adjacency, IPsec Tunnel 1042 7.8.2. Transport Adjacency 1044 Definition: 1046 An SA bundle consisting of two or more transport mode SA's. 1048 Discussion: 1050 Transport adjacency is a form of tunnel nesting. In this case two 1051 or more transport mode IPsec tunnels are set side by side to 1052 enhance applied security properties. 1054 Transport adjacency can be used with a mix of AH and ESP tunnels 1055 although some combinations are not preferred. If AH and ESP are 1056 mixed, the ESP tunnel should always encapsulate the AH tunnel. 1057 The reverse combination is a valid combination but doesn't make 1058 cryptographical sense. 1060 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1061 | | | | 1062 | | | | 1063 | +------{SA1 (ESP transport)}--------+ | 1064 | | 1065 +-------------{SA2 (AH transport)}--------------+ 1067 In the IP Cloud a packet would have a format like this : 1068 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 1070 Issues: 1072 This is rarely used in the way it is depicted. It is more common, 1073 but still not likely, that SA's are established from different 1074 gateways as depicted in the Nested Tunnels figure. The packet 1075 format in the IP Cloud would remain unchanged. 1077 See Also: 1079 Nested Tunnels, IPsec Tunnel 1081 7.9. Transform protocols 1083 Definition: 1085 Encryption and authentication algorithms that provide cryptograhic 1086 services to the IPsec Protocols. 1088 Discussion: 1090 Some algorithms run significantly slower than others. A decision 1091 for which algorithm to use is usually based on the tradeoff 1092 between performance and security strength. For example, 3DES 1093 encryption is generally slower then DES encryption. 1095 Issues: 1097 N/A 1099 See Also: 1101 Authentication protocols, Encryption protocols 1103 7.9.1. Authentication Protocols 1105 Definition: 1107 Algorithms which provide data integrity and data source 1108 authentication. 1110 Discussion: 1112 Authentication protocols provide no confidentiality. Commonly 1113 used authentication algorithms/protocols are: 1115 * MD5-HMAC 1116 * SHA-HMAC 1117 * AES-HMAC 1119 Issues: 1121 N/A 1123 See Also: 1125 Transform protocols, Encryption protocols 1127 7.9.2. Encryption Protocols 1129 Definition: 1131 Algorithms which provide data confidentiality. 1133 Discussion: 1135 Encryption protocols provide no authentication. Commonly used 1136 encryption algorithms/protocols are: 1138 * NULL encryption 1139 * DES-CBC 1140 * 3DES-CBC 1141 * AES-CBC 1143 Issues: 1145 The null-encryption option is a valid encryption mechanism to 1146 provide an alternative to using AH. There is no confidentiality 1147 protection with null-encryption. Note also that when using ESP 1148 null-encryption the authentication and integrity services only 1149 apply for the upper layer protocols and not for the IP header 1150 itself. 1152 DES has been officially deprecated by NIST, though it is still 1153 mandated by the IPsec framework and is still commonly implemented 1154 and used due to it's speed advantage over 3DES. AES will be the 1155 successor of 3DES due to its superior encryption and performance 1156 advantage. 1158 See Also: 1160 Transform protocols, Authentication protocols 1162 7.10. IPsec Protocols 1164 Definition: 1166 A suite of protocols which provide a framework of open standards 1167 that provides data origin confidentiality, data integrity, and 1168 data origin authenticity between participating peers at the IP 1169 layer. The IPsec protocol suite set of standards is documented in 1170 [RFC2401] through [RFC2412] and [RFC2451]. 1172 Discussion: 1174 The IPsec Protocol suite is modular and forward compatible. The 1175 protocols that comprise the IPsec protocol suite can be replaced 1176 with new versions of those protocols as the older versions become 1177 obsolete. For example, IKEv2 will soon replace IKEv1. 1179 Issues: 1181 N/A 1183 See Also: 1185 AH, ESP 1187 7.10.1. Authentication Header (AH) 1189 Definition: 1191 Provides data origin authentication and data integrity (including 1192 replay protection) security services as defined in [RFC2402]. 1194 Discussion: 1196 The AH protocol supports two modes of operation i.e. tunnel mode 1197 and transport mode. 1199 In transport mode, AH is inserted after the IP header and before a 1200 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any 1201 other IPsec headers that have already been inserted. In the 1202 context of IPv4, this calls for placing AH after the IP header 1203 (and any options that it contains), but before the next layer 1204 protocol. In the IPv6 context, AH is viewed as an end-to-end 1205 payload, and thus should appear after hop-by-hop, routing, and 1206 fragmentation extension headers. The destination options 1207 extension header(s) could appear before or after or both before 1208 and after the AH header depending on the semantics desired. 1210 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1211 source and destination addresses, while an "outer" IP header 1212 contains the addresses of the IPsec "peers," e.g., addresses of 1213 security gateways. In tunnel mode, AH protects the entire inner 1214 IP packet, including the entire inner IP header. The position of 1215 AH in tunnel mode, relative to the outer IP header, is the same as 1216 for AH in transport mode. 1218 Issues: 1220 AH is rarely used to secure traffic over the Internet. 1222 See Also: 1224 Transform protocols, IPsec protocols, Encapsulated Security 1225 Payload 1227 7.10.2. Encapsulated Security Payload (ESP) 1229 Definition: 1231 Provides data origin authentication, data integrity (including 1232 replay protection) and data confidentiality as defined in 1233 [RFC2406]. 1235 Discussion: 1237 The ESP protocol supports two modes of operation i.e. tunnel mode 1238 and transport mode. 1240 In transport mode, ESP is inserted after the IP header and before 1241 a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context 1242 of IPv4, this translates to placing ESP after the IP header (and 1243 any options that it contains), but before the next layer protocol. 1244 In the IPv6 context, ESP is viewed as an end-to-end payload, and 1245 thus should appear after hop-by-hop, routing, and fragmentation 1246 extension headers. Destination options extension header(s) could 1247 appear before, after, or both before and after the ESP header 1248 depending on the semantics desired. However, since ESP protects 1249 only fields after the ESP header, it generally will be desirable 1250 to place the destination options header(s) after the ESP header. 1252 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1253 source and destination addresses, while an "outer" IP header 1254 contains the addresses of the IPsec "peers", e.g., addresses of 1255 security gateways. Mixed inner and outer IP versions are allowed, 1256 i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP 1257 protects the entire inner IP packet, including the entire inner IP 1258 header. The position of ESP in tunnel mode, relative to the outer 1259 IP header, is the same as for ESP in transport mode. 1261 Issues: 1263 N/A 1265 See Also: 1267 Transform protocols, IPsec protocols, Authentication Header 1269 7.11. NAT Traversal (NAT-T) 1271 Definition: 1273 The capability to support IPsec functionality in the presence of 1274 NAT devices. 1276 Discussion: 1278 NAT-Traversal requires some modifications to IKE as defined in 1279 [RFC3947]. Specifically, in phase 1, it requires detecting if the 1280 other end supports NAT-Traversal, and detecting if there are one 1281 or more NAT instances along the path from host to host. In IKE 1282 Quick Mode, there is a need to negotiate the use of UDP 1283 encapsulated IPsec packets. 1285 NAT-T also describes how to transmit the original source and 1286 destination addresses to the corresponding IPsec Device. The 1287 original source and destination addresses are used in transport 1288 mode to incrementally update the TCP/IP checksums so that they 1289 will match after the NAT transform (The NAT cannot do this, 1290 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1291 packet). 1293 Issues: 1295 N/A 1297 See Also: 1299 IKE, ISAKMP, IPsec Device 1301 7.12. IP Compression 1303 Definition: 1305 A mechanism as defined in [RFC2393] that reduces the size of the 1306 payload that needs to be encrypted. 1308 Discussion: 1310 IP payload compression is a protocol to reduce the size of IP 1311 datagrams. This protocol will increase the overall communication 1312 performance between a pair of communicating hosts/gateways 1313 ("nodes") by compressing the datagrams, provided the nodes have 1314 sufficient computation power, through either CPU capacity or a 1315 compression coprocessor, and the communication is over slow or 1316 congested links. 1318 IP payload compression is especially useful when encryption is 1319 applied to IP datagrams. Encrypting the IP datagram causes the 1320 data to be random in nature, rendering compression at lower 1321 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1322 ineffective. If both compression and encryption are required, 1323 compression must be applied before encryption. 1325 Issues: 1327 N/A 1329 See Also: 1331 IKE, ISAKMP, IPsec Device 1333 7.13. Security Context 1335 Definition: 1337 A security context is a collection of security parameters that 1338 describe the characteristics of the path that an IPsec Tunnel will 1339 take, all of the IPsec Tunnel parameters and the effects it has on 1340 the underlying protected traffic. Security Context encompasses 1341 protocol suite and security policy. 1343 Discussion: 1345 In order to fairly compare multiple IPsec devices it is imperative 1346 that an accurate overview is given of all security parameters that 1347 were used to establish the IPsec Tunnels or manually created SAs 1348 and to secure the traffic between protected networks. Security 1349 Context is not a metric; it is included to accurately reflect the 1350 test environment variables when reporting the methodology results. 1351 To avoid listing too much information when reporting metrics, we 1352 have divided the security context into an IKE context and an IPsec 1353 context. 1355 When merely discussing the behavior of traffic flows through IPsec 1356 devices, an IPsec context MUST be provided. In other cases the 1357 scope of a discussion or report may focus on a more broad set of 1358 behavioral characteristics of the IPsec device, in which case both 1359 an IPsec and an IKE context MUST be provided. 1361 The IPsec context MUST consist of the following elements: 1363 * Manual Keyed Tunnels versus IKE negotiated Tunnels 1365 * Number of IPsec Tunnels or IPsec SA's 1367 * IPsec protocol (AH or ESP) 1369 * IPsec protocol mode (tunnel or transport) 1371 * Authentication algorithm used by AH/ESP 1373 * Encryption algoritm used ESP (if applicable) 1375 * IPsec SA lifetime (traffic and time based) 1377 The IPsec Context MAY also list: 1379 * Selectors 1381 * Fragmentation handling 1383 The IKE Context MUST consist of the following elements: 1385 * Number of IPsec Tunnels. 1387 + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable) 1389 + IKE Phase 1 parameters 1390 - Authentication algorithm 1392 - Encryption algorithm 1394 - DH-Group 1396 - SA lifetime (traffic and time based) 1398 - Authentication mechanism (pre-shared key, RSA-sig, 1399 certificate, etc) 1401 + IKE Phase 2 parameters 1403 - IPsec protocol (part of IPsec context) 1405 - IPsec protocol mode (part of IPsec context) 1407 - Authentication algorithm (part of IPsec context) 1409 - Encryption algorithm (part of IPsec context) 1411 - DH-Group 1413 - PFS used 1415 - SA Lifetime (part of IPsec context) 1417 * Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd] 1419 * IP Compression [RFC2393] 1421 The IKE context MAY also list: 1423 * Phase 1 mode (main or aggressive) 1425 * Available bandwidth and latency to Certificate Authority server 1426 (if applicable) 1428 Issues: 1430 A Security Context will be an important element in describing the 1431 environment where protected traffic is traveling through. 1433 See Also: 1435 IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, 1436 Selectors, IPsec Tunnel 1438 8. Framesizes 1440 8.1. Layer3 clear framesize 1442 Definition: 1444 The total size of the unencrypted L3 PDU. 1446 Discussion: 1448 In relation to IPsec this is the size of the IP header and its 1449 payload. It SHALL NOT include any encapsulations that MAY be 1450 applied before the PDU is processed for encryption. 1452 IPv4 example: 46 bytes PDU = 20 bytes IP header + 26 bytes 1453 payload. 1455 Measurement Units: 1457 Bytes 1459 Issues: 1461 N/A 1463 See Also: 1465 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1466 Encrypted Framesize. 1468 8.2. Layer3 encrypted framesize 1470 Definition: 1472 The total size of the encrypted L3 PDU. 1474 Discussion: 1476 The size of the IP packet and its payload after encapsulations MAY 1477 be applied and the PDU is being processed by the transform. 1479 For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform 1480 has been applied an unencrypted or clear layer3 framesize of 46 1481 bytes Becomes 96 bytes: 1483 20 bytes outer IP header (tunnel mode) 1484 4 bytes SPI (ESP header) 1485 4 bytes Sequence (ESP Header) 1486 8 bytes IV (IOS ESP-3DES) 1487 46 bytes payload 1488 0 bytes pad (ESP-3DES 64 bit) 1489 1 byte Pad length (ESP Trailer) 1490 1 byte Next Header (ESP Trailer) 1491 12 bytes ESP-HMAC SHA1 96 digest 1493 Measurement Units: 1495 Bytes 1497 Issues: 1499 N/A 1501 See Also: 1503 Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted 1504 Framesize. 1506 9. Performance Metrics 1508 9.1. IPsec Tunnels Per Second (TPS) 1510 Definition: 1512 The measurement unit for the IPsec Tunnel Setup Rate tests. The 1513 rate at which IPsec Tunnels are established per second. 1515 Discussion: 1517 According to [RFC2401] two IPsec Tunnels cannot be established 1518 between the same gateways with the same selectors. This is to 1519 prevent overlapping IPsec Tunnels. If overlapping IPsec Tunnels 1520 are attempted, the error will cause the IPsec Tunnel setup time to 1521 take longer than if the IPsec Tunnel setup was successful. For 1522 this reason, a unique pair of selector sets are required for IPsec 1523 Tunnel Setup Rate testing. 1525 Issues: 1527 A unique pair of selector sets are required for TPS testing. 1529 See Also: 1531 IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, IKE 1532 Setup Rate, IPsec Setup Rate 1534 9.2. Tunnel Rekeys Per Seconds (TRPS) 1536 Definition: 1538 A metric that quantifies the number of IKE Phase 1 or Phase 2 1539 rekeys per seconds a DUT can correctly process. 1541 Discussion: 1543 This metric will be will be primary used with Tunnel Rekey 1544 behavior tests. 1546 TRPS will provide a metric used to see system behavior under 1547 stressful conditions where large volumes of SA's are being rekeyed 1548 at the same time or in a short timespan. 1550 Issues: 1552 N/A 1554 See Also: 1556 Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey Rate 1558 9.3. IPsec Tunnel Attempts Per Second (TAPS) 1560 Definition: 1562 A metric that quantifies the number of successful and unsuccessful 1563 IPsec Tunnel establishment requests per second. 1565 Discussion: 1567 This metric can be used to measure IKE DOS Resilience behavior 1568 test. 1570 TAPS provides an important metric to validate the stability of an 1571 IPsec device, if stressed with valid (large number of IPsec tunnel 1572 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1573 any style) tunnel establishment requests. IPsec Tunnel setups 1574 offered to an IPsec devices can either fail due to lack of 1575 resources in the IPsec device to process all the requests or due 1576 to an IKE DOS attack (usually the former is a result of the 1577 latter). 1579 Issues: 1581 If the TAPS increases, the TPS usually decreases, due to burdening 1582 of the DUT with the DOS attack traffic. 1584 See Also: 1586 N/A 1588 10. Test Definitions 1590 10.1. Capacity 1592 10.1.1. IKE SA Capacity 1594 Definition: 1596 The maximum number of IKE SA's that can be sustained on an IPsec 1597 Device. 1599 Discussion: 1601 This metric will represent the quantity of peer a given IPsec 1602 device can establish. It is the maximum number of Active Tunnels 1603 that can be sustained by an IPsec Device. 1605 Measurement Units: 1607 IKE SA's 1609 Issues: 1611 N/A 1613 See Also: 1615 IPsec SA Capacity 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 This metric will represent the quantity of traffic flows a given 1627 IPsec Device can protect. In contrast with the IKE SA Capacity, 1628 the emphasis for this test lies on the number of IPsec SA's that 1629 can be established in the worst case scenario. This scenario 1630 would be a case where 1 IKE SA is used to negotiate multiple IPsec 1631 SA's. It is the maximum number of Active Tunnels that can be 1632 sustained by an IPsec Device where only 1 IKE SA is used to 1633 exchange keying material. 1635 Measurement Units: 1637 IPsec SA's 1639 Issues: 1641 N/A 1643 See Also: 1645 IKE SA Capacity 1647 10.2. Throughput 1649 10.2.1. IPsec Throughput 1651 Definition: 1653 The maximum rate through an Active Tunnel at which none of the 1654 offered frames are dropped by the device under test. 1656 Discussion: 1658 The IPsec Throughput is almost identically defined as Throughput 1659 in [RFC1242], section 3.17. The only difference is that the 1660 throughput is measured with a traffic flow getting encrypted and 1661 decrypted by an IPsec device. IPsec Throughput is an end-to-end 1662 measurement. 1664 The metric can be represented in two variantions depending on 1665 where measurement is taken in the SUT. One can look at throughput 1666 from a cleartext point of view i.e. find the maximum rate where 1667 clearpackets no longer get dropped. This resulting rate can be 1668 recalculated with an encrypted framesize to represent the 1669 encryption throughput rate. The latter is the preferred method of 1670 representation and shall be called the IPsec Throughput. 1672 Measurement Units: 1674 Packets per seconds (pps) 1676 Issues: 1678 N/A 1680 See Also: 1682 IPsec Encryption Throughput, IPsec Decryption Throughput 1684 10.2.2. IPsec Encryption Throughput 1686 Definition: 1688 The maximum encryption rate through an Active Tunnel at which none 1689 of the offered cleartext frames are dropped by the device under 1690 test. 1692 Discussion: 1694 Since encryption throughput is not necessarily equal to the 1695 decryption throughput, both of the forwarding rates must be 1696 measured independently. The independent forwarding rates have to 1697 measured with the help of an IPsec aware test device that can 1698 originate and terminate IPsec and IKE SA. As defined in 1699 [RFC1242], measurements should be taken with an assortment of 1700 frame sizes. 1702 Measurement Units: 1704 Packets per seconds (pps) 1706 Issues: 1708 In some cases packets are offered to an IPsec Device that have a 1709 framesize that is larger then the MTU of the ingress interface of 1710 the IPsec Tunnel that is transporting the packet. In this case 1711 fragmentation will be required before IPsec services are applied. 1713 In other cases, the packet is of a size very close to the MTU of 1714 the egress interface of the IPsec Tunnel. Here, the mere addition 1715 of the IPsec header will create enough overhead to make the IPsec 1716 packet larger then the MTU of the egress interface. In such 1717 instance, the original payload packet must be fragmented either 1718 before or after the IPsec overhead is applied. 1720 Note that the two aforementioned scenario's can happen 1721 simultaniously on a single packet, creating multiple small 1722 fragments. 1724 When measuring the IPsec Encryption Throughput, one has to 1725 consider that when probing with packets of a size near MTU's 1726 associated with the IPsec Tunnel, fragmentation may accor and the 1727 decrypting IPsec Device (either a tester or a corresponding IPsec 1728 peer) has to reassemble the IPsec and/or payload fragments to 1729 validate its content. 1731 The end points (i.e. hosts, subnets) should NOT see any fragments 1732 at ANY time. Only on the IPsec link, fragments MAY occur. 1734 See Also: 1736 IPsec Throughput, IPsec Decryption Throughput 1738 10.2.3. IPsec Decryption Throughput 1740 Definition: 1742 The maximum decryption rate through an Active Tunnel at which none 1743 of the offered encrypted frames are dropped by the device under 1744 test. 1746 Discussion: 1748 Since encryption throughput is not necessarily equal to the 1749 decryption throughput, both of the forwarding rates must be 1750 measured independently. 1752 The independent forwarding rates have to be measured with the help 1753 of an IPsec aware test device that can originate and terminate 1754 IPsec and IKE SA. As defined in [RFC1242], measurements should be 1755 taken with an assortment of frame sizes. 1757 Measurement Units: 1759 Packets per seconds (pps) 1761 Issues: 1763 When measuring the IPsec Decryption Throughput, one has to 1764 consider that it is likely that the encrypting IPsec Device has to 1765 fragment certain packets that have a frame size near MTU's 1766 associated with the IPsec Tunnel. 1768 The decrypting IPsec Device has to reassemble the IPsec and/or 1769 payload fragments to validate its content. 1771 The end points (i.e. hosts, subnets) should NOT see any fragments 1772 at ANY time. Only on the IPsec link, fragments MAY occur. 1774 See Also: 1776 IPsec Throughput, IPsec Encryption Throughput 1778 10.3. Latency 1780 10.3.1. IPsec Latency 1782 Definition: 1784 Time required to propagate a cleartext frame from the input 1785 interface of an initiator, through an Active Tunnel, to the output 1786 interface of the responder. 1788 Discussion: 1790 The IPsec Latency is the time interval starting when the end of 1791 the first bit of the cleartext frame reaches the input interface 1792 of the initiator and ending when the start of the first bit of the 1793 same cleartext frame is detected on the output interface of the 1794 responder. The frame has passed through an Active Tunnel between 1795 an initiator and a responder and has been through an encryption 1796 and decryption cycle. 1798 Measurement Units: 1800 Time units with enough precision to reflect latency measurement. 1802 Issues: 1804 N/A 1806 See Also: 1808 IPsec Encryption Latency, IPsec Decryption Latency 1810 10.3.2. IPsec Encryption Latency 1812 Definition: 1814 The IPsec Encryption Latency is the time interval starting when 1815 the end of the first bit of the cleartext frame reaches the input 1816 interface, through an Active Tunnel, and ending when the start of 1817 the first bit of the encrypted output frame is seen on the output 1818 interface. 1820 Discussion: 1822 IPsec Encryption Latency is the latency introduced when encrypting 1823 traffic through an IPsec tunnel. 1825 Like encryption/decryption throughput, it is not always the case 1826 that encryption latency equals the decryption latency. Therefore 1827 a distinction between the two has to be made in order to get a 1828 more accurate view of where the latency is the most pronounced. 1830 The independent encryption/decryption latencies have to be 1831 measured with the help of an IPsec aware test device that can 1832 originate and terminate IPsec and IKE SA. As defined in 1833 [RFC1242], measurements should be taken with an assortment of 1834 frame sizes. 1836 Measurement Units: 1838 Time units with enough precision to reflect latency measurement. 1840 Issues: 1842 N/A 1844 See Also: 1846 IPsec Latency, IPsec Decryption Latency 1848 10.3.3. IPsec Decryption Latency 1849 Definition: 1851 The IPsec decryption Latency is the time interval starting when 1852 the end of the first bit of the encrypted frame reaches the input 1853 interface, through an Active Tunnel, and ending when the start of 1854 the first bit of the decrypted output frame is seen on the output 1855 interface. 1857 Discussion: 1859 IPsec Decryption Latency is the latency introduced when decrypting 1860 traffic through an Active Tunnel. Like encryption/decryption 1861 throughput, it is not always the case that encryption latency 1862 equals the decryption latency. Therefore a distinction between 1863 the two has to be made in order to get a more accurate view of 1864 where the latency is the most pronounced. 1866 The independent encryption/decryption latencies have to be 1867 measured with the help of an IPsec aware test device that can 1868 originate and terminate IPsec and IKE SA's. As defined in 1869 [RFC1242], measurements should be taken with an assortment of 1870 frame sizes. 1872 Measurement Units: 1874 Time units with enough precision to reflect latency measurement. 1876 Issues: 1878 N/A 1880 See Also: 1882 IPsec Latency, IPsec Encryption Latency 1884 10.3.4. Time To First Packet 1886 Definition: 1888 The Time To First Packet (TTFP) is the time required to process a 1889 cleartext packet from a traffic stream that requires encryption 1890 services when no IPsec Tunnel is present. 1892 Discussion: 1894 The Time To First Packet addresses the issue of responsiveness of 1895 an IPsec device by looking how long it takes to transmit a packet 1896 over Configured Tunnel. The Time To First Packet MUST include the 1897 time to set up the established tunnel, triggered by the traffic 1898 flow (both phase 1 and phase 2 setup times SHALL be included) and 1899 the time it takes to encrypt and decrypt the packet on a 1900 corresponding peer. In short it is the IPsec Tunnel setup time 1901 plus the propagation delay of the packet through the Active 1902 Tunnel. 1904 It must be noted that it is highly unlikely that the first packet 1905 of the traffic flow will be the packet that will be used to 1906 measure the TTFP. There MAY be several protocol layers in the 1907 stack before the tunnel is formed and the traffic is forwarded, 1908 hence several packets COULD be lost during negotiation, for 1909 example, ARP and/or IKE. 1911 Measurement Units: 1913 Time units with enough precision to reflect a TTFP measurement. 1915 Issues: 1917 Only relevant when using IKE for tunnel negotiation. 1919 10.4. Frame Loss 1921 10.4.1. IPsec Frame Loss 1923 Definition: 1925 Percentage of cleartext frames that should have been forwarded 1926 through an Active Tunnel under steady state (constant) load but 1927 were dropped before encryption or after decryption. 1929 Discussion: 1931 The IPsec Frame Loss is almost identically defined as Frame Loss 1932 Rate in [RFC1242], section 3.6. The only difference is that the 1933 IPsec Frame Loss is measured with a traffic flow getting encrypted 1934 and decrypted by an IPsec Device. IPsec Frame Loss is an end-to- 1935 end measurement. 1937 Measurement Units: 1939 Percent (%) 1941 Issues: 1943 N/A 1945 See Also: 1947 IPsec Encryption Frame Loss, IPsec Decryption Frame Loss 1949 10.4.2. IPsec Encryption Frame Loss 1951 Definition: 1953 Percentage of cleartext frames that should have been encrypted 1954 through an Active Tunnel under steady state (constant) load but 1955 were dropped. 1957 Discussion: 1959 A DUT will always have an inherent forwarding limitation. This 1960 will be more pronounced when IPsec is employed on the DUT. There 1961 is a possibility that the offered traffic rate at the Active 1962 Tunnel is too high to be transported through the Active Tunnel and 1963 not all cleartext packets will get encrypted. In that case, some 1964 percentage of the cleartext traffic will be dropped. This drop 1965 percentage is called the IPsec Encryption Frame Loss. 1967 Measurement Units: 1969 Percent (%) 1971 Issues: 1973 N/A 1975 See Also: 1977 IPsec Frame Loss, IPsec Decryption Frame Loss 1979 10.4.3. IPsec Decryption Frame Loss 1981 Definition: 1983 Percentage of encrypted frames that should have been decrypted 1984 through an Active Tunnel under steady state (constant) load but 1985 were dropped. 1987 Discussion: 1989 A DUT will also have an inherent forwarding limitation when 1990 decrypting packets. When Active Tunnel encrypted traffic is 1991 offered at a costant load, there might be a possibility that the 1992 IPsec Device that needs to decrypt the traffic will not be able to 1993 perfom this action on all of the packets due to limitations of the 1994 decryption performance. The percentage of encrypted frames that 1995 would get dropped under these conditions is called the IPsec 1996 Decryption Frame Loss. 1998 Measurement Units: 2000 Percent (%) 2002 Issues: 2004 N/A 2006 See Also: 2008 IPsec Frame Loss, IPsec Encryption Frame Loss 2010 10.4.4. IKE Phase 2 Rekey Frame Loss 2012 Definition: 2014 Number of frames dropped as a result of an inefficient IKE Phase 2 2015 rekey. 2017 Discussion: 2019 Normal operation of an IPsec Device would require that a rekey 2020 does not create temporary IPsec Frame Loss of a traffic stream 2021 that is protected by the IKE Phase 2 SA's (i.e. IPsec SA's). 2022 Nevertheless there can be situations where IPsec Frame Loss occurs 2023 during this rekey process. 2025 This metric should be ideally zero but this may not be the case on 2026 IPsec Devices where IPsec funtionality is not a core feature. 2028 Measurement Units: 2030 Number of N-octet frames 2032 Issues: 2034 N/A 2036 See Also: 2038 IKE Phase 2 Rekey Rate 2040 10.5. Back-to-back Frames 2042 10.5.1. IPsec Back-to-back Frames 2044 Definition: 2046 A burst of cleartext frames, offered at a constant load that can 2047 be sent through an Active Tunnel without losing a single cleartext 2048 frame after decryption. 2050 Discussion: 2052 The IPsec Back-to-back Frames is almost identically defined as 2053 Back-to-back in [RFC1242], section 3.1. The only difference is 2054 that the IPsec Back-to-back Frames is measured with a traffic flow 2055 getting encrypted and decrypted by an IPsec Device. IPsec Back- 2056 to-back Frames is an end-to-end measurement. 2058 Measurement Units: 2060 Number of N-octet frames in burst. 2062 Issues: 2064 Recommended test frame sizes will be addressed in methodology 2065 document. 2067 See Also: 2069 IPsec Encryption Back-to-back frames, IPsec Decryption Back-to- 2070 back frames 2072 10.5.2. IPsec Encryption Back-to-back Frames 2074 Definition: 2076 A burst of cleartext frames, offered at a constant load that can 2077 be sent through an Active Tunnel without losing a single encrypted 2078 frame. 2080 Discussion: 2082 IPsec Encryption back-to-back frames is the measure of the maximum 2083 burst size that an IPsec Device can handle for encrypting traffic 2084 that it receives as plaintext. Since it is not necessarily the 2085 case that the maximum burst size a DUT can handle for encryption 2086 is equal to the maximum burst size a DUT can handle for 2087 decryption, both of these capabilities must be measured 2088 independently. The IPsec Encryption Back-to-back frame 2089 measurement has to be measured with the help of an IPsec aware 2090 test device that can decrypt the traffic to determine the validity 2091 of the encrypted frames. 2093 Measurement Units: 2095 Number of N-octet frames in burst. 2097 Issues: 2099 Recommended test frame sizes will be addressed in future 2100 methodology document. 2102 See Also: 2104 IPsec Back-to-back frames, IPsec Decryption Back-to-back frames 2106 10.5.3. IPsec Decryption Back-to-back Frames 2108 Definition: 2110 The number of encrypted frames, offered at a constant load, that 2111 can be sent through an Active Tunnel without losing a single 2112 cleartext frame. 2114 Discussion: 2116 IPsec Decryption Back-to-back frames is the measure of the maximum 2117 burst size that an IPsec Device can handle for decrypting traffic 2118 that it receives as encrypted traffic. Since it is not 2119 necessarily the case that the maximum burst size a DUT can handle 2120 for decryption is equal to the maximum burst size a DUT can handle 2121 for encryption, both of these capabilities must be measured 2122 independently. The IPsec Decryption Back-to-back frame 2123 measurement has to be measured with the help of an IPsec aware 2124 test device that can determine the validity of the decrypted 2125 frames. 2127 Measurement Units: 2129 Number of N-octet frames in burst. 2131 Issues: 2133 Recommended test frame sizes will be addressed in methodology 2134 document. 2136 See Also: 2138 IPsec Back-to-back frames, IPsec Encryption back-to-back frames 2140 10.6. Tunnel Setup Behavior 2142 10.6.1. IPsec Tunnel Setup Rate 2144 Definition: 2146 The maximum number of IPsec Tunnels per second that an IPsec 2147 Device can successfully establish. 2149 Discussion: 2151 The Tunnel Setup Rate SHOULD be measured at varying number of 2152 IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the DUT. 2153 Several factors may influence Tunnel Setup Rate, such as: TAPS 2154 rate, Background cleartext traffic load on the secure interface, 2155 Already established IPsec Tunnels, Authentication method such as 2156 pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used 2157 (when using RSA/DSS). 2159 Measurement Units: 2161 Tunnels Per Second (TPS) 2163 Issues: 2165 N/A 2167 See Also: 2169 IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel Rekey 2170 Behavior 2172 10.6.2. IKE Phase 1 Setup Rate 2174 Definition: 2176 The maximum number of sucessful IKE Phase 1 SA's per second that 2177 an IPsec Device can establish. 2179 Discussion: 2181 The Phase 1 Setup Rate is a portion of the IPsec Tunnel Setup 2182 Rate. In the process of establishing an IPsec Tunnel, it is 2183 interesting to know what the limiting factor of the IKE Finite 2184 State Machine (FSM) is i.e. is it limited by the Phase 1 2185 processing delays or rather by the Phase 2 processing delays. 2187 Measurement Units: 2189 Tunnels Per Second (TPS) 2191 Issues: 2193 N/A 2195 See Also: 2197 IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel 2198 Rekey Behavior 2200 10.6.3. IKE Phase 2 Setup Rate 2202 Definition: 2204 The maximum number of successfully IKE Phase 2 SA's per second 2205 that an IPsec Device can Only relevant when using IKE establish. 2207 Discussion: 2209 The IKE Phase 2 Setup Rate is a portion of the IPsec Tunnel Setup 2210 Rate. For identical reasons why it is required to quantify the 2211 IKE Phase 1 Setup Rate, it is a good practice to know the 2212 processing delays involved in setting up an IKE Phase 2 SA for 2213 each direction of the protected traffic flow. 2215 IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of 2216 two IKE Phase 2 SA's. 2218 Note that once you have the IPsec Tunnel Setup Rate and either the 2219 IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can 2220 extrapolate the unmeasured metric. It is however highly 2221 RECOMMENDED to measure all three metrics. 2223 Measurement Units: 2225 Tunnels Per Second (TPS) 2227 Issues: 2229 N/A 2231 See Also: 2233 IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec Tunnel 2234 Rekey Behavior 2236 10.7. IPsec Tunnel Rekey Behavior 2238 10.7.1. IKE Phase 1 Rekey Rate 2240 Definition: 2242 The number of IKE Phase 1 SA's that can be succesfully re- 2243 establish per second. 2245 Discussion: 2247 Although the IKE Phase 1 Rekey Rate has less impact on the 2248 forwarding behavior of traffic that requires security services 2249 then the IKE Phase 2 Rekey Rate, it can pose a large burden on the 2250 CPU or network processor of the IPsec Device. Due to the highly 2251 computational nature of a Phase 1 exchange, it may impact the 2252 stability of Active Tunnels in the network when the IPsec Device 2253 fails to properly rekey an IKE Phase 1 SA. 2255 Measurement Units: 2257 Tunnel Rekeys per second (TRPS) 2259 Issues: 2261 N/A 2263 See Also: 2265 IKE Phase 2 Rekey Rate 2267 10.7.2. IKE Phase 2 Rekey Rate 2269 Definition: 2271 The number of IKE Phase 2 SA's that can be succesfully re- 2272 negotiated per second. 2274 Discussion: 2276 Although many implementations will usually derive new keying 2277 material before the old keys expire, there may still be a period 2278 of time where frames get dropped before the IKE Phase 2 tunnels 2279 are successfully re-established. There may also be some packet 2280 loss introduced when the handover of traffic is done from the 2281 expired IPsec SA's to the newly negotiated IPsec SA's. To measure 2282 the IKE Phase 2 rekey rate, the measurement will require an IPsec 2283 aware test device to act as a responder when negotiating the new 2284 IKE Phase 2 keying material. 2286 The test methodology report must specify if PFS is enabled in 2287 reported security context. 2289 Measurement Units: 2291 Tunnel Rekeys per second (TRPS) 2293 Issues: 2295 N/A 2297 See Also: 2299 IKE Phase 1 Rekey Rate 2301 10.8. IPsec Tunnel Failover Time 2303 Definition: 2305 Time required to recover all IPsec Tunnels on a stanby IPsec 2306 Device, after a catastrophic failure occurs on the active IPsec 2307 Device. 2309 Discussion: 2311 Recovery time required to re-establish all IPsec Tunnels and 2312 reroute all traffic on a standby node or other failsafe system 2313 after a failure has occurred in the DUT/SUT. Failure can include 2314 but are not limited to a catastrophic IPsec Device failure, a 2315 encryption engine failure, link outage, etc ... . The recovery 2316 time is delta between the point of failure and the time the first 2317 packet is seen on the last restored IPsec Tunnel on the backup 2318 device. 2320 Measurement Units: 2322 Time units with enough precision to reflect IPsec Tunnel Failover 2323 Time. 2325 Issues: 2327 N/A 2329 11. Security Considerations 2331 As this document is solely for the purpose of providing test 2332 benchmarking terminology and describes neither a protocol nor a 2333 protocol's implementation; there are no security considerations 2334 associated with this document. 2336 12. Acknowledgements 2338 The authors would like to acknowledge the following individual for 2339 their help and participation of the compilation and editing of this 2340 document: Debby Stopp, Ixia. 2342 13. Contributors 2344 The authors would like to acknowledge the following individual for 2345 their significant help, guidance, and contributions to this document: 2346 Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. 2348 14. References 2349 14.1. Normative References 2351 [RFC1242] Bradner, S., "Benchmarking terminology for network 2352 interconnection devices", RFC 1242, July 1991. 2354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2355 Requirement Levels", BCP 14, RFC 2119, March 1997. 2357 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2358 Switching Devices", RFC 2285, February 1998. 2360 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 2361 Payload Compression Protocol (IPComp)", RFC 2393, 2362 December 1998. 2364 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2365 Internet Protocol", RFC 2401, November 1998. 2367 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 2368 RFC 2402, November 1998. 2370 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2371 ESP and AH", RFC 2403, November 1998. 2373 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2374 ESP and AH", RFC 2404, November 1998. 2376 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 2377 Algorithm With Explicit IV", RFC 2405, November 1998. 2379 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2380 Payload (ESP)", RFC 2406, November 1998. 2382 [RFC2407] Piper, D., "The Internet IP Security Domain of 2383 Interpretation for ISAKMP", RFC 2407, November 1998. 2385 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 2386 Security Association and Key Management Protocol 2387 (ISAKMP)", RFC 2408, November 1998. 2389 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2390 (IKE)", RFC 2409, November 1998. 2392 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2393 Its Use With IPsec", RFC 2410, November 1998. 2395 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 2396 Document Roadmap", RFC 2411, November 1998. 2398 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 2399 RFC 2412, November 1998. 2401 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2402 Algorithms", RFC 2451, November 1998. 2404 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 2405 Network Interconnect Devices", RFC 2544, March 1999. 2407 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 2408 March 1999. 2410 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 2411 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 2412 RFC 2661, August 1999. 2414 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2415 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2416 March 2000. 2418 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 2419 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 2420 January 2005. 2422 [I-D.ietf-ipsec-ikev2] 2423 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2424 draft-ietf-ipsec-ikev2-17 (work in progress), 2425 October 2004. 2427 [I-D.ietf-ipsec-dpd] 2428 Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- 2429 Based Method of Detecting Dead IKE Peers", 2430 draft-ietf-ipsec-dpd-04 (work in progress), October 2003. 2432 [I-D.ietf-ipsec-properties] 2433 Krywaniuk, A., "Security Properties of the IPsec Protocol 2434 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2435 July 2002. 2437 [FIPS.186-1.1998] 2438 National Institute of Standards and Technology, "Digital 2439 Signature Standard", FIPS PUB 186-1, December 1998, 2440 . 2442 14.2. Informative References 2444 [Designing Network Security] 2445 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2446 Published: May 07, 1999; Copyright: 1999, 1999. 2448 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2449 Mechanism for Internet", from IEEE Proceedings of the 2450 1996 Symposium on Network and Distributed Systems 2451 Security, 2452 URI http://www.research.ibm.com/security/skeme.ps, 1996. 2454 Authors' Addresses 2456 Merike Kaeo 2457 Double Shot Security 2458 520 Washington Blvd #363 2459 Marina Del Rey, CA 90292 2460 US 2462 Phone: +1 (310)866-0165 2463 Email: kaeo@merike.com 2465 Tim Van Herck 2466 Cisco Systems 2467 170 West Tasman Drive 2468 San Jose, CA 95134-1706 2469 US 2471 Email: herckt@cisco.com 2473 Michele Bustos 2474 IXIA 2475 26601 W. Agoura Rd. 2476 Calabasas, CA 91302 2477 US 2479 Phone: +1 (818)444-3244 2480 Email: mbustos@ixiacom.com 2482 Intellectual Property Statement 2484 The IETF takes no position regarding the validity or scope of any 2485 Intellectual Property Rights or other rights that might be claimed to 2486 pertain to the implementation or use of the technology described in 2487 this document or the extent to which any license under such rights 2488 might or might not be available; nor does it represent that it has 2489 made any independent effort to identify any such rights. Information 2490 on the procedures with respect to rights in RFC documents can be 2491 found in BCP 78 and BCP 79. 2493 Copies of IPR disclosures made to the IETF Secretariat and any 2494 assurances of licenses to be made available, or the result of an 2495 attempt made to obtain a general license or permission for the use of 2496 such proprietary rights by implementers or users of this 2497 specification can be obtained from the IETF on-line IPR repository at 2498 http://www.ietf.org/ipr. 2500 The IETF invites any interested party to bring to its attention any 2501 copyrights, patents or patent applications, or other proprietary 2502 rights that may cover technology that may be required to implement 2503 this standard. Please address the information to the IETF at 2504 ietf-ipr@ietf.org. 2506 Disclaimer of Validity 2508 This document and the information contained herein are provided on an 2509 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2510 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2511 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2512 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2513 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2514 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2516 Copyright Statement 2518 Copyright (C) The Internet Society (2006). This document is subject 2519 to the rights, licenses and restrictions contained in BCP 78, and 2520 except as set forth therein, the authors retain all their rights. 2522 Acknowledgment 2524 Funding for the RFC Editor function is currently provided by the 2525 Internet Society.