idnits 2.17.1 draft-ietf-bmwg-ipsec-term-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 55 longer pages, the longest (page 32) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 57 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 (August 2004) is 7194 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 1135, but not defined == Missing Reference: 'GW2' is mentioned on line 1135, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 1135, but not defined == Missing Reference: 'GW3' is mentioned on line 1135, but not defined == Missing Reference: 'GW4' is mentioned on line 1135, but not defined == Missing Reference: 'ESP' is mentioned on line 1310, but not defined == Missing Reference: 'AH' is mentioned on line 1277, but not defined == Missing Reference: 'IP' is mentioned on line 1143, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 1310, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 1310, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 1310, but not defined == Missing Reference: 'IP ORIG' is mentioned on line 1310, but not defined == Missing Reference: 'L4 HDR' is mentioned on line 1310, but not defined == Missing Reference: 'IP NEW' is mentioned on line 1310, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1372, but not defined == Unused Reference: 'RFC2119' is defined on line 2377, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 2393, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 2396, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 2399, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 2415, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 2418, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 2441, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-udp-encaps' is defined on line 2455, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-nat-reqts' is defined on line 2460, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2465, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 ** Downref: Normative reference to an Informational RFC: RFC 2285 ** Obsolete normative reference: RFC 2393 (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Informational RFC: RFC 2544 ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-dpd (ref. 'I-D.ietf-ipsec-dpd') ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-nat-reqts (ref. 'I-D.ietf-ipsec-nat-reqts') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipsec-properties' Summary: 18 errors (**), 0 flaws (~~), 31 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Benchmarking Working Group M. Bustos 2 Internet-Draft IXIA 3 Expires: January 30, 2005 T. Van Herck 4 Cisco Systems 5 M. Kaeo 6 Double Shot Security 7 August 2004 9 Terminology for Benchmarking IPSec Devices 10 draft-ietf-bmwg-ipsec-term-04 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 30, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This purpose of this document is to define terminology specific to 42 measuring the performance of IPsec devices. It builds upon the 43 tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF 44 Benchmarking Methodology Working Group (BMWG) documents used for 45 benchmarking routers and switches. This document seeks to extend 46 these efforts specific to the IPsec paradigm. The BMWG produces two 47 major classes of documents: Benchmarking Terminology documents and 48 Benchmarking Methodology documents. The Terminology documents 49 present the benchmarks and other related terms. The Methodology 50 documents define the procedures required to collect the benchmarks 51 cited in the corresponding Terminology documents. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . 4 57 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 58 2.1.1 Security Associations . . . . . . . . . . . . . . . . 6 59 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . 6 60 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Definition Format . . . . . . . . . . . . . . . . . . . . . 8 62 5. Key Words to Reflect Requirements . . . . . . . . . . . . . 9 63 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 9 64 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.3.1 IKEv1 Phase 1 . . . . . . . . . . . . . . . . . . . . 12 69 7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 12 70 7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13 71 7.3.4 IKEv2 Phase 1 . . . . . . . . . . . . . . . . . . . . 13 72 7.3.5 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14 73 7.3.6 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15 74 7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15 75 7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16 76 7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17 77 7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 17 78 7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . 18 79 7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . 18 80 7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . 19 81 7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . 20 83 7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 20 84 7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 21 85 7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . 22 86 7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . 22 87 7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . 23 88 7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 24 89 7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 24 90 7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 25 91 7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25 92 7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26 93 7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 26 94 7.10 IPSec Protocols . . . . . . . . . . . . . . . . . . . . 27 95 7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 28 96 7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 28 98 7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29 99 7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 30 100 7.13 Security Context . . . . . . . . . . . . . . . . . . . . 30 101 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 103 8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 104 8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34 105 8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34 106 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 35 107 9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35 108 9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36 109 9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36 110 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37 111 10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37 112 10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . 37 113 10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . 38 114 10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . 38 115 10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 39 116 10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . 39 117 10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40 118 10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41 119 10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 41 120 10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 42 121 10.3.1 IPSec Tunnel Frame Loss . . . . . . . . . . . . . . 42 122 10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43 123 10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 43 124 10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 44 125 10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45 126 10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . 45 127 10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . 45 128 10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . 46 129 10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47 130 10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47 131 10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 47 132 10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 48 133 10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49 134 10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49 135 10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 49 136 10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 50 137 10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51 138 11. Security Considerations . . . . . . . . . . . . . . . . . . 52 139 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 140 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 141 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 142 14.1 Normative References . . . . . . . . . . . . . . . . . . . 52 143 14.2 Informative References . . . . . . . . . . . . . . . . . . 54 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 145 Intellectual Property and Copyright Statements . . . . . . . 56 147 1. Introduction 149 Despite the need to secure communications over a public medium there 150 is no standard method of performance measurement nor a standard in 151 the terminology used to develop such hardware and software solutions. 152 This results in varied implementations which challenge 153 interoperability and direct performance comparisons. Standardized 154 IPsec terminology and performance test methodologies will enable 155 users to determine if the IPsec device they select will withstand 156 loads of secured traffic that meet their requirements. 158 To appropriately define the parameters and scope of this document, 159 this section will give a brief overview of the IPsec standard: 161 2. IPsec Fundamentals 163 IPsec is a framework of open standards that provides data 164 confidentiality, data integrity, and data authenticity between 165 participating peers. IPsec provides these security services at the 166 IP layer. IPsec uses IKE to handle negotiation of protocols and 167 algorithms based on local policy, and to generate the encryption and 168 authentication keys to be used. IPsec can be used to protect one or 169 more data flows between a pair of hosts, between a pair of security 170 gateways, or between a security gateway and a host. The IPsec 171 protocol suite set of standards is documented in RFC's [RFC2401] 172 through [RFC2412] and [RFC2451]. The reader is assumed to be 173 familiar with these documents. Some Internet Drafts supersede these 174 RFC's and will be taken into consideration. 176 IPsec itself defines the following: 178 Authentication Header (AH): A security protocol, defined in 179 [RFC2402], which provides data authentication and optional 180 anti-replay services. AH ensures the integrity and data origin 181 authentication of the IP datagram as well as the invariant fields in 182 the outer IP header. 184 Encapsulating Security Payload (ESP): A security protocol, defined in 185 [RFC2406], which provides confidentiality, data origin 186 authentication, connectionless integrity, an anti-replay service and 187 limited traffic flow confidentiality. The set of services provided 188 depends on options selected at the time of Security Association (SA) 189 establishment and on the location of the implementation in a network 190 topology. ESP authenticates only headers and data after the IP 191 header. 193 Internet Key Exchange (IKE): A hybrid protocol which implements 194 Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP 195 framework. While IKE can be used with other protocols, its initial 196 implementation is with the IPsec protocol. IKE provides 197 authentication of the IPsec peers, negotiates IPsec security 198 associations, and establishes IPsec keys. 200 The AH and ESP protocols each support two modes of operation: 201 transport mode and tunnel mode. In transport mode, two hosts provide 202 protection primarily for upper-layer protocols. The cryptographic 203 endpoints (where the encryption and decryption take place) are the 204 source and destination of the data packet. In IPv4, a transport mode 205 security protocol header appears immediately after the IP header and 206 before any higher-layer protocols (such as TCP or UDP). 208 In the case of AH in transport mode, all upper-layer information is 209 protected, and all fields in the IPv4 header excluding the fields 210 typically are modified in transit. The fields of the IPv4 header 211 that are not included are, therefore, set to 0 before applying the 212 authentication algorithm. These fields are as follows: 214 * TOS 215 * TTL 216 * Header Checksum 217 * Offset 218 * Flags 220 In the case of ESP in transport mode, security services are provide 221 only for the higher-layer protocols, not for the IP header. 223 A tunnel is a vehicle for encapsulating packets inside a protocol 224 that is understood at the entry and exit points of a given network. 225 These entry and exit points are defined as tunnel interfaces. 227 Both the AH and ESP protocols can be used in tunnel mode for data 228 packet endpoints as well as by intermediate security gateways. In 229 tunnel mode, there is an "outer" IP header that specifies the IPsec 230 processing destination, plus an "inner" IP header that specifies the 231 ultimate destination for the packet. The source address in the outer 232 IP header is the initiating cryptographic endpoint; the source 233 address in the inner header is the true source address of the packet. 234 The security protocol header appears after the outer IP header and 235 before the inner IP header. 237 If AH is employed in tunnel mode, portions of the outer IP header are 238 given protection (those same fields as for transport mode, described 239 earlier in this section), as well as all of the tunneled IP packet 240 (that is, all of the inner IP header is protected as are the 241 higher-layer protocols). If ESP is employed, the protection is 242 afforded only to the tunneled packet, not to the outer header. 244 2.1 IPsec Operation 246 2.1.1 Security Associations 248 The concept of a Security Association (SA) is fundamental to IPsec. 249 An SA is a relationship between two or more entities that describes 250 how the entities will use security services to communicate. The SA 251 includes: an encryption algorithm, an authentication algorithm and a 252 shared session key. 254 Because an SA is unidirectional, two SAs (one in each direction) are 255 required to secure typical, bidirectional communication between two 256 entities. The security services associated with an SA can be used 257 for AH or ESP, but not for both. If both AH and ESP protection is 258 applied to a traffic stream, two (or more) SAs are created for each 259 direction to protect the traffic stream. 261 The SA is uniquely identified by the security parameter index (SPI) 262 [RFC2406]. When a system sends a packet that requires IPsec 263 protection, it looks up the SA in its database and applies the 264 specified processing and security protocol (AH/ESP), inserting the 265 SPI from the SA into the IPsec header. When the IPsec peer receives 266 the packet, it looks up the SA in its database by destination 267 address, protocol, and SPI and then processes the packet as required. 269 2.1.2 Key Management 271 IPsec uses cryptographic keys for authentication, integrity and 272 encryption services. Both manual provisioning and automatic 273 distribution of keys is supported. IKE is specified as the 274 public-key-based approach for automatic key management. 276 IKE authenticates each peer involved in IPsec, negotiates the 277 security policy, and handles the exchange of session keys. IKE is a 278 hybrid protocol, combining parts of the following protocols to 279 negotiate and derive keying material for SAs in a secure and 280 authenticated manner: 282 1. ISAKMP [RFC2408] (Internet Security Association and Key 283 Management Protocol), which provides a framework for 284 authentication and key exchange but does not define them. ISAKMP 285 is designed to be key exchange independent; it is designed to 286 support many different key exchanges. 288 2. Oakley [RFC2412], which describes a series of key exchanges, 289 called modes, and details the services provided by each (for 290 example, perfect forward secrecy for keys, identity protection, 291 and authentication). 293 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 294 describes a versatile key exchange technique that provides 295 anonymity, reputability, and quick key refreshment. 297 IKE creates an authenticated, secure tunnel between two entities and 298 then negotiates the security association for IPsec. This is 299 performed in two phases. 301 In Phase 1, the two unidirectional SA's establish a secure, 302 authenticated channel with which to communicate. Phase 1 has two 303 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 304 provides identity protection. When identity protection is not 305 needed, Aggressive Mode can be used. The completion of Phase 1 is 306 called an IKE SA. 308 The following attributes are used by IKE and are negotiated as part 309 of the IKE SA: 311 o Encryption algorithm. 313 o Hash algorithm. 315 o Authentication method (digital signature, public-key encryption or 316 pre-shared key). 318 o Diffie-Hellman group information. 320 After the attributes are negotiated, both parties must be 321 authenticated to each other. IKE supports multiple authentication 322 methods. The following mechanisms are generally implemented: 324 o Pre-shared keys: The same key is pre-installed on each host. IKE 325 peers authenticate each other by computing and sending a keyed 326 hash of data that includes the pre-shared key. If the receiving 327 peer can independently create the same hash using its preshared 328 key, it knows that both parties must share the same secret, and 329 thus the other party is authenticated. 331 o Public key cryptography: Each party generates a pseudo-random 332 number (a nonce) and encrypts it and its ID using the other 333 party's public key. The ability for each party to compute a keyed 334 hash containing the other peer's nonce and ID, decrypted with the 335 local private key, authenticates the parties to each other. This 336 method does not provide nonrepudiation; either side of the 337 exchange could plausibly deny that it took part in the exchange. 339 o Digital signature: Each device digitally signs a set of data and 340 sends it to the other party. This method is similar to the 341 public-key cryptography approach except that it provides 342 nonrepudiation. 344 Note that both digital signature and public-key cryptography require 345 the use of digital certificates to validate the public/private key 346 mapping. IKE allows the certificate to be accessed independently or 347 by having the two devices explicitly exchange certificates as part of 348 IKE. Both parties must have a shared session key to encrypt the IKE 349 tunnel. The Diffie-Hellman protocol is used to agree on a common 350 session key. 352 In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's 353 will be called IPsec SAs. These IPsec SA's use a different shared 354 key than that used for the IKE_SA. The IPsec SA shared key can be 355 derived by using Diffie-Hellman again or by refreshing the shared key 356 derived from the original Diffie-Hellman exchange that generated the 357 IKE_SA by hashing it with nonces. Once the shared key is derived and 358 additional communication parameters are negotiated, the IPsec SA's 359 are established and traffic can be exchanged using the negotiated 360 parameters. Note that for IKEv2, the term CHILD-SA is used for what 361 we call an IPsec SA. 363 3. Document Scope 365 The primary focus of this document is to establish useful performance 366 testing terminology for IPsec devices that support IKEv1. We want to 367 constrain the terminology specified in this document to meet the 368 requirements of the Methodology for Benchmarking IPSec Devices 369 documented test methodologies. The testing will be constrained to 370 devices acting as IPsec gateways and will pertain to both IPsec 371 tunnel and transport mode. 373 Any testing involving interoperability and/or conformance issues, 374 L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and 375 anything that does not specifically relate to the establishment and 376 tearing down of IPsec tunnels is specifically out of scope. It is 377 assumed that all relevant networking parameters that facilitate in 378 the running of these tests are pre-configured (this includes at a 379 minimum ARP caches and routing tables). This document will encompass 380 updates to AH, ESP and NAT Traversal. Since NAT traversal has been 381 included in the document, NAT is not included in this document. 383 4. Definition Format 385 The definition format utilized by this document is described in 386 [RFC1242], Section 2. 388 Term to be defined. 390 Definition: 392 The specific definition for the term. 394 Discussion: 396 A brief discussion of the term, its application, or other 397 information that would build understanding. 399 Issues: 401 List of issues or conditions that affect this term. This field 402 can present items the may impact the term's related methodology or 403 otherwise restrict its measurement procedures. 405 [Measurement units:] 407 Units used to record measurements of this term. This field is 408 mandatory where applicable. This field is optional in this 409 document. 411 [See Also:] 413 List of other terms that are relevant to the discussion of this 414 term. This field is optional in this document. 416 5. Key Words to Reflect Requirements 418 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 419 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 420 document are to be interpreted as described in RFC 2119. RFC 2119 421 defines the use of these key words to help make the intent of 422 standards track documents as clear as possible. While this document 423 uses these keywords, this document is not a standards track document. 425 6. Existing Benchmark Definitions 427 It is recommended that readers consult [RFC1242], [RFC2544] and 428 [RFC2285] before making use of this document. These and other IETF 429 Benchmarking Methodology Working Group (BMWG) router and switch 430 documents contain several existing terms relevant to benchmarking the 431 performance of IPsec devices. The conceptual framework established 432 in these earlier RFCs will be evident in this document. 434 This document also draws on existing terminology defined in other 435 BMWG documents. Examples include, but are not limited to: 437 Throughput [RFC 1242, section 3.17] 438 Latency [RFC 1242, section 3.8] 439 Frame Loss Rate [RFC 1242, section 3.6] 440 Forwarding Rates [RFC 2285, section 3.6] 441 Loads [RFC 2285, section 3.5] 443 Note: "DUT/SUT" refers to a metric that may be applicable to a DUT 444 (Device Under Test) or an SUT (System Under Test). 446 7. Definitions 448 7.1 IPsec 450 Definition: 452 IPsec or IP Security protocol suite which comprises a set of 453 standards used to provide security services at the IP layer. 455 Discussion: 457 IPsec is a framework of protocols that offer authentication, 458 authenticity and encryption services to the IP and/or upper layer 459 protocols. The major components of the protocol suite are IKE, 460 used for key exchanges, and IPsec protocols such as AH and ESP, 461 which use the exchanged keys to protect payload traffic. 463 Issues: 465 N/A 467 See Also: 469 IPsec Device, IKE, ISAKMP, ESP, AH 471 7.2 ISAKMP 473 Definition: 475 The Internet Security Association and Key Management Protocol, 476 which provides a framework for authentication and key exchange but 477 does not define them. ISAKMP is designed to be key exchange 478 independent; it is designed to support many different key 479 exchanges. ISAKMP is defined in [RFC2407]. 481 Discussion: 483 Though ISAKMP is only a framework for the IPsec standard key 484 management protocol, it is often misused and interchanged with the 485 term 'IKE', which is an implementation of ISAKMP. 487 Issues: 489 When implementations refer to the term 'ISAKMP SA', it refers to 490 an IKE Phase 1 SA. 492 See Also: 494 IKE, Security Association 496 7.3 IKE 498 Definition: 500 A hybrid key management protocol that allows secure negotiation of 501 IPsec SA paramters. 503 Discussion: 505 A hybrid protocol, defined in [RFC2409], from the following 3 506 protocols: 508 * ISAKMP (Internet Security Association and Key Management 509 Protocol), which provides a framework for authentication and 510 key exchange but does not define them. ISAKMP is designed to 511 be key exchange independent; it is designed to support many 512 different key exchanges. 514 * Oakley, which describes a series of key exchanges, called 515 modes, and details the services provided by each (for example, 516 perfect forward secrecy for keys, identity protection, and 517 authentication). [RFC2412] 519 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 520 describes a versatile key exchange technique that provides 521 anonymity, reputability, and quick key refreshment. 523 Note that IKE is an optional protocol within the IPsec framework. 524 Tunnels may also be manually configured i.e. the administrator 525 will provide keys that will be associated with the Phase 2 SA's as 526 long as the IPsec Tunnel is configured. This method is the most 527 basic mechanism to establish an IPsec tunnel between two IPsec 528 devices but it also decreases the level of protection since the 529 keys are not changing as they normally would during an IKE phase 2 530 rekey. 532 Issues: 534 During the first IPsec deployment experiences, ambiguities were 535 found in the IKEv1 specification, which lead to interoperability 536 problems. To resolve these issues, IKEv1 is being updated by 537 IKEv2. 539 See Also: 541 ISAKMP, IPsec, Security Association 543 7.3.1 IKEv1 Phase 1 545 Definition: 547 The shared policy and key(s) used by negotiating peers to set up a 548 secure authenticated "control channel" for further IKE 549 communications. 551 Discussion: 553 Note that IKE is an optional protocol within the IPsec framework 554 and keys can also be manually configured. 556 Issues: 558 In other documents often referenced as ISAKMP SA or IKE SA. 560 See Also: 562 IKE, ISAKMP 564 7.3.2 IKE Phase 1 Main Mode 566 Definition: 568 Main Mode is an instantiation of the ISAKMP Identity Protect 569 Exchange, defined in [RFC2409]. Upon successful completion it 570 results in the establishment of an IKE Phase 1 SA. 572 Discussion: 574 IKE Main Mode use 3 distinct message pairs, for a total of 6 575 messages. The first two messages negotiate policy; the next two 576 represent Diffie-Hellman public values and ancillary data (e.g. 577 nonces); and the last two messages authenticate the Diffie-Hellman 578 Exchange. The authentication method negotiated as part of the 579 initial IKE Phase 1 influence the composition of the payloads but 580 not their purpose. 582 Issues: 584 N/A 586 See Also: 588 ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 590 7.3.3 IKE Phase 1 Aggressive Mode 592 Definition: 594 Aggressive Mode is an instantiation of the ISAKMP Aggressive 595 Exchange, defined in [RFC2409]. Upon successful completion it 596 results in the establishment of an IKE Phase 1 SA. 598 Discussion: 600 IKE Aggressive Mode uses 3 messages. The first two messages 601 negotiate policy, exchange Diffie-Hellman public values and 602 ancillary data necessary for the exchange, and identities. In 603 addition the second message authenticates the Responder. The 604 third message authenticates the Initiator and provides proof of 605 participation in the exchange. 607 Issues: 609 For IKEv1 the standard specifies that all implementations use both 610 main and agressive mode, however, it is common to use only main 611 mode. 613 See Also: 615 ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 617 7.3.4 IKEv2 Phase 1 618 Definition: 620 IKEv2 calls the IKEv1 Phase 1 the IKEv2 Initial Exchange. 622 Discussion: 624 IKEv2 uses 2 exchanges (i.e. four messages) to complete its 625 initial exchange. The first pair of messages (IKE_SA_INIT) 626 negotiate cryptographic algorithms, exchange nonces and do a 627 Diffie-Hellman exchange. The second pair of messages (IKE_AUTH) 628 authenticate the previous messages, exchange identities and 629 certificates, and establish the first CHILD_SA. Parts of the 630 IKE_AUTH messages are encrypted and integrity protected with keys 631 established through the IKE_SA_INIT exchange. 633 Issues: 635 In some scenarios, only a single CHILD_SA is needed between IPsec 636 endpoints and therefore there would be no additional exchanges. 637 However, subsequent exchanges (i.e. the CREATE_CHILD_SA exchange) 638 are often used for re-keying purposes. 640 See Also: 642 ISAKMP, IKE, IKEv1 Phase 1, Phase 1 Main Mode 644 7.3.5 IKE Phase 2 646 Definition: 648 ISAKMP phase which upon successful completion establishes the 649 shared keys used by the negotiating peers to set up a secure "data 650 channel" for IPsec. 652 Discussion: 654 The main purpose of Phase 2 is to produce the key for the IPsec 655 tunnel. Phase 2 is also used to regenerate the key being used for 656 IPsec (called "rekeying"), as well as for exchanging informational 657 messages. 659 IKEv2 calls the IKEv1 phase 2 the IKEv2 CREATE_CHILD_SA Exchange. 660 These messages are used to create additional CHILD_SAs between 661 IPsec endpoints or to re-key existing CHILD-SAs. 663 Issues: 665 In other documents also referenced as IPsec SA. 667 See Also: 669 IKE Phase 1, ISAKMP, IKE 671 7.3.6 Phase 2 Quick Mode 673 Definition: 675 Quick Mode is an instanciation of IKE Phase 2. After successful 676 completion it will result in one or typically two or more IPsec 677 SA's 679 Discussion: 681 Quick Mode is used to negotiate the SA's and keys that will be 682 used to protect the user data, i.e. the IPsec SA. Three 683 different messages are exchanged, which are protected by the 684 security parameters negotiated by the IKE phase 1 exchange. An 685 additional Diffie-Hellman exchange may be performed if PFS 686 (Perfect Forward Secrecy) is enabled. 688 The IKEv2 CREATE_CHILD_SA exchange consists of a single request/ 689 response pair. These messages are cryptographically protected 690 using the cryptographic algorithms and keys negotiated in the 691 IKE_SA_INIT messages. 693 Issues: 695 N/A 697 See Also: 699 ISAKMP, IKE, IKE Phase 2 701 7.4 Security Association (SA) 703 Definition: 705 A simplex (unidirectional) logical connection that links a traffic 706 flow to a set of security parameters. All traffic traversing an 707 SA is provided the same security processing and will be subjected 708 to a common set of encryption and/or authentication algorithms. 710 In IPsec, an SA is an Internet layer abstraction implemented 711 through the use of AH or ESP as defined in [RFC2401]. 713 Discussion: 715 A set of policy and key(s) used to protect information. It is a 716 negotiation agreement between two IPsec devices, specifically the 717 Initiator and Responder. 719 Issues: 721 N/A 723 See Also: 725 Initiator, Responder 727 7.5 Selectors 729 Definition: 731 A mechanism used for the classification of traffic flows that 732 require encryption and/or authentication services. 734 Discussion: 736 The selectors are a set of fields that will be extracted from the 737 network and transport layer headers that provide the ability to 738 classify the traffic flow and associate it with an SA. 740 After classification, a decision can be made if the traffic needs 741 to be encrypted/decrypted and how this should be done depending on 742 the SA linked to the traffic flow. Simply put, selectors classify 743 IP packets that require IPsec processing and those packets that 744 must be passed along without any intervention of the IPsec 745 framework. 747 Selectors are flexible objects that can match on ranges of source 748 and destination addresses and ranges of source and destination 749 ports. 751 Issues: 753 Both sides must agree exactly on both the networks being 754 protected, and they both must agree on how to describe the 755 networks (range, subnet, addresses). This is a common point of 756 non-interoperability. 758 7.6 IPsec Device 760 Definition: 762 Any implementation that has the ability to process data flows 763 according to the IPsec protocol suite specifications. 765 Discussion: 767 Implementations can be grouped by 'external' properties (e.g. 768 software vs. hardware implementations) but more important is the 769 subtle differences that implementations may have with relation to 770 the IPsec Protocol Suite. Not all implementations will cover all 771 RFC's that encompass the IPsec Protocol Suite, but the majority 772 will support a large subset of features described in the suite, 773 nor will all implementations utilize all of the cryptographic 774 functions listed in the RFC's. 776 In that context, any implementation, that supports basic IP layer 777 security services as described in the IPsec protocol suite shall 778 be called an IPsec Device. 780 Issues: 782 Due to the fragmented nature of the IPsec Protocol Suite RFC's, it 783 is possible that IPsec implementations will not be able to 784 interoperate. Therefore it is important to know which features 785 and options are implemented in the IPsec Device. 787 See Also: 789 IPsec 791 7.6.1 Initiator 793 Definition: 795 An IPsec devices which starts the negotiation of IKE Phase 1 and 796 Phase 2 tunnels. 798 Discussion: 800 When a traffic flow is offered at an IPsec device and it is 801 determined that the flow must be protected, but there is no IPsec 802 tunnel to send the traffic through, it is the responsibility of 803 the IPsec device to start a negotiation process that will 804 instantiate the IPsec tunnel. This process will establish an IKE 805 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 806 eventually resulting in secured data transport. The device that 807 takes the action to start this negotiation process will be called 808 an Initiator. 810 Issues: 812 IPsec devices/implementations can be both an initiator as well as 813 a responder. The distinction is useful from a test perspective. 815 See Also: 817 Responder, IKE, IPsec 819 7.6.2 Responder 821 Definition: 823 An IPsec devices which replies to incoming IKE Phase 1 and Phase 2 824 tunnel requests and process these messages in order to establish a 825 tunnel. 827 Discussion: 829 When an initiator attempts to establish SA's with another IPsec 830 device, this peer will need to evaluate the proposals made by the 831 initiator and either accept or deny them. In the former case, the 832 traffic flow will be decrypted according to the negotiated 833 parameters. Such a device will be called a Responder. 835 Issues: 837 IPsec devices/implementations can usually be both an initiator as 838 well as a responder. The distinction is useful from a test 839 perspective. 841 See Also: 843 Initiator, IKE 845 7.6.3 IPsec Client 847 Definition: 849 IPsec Devices that will only act as an Initiator. 851 Discussion: 853 In some situations it is not needed or prefered to have an IPsec 854 device respond to an inbound tunnel request. In the case of e.g. 855 road warriors or home office scenarios the only property needed 856 from the IPsec device is the ability to securely connect to a 857 remote private network. The IPsec Client will set up one or more 858 Tunnels to an IPsec Server on the network that needs to be 859 accessed and to provide the required security services. An IPsec 860 client will silently drop and ignore any inbound tunnel requests. 861 IPsec clients are generally used to connect remote users in a 862 secure fashion over the Internet to a private network. 864 Issues: 866 N/A 868 See Also: 870 IPsec device, IPsec Server, Initiator, Responder 872 7.6.4 IPsec Server 874 Definition: 876 IPSec Devices that can both act as an Initiator as well as a 877 Responder. 879 Discussion: 881 IPSec Servers are mostly positioned at private network edges and 882 provide several functions : 884 Responds to tunnel setup request from IPSec Clients. 886 Responds to tunnel setup request from other IPsec devices 887 (Initiators). 889 Initiate tunnels to other IPsec servers inside or outside the 890 private network. 892 Issues: 894 IPsec Servers are also sometimes referred to as 'VPN 895 Concentrators'. 897 See Also: 899 IPsec Device, IPsec Client, Initiator, Responder 901 7.7 Tunnels 903 The term "tunnel" is often used in a variety of contexts. To avoid 904 any discrepancies, in this document, the following distinctions have 905 been defined : 907 7.7.1 IKE Tunnel 909 Definition: 911 A single Phase 1 IKE SA. 913 Discussion: 915 An IKE Tunnel between IPsec devices facilitates a mechanism for 916 secure negotiation of Phase 1 properties and Phase 2 SA's needed 917 for protected data transport. The initiator may choose which mode 918 to start the negotiation of the IKE Tunnel in. This can be either 919 main mode or aggressive mode. 921 Issues: 923 Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel. 925 See Also: 927 Tunnel, IPsec Tunnel, Security Association, IKE, IKE Phase 1 929 7.7.2 IPsec Tunnel 931 Definition: 933 One or more Phase 2 SA's that are negotiated in conjuntion with an 934 IKE Tunnel. 936 Discussion: 938 In the case of simplex communication, a single phase 2 SA. 940 In the more likely case where bidirectional communication is 941 needed it is a pair (2) Phase 2 SA's. The two SA's are used to 942 secure inbound and outbound traffic. 944 Not in all situations is it required to have an existing IKE 945 Tunnel in order to negotiate IPsec Tunnel properties and 946 parameters. Manually keyed tunnels allow the set up of IPsec 947 Tunnels without the need of the IKE protocol. 949 Issues: 951 Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be 952 multiple). 954 See Also: 956 Tunnel, IKE Tunnel, Security Association, IKE, IKE Phase 2 958 7.7.3 Tunnel 960 Definition: 962 The combination of an IKE Tunnel and an IPsec Tunnel 964 Discussion: 966 In the majority of the cases IPsec is used to protect 967 bidirectional traffic flows. Unless stated otherwise a 'Tunnel' 968 will be defined as a single Phase 1 SA and two Phase 2 SA's that 969 are associated with the Phase 1 SA. 971 Issues: 973 If other than a single Phase 2 SA, for each direction, have been 974 negotiated through a single IKE Tunnel, then this specific ratio 975 MUST be mentioned and the term 'Tunnel' MUST NOT be used in this 976 context." 978 See Also: 980 IKE Tunnel, IPsec Tunnel 982 7.7.4 Configured Tunnel 984 Definition: 986 A tunnel that is present in the IPSec device's configuration but 987 does not have any entries in the SADBi.e. SA's. 989 Discussion: 991 Several steps are required before a Tunnel can be used to actually 992 transport traffic. The very first step is to configure the tunnel 993 in the IPsec device. In that way packet classification can make a 994 decision if it is required to start negotiating SA's. At this 995 time there are no SA's associated with the Tunnel and no traffic 996 is going through the IPsec device that matches the Selectors, 997 which would instantiate the Tunnel. 999 A Configured Tunnel is also a tunnel that has relinquished all 1000 it's SA's and is not transmitting data anymore. To be more 1001 specific, when an Established or an Active Tunnel is terminated 1002 due to either an administrative action or an IKE event that teared 1003 down the tunnel, the tunnel will be back in a configured state. 1005 Issues: 1007 N/A 1009 See Also: 1011 Tunnel, Established Tunnel, Active Tunnel 1013 7.7.5 Established Tunnel 1015 Definition: 1017 A Tunnel that has completed Phase 1 and Phase 2 SA negotiations 1018 but is otherwise idle. 1020 Discussion: 1022 A second step needed to ensure that a Tunnel can transport data is 1023 to complete the Phase 1 and Phase 2 negotiations. After the 1024 packet classification process has asserted that a packet requires 1025 security services, the negotation is started to obtain both Phase 1026 1 and Phase 2 SA's. After this is completed the tunnel is called 1027 'Established'. Note that at this time there is still no traffic 1028 flowing through the Tunnel. Just enough packet(s) have been sent 1029 to the IPsec device that matched the selectors and triggered the 1030 Tunnel setup. This may also be acomplished by an administrative 1031 command to connect the Tunnel, in which case the Tunnel is not 1032 triggered by any positive packet classification. 1034 Issues: 1036 In the case of manually keyed tunnels, there is no distinction 1037 between a Configured Tunnel or an Established Tunnel since there 1038 is no negotiation required with these type of Tunnels and the 1039 Tunnel is Established at time of Configuration since all keying 1040 information is known at that point. 1042 See Also: 1044 Tunnel, Configured Tunnel, Active Tunnel 1046 7.7.6 Active Tunnel 1048 Definition: 1050 A tunnel that has completed Phase 1 and Phase 2 SA negotiations 1051 and is forwarding data. 1053 Discussion: 1055 When a Tunnel is Established and it is transporting traffic, the 1056 tunnel is called 'Active'. 1058 Issues: 1060 The distinction between an Active Tunnel and Configured/ 1061 Established Tunnel is made in the context of manual keyed Tunnels. 1062 In this case it would be possible to have an Established tunnel on 1063 an IPsec device which has no counterpart on it's corresponding 1064 peer. This will lead to encrypted traffic flows which will be 1065 discarded on the receiving peer. Only if both peers have an 1066 Established Tunnel that shows evidence of traffic transport, it 1067 may be called an Active Tunnel. 1069 See Also: 1071 Tunnel, Configured Tunnel, Established Tunnel 1073 7.8 Iterated Tunnels 1075 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 1076 The bundles are divided into two major groups : 1078 7.8.1 Nested Tunnels 1080 Definition: 1082 An SA bundle consisting of two or more 'tunnel mode' SA's. 1084 Discussion: 1086 The process of nesting tunnels can theoretically be repeated 1087 multiple times (for example, tunnels can be many levels deep), but 1088 for all practical purposes, most implementations limit the level 1089 of nesting. Nested tunnels can use a mix of AH and ESP 1090 encapsulated traffic. 1092 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1093 | | | | 1094 | | | | 1095 | +----{SA1 (ESP tunnel)}----+ | 1096 | | 1097 +--------------{SA2 (AH tunnel)}---------------+ 1099 In the IP Cloud a packet would have a format like this : 1100 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 1102 Nested tunnels can be deployed to provide additional security on 1103 already secured traffic. A typical example of this would be that 1104 the inner gateways (GW2 and GW3) are securing traffic between two 1105 branch offices and the outer gateways (GW1 & GW4) add an 1106 additional layer of security between departments within those 1107 branch offices. 1109 Issues: 1111 N/A 1113 See Also: 1115 Transport Adjacency, IPsec Tunnel 1117 7.8.2 Transport Adjacency 1119 Definition: 1121 An SA bundle consisting of two or more transport mode SA's. 1123 Discussion: 1125 Transport adjacency is a form of tunnel nesting. In this case two 1126 or more transport mode IPsec tunnels are set side by side to 1127 enhance applied security properties. 1129 Transport adjacency can be used with a mix of AH and ESP tunnels 1130 although some combinations are not preferred. If AH and ESP are 1131 mixed, the ESP tunnel should always encapsulate the AH tunnel. 1132 The reverse combination is a valid combination but doesn't make 1133 cryptographical sense. 1135 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1136 | | | | 1137 | | | | 1138 | +------{SA1 (ESP transport)}--------+ | 1139 | | 1140 +-------------{SA2 (AH transport)}--------------+ 1142 In the IP Cloud a packet would have a format like this : 1143 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 1145 Issues: 1147 This is rarely used. 1149 See Also: 1151 Nested Tunnels, IPsec Tunnel 1153 7.9 Transform protocols 1155 Definition: 1157 Encryption and authentication algorithms that provide 1158 cryptograhical services to the IPsec Protocols. 1160 Discussion: 1162 Some algorithms run significantly slower than others. For 1163 example, TripleDES encryption is one third as fast as DES 1164 encryption. 1166 Issues: 1168 N/A 1170 See Also: 1172 Authentication protocols, Encryption protocols 1174 7.9.1 Authentication Protocols 1176 Definition: 1178 Algorithms which provide data integrity and data source 1179 authentication. 1181 Discussion: 1183 Authentication protocols provide no confidentiality. Commonly 1184 used authentication algorithms/protocols are: 1186 * MD5-HMAC 1187 * SHA-HMAC 1188 * AES-HMAC 1190 Issues: 1192 SHA-HMAC is thought to be more secure than MD5-HMAC and is often 1193 used. AES-HMAC is still fairly new and not in common use yet. 1195 See Also: 1197 Transform protocols, Encryption protocols 1199 7.9.2 Encryption Protocols 1201 Definition: 1203 Algorithms which provide data confidentiality. 1205 Discussion: 1207 Encryption protocols provide no authentication. Commonly used 1208 encryption algorithms/protocols are: 1210 * NULL encryption 1211 * DES-CBC 1212 * 3DES-CBC 1213 * AES-CBC 1215 Issues: 1217 Null option is a valid encryption mechanism although it reverts to 1218 use of IPsec back to message authenticity but only for upper layer 1219 protocols, and is commonly used. 1221 DES has been officially deprecated by NIST, though it is still 1222 mandated RFC and is still commonly implemented and used due to 1223 it's speed advantage over 3DES. 1225 See Also: 1227 Transform protocols, Authentication protocols 1229 7.10 IPSec Protocols 1231 Definition: 1233 A suite of protocols which provide a framework of open standards 1234 that provides data confidentiality, data integrity, and data 1235 authenticity between participating peers at the IP layer. The 1236 IPsec protocol suite set of standards is documented in [RFC2401] 1237 through [RFC2412] and [RFC2451]. 1239 Discussion: 1241 The IPsec Protocol suite is modular and forward compatible. The 1242 protocols that comprise the IPsec protocol suite can be replaced 1243 with new versions of those protocols as the older versions become 1244 obsolete. For example, IKEv2 will soon replace IKEv1. 1246 Issues: 1248 N/A 1250 See Also: 1252 AH, ESP 1254 7.10.1 Authentication Header (AH) 1256 Definition: 1258 Provides authentication and data integrity (including replay 1259 protection) security services [RFC2402]. 1261 Discussion: 1263 The AH protocol supports both modes of operation; tunnel mode and 1264 transport mode. If AH is employed in tunnel mode, portions of the 1265 outer IP header are given protection, as well as all of the 1266 tunneled IP packet (that is, all of the inner IP header is 1267 protected as are the higher-layer protocols). In the case of AH 1268 in transport mode, all upper-layer information is protected, and 1269 all fields in the IPv4 header excluding the fields typically are 1270 modified in transit. 1272 Original IPv4 packet : 1273 [IP ORIG][L4 HDR][PAYLOAD] 1274 In transport mode : 1275 [IP ORIG][AH][L4 HDR][PAYLOAD] 1276 In tunnel mode : 1277 [IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD] 1279 Issues: 1281 AH is rarely used/implemented. 1283 See Also: 1285 Transform protocols, IPsec protocols, Encapsulated Security 1286 Payload 1288 7.10.2 Encapsulated Security Payload (ESP) 1290 Definition: 1292 Provides three essential components needed for secure data 1293 exchange: authentication, integrity (including replay protection) 1294 and confidentiality as defined in [RFC2406]. 1296 Discussion: 1298 The ESP protocol supports both modes of operation i.e. tunnel 1299 mode and transport mode. If ESP is employed in tunnel mode, the 1300 protection is afforded only to the tunneled packet, not to the 1301 outer header. In the case of ESP in transport mode, security 1302 services are provided only for the higher-layer protocols, not for 1303 the IP header. 1305 Original IPv4 packet : 1306 [IP ORIG][L4 HDR][PAYLOAD] 1307 In transport mode : 1308 [IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] 1309 In tunnel mode : 1310 [IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] 1312 Issues: 1314 N/A 1316 See Also: 1318 Transform protocols, IPsec protocols, Authentication Header 1320 7.11 NAT Traversal (NAT-T) 1322 Definition: 1324 The capability to support IPsec functionality in the presence of 1325 NAT devices. 1327 Discussion: 1329 NAT-Traversal requires some modifications to IKE as defined in 1330 [I-D.ietf-ipsec-nat-t-ike]. Specifically, in phase 1, it requires 1331 detecting if the other end supports NAT-Traversal, and detecting 1332 if there are one or more NAT instances along the path from host to 1333 host. In IKE Quick Mode, there is a need to negotiate the use of 1334 UDP encapsulated IPsec packets. 1336 NAT-T also describes how to transmit the original source and 1337 destination addresses to the corresponding IPsec Device. The 1338 original source and destination addresses are used in transport 1339 mode to incrementally update the TCP/IP checksums so that they 1340 will match after the NAT transform (The NAT cannot do this, 1341 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1342 packet). 1344 Issues: 1346 N/A 1348 See Also: 1350 IKE 1352 7.12 IP Compression 1354 Definition: 1356 A mechanism as defined in [RFC2393] that reduces the size of the 1357 payload that needs to be encrypted. 1359 Discussion: 1361 IP payload compression is a protocol to reduce the size of IP 1362 datagrams. This protocol will increase the overall communication 1363 performance between a pair of communicating hosts/gateways 1364 ("nodes") by compressing the datagrams, provided the nodes have 1365 sufficient computation power, through either CPU capacity or a 1366 compression coprocessor, and the communication is over slow or 1367 congested links. 1369 IP payload compression is especially useful when encryption is 1370 applied to IP datagrams. Encrypting the IP datagram causes the 1371 data to be random in nature, rendering compression at lower 1372 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1373 ineffective. If both compression and encryption are required, 1374 compression must be applied before encryption. 1376 Issues: 1378 N/A 1380 7.13 Security Context 1382 Definition: 1384 A security context is a collection of security parameters that 1385 describe the characteristics of the path that a tunnel will take, 1386 all of the tunnel parameters and the effects it has on the 1387 underlying protected traffic. Security Context encompasses 1388 protocol suite and security policy(ies). 1390 Discussion: 1392 In order to fairly compare multiple IPsec devices it is imperative 1393 that an accurate overview is given of all security parameters that 1394 were used to establish tunnels and to secure the traffic between 1395 protected networks. Security Context is not a metric; it is 1396 included to accurately reflect the test environment variables when 1397 reporting the methodology results. To avoid listing too much 1398 information when reporting metrics, we have divided the security 1399 context into an IKE context and an IPsec context. 1401 When merely discussing the behavior of traffic flows through IPsec 1402 devices, an IPsec context MUST be provided. In other cases the 1403 scope of a discussion or report may focus on a more broad set of 1404 behavioral characteristics of the IPsec device, the both and IPsec 1405 and an IKE context MUST be provided. 1407 The IPsec context MUST consist of the following elements: 1409 * Number of IPsec tunnels 1411 * IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio) 1413 * IPsec protocol 1415 * IPsec mode (tunnel or transport) 1417 * Authentication protocol used by IPsec 1419 * Encryption protocol used by IPsec (if applicable) 1421 * IPsec SA lifetime (traffic and time based) 1423 The IPsec Context MAY also list: 1425 * Selectors 1427 * Fragmentation handling 1429 The IKE Context MUST consist of the following elements: 1431 * Number of IKE tunnels. 1433 * Authentication protocol used by IKE 1435 * Encryption protocol used by IKE 1437 * Key exchange mechanism (pre-shared key, certificate authority, 1438 etc ...) 1440 * Key size (if applicable) 1442 * Diffie-Hellman group 1444 * IKE SA lifetime (time based) 1446 * Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd] 1448 * IP Compression [RFC2393] 1450 * PFS Diffie-Hellman group 1452 The IKE context MAY also list: 1454 * Phase 1 mode (main or aggressive) 1456 * Available bandwidth and latency to Certificate Authority server 1457 (if applicable) 1459 Issues: 1461 A Security Context will be an important element in describing the 1462 environment where protected traffic is traveling through. 1464 See Also: 1466 IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, 1467 Selectors, IPsec Tunnel 1469 8. Framesizes 1471 8.1 Layer3 clear framesize 1473 Definition: 1475 The total size of the unencrypted L3 PDU. 1477 Discussion: 1479 In relation to IPsec this is the size of the IP header and its 1480 payload. It SHALL NOT include any encapsulations that MAY be 1481 applied before the PDU is processed for encryption. 1483 For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload. 1485 Measurement Units: 1487 Bytes 1489 Issues: 1491 N/A 1493 See Also: 1495 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1496 Encrypted Framesize. 1498 8.2 Layer3 encrypted framesize 1500 Definition: 1502 The total size of the encrypted L3 PDU. 1504 Discussion: 1506 The size of the IP packet and it�s payload after encapsulations 1507 MAY be applied and the PDU is being processed by the transform. 1509 For example, after a tunnel mode ESP 3DES/SHA1 transform has been 1510 applied an unencrypted or clear layer3 framesize of 46 bytes 1511 Becomes 96 bytes: 1513 20 bytes outer IP header (tunnel mode) 1514 4 bytes SPI (ESP header) 1515 4 bytes Sequence (ESP Header) 1516 8 bytes IV (IOS ESP-3DES) 1517 46 bytes payload 1518 0 bytes pad (ESP-3DES 64 bit) 1519 1 byte Pad length (ESP Trailer) 1520 1 byte Next Header (ESP Trailer) 1521 12 bytes ESP-HMAC SHA1 96 digest 1523 Measurement Units: 1525 Bytes 1527 Issues: 1529 N/A 1531 See Also: 1533 Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted 1534 Framesize. 1536 8.3 Layer2 clear framesize 1538 Definition: 1540 The total size of the unencrypted L2 PDU. 1542 Discussion: 1544 This is the Layer 3 clear framesize plus all the layer2 overhead. 1545 In the case of Ethernet this would be 18 bytes. 1547 For example, a 46 byte Layer3 clear framesize packet would become 1548 64 Bytes after Ethernet Layer2 overhead is added: 1550 6 bytes destination mac address 1551 6 bytes source mac address 1552 2 bytes length/type field 1553 46 bytes layer3 (IP) payload 1554 4 bytes FCS 1556 Measurement Units: 1558 Bytes 1560 Issues: 1562 If it is not mentioned explicitly what kind of framesize is used, 1563 the layer2 clear framesize will be the default. 1565 See Also: 1567 Layer3 clear framesize, Layer2 encrypted framesize, Layer2 1568 encrypted framesize. 1570 8.4 Layer2 encrypted framesize 1572 Definition: 1574 The total size of the encrypted L2 PDU. 1576 Discussion: 1578 This is the Layer 3 encrypted framesize plus all the layer2 1579 overhead. In the case of Ethernet this would be 18 bytes. 1581 For example, a 96 byte Layer3 encrypted framesize packet would 1582 become 114 bytes after Ethernet Layer2 overhead is added: 1584 6 bytes destination mac address 1585 6 bytes source mac address 1586 2 bytes length/type field 1587 96 bytes layer3 (IPsec) payload 1588 4 bytes FCS 1590 Measurement Units: 1592 Bytes 1594 Issues: 1596 N/A 1598 See Also: 1600 Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear 1601 Framesize 1603 9. Performance Metrics 1605 9.1 Tunnels Per Second (TPS) 1607 Definition: 1609 The measurement unit for the Tunnel Setup Rate tests. The rate 1610 that Tunnels are established per second. 1612 Discussion: 1614 According to [RFC2401] two tunnels cannot be established between 1615 the same gateways with the same selectors. This is to prevent 1616 overlapping tunnels. If overlapping tunnels are attempted, the 1617 error will take longer than if the tunnel setup was successful. 1618 For this reason, a unique pair of selector sets are required for 1619 TPS testing. 1621 Issues: 1623 A unique pair of selector sets are required for TPS testing. 1625 See Also: 1627 Tunnel Setup Rate Behavior, Tunnel Setup Rate, IKE Setup Rate, 1628 IPsec Setup Rate 1630 9.2 Tunnel Rekeys Per Seconds (TRPS) 1632 Definition: 1634 A metric that quantifies the number of IKE or IPsec Tunnel rekey's 1635 per seconds a DUT can correctly process. 1637 Discussion: 1639 This metric will be will be primary used with Tunnel Rekey 1640 behavior tests. 1642 TRPS will provide a metric used to see system behavior under 1643 stressful conditions where large volumes of tunnels are being 1644 rekeyed at the same time or in a short timespan. 1646 Issues: 1648 N/A 1650 See Also: 1652 Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate 1654 9.3 Tunnel Attempts Per Second (TAPS) 1656 Definition: 1658 A metric that quantifies the number of successful and unsuccessful 1659 tunnel (both Phase 1 or Phase 2) establishment requests per 1660 second. 1662 Discussion: 1664 This metric can be used to measure IKE DOS Resilience behavior 1665 test. 1667 TAPS provides an important metric to validate the stability of a 1668 platform, if stressed with valid (large number of IPsec tunnel 1669 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1670 any style) tunnel establishment requests. 1672 Issues: 1674 If the TAPS increases, the TPS usually decreases, due to burdening 1675 of the DUT with the DOS attack traffic. 1677 10. Test Definitions 1679 10.1 Throughput 1681 10.1.1 Tunnel Throughput 1683 Definition: 1685 The maximum rate through an IPsec tunnel at which none of the 1686 offered frames are dropped by the device under test. 1688 Discussion: 1690 The IPsec Tunnel Throughput is almost identically defined as 1691 Throughput in [RFC1242], section 3.17. The only difference is 1692 that the throughput is measured with a traffic flow getting 1693 encrypted and decrypted by an IPsec device. IPsec Tunnel 1694 Throughput is an end-to-end measurement. 1696 The metric can be represented in two variantions depending on 1697 where measurement is taken in the SUT. One can look at throughput 1698 from a cleartext point of view i.e. find the maximum rate where 1699 clearpackets no longer get dropped. This resulting rate can be 1700 recalculated with an encrypted framesize to represent the 1701 encryption throughput rate. The latter is the preferred method of 1702 representation. 1704 Measurement Units: 1706 Packets per seconds (pps), Mbps 1708 Issues: 1710 N/A 1712 See Also: 1714 IPsec Encryption Throughput, IPsec Decryption Throughput 1716 10.1.2 IPsec Encryption Throughput 1718 Definition: 1720 The maximum encryption rate through an IPsec tunnel at which none 1721 of the offered cleartext frames are dropped by the device under 1722 test. 1724 Discussion: 1726 Since encryption throughput is not necessarily equal to the 1727 decryption throughput, both of the forwarding rates must be 1728 measured independently. The independent forwarding rates have to 1729 measured with the help of an IPsec aware test device that can 1730 originate and terminate IPsec and IKE tunnels. As defined in 1731 [RFC1242], measurements should be taken with an assortment of 1732 frame sizes. 1734 Measurement Units: 1736 Packets per seconds (pps), Mbps 1738 Issues: 1740 N/A 1742 See Also: 1744 IPsec Tunnel Throughput, IPsec Decryption Throughput 1746 10.1.3 IPsec Decryption Throughput 1748 Definition: 1750 The maximum decryption rate through an IPsec tunnel at which none 1751 of the offered encrypted frames are dropped by the device under 1752 test. 1754 Discussion: 1756 Since encryption throughput is not necessarily equal to the 1757 decryption throughput, both of the forwarding rates must be 1758 measured independently. 1760 The independent forwarding rates have to be measured with the help 1761 of an IPsec aware test device that can originate and terminate 1762 IPsec and IKE tunnels. As defined in [RFC1242], measurements 1763 should be taken with an assortment of frame sizes. 1765 Measurement Units: 1767 Packets per seconds (pps), Mbps 1769 Issues: 1771 Recommended test frame sizes will be addressed in future 1772 methodology document. 1774 See Also: 1776 IPsec Tunnel Throughput, IPsec Encryption Throughput 1778 10.2 Latency 1780 10.2.1 Tunnel Latency 1782 Definition: 1784 Time required to propagate a cleartext frame from the input 1785 interface of an initiator, through an IPsec Tunnel, to the output 1786 interface of the responder. 1788 Discussion: 1790 The Tunnel 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 IPsec 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 Tunnel Encryption Latency, IPsec Tunnel Decryption Latency 1810 10.2.2 IPsec Tunnel Encryption Latency 1812 Definition: 1814 The IPsec Tunnel Encryption Latency is the time interval starting 1815 when the end of the first bit of the cleartext frame reaches the 1816 input interface, through an IPsec tunnel, and ending when the 1817 start of the first bit of the encrypted output frame is seen on 1818 the output interface. 1820 Discussion: 1822 IPsec Tunnel Encryption latency is the latency introduced when 1823 encrypting 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 tunnels. 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 Tunnel Latency, IPsec Tunnel Decryption Latency 1848 10.2.3 IPsec Tunnel Decryption Latency 1850 Definition: 1852 The IPsec Tunnel decryption Latency is the time interval starting 1853 when the end of the first bit of the encrypted frame reaches the 1854 input interface, through an IPsec tunnel, and ending when the 1855 start of the first bit of the decrypted output frame is seen on 1856 the output interface. 1858 Discussion: 1860 IPsec Tunnel decryption latency is the latency introduced when 1861 decrypting traffic through an IPsec tunnel. Like encryption/ 1862 decryption throughput, it is not always the case that encryption 1863 latency equals the decryption latency. Therefore a distinction 1864 between the two has to be made in order to get a more accurate 1865 view of where the latency is the most pronounced. 1867 The independent encryption/decryption latencies have to be 1868 measured with the help of an IPsec aware test device that can 1869 originate and terminate IPsec and IKE tunnels. As defined in 1870 [RFC1242], measurements should be taken with an assortment of 1871 frame sizes. 1873 Measurement Units: 1875 Time units with enough precision to reflect latency measurement. 1877 Issues: 1879 N/A 1881 See Also: 1883 IPsec Tunnel Latency, IPsec Tunnel Encryption Latency 1885 10.2.4 Time To First Packet 1887 Definition: 1889 The Time To First Packet (TTFP) is the time required process an 1890 cleartext packet when no tunnel is present. 1892 Discussion: 1894 The TTFP addresses the issue of responsiveness of an IPsec device 1895 by looking how long it take to transmit a packet over a not yet 1896 established tunnel path. The TTFP MUST include the time to set up 1897 the tunnel, triggered by the traffic flow (both phase 1 and phase 1898 2 setup times are included) and the time it takes to encrypt and 1899 decrypt the packet on a corresponding peer. 1901 It must be noted that it is highly unlikely that the first packet 1902 of the traffic flow will be the packet that will be used to 1903 measure the TTFP. There MAY be several protocol layers in the 1904 stack before the tunnel is formed and the traffic is forwarded, 1905 hence several packets COULD be lost during negotiation, for 1906 example, ARP and/or IKE. 1908 Measurement Units: 1910 Time units with enough precision to reflect a TTFP measurement. 1912 Issues: 1914 N/A 1916 10.3 Frame Loss 1918 10.3.1 IPSec Tunnel Frame Loss 1920 Definition: 1922 Percentage of cleartext frames that should have been forwarded 1923 through a Tunnel under steady state (constant) load but were 1924 dropped before encryption or after decryption. 1926 Discussion: 1928 The IPsec Tunnel Frame Loss is almost identically defined as Frame 1929 Loss Rate in [RFC1242], section 3.6. The only difference is that 1930 the IPsec Tunnel Frame Loss Rate is measured with a traffic flow 1931 getting encrypted and decrypted by an IPsec device. IPsec Tunnel 1932 Frame Loss Rate is an end-to-end measurement. 1934 Measurement Units: 1936 Percent (%) 1938 Issues: 1940 N/A 1942 See Also: 1944 IPsec Tunnel Encryption Frame Loss, IPsec Tunnel Decryption Frame 1945 Loss 1947 10.3.2 IPsec Tunnel Encryption Frame Loss 1949 Definition: 1951 Percentage of cleartext frames that should have been encrypted 1952 through an IPsec tunnel under steady state (constant) load but 1953 were dropped. 1955 Discussion: 1957 DUT's will always have an inherent forwarding limitation. This 1958 will be more pronounced when IPsec is employed on the DUT. The 1959 moment that a Tunnel is established and traffic is offered at a 1960 given rate that will flow through that tunnel, there is a 1961 possibility that the offered traffic rate at the tunnel is too 1962 high to be transported through the IPsec tunnel and not all 1963 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 Tunnel Encryption Frame Loss. 1967 Measurement Units: 1969 Percent (%) 1971 Issues: 1973 N/A 1975 See Also: 1977 IPsec Tunnel Frame Loss, IPsec Tunnel Decryption Frame Loss 1979 10.3.3 IPsec Tunnel Decryption Frame Loss 1981 Definition: 1983 Percentage of encrypted frames that should have been decrypted 1984 through an IPsec 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 established 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 Tunnel Decryption Frame Loss. 1998 Measurement Units: 2000 Percent (%) 2002 Issues: 2004 N/A 2006 See Also: 2008 IPsec Tunnel Frame Loss, IPsec Tunnel Encryption Frame Loss 2010 10.3.4 Phase 2 Rekey Frame Loss 2012 Definition: 2014 Number of frames dropped as a result of an inefficient Phase 2 2015 rekey. 2017 Discussion: 2019 Normal operation of an IPSec device would require that a rekey 2020 does not create temporary Frame Loss of a traffic stream that is 2021 protected by the Phase 2 SA's. Nevertheless there can be 2022 situations where Frame Loss occurs during the rekey process. 2024 This metric should be ideally zero but this may not be the case on 2025 IPsec devices where IPsec funtionality is not a core feature. 2027 Measurement Units: 2029 Number of N-octet frames 2031 Issues: 2033 N/A 2035 See Also: 2037 Phase 2 Rekey Rate 2039 10.4 Back-to-back Frames 2041 10.4.1 Tunnel Back-to-back Frames 2043 Definition: 2045 A burst of cleartext frames, offered at a constant load that can 2046 be sent through an IPsec tunnel without losing a single cleartext 2047 frame after decryption. 2049 Discussion: 2051 The Tunnel Back-to-back Frames is almost identically defined as 2052 Back-to-back in [RFC1242], section 3.1. The only difference is 2053 that the Tunnel Back-to-back Frames is measured with a traffic 2054 flow getting encrypted and decrypted by an IPsec device. Tunnel 2055 Back-to-back Frames is an end-to-end measurement. 2057 Measurement Units: 2059 Number of N-octet frames in burst. 2061 Issues: 2063 Recommended test frame sizes will be addressed in future 2064 methodology document. 2066 See Also: 2068 Encryption Back-to-back frames, Decryption Back-to-back frames 2070 10.4.2 Encryption Back-to-back Frames 2072 Definition: 2074 A burst of cleartext frames, offered at a constant load that can 2075 be sent through an IPsec tunnel without losing a single encrypted 2076 frame. 2078 Discussion: 2080 Encryption back-to-back frames is the measure of the maximum burst 2081 size that a device can handle for encrypting traffic that it 2082 receives as plaintext. Since it is not necessarily the case that 2083 the maximum burst size a DUT can handle for encryption is equal to 2084 the maximum burst size a DUT can handle for decryption, both of 2085 these capabilities must be measured independently. The encryption 2086 back-to-back frame measurement has to be measured with the help of 2087 an IPsec aware test device that can decrypt the traffic to 2088 determine the validity of the encrypted frames. 2090 Measurement Units: 2092 Number of N-octet frames in burst. 2094 Issues: 2096 Recommended test frame sizes will be addressed in future 2097 methodology document. 2099 See Also: 2101 Tunnel Back-to-back frames, Decryption Back-to-back frames 2103 10.4.3 Decryption Back-to-back Frames 2105 Definition: 2107 The number of encrypted frames, offered at a constant load, that 2108 can be sent through an IPsec tunnel without losing a single 2109 cleartext frame. 2111 Discussion: 2113 Decryption back-to-back frames is the measure of the maximum burst 2114 size that a device can handle for decrypting traffic that it 2115 receives as encrypted traffic. Since it is not necessarily the 2116 case that the maximum burst size a DUT can handle for decryption 2117 is equal to the maximum burst size a DUT can handle for 2118 encryption, both of these capabilities must be measured 2119 independently. The decryption back-to-back frame measurement has 2120 to be measured with the help of an IPsec aware test device that 2121 can determine the validity of the decrypted frames. 2123 Measurement Units: 2125 Number of N-octet frames in burst. 2127 Issues: 2129 Recommended test frame sizes will be addressed in future 2130 methodology document. 2132 See Also: 2134 Tunnel Back-to-back frames, Encryption back-to-back frames 2136 10.5 Tunnel Setup Rate Behavior 2138 10.5.1 Tunnel Setup Rate 2140 Definition: 2142 The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second 2143 that an IPsec device can successfully establish. 2145 Discussion: 2147 The tunnel setup rate SHOULD be measured at varying number of 2148 tunnels on the DUT. Several factors may influence Tunnel Setup 2149 Rate, such as: TAPS rate, Background cleartext traffic load on the 2150 secure interface, Already established tunnels, Authentication 2151 method such as pre-shared keys, RSA-encryption, RSA-signature, DSS 2152 Key sizes used (when using RSA/DSS). 2154 Measurement Units: 2156 Tunnels Per Second (TPS) 2158 Issues: 2160 N/A 2162 See Also: 2164 Phase 1 Setup Rate, Phase 2 Setup Rate, Tunnel Rekey 2166 10.5.2 Phase 1 Setup Rate 2167 Definition: 2169 The maximum number of IKE tunnels (1 IKE Phase 1 SA) per second 2170 that an IPsec device can be observed to successfully establish. 2172 Discussion: 2174 The Phase 1 Setup Rate is a portion of the Tunnel Setup Rate. In 2175 the process of establishing a Tunnel, it is interesting to know 2176 what the limiting factor of the IKE Finite State Machine is i.e. 2177 is it limited by the Phase 1 processing delays or rather by the 2178 Phase 2 processing delays. 2180 Measurement Units: 2182 Tunnels Per Second (TPS) 2184 Issues: 2186 N/A 2188 See Also: 2190 Tunnel Setup Rate, Phase 2 Setup Rate, Tunnel Rekey 2192 10.5.3 Phase 2 Setup Rate 2194 Definition: 2196 The maximum number of IPsec tunnels (2 IKE Phase 2 SA's) per 2197 second that a IPsec device can be observed to successfully 2198 establish. 2200 Discussion: 2202 The Phase 2 Setup Rate is a portion of the Tunnel Setup Rate. For 2203 identical reasons why it is required to quantify the Phase 1 Setup 2204 Rate, it is a good practice to know the processing delays involved 2205 in setting up a Phase 2 SA for each direction of the protected 2206 traffic flow. 2208 Note that once you have the Tunnel Setup Rate and either the Phase 2209 1 or the Phase 2 Setup Rate data, you can extrapolate the 2210 unmeasured metric, although it is RECOMMENDED to measure all three 2211 metrics. 2213 Measurement Units: 2215 Tunnels Per Second (TPS) 2217 Issues: 2219 N/A 2221 See Also: 2223 Tunnel Setup Rate, Phase 1 Setup Rate, Tunnel Rekey 2225 10.6 Tunnel Rekey 2227 10.6.1 Phase 1 Rekey Rate 2229 Definition: 2231 The number of Phase 1 SA's that can be succesfully re-establish 2232 per second. 2234 Discussion: 2236 Although the Phase 1 Rekey Rate has less impact on the forwarding 2237 behavior of traffic that requires security services then the Phase 2238 2 Rekey Rate, it can pose a large burden on the CPU or network 2239 processor of the IPsec Device. Due to the highly computational 2240 nature of a Phase 1 exchange, it may impact the stability of 2241 Active Tunnels in the network when the IPsec Device fails to 2242 properly rekey an IKE Tunnel. 2244 Measurement Units: 2246 Rekey's per second 2248 Issues: 2250 N/A 2252 See Also: 2254 Phase 2 Rekey Rate 2256 10.6.2 Phase 2 Rekey Rate 2257 Definition: 2259 The number of Phase 2 SA's that can be succesfully re-negotiated 2260 per-second. 2262 Discussion: 2264 Although many implementations will usually derive new keying 2265 material before the old keys expire, there may still be a period 2266 of time where frames get dropped before the phase 2 tunnels are 2267 successfully re-established. There may also be some packetloss 2268 introduced when the handover of traffic is done from the expired 2269 SA to the newly negotiated SA. To measure the phase 2 rekey rate, 2270 the measurement will require an IPsec aware test device to act as 2271 a responder when negotiating the new phase 2 keying material. 2273 The test methodology report must specify if PFS is enabled in 2274 reported security context. 2276 Measurement Units: 2278 Rekey's per second 2280 Issues: 2282 N/A 2284 See Also: 2286 Phase 1 Rekey Rate 2288 10.7 Tunnel Failover Time (TFT) 2290 Definition: 2292 Time required to recover all tunnels on a stanby IPsec device, 2293 after a catastrophic failure occurs on the active IPsec device. 2295 Discussion: 2297 Recovery time required to re-establish all tunnels and reroute all 2298 traffic on a standby node or other failsafe system after a failure 2299 has occurred. Failure can include but are not limited to a 2300 catastrophic IPsec Device failure, a encryption engine failure, 2301 link outage. The recovery time is delta between the point of 2302 failure and the time the first packet is seen on the last restored 2303 tunnel on the backup device. 2305 Measurement Units: 2307 Time units with enough precision to reflect Tunnel Failover Time. 2309 Issues: 2311 N/A 2313 10.8 IKE DOS Resilience Rate 2315 Definition: 2317 The IKE Denial Of Service (DOS) Resilience Rate provides a rate of 2318 invalid or mismatching IKE tunnels setup attempts at which it is 2319 no longer possible to set up a valid IKE tunnel. 2321 Discussion: 2323 The IKE DOS Resilience Rate will provide a metric to how robust 2324 and hardened an IPsec device is against malicious attempts to set 2325 up a tunnel. 2327 IKE DOS attacks can pose themselves in various forms and do not 2328 necessarily have to have a malicious background. It is sufficient 2329 to make a typographical error in a shared secret in an IPsec 2330 aggregation device to be susceptible to a large number of IKE 2331 attempts that need to be turned down. Due to the intense 2332 computational nature of an IKE exchange every single IKE tunnel 2333 attempt that has to be denied will take a non-negligible time an a 2334 CPU in the IPsec device. 2336 Depending on how many of these messages have to be processed, a 2337 system might end up in a state that it is only doing key exchanges 2338 and burdening the CPU for any other processes that might be 2339 running in the IPsec device. At this point it will be no longer 2340 possible to process a valid IKE tunnel setup request and thus IKE 2341 DOS is in effect. 2343 Measurement Units: 2345 Tunnel Attempts Per Seconds (TAPS) 2347 Issues: 2349 N/A 2351 11. Security Considerations 2353 As this document is solely for the purpose of providing test 2354 benchmarking terminology and describes neither a protocol nor a 2355 protocol's implementation; there are no security considerations 2356 associated with this document. 2358 12. Acknowledgements 2360 The authors would like to acknowledge the following individual for 2361 their help and participation of the compilation and editing of this 2362 document: Debby Stopp, Ixia. 2364 13. Contributors 2366 The authors would like to acknowledge the following individual for 2367 their significant help, guidance, and contributions to this document: 2368 Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. 2370 14. References 2372 14.1 Normative References 2374 [RFC1242] Bradner, S., "Benchmarking terminology for network 2375 interconnection devices", RFC 1242, July 1991. 2377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2378 Requirement Levels", BCP 14, RFC 2119, March 1997. 2380 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2381 Switching Devices", RFC 2285, February 1998. 2383 [RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP 2384 Payload Compression Protocol (IPComp)", RFC 2393, December 2385 1998. 2387 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2388 Internet Protocol", RFC 2401, November 1998. 2390 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2391 2402, November 1998. 2393 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2394 ESP and AH", RFC 2403, November 1998. 2396 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2397 ESP and AH", RFC 2404, November 1998. 2399 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 2400 Algorithm With Explicit IV", RFC 2405, November 1998. 2402 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2403 Payload (ESP)", RFC 2406, November 1998. 2405 [RFC2407] Piper, D., "The Internet IP Security Domain of 2406 Interpretation for ISAKMP", RFC 2407, November 1998. 2408 [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet 2409 Security Association and Key Management Protocol 2410 (ISAKMP)", RFC 2408, November 1998. 2412 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2413 (IKE)", RFC 2409, November 1998. 2415 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2416 Its Use With IPsec", RFC 2410, November 1998. 2418 [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 2419 Document Roadmap", RFC 2411, November 1998. 2421 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2422 2412, November 1998. 2424 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2425 Algorithms", RFC 2451, November 1998. 2427 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 2428 Network Interconnect Devices", RFC 2544, March 1999. 2430 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 2431 1999. 2433 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. 2434 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2435 2661, August 1999. 2437 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 2438 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2439 2000. 2441 [I-D.ietf-ipsec-ikev2] 2442 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2443 draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. 2445 [I-D.ietf-ipsec-dpd] 2446 Huang, G., Beaulieu, S. and D. Rochefort, "A Traffic-Based 2447 Method of Detecting Dead IKE Peers", 2448 draft-ietf-ipsec-dpd-04 (work in progress), October 2003. 2450 [I-D.ietf-ipsec-nat-t-ike] 2451 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 2452 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 2453 2004. 2455 [I-D.ietf-ipsec-udp-encaps] 2456 Huttunen, A., "UDP Encapsulation of IPsec Packets", 2457 draft-ietf-ipsec-udp-encaps-09 (work in progress), May 2458 2004. 2460 [I-D.ietf-ipsec-nat-reqts] 2461 Aboba, B. and W. Dixon, "IPsec-NAT Compatibility 2462 Requirements", draft-ietf-ipsec-nat-reqts-06 (work in 2463 progress), October 2003. 2465 [I-D.ietf-ipsec-properties] 2466 Krywaniuk, A., "Security Properties of the IPsec Protocol 2467 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2468 July 2002. 2470 [FIPS.186-1.1998] 2471 National Institute of Standards and Technology, "Digital 2472 Signature Standard", FIPS PUB 186-1, December 1998, 2473 . 2475 14.2 Informative References 2477 [Designing Network Security] 2478 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2479 Published: May 07, 1999; Copyright: 1999, 1999. 2481 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2482 Mechanism for Internet", from IEEE Proceedings of the 2483 1996 Symposium on Network and Distributed Systems 2484 Security, URI http://www.research.ibm.com/security/ 2485 skeme.ps, 1996. 2487 Authors' Addresses 2489 Michele Bustos 2490 IXIA 2491 26601 W. Agoura Rd. 2492 Calabasas, CA 91302 2493 US 2495 Phone: +1 (818)444-3244 2496 EMail: mbustos@ixiacom.com 2498 Tim Van Herck 2499 Cisco Systems 2500 170 West Tasman Dr. 2501 San Jose, CA 95134-1706 2502 US 2504 Phone: +1 (408)527-2461 2505 EMail: herckt@cisco.com 2507 Merike Kaeo 2508 Double Shot Security 2509 520 Washington Blvd #363 2510 Marina Del Rey, CA 90292 2511 US 2513 Phone: +1 (310)866-0165 2514 EMail: kaeo@merike.com 2516 Intellectual Property Statement 2518 The IETF takes no position regarding the validity or scope of any 2519 intellectual property or other rights that might be claimed to 2520 pertain to the implementation or use of the technology described in 2521 this document or the extent to which any license under such rights 2522 might or might not be available; neither does it represent that it 2523 has made any effort to identify any such rights. Information on the 2524 IETF's procedures with respect to rights in standards-track and 2525 standards-related documentation can be found in BCP-11. Copies of 2526 claims of rights made available for publication and any assurances of 2527 licenses to be made available, or the result of an attempt made to 2528 obtain a general license or permission for the use of such 2529 proprietary rights by implementors or users of this specification can 2530 be obtained from the IETF Secretariat. 2532 The IETF invites any interested party to bring to its attention any 2533 copyrights, patents or patent applications, or other proprietary 2534 rights which may cover technology that may be required to practice 2535 this standard. Please address the information to the IETF Executive 2536 Director. 2538 Full Copyright Statement 2540 Copyright (C) The Internet Society (2004). All Rights Reserved. 2542 This document and translations of it may be copied and furnished to 2543 others, and derivative works that comment on or otherwise explain it 2544 or assist in its implementation may be prepared, copied, published 2545 and distributed, in whole or in part, without restriction of any 2546 kind, provided that the above copyright notice and this paragraph are 2547 included on all such copies and derivative works. However, this 2548 document itself may not be modified in any way, such as by removing 2549 the copyright notice or references to the Internet Society or other 2550 Internet organizations, except as needed for the purpose of 2551 developing Internet standards in which case the procedures for 2552 copyrights defined in the Internet Standards process must be 2553 followed, or as required to translate it into languages other than 2554 English. 2556 The limited permissions granted above are perpetual and will not be 2557 revoked by the Internet Society or its successors or assignees. 2559 This document and the information contained herein is provided on an 2560 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2561 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2562 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2563 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2564 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2566 Acknowledgment 2568 Funding for the RFC Editor function is currently provided by the 2569 Internet Society.