idnits 2.17.1 draft-ietf-bmwg-ipsec-term-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 28, 2009) is 5380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GW1' is mentioned on line 913, but not defined == Missing Reference: 'GW2' is mentioned on line 913, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 913, but not defined == Missing Reference: 'GW3' is mentioned on line 913, but not defined == Missing Reference: 'GW4' is mentioned on line 913, but not defined == Missing Reference: 'ESP' is mentioned on line 921, but not defined == Missing Reference: 'AH' is mentioned on line 921, but not defined == Missing Reference: 'IP' is mentioned on line 921, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 921, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 921, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 921, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1115, but not defined == Unused Reference: 'RFC2119' is defined on line 1929, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 1945, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 1948, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 1951, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 1967, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 1970, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2013, but no explicit reference was found in the text ** 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) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 13 errors (**), 0 flaws (~~), 20 warnings (==), 2 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 Intended status: Informational T. Van Herck 5 Expires: January 29, 2010 Cisco Systems 6 M. Bustos 7 IXIA 8 July 28, 2009 10 Terminology for Benchmarking IPsec Devices 11 draft-ietf-bmwg-ipsec-term-12 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on January 29, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This purpose of this document is to define terminology specific to 60 measuring the performance of IPsec devices. It builds upon the 61 tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF 62 Benchmarking Methodology Working Group (BMWG) documents used for 63 benchmarking routers and switches. This document seeks to extend 64 these efforts specific to the IPsec paradigm. The BMWG produces two 65 major classes of documents: Benchmarking Terminology documents and 66 Benchmarking Methodology documents. The Terminology documents 67 present the benchmarks and other related terms. The Methodology 68 documents define the procedures required to collect the benchmarks 69 cited in the corresponding Terminology documents. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7 77 3.1.1. Security Associations . . . . . . . . . . . . . . . . 7 78 3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 8 79 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10 80 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10 81 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 10 82 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13 87 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13 88 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13 89 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14 90 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14 91 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 15 92 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15 93 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 15 94 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 16 95 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 17 96 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 17 97 7.6.4. IPsec Gateway . . . . . . . . . . . . . . . . . . . . 17 98 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 18 100 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 18 101 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 19 102 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 19 103 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 20 104 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 20 105 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 21 106 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 21 107 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 22 108 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 22 109 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 23 110 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23 111 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24 112 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25 113 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25 114 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26 115 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28 116 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28 117 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29 118 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30 119 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30 120 9.2. Tunnel Rekeys Per Second (TRPS) . . . . . . . . . . . . . 30 121 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 30 122 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 123 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 31 125 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 31 126 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32 127 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32 128 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 32 129 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 33 130 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34 131 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 34 132 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 34 133 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 35 134 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 35 135 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 36 136 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 36 137 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 36 138 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 37 139 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 37 140 10.5. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 38 141 10.5.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 38 142 10.5.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 38 143 10.5.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 39 144 10.6. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 39 145 10.6.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 39 146 10.6.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 40 147 10.7. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 40 148 10.8. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 41 149 10.8.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 41 150 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . 41 151 10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . 42 152 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 153 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 154 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 155 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 156 13.2. Informative References . . . . . . . . . . . . . . . . . . 45 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 159 1. Introduction 161 Despite the need to secure communications over a public medium there 162 is no standard method of performance measurement nor a standard in 163 the terminology used to develop such hardware and software solutions. 164 This results in varied implementations which challenge 165 interoperability and direct performance comparisons. Standardized 166 IPsec terminology and performance test methodologies will enable 167 users to determine if the IPsec device they select will withstand 168 loads of secured traffic that meet their requirements. 170 To appropriately define the parameters and scope of this document, 171 this section will give a brief overview of the IPsec standard. 173 2. Document Scope 175 The primary focus of this document is to establish useful performance 176 testing terminology for IPsec devices that support manual keying and 177 IKEv1. A seperate document will be written specifically to address 178 testing using the updated IKEv2 specification. The terminology 179 specified in this document is constrained to meet the requirements of 180 the Methodology for Benchmarking IPsec Devices documented test 181 methodologies. 183 Both IPv4 and IPv6 addressing will be taken into consideration. 185 The testing will be constrained to: 187 o Devices acting as IPsec gateways whose tests will pertain to both 188 IPsec tunnel and transport mode. 190 o Devices acting as IPsec end-hosts whose tests will pertain to both 191 IPsec tunnel and transport mode. 193 Any testing involving interoperability and/or conformance issues, 194 L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and 195 anything that does not specifically relate to the establishment and 196 tearing down of IPsec tunnels is specifically out of scope. It is 197 assumed that all relevant networking parameters that facilitate in 198 the running of these tests are pre-configured (this includes at a 199 minimum ARP caches, routing tables, neighbor tables, etc ...). 201 3. IPsec Fundamentals 203 IPsec is a framework of open standards that provides data 204 confidentiality, data integrity, and data origin authenticity between 205 participating peers. IPsec provides these security services at the 206 IP layer. IPsec uses IKE to handle negotiation of protocols and 207 algorithms based on local policy, and to generate the encryption and 208 authentication keys to be used. IPsec can be used to protect one or 209 more data flows between a pair of hosts, between a pair of security 210 gateways, or between a security gateway and a host. The IPsec 211 protocol suite set of standards is documented in RFC's [RFC2401] 212 through [RFC2412] and [RFC2451]. At this time [RFC4301] updates 213 [RFC2401] (IPsec Architecture), [RFC4302] updates [RFC2402] (AH) and 214 [RFC4303] updates [RFC2406] (ESP) and [RFC4306] updates [RFC2409] 215 (IKE).The reader is assumed to be familiar with these documents. 217 IPsec itself defines the following: 219 Authentication Header (AH): A security protocol, defined in 220 [RFC4302], which provides data authentication and optional anti- 221 replay services. AH ensures the integrity and data origin 222 authentication of the IP datagram as well as the invariant fields in 223 the outer IP header. 225 Encapsulating Security Payload (ESP): A security protocol, defined in 226 [RFC4303], which provides confidentiality, data origin 227 authentication, connectionless integrity, an anti-replay service and 228 limited traffic flow confidentiality. The set of services provided 229 depends on options selected at the time of Security Association (SA) 230 establishment and on the location of the implementation in a network 231 topology. ESP authenticates only headers and data after the IP 232 header. 234 Internet Key Exchange (IKE): A hybrid protocol which implements 235 Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP 236 framework. While IKE can be used with other protocols, its initial 237 implementation is with the IPsec protocol. IKE provides 238 authentication of the IPsec peers, negotiates IPsec security 239 associations, and establishes IPsec keys. 241 The AH and ESP protocols each support two modes of operation: 242 transport mode and tunnel mode. In transport mode, two hosts provide 243 protection primarily for upper-layer protocols. The cryptographic 244 endpoints (where the encryption and decryption take place) are the 245 source and destination of the data packet. In IPv4, a transport mode 246 security protocol header appears immediately after the IP header and 247 before any higher-layer protocols (such as TCP or UDP). In IPv6, the 248 security protocol header appears after the base IP header and 249 selected extension headers. It may appear before or after 250 destination options but must appear before next layer protocols 251 (e.g., TCP, UDP, SCTP) 252 In the case of AH in transport mode, security services are provided 253 to selected portions of the IP header preceding the AH header, 254 selected portions of extension headers, and selected options 255 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 256 IPv6 Destination extension headers). Any fields in these headers/ 257 extension headers which are modified in transit are set to 0 before 258 applying the authentication algorithm. If a field is mutable, but 259 its value at the receiving IPsec peer is predictable, then that value 260 is inserted into the field before applying the cryptographic 261 algorithm. 263 In the case of ESP in transport mode, security services are provide 264 only for the higher-layer protocols, not for the IP header or any 265 extension headers preceding the ESP header. 267 A tunnel is a vehicle for encapsulating packets inside a protocol 268 that is understood at the entry and exit points of a given network. 269 These entry and exit points are defined as tunnel interfaces. 271 Both the AH and ESP protocols can be used in tunnel mode for data 272 packet endpoints as well as by intermediate security gateways. In 273 tunnel mode, there is an "outer" IP header that specifies the IPsec 274 processing destination, plus an "inner" IP header that specifies the 275 ultimate destination for the packet. The source address in the outer 276 IP header is the initiating cryptographic endpoint; the source 277 address in the inner header is the true source address of the packet. 278 The security protocol header appears after the outer IP header and 279 before the inner IP header. 281 If AH is employed in tunnel mode, portions of the new outer IP header 282 are given protection (those same fields as for transport mode, 283 described earlier in this section), as well as all of the tunneled IP 284 packet (that is, all of the inner IP header is protected as are the 285 higher-layer protocols). If ESP is employed, the protection is 286 afforded only to the tunneled packet, not to the new outer IP header. 288 3.1. IPsec Operation 290 3.1.1. Security Associations 292 The concept of a Security Association (SA) is fundamental to IPsec. 293 An SA is a relationship between two or more entities that describes 294 how the entities will use security services to communicate. The SA 295 includes: an encryption algorithm, an authentication algorithm and a 296 shared session key. 298 Because an SA is unidirectional, two SA's (one in each direction) are 299 required to secure typical, bidirectional communication between two 300 entities. The security services associated with an SA can be used 301 for AH or ESP, but not for both. If both AH and ESP protection are 302 applied to a traffic stream, two (or more) SA's are created for each 303 direction to protect the traffic stream. 305 The SA is uniquely identified by the Security Parameter Index (SPI) 306 [RFC2406]. When a system sends a packet that requires IPsec 307 protection, it looks up the SA in its database and applies the 308 specified processing and security protocol (AH/ESP), inserting the 309 SPI from the SA into the IPsec header. When the IPsec peer receives 310 the packet, it looks up the SA in its database by destination 311 address, protocol, and SPI and then processes the packet as required. 313 3.1.2. Key Management 315 IPsec uses cryptographic keys for authentication, integrity and 316 encryption services. Both manual provisioning and automatic 317 distribution of keys are supported. IKE is specified as the public- 318 key-based approach for automatic key management. 320 IKE authenticates each peer involved in IPsec, negotiates the 321 security policy, and handles the exchange of session keys. IKE is a 322 hybrid protocol, combining parts of the following protocols to 323 negotiate and derive keying material for SA's in a secure and 324 authenticated manner: 326 1. ISAKMP [RFC2408] (Internet Security Association and Key 327 Management Protocol), which provides a framework for 328 authentication and key exchange but does not define them. ISAKMP 329 is designed to be key exchange independent; it is designed to 330 support many different key exchanges. 332 2. Oakley [RFC2412], which describes a series of key exchanges, 333 called modes, and details the services provided by each (for 334 example, perfect forward secrecy for keys, identity protection, 335 and authentication). 337 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 338 describes a versatile key exchange technique that provides 339 anonymity, reputability, and quick key refreshment. 341 IKE creates an authenticated, secure tunnel between two entities and 342 then negotiates the security association for IPsec. In the original 343 IKE specification [RFC2409], this is performed in two phases. 345 In Phase 1, the two unidirectional SA's establish a secure, 346 authenticated channel with which to communicate. Phase 1 has two 347 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 348 provides identity protection. When identity protection is not 349 needed, Aggressive Mode can be used. The completion of Phase 1 is 350 called an IKE SA. 352 The following attributes are used by IKE and are negotiated as part 353 of the IKE SA: 355 o Encryption algorithm. 357 o Hash algorithm. 359 o Authentication method (digital signature, public-key encryption or 360 pre-shared key). 362 o Diffie-Hellman group information. 364 After the attributes are negotiated, both parties must be 365 authenticated to each other. IKE supports multiple authentication 366 methods. The following mechanisms are generally implemented: 368 o Pre-shared keys: The same key is pre-installed on each host. IKE 369 peers authenticate each other by computing and sending a keyed 370 hash of data that includes the pre-shared key. If the receiving 371 peer can independently create the same hash using its preshared 372 key, it knows that both parties must share the same secret, and 373 thus the other party is authenticated. 375 o Public key cryptography: Each party generates a pseudo-random 376 number (a nonce) and encrypts it and its ID using the other 377 party's public key. The ability for each party to compute a keyed 378 hash containing the other peer's nonce and ID, decrypted with the 379 local private key, authenticates the parties to each other. This 380 method does not provide nonrepudiation; either side of the 381 exchange could plausibly deny that it took part in the exchange. 383 o Digital signature: Each device digitally signs a set of data and 384 sends it to the other party. This method is similar to the 385 public-key cryptography approach except that it provides 386 nonrepudiation. 388 Note that both digital signature and public-key cryptography require 389 the use of digital certificates to validate the public/private key 390 mapping. IKE allows the certificate to be accessed independently or 391 by having the two devices explicitly exchange certificates as part of 392 IKE. Both parties must have a shared session key to encrypt the IKE 393 tunnel. The Diffie-Hellman protocol is used to agree on a common 394 session key. 396 In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's 397 will be called IPsec SA's. These IPsec SA's use a different shared 398 key than that used for the IKE_SA. The IPsec SA shared key can be 399 derived by using Diffie-Hellman again or by refreshing the shared key 400 derived from the original Diffie-Hellman exchange that generated the 401 IKE_SA by hashing it with nonces. Once the shared key is derived and 402 additional communication parameters are negotiated, the IPsec SA's 403 are established and traffic can be exchanged using the negotiated 404 parameters. 406 4. Definition Format 408 The definition format utilized by this document is described in 409 [RFC1242], Section 2. 411 Term to be defined. 413 Definition: The specific definition for the term. 415 Discussion: A brief discussion of the term, its application, or 416 other information that would build understanding. 418 Issues: List of issues or conditions that affect this term. This 419 field can present items the may impact the term's related 420 methodology or otherwise restrict its measurement procedures. 422 Measurement units: (OPTIONAL) Units used to record measurements of 423 this term. This field is mandatory where applicable. This field 424 is optional in this document. 426 See Also: (OPTIONAL) List of other terms that are relevant to the 427 discussion of this term. This field is optional in this document. 429 5. Key Words to Reflect Requirements 431 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 432 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 433 document are to be interpreted as described in RFC 2119. RFC 2119 434 defines the use of these key words to help make the intent of 435 standards track documents as clear as possible. While this document 436 uses these keywords, this document is not a standards track document. 438 6. Existing Benchmark Definitions 440 It is recommended that readers consult [RFC1242], [RFC2544] and 442 [RFC2285] before making use of this document. These and other IETF 443 Benchmarking Methodology Working Group (BMWG) router and switch 444 documents contain several existing terms relevant to benchmarking the 445 performance of IPsec devices. The conceptual framework established 446 in these earlier RFC's will be evident in this document. 448 This document also draws on existing terminology defined in other 449 BMWG documents. Examples include, but are not limited to: 451 Throughput [RFC 1242, section 3.17] 452 Latency [RFC 1242, section 3.8] 453 Frame Loss Rate [RFC 1242, section 3.6] 454 Forwarding Rates [RFC 2285, section 3.6] 455 Loads [RFC 2285, section 3.5] 457 7. Definitions 459 7.1. IPsec 461 Definition: IPsec or IP Security protocol suite which comprises a 462 set of standards used to provide security services at the IP 463 layer. 465 Discussion: IPsec is a framework of protocols that offer 466 authentication, integrity and encryption services to the IP and/or 467 upper layer protocols. The major components of the protocol suite 468 are IKE, used for key exchanges, and IPsec protocols such as AH 469 and ESP, which use the exchanged keys to protect payload traffic. 471 Issues: N/A 473 See Also: IPsec Device, IKE, ISAKMP, ESP, AH 475 7.2. ISAKMP 477 Definition: The Internet Security Association and Key Management 478 Protocol, which provides a framework for authentication and key 479 exchange but does not define them. ISAKMP is designed to be key 480 exchange independent; it is designed to support many different key 481 exchanges. ISAKMP is defined in [RFC2407]. 483 Discussion: Though ISAKMP is only a framework for the IPsec standard 484 key management protocol, it is often misused and interchanged with 485 the term 'IKE', which is an implementation of ISAKMP. 487 Issues: When implementations refer to the term 'ISAKMP SA', it 488 refers to an IKE Phase 1 SA. 490 See Also: IKE, Security Association 492 7.3. IKE 494 Definition: A hybrid key management protocol that provides 495 authentication of the IPsec peers, negotiates IPsec SA's and 496 establishes IPsec keys. 498 Discussion: A hybrid protocol, defined in [RFC2409], from the 499 following 3 protocols: 501 * ISAKMP (Internet Security Association and Key Management 502 Protocol), which provides a framework for authentication and 503 key exchange but does not define them. ISAKMP is designed to 504 be key exchange independent; it is designed to support many 505 different key exchanges. 507 * Oakley, which describes a series of key exchanges, called 508 modes, and details the services provided by each (for example, 509 perfect forward secrecy for keys, identity protection, and 510 authentication). [RFC2412] 512 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 513 describes a versatile key exchange technique that provides 514 anonymity, reputability, and quick key refreshment. 516 Note that IKE is an optional protocol within the IPsec framework. 517 IPsec SA's may also be manually configured. Manual keying is the 518 most basic mechanism to establish IPsec SA's between two IPsec 519 devices. However, it is not a scalable solution and often 520 manually configured keys are not changed on a periodic basis which 521 reduces the level of protection since the keys are effectively 522 static and as a result are more prone to various attacks. When 523 IKE is employed as a key management protocol, the keys are 524 automatically renegotiated on a user-defined basis (time and/or 525 traffic volume based) as part of the IKE rekeying mechanism. 527 Issues: During the first IPsec deployment experiences, ambiguities 528 were found in the IKEv1 specification, which lead to 529 interoperability problems. To resolve these issues, IKEv1 is 530 being updated by IKEv2. 532 See Also: ISAKMP, IPsec, Security Association 534 7.3.1. IKE Phase 1 536 Definition: The shared policy and key(s) used by negotiating peers 537 to establish a secure authenticated "control channel" for further 538 IKE communications. 540 Discussion: The IPsec framework mandates that SPI's are used to 541 secure payload traffic. If IKE is employed all SPI information 542 will be exchanged between the IPsec devices. This has to be done 543 in a secure fashion and for that reason IKE will set up a secure 544 "control channel" over which it can exchange this information. 546 Note that IKE is an optional protocol within the IPsec framework 547 and that SPI information can also be manually configured. 549 Issues: In some documents often referenced as ISAKMP SA or IKE SA. 551 See Also: IKE, ISAKMP 553 7.3.2. IKE Phase 1 Main Mode 555 Definition: Main Mode is an instantiation of the ISAKMP Identity 556 Protect Exchange, defined in [RFC2409]. Upon successful 557 completion it results in the establishment of an IKE Phase 1 SA. 559 Discussion: IKE Main Mode use 3 distinct message pairs, for a total 560 of 6 messages. The first two messages negotiate policy; the next 561 two represent Diffie-Hellman public values and ancillary data 562 (e.g. nonces); and the last two messages authenticate the Diffie- 563 Hellman Exchange. The authentication method negotiated as part of 564 the initial IKE Phase 1 influence the composition of the payloads 565 but not their purpose. 567 Issues: N/A 569 See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 571 7.3.3. IKE Phase 1 Aggressive Mode 573 Definition: Aggressive Mode is an instantiation of the ISAKMP 574 Aggressive Exchange, defined in [RFC2409]. Upon successful 575 completion it results in the establishment of an IKE Phase 1 SA. 577 Discussion: IKE Aggressive Mode uses 3 messages. The first two 578 messages negotiate policy, exchange Diffie-Hellman public values 579 and ancillary data necessary for the exchange, and identities. In 580 addition the second message authenticates the Responder. The 581 third message authenticates the Initiator and provides proof of 582 participation in the exchange. 584 Issues: For IKEv1 the standard specifies that all implementations 585 use both main and agressive mode, however, it is common to use 586 only main mode. 588 See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 590 7.3.4. IKE Phase 2 592 Definition: ISAKMP phase which upon successful completion 593 establishes the shared keys used by the negotiating peers to set 594 up a secure "data channel" for IPsec. 596 Discussion: The main purpose of Phase 2 is to produce the key for 597 the IPsec tunnel. Phase 2 is also used for exchanging 598 informational messages. 600 Issues: In other documents also referenced as IPsec SA. 602 See Also: IKE Phase 1, ISAKMP, IKE 604 7.3.5. Phase 2 Quick Mode 606 Definition: Quick Mode is an instantiation of IKE Phase 2. After 607 successful completion it will result in one or typically two or 608 more IPsec SA's 610 Discussion: Quick Mode is used to negotiate the SA's and keys that 611 will be used to protect the user data. Three different messages 612 are exchanged, which are protected by the security parameters 613 negotiated by the IKE phase 1 exchange. An additional Diffie- 614 Hellman exchange may be performed if PFS (Perfect Forward Secrecy) 615 is enabled. 617 Issues: N/A 619 See Also: ISAKMP, IKE, IKE Phase 2 621 7.4. Security Association (SA) 623 Definition: A set of policy and key(s) used to protect traffic flows 624 that require authentication and/or encryption services. It is a 625 negotiation agreement between two IPsec devices, specifically the 626 Initiator and Responder. 628 Discussion: A simplex (unidirectional) logical connection that links 629 a traffic flow to a set of security parameters. All traffic 630 traversing an SA is provided the same security processing and will 631 be subjected to a common set of encryption and/or authentication 632 algorithms. In IPsec, an SA is an Internet layer abstraction 633 implemented through the use of AH or ESP as defined in [RFC2401]. 635 Issues: N/A 637 See Also: Initiator, Responder 639 7.5. Selectors 641 Definition: A mechanism used for the classification of traffic flows 642 that require authentication and/or encryption services. 644 Discussion: The selectors are a set of fields that will be extracted 645 from the network and transport layer headers that provide the 646 ability to classify the traffic flow and associate it with an SA. 648 After classification, a decision can be made if the traffic needs 649 to be encrypted/decrypted and how this should be done depending on 650 the SA linked to the traffic flow. Simply put, selectors classify 651 IP packets that require IPsec processing and those packets that 652 must be passed along without any intervention of the IPsec 653 framework. 655 Selectors are flexible objects that can match on ranges of source 656 and destination addresses and ranges of source and destination 657 ports. 659 Issues: Both sides must agree exactly on both the networks being 660 protected, and they both must agree on how to describe the 661 networks (range, subnet, addresses). This is a common point of 662 non-interoperability. 664 7.6. IPsec Device 665 Definition: Any implementation that has the ability to process data 666 flows according to the IPsec protocol suite specifications. 668 Discussion: Implementations can be grouped by 'external' properties 669 (e.g. software vs. hardware implementations) but more important is 670 the subtle differences that implementations may have with relation 671 to the IPsec Protocol Suite. Not all implementations will cover 672 all RFC's that encompass the IPsec Protocol Suite, but the 673 majority will support a large subset of features described in the 674 suite, nor will all implementations utilize all of the 675 cryptographic functions listed in the RFC's. 677 In that context, any implementation, that supports basic IP layer 678 security services as described in the IPsec protocol suite shall 679 be called an IPsec Device. 681 Issues: Due to the fragmented nature of the IPsec Protocol Suite 682 RFC's, it is possible that IPsec implementations will not be able 683 to interoperate. Therefore it is important to know which features 684 and options are implemented in the IPsec Device. 686 See Also: IPsec 688 7.6.1. Initiator 690 Definition: An IPsec device which starts the negotiation of IKE 691 Phase 1 and IKE Phase 2 SA's. 693 Discussion: When a traffic flow is offered at an IPsec device and it 694 is determined that the flow must be protected, but there is no 695 IPsec tunnel to send the traffic through, it is the responsibility 696 of the IPsec device to start a negotiation process that will 697 instantiate the IPsec tunnel. This process will establish an IKE 698 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 699 eventually resulting in secured data transport. The device that 700 takes the action to start this negotiation process will be called 701 an Initiator. 703 Issues: IPsec devices/implementations can be both an initiator as 704 well as a responder. The distinction is useful from a test 705 perspective. 707 See Also: Responder, IKE, IPsec 709 7.6.2. Responder 711 Definition: An IPsec device which replies to incoming IKE Phase 1 712 and IKE Phase 2 requests and processes these messages in order to 713 establish an IPsec tunnel. 715 Discussion: When an initiator attempts to establish SA's with 716 another IPsec device, this peer will need to evaluate the 717 proposals made by the initiator and either accept or deny them. 718 In the former case, the traffic flow will be decrypted according 719 to the negotiated parameters. Such a device will be called a 720 Responder. 722 Issues: IPsec devices/implementations can usually be both an 723 initiator as well as a responder. The distinction is useful from 724 a test perspective. 726 See Also: Initiator, IKE 728 7.6.3. IPsec Client 730 Definition: IPsec Devices that will only act as an Initiator. 732 Discussion: In some situations it is not needed or prefered to have 733 an IPsec device respond to an inbound IKE SA or IPsec SA request. 734 In the case of e.g. road warriors or home office scenarios the 735 only property needed from the IPsec device is the ability to 736 securely connect to a remote private network. The IPsec Client 737 will initiate one or more IPsec tunnels to an IPsec Server on the 738 network that needs to be accessed and to provide the required 739 security services. An IPsec client will silently drop and ignore 740 any inbound IPsec tunnel requests. IPsec clients are generally 741 used to connect remote users in a secure fashion over the Internet 742 to a private network. 744 Issues: N/A 746 See Also: IPsec device, IPsec Server, Initiator, Responder 748 7.6.4. IPsec Gateway 750 Definition: IPsec Devices that can both act as an Initiator as well 751 as a Responder. 753 Discussion: IPsec Servers are mostly positioned at private network 754 edges and provide several functions: 756 * Responds to IPsec tunnel setup request from IPsec Clients. 758 * Responds to IPsec tunnel setup request from other IPsec devices 759 (Initiators). 761 * Initiate IPsec tunnels to other IPsec servers inside or outside 762 the private network. 764 Issues: IPsec Gateways are also sometimes referred to as 'IPsec 765 Servers' or 'VPN Concentrators'. 767 See Also: IPsec Device, IPsec Client, Initiator, Responder 769 7.7. Tunnels 771 The term "tunnel" is often used in a variety of contexts. To avoid 772 any discrepancies, in this document, the following distinctions have 773 been defined: 775 7.7.1. IPsec Tunnel 777 Definition: The combination of an IKE Phase 1 SA and a single pair 778 of IKE Phase 2 SA's. 780 Discussion: An IPsec Tunnel will be defined as a single (1) Phase 1 781 SA and a pair (2) Phase 2 SA's. This construct will allow 782 bidirectional traffic to be passed between two IPsec Devices where 783 the traffic can benefit form the services offered in the IPsec 784 framework. 786 Issues: Since it is implied that a Phase 1 SA is used, an IPsec 787 Tunnel will be by definition a dynamically negotiated secured 788 link. If manual keying is used to enable secure data transport, 789 then this link will merely be referred to as a pair of IPsec SA's. 791 It is very likely that more then one pair of Phase 2 SA's are 792 associated with a single Phase 1 SA. Also in this case, the IPsec 793 Tunnel definition WILL NOT apply. Instead the ratio between Phase 794 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella 795 term of "IPsec Tunnel" MUST NOT be used in this context. 797 See Also: IKE Phase 1, IKE Phase 2 799 7.7.2. Configured Tunnel 800 Definition: An IPsec tunnel or a pair of IPsec SA's in the case of 801 manual keying that is provisioned in the IPsec device's 802 configuration. 804 Discussion: Several steps are required before IPsec can be used to 805 actually transport traffic. The very first step is to configure 806 the IPsec Tunnel (or IPsec SA's in the case of manual keying) in 807 the IPsec device. When using IKE there are no SA's associated 808 with the IPsec Tunnel and no traffic is going through the IPsec 809 device that matches the Selectors, which would instantiate the 810 IPsec Tunnel. When using either manual keying or IKE, a 811 configured tunnel will not have a populated Security Association 812 Database (SADB). 814 Issues: When using IKE, a configured tunnel will not have any SA's 815 while with manual keying, the SA's will have simply been 816 configured but not populated in the SADB. 818 See Also: IPsec Tunnel, Established Tunnel, Active Tunnel 820 7.7.3. Established Tunnel 822 Definition: An IPsec device that has a populated SADB and is ready 823 to provide security services to the appropriate traffic. 825 Discussion: When using IKE, a second step needed to ensure that an 826 IPsec Tunnel can transport data is to complete the Phase 1 and 827 Phase 2 negotiations. After the packet classification process has 828 asserted that a packet requires security services, the negotation 829 is started to obtain both Phase 1 and Phase 2 SA's. After this is 830 completed and the SADB is populated, the IPsec Tunnel is called 831 'Established'. Note that at this time there is still no traffic 832 flowing through the IPsec Tunnel. Just enough packet(s) have been 833 sent to the IPsec device that matched the selectors and triggered 834 the IPsec Tunnel setup to result in a populated SADB. In the case 835 of manual keying, populating the SADB is accomplished by a 836 separate administrative command. 838 Issues: N/A 840 See Also: IPsec Tunnel, Configured Tunnel, Active Tunnel 842 7.7.4. Active Tunnel 844 Definition: An IPsec device that is forwarding secured data. 846 Discussion: When a Tunnel is Established and it is transporting 847 traffic that is authenticated and/or encrypted, the tunnel is 848 called 'Active'. 850 Issues: The distinction between an Active Tunnel and Configured/ 851 Established Tunnel is made in the context of manual keyed Tunnels. 852 In this case it would be possible to have an Established tunnel on 853 an IPsec device which has no counterpart on it's corresponding 854 peer. This will lead to encrypted traffic flows which will be 855 discarded on the receiving peer. Only if both peers have an 856 Established Tunnel that shows evidence of traffic transport, it 857 may be called an Active Tunnel. 859 See Also: IPsec Tunnel, Configured Tunnel, Established Tunnel 861 7.8. Iterated Tunnels 863 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 864 The bundles are divided into two major groups : 866 7.8.1. Nested Tunnels 868 Definition: An SA bundle consisting of two or more 'tunnel mode' 869 SA's. 871 Discussion: The process of nesting tunnels can theoretically be 872 repeated multiple times (for example, tunnels can be many levels 873 deep), but for all practical purposes, most implementations limit 874 the level of nesting. Nested tunnels can use a mix of AH and ESP 875 encapsulated traffic. 877 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 878 | | | | 879 | | | | 880 | +----{SA1 (ESP tunnel)}----+ | 881 | | 882 +--------------{SA2 (AH tunnel)}---------------+ 884 In the IP Cloud a packet would have a format like this : 885 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 887 Nested tunnels can be deployed to provide additional security on 888 already secured traffic. A typical example of this would be that 889 the inner gateways (GW2 and GW3) are securing traffic between two 890 branch offices and the outer gateways (GW1 & GW4) add an 891 additional layer of security between departments within those 892 branch offices. 894 Issues: N/A 896 See Also: Transport Adjacency, IPsec Tunnel 898 7.8.2. Transport Adjacency 900 Definition: An SA bundle consisting of two or more transport mode 901 SA's. 903 Discussion: Transport adjacency is a form of tunnel nesting. In 904 this case two or more transport mode IPsec tunnels are set side by 905 side to enhance applied security properties. 907 Transport adjacency can be used with a mix of AH and ESP tunnels 908 although some combinations are not preferred. If AH and ESP are 909 mixed, the ESP tunnel should always encapsulate the AH tunnel. 910 The reverse combination is a valid combination but doesn't make 911 cryptographical sense. 913 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 914 | | | | 915 | | | | 916 | +------{SA1 (ESP transport)}--------+ | 917 | | 918 +-------------{SA2 (AH transport)}--------------+ 920 In the IP Cloud a packet would have a format like this : 921 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 923 Issues: This is rarely used in the way it is depicted. It is more 924 common, but still not likely, that SA's are established from 925 different gateways as depicted in the Nested Tunnels figure. The 926 packet format in the IP Cloud would remain unchanged. 928 See Also: Nested Tunnels, IPsec Tunnel 930 7.9. Transform protocols 932 Definition: Encryption and authentication algorithms that provide 933 cryptograhic services to the IPsec Protocols. 935 Discussion: Some algorithms run significantly slower than others. A 936 decision for which algorithm to use is usually based on the 937 tradeoff between performance and security strength. For example, 938 3DES encryption is generally slower then DES encryption. 940 Issues: N/A 942 See Also: Authentication protocols, Encryption protocols 944 7.9.1. Authentication Protocols 946 Definition: Algorithms which provide data integrity and data source 947 authentication. 949 Discussion: Authentication protocols provide no confidentiality. 950 Commonly used authentication algorithms/protocols are: 952 * MD5-HMAC 953 * SHA-HMAC 954 * AES-HMAC 956 Issues: N/A 958 See Also: Transform protocols, Encryption protocols 960 7.9.2. Encryption Protocols 962 Definition: Algorithms which provide data confidentiality. 964 Discussion: Encryption protocols provide no authentication. 965 Commonly used encryption algorithms/protocols are: 967 * NULL encryption 968 * DES-CBC 969 * 3DES-CBC 970 * AES-CBC 972 Issues: The null-encryption option is a valid encryption mechanism 973 to provide an alternative to using AH. There is no 974 confidentiality protection with null-encryption. Note also that 975 when using ESP null-encryption the authentication and integrity 976 services only apply for the upper layer protocols and not for the 977 IP header itself. 979 DES has been officially deprecated by NIST, though it is still 980 mandated by the IPsec framework and is still commonly implemented 981 and used due to it's speed advantage over 3DES. AES will be the 982 successor of 3DES due to its superior encryption and performance 983 advantage. 985 See Also: Transform protocols, Authentication protocols 987 7.10. IPsec Protocols 989 Definition: A suite of protocols which provide a framework of open 990 standards that provides data origin confidentiality, data 991 integrity, and data origin authenticity between participating 992 peers at the IP layer. The original IPsec protocol suite set of 993 standards is documented in [RFC2401] through [RFC2412] and 994 [RFC2451]. At this time [RFC4301] updates [RFC2401] (IPsec 995 Architecture), [RFC4302] updates [RFC2402] (AH) and [RFC4303] 996 updates [RFC2406] (ESP) 998 Discussion: The IPsec Protocol suite is modular and forward 999 compatible. The protocols that comprise the IPsec protocol suite 1000 can be replaced with new versions of those protocols as the older 1001 versions become obsolete. For example, IKEv2 will soon replace 1002 IKEv1. 1004 Issues: N/A 1006 See Also: AH, ESP 1008 7.10.1. Authentication Header (AH) 1010 Definition: Provides data origin authentication and data integrity 1011 (including replay protection) security services as defined in 1012 [RFC4302]. 1014 Discussion: The AH protocol supports two modes of operation i.e. 1015 tunnel mode and transport mode. 1017 In transport mode, AH is inserted after the IP header and before a 1018 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any 1019 other IPsec headers that have already been inserted. In the 1020 context of IPv4, this calls for placing AH after the IP header 1021 (and any options that it contains), but before the next layer 1022 protocol. In the IPv6 context, AH is viewed as an end-to-end 1023 payload, and thus should appear after hop-by-hop, routing, and 1024 fragmentation extension headers. The destination options 1025 extension header(s) could appear before or after or both before 1026 and after the AH header depending on the semantics desired. 1028 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1029 source and destination addresses, while an "outer" IP header 1030 contains the addresses of the IPsec "peers," e.g., addresses of 1031 security gateways. In tunnel mode, AH protects the entire inner 1032 IP packet, including the entire inner IP header. The position of 1033 AH in tunnel mode, relative to the outer IP header, is the same as 1034 for AH in transport mode. 1036 Issues: AH is rarely used to secure traffic over the Internet. 1038 See Also: Transform protocols, IPsec protocols, Encapsulated 1039 Security Payload 1041 7.10.2. Encapsulated Security Payload (ESP) 1043 Definition: Provides data origin authentication, data integrity 1044 (including replayprotection) and data confidentiality as defined 1045 in [RFC4303]. 1047 Discussion: The ESP protocol supports two modes of operation i.e. 1048 tunnel mode and transport mode. 1050 In transport mode, ESP is inserted after the IP header and before 1051 a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context 1052 of IPv4, this translates to placing ESP after the IP header (and 1053 any options that it contains), but before the next layer protocol. 1054 In the IPv6 context, ESP is viewed as an end-to-end payload, and 1055 thus should appear after hop-by-hop, routing, and fragmentation 1056 extension headers. Destination options extension header(s) could 1057 appear before, after, or both before and after the ESP header 1058 depending on the semantics desired. However, since ESP protects 1059 only fields after the ESP header, it generally will be desirable 1060 to place the destination options header(s) after the ESP header. 1062 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1063 source and destination addresses, while an "outer" IP header 1064 contains the addresses of the IPsec "peers", e.g., addresses of 1065 security gateways. Mixed inner and outer IP versions are allowed, 1066 i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP 1067 protects the entire inner IP packet, including the entire inner IP 1068 header. The position of ESP in tunnel mode, relative to the outer 1069 IP header, is the same as for ESP in transport mode. 1071 Issues: N/A 1072 See Also: Transform protocols, IPsec protocols, Authentication 1073 Header 1075 7.11. NAT Traversal (NAT-T) 1077 Definition: The capability to support IPsec functionality in the 1078 presence of NAT devices. 1080 Discussion: NAT-Traversal requires some modifications to IKE as 1081 defined in [RFC3947]. Specifically, in phase 1, it requires 1082 detecting if the other end supports NAT-Traversal, and detecting 1083 if there are one or more NAT instances along the path from host to 1084 host. In IKE Quick Mode, there is a need to negotiate the use of 1085 UDP encapsulated IPsec packets. 1087 NAT-T also describes how to transmit the original source and 1088 destination addresses to the corresponding IPsec Device. The 1089 original source and destination addresses are used in transport 1090 mode to incrementally update the TCP/IP checksums so that they 1091 will match after the NAT transform (The NAT cannot do this, 1092 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1093 packet). 1095 Issues: N/A 1097 See Also: IKE, ISAKMP, IPsec Device 1099 7.12. IP Compression 1101 Definition: A mechanism as defined in [RFC2393] that reduces the 1102 size of the payload that needs to be encrypted. 1104 Discussion: IP payload compression is a protocol to reduce the size 1105 of IP datagrams. This protocol will increase the overall 1106 communication performance between a pair of communicating hosts/ 1107 gateways ("nodes") by compressing the datagrams, provided the 1108 nodes have sufficient computation power, through either CPU 1109 capacity or a compression coprocessor, and the communication is 1110 over slow or congested links. 1112 IP payload compression is especially useful when encryption is 1113 applied to IP datagrams. Encrypting the IP datagram causes the 1114 data to be random in nature, rendering compression at lower 1115 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1116 ineffective. If both compression and encryption are required, 1117 compression must be applied before encryption. 1119 Issues: N/A 1121 See Also: IKE, ISAKMP, IPsec Device 1123 7.13. Security Context 1125 Definition: A security context is a collection of security 1126 parameters that describe the characteristics of the path that an 1127 IPsec Tunnel will take, all of the IPsec Tunnel parameters and the 1128 effects it has on the underlying protected traffic. Security 1129 Context encompasses protocol suite and security policy. 1131 Discussion: In order to fairly compare multiple IPsec devices it is 1132 imperative that an accurate overview is given of all security 1133 parameters that were used to establish the IPsec Tunnels or 1134 manually created SA's and to secure the traffic between protected 1135 networks. Security Context is not a metric. It is included to 1136 accurately reflect the test environment variables when reporting 1137 the methodology results. To avoid listing too much information 1138 when reporting metrics, the Security Context is divided into an 1139 IKE context and an IPsec context. 1141 When merely discussing the behavior of traffic flows through IPsec 1142 devices, an IPsec context MUST be provided. In other cases the 1143 scope of a discussion or report may focus on a more broad set of 1144 behavioral characteristics of the IPsec device, in which case both 1145 an IPsec and an IKE context MUST be provided. 1147 The IPsec context MUST consist of the following elements: 1149 * Manual Keyed Tunnels versus IKE negotiated Tunnels 1151 * Number of IPsec Tunnels or IPsec SA's 1153 * IPsec protocol (AH or ESP) 1155 * IPsec protocol mode (tunnel or transport) 1157 * Authentication algorithm used by AH/ESP 1159 * Encryption algoritm used ESP (if applicable) 1161 * IPsec SA lifetime (traffic and time based) 1163 * Anti Replay Window Size (Assumed to be 64 packets if not 1164 specified) 1166 The IPsec Context MAY also list: 1168 * Selectors 1170 * Fragmentation handling (assumed to be post-encryption when not 1171 mentioned) 1173 * Path MTU Discovery (PMTUD) (assumed disabled when not 1174 mentioned) 1176 The IKE Context MUST consist of the following elements: 1178 * Number of IPsec Tunnels. 1180 + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable) 1182 + IKE Phase 1 parameters 1184 - Authentication algorithm 1186 - Encryption algorithm 1188 - DH-Group 1190 - SA lifetime (traffic and time based) 1192 - Authentication mechanism (pre-shared key, RSA-sig, 1193 certificate, etc) 1195 + IKE Phase 2 parameters 1197 - IPsec protocol (part of IPsec context) 1199 - IPsec protocol mode (part of IPsec context) 1201 - Authentication algorithm (part of IPsec context) 1203 - Encryption algorithm (part of IPsec context) 1205 - DH-Group 1207 - PFS Group used 1209 - SA Lifetime (part of IPsec context) 1211 * Use of IKE Keepalive or Dead Peer Detection (DPD), as defined 1212 in [RFC3706], and its interval and retry values (assumed 1213 disabled when not mentioned). 1215 * IP Compression [RFC2393] 1217 The IKE context MUST also list: 1219 * Phase 1 mode (main or aggressive) 1221 * Available bandwidth and latency to Certificate Authority server 1222 (if applicable) 1224 * Indication of NAT traversal 1226 Issues: A Security Context will be an important element in 1227 describing the environment where protected traffic is traveling 1228 through. 1230 See Also: IPsec Protocols, Transform Protocols, IKE Phase 1, IKE 1231 phase 2, Selectors, IPsec Tunnel 1233 8. Framesizes 1235 8.1. Layer3 clear framesize 1237 Definition: The total size of the unencrypted L3 PDU. 1239 Discussion: In relation to IPsec this is the size of the IP header 1240 and its payload. It SHALL NOT include any encapsulations that MAY 1241 be applied before the PDU is processed for encryption. 1243 IPv4 example: For a 64 byte Ethernet packet, the IPv4 Layer3 PDU 1244 is calculated as: 1246 L3 PDU = 64 bytes - L2 Ethernet Header (18 bytes) 1247 = 46 bytes PDU 1248 = 20 bytes IPv4 header + 26 bytes payload. 1250 IPv6 example: For a 64 byte Ethernet packet, the IPv6 Layer3 PDU 1251 is calculated as: 1253 L3 PDU = 64 bytes - L2 Ethernet Header (18 bytes) 1254 = 46 bytes PDU 1255 = 40 bytes IPv6 base header + 6 bytes payload. 1257 Measurement Units: Bytes 1258 Issues: N/A 1260 See Also: Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1261 Encrypted Framesize. 1263 8.2. Layer3 encrypted framesize 1265 Definition: The total size of the encrypted L3 PDU. 1267 Discussion: The size of the IP packet and its payload after 1268 encapsulations MAY be applied and the PDU is being processed by 1269 the transform. 1271 For example, when using a tunnel mode ESP 3DES/SHA1 transform to 1272 protect an unencrypted IPv4 L3 PDU of 46 bytes, the L3 encrypted 1273 framesize becomes 96 bytes: 1275 20 bytes outer IPv4 header (Tunnel mode) 1276 4 bytes SPI (ESP Header) 1277 4 bytes Sequence (ESP Header) 1278 8 bytes IV (IOS ESP-3DES) 1279 46 bytes payload (Original IPv4 L3 PDU) 1280 0 bytes pad (ESP-3DES 64 bit) 1281 1 byte Pad length (ESP Trailer) 1282 1 byte Next Header (ESP Trailer) 1283 12 bytes ESP-HMAC SHA1 96 digest 1285 For the same example but protecting an unencrypted IPv6 L3 PDU of 1286 46 bytes, the L3 framesize becomes 116 bytes: 1288 40 bytes outer IPv6 header (Tunnel mode) 1289 4 bytes SPI (ESP Extension Header) 1290 4 bytes Sequence (ESP Extension Header) 1291 8 bytes IV (IOS ESP-3DES) 1292 46 bytes payload (Original IPv6 L3 PDU) 1293 0 bytes pad (ESP-3DES 64 bit) 1294 1 byte Pad length (ESP Trailer) 1295 1 byte Next Header (ESP Trailer) 1296 12 bytes ESP-HMAC SHA1 96 digest 1298 Measurement Units: Bytes 1300 Issues: N/A 1302 See Also: Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 1303 Encrypted Framesize. 1305 9. Performance Metrics 1307 9.1. IPsec Tunnels Per Second (TPS) 1309 Definition: The measurement unit for the IPsec Tunnel Setup Rate 1310 tests. The rate at which IPsec Tunnels are established per 1311 second. 1313 Discussion: According to [RFC2401] two IPsec Tunnels cannot be 1314 established between the same gateways with the same selectors. 1315 This is to prevent overlapping IPsec Tunnels. If overlapping 1316 IPsec Tunnels are attempted, the error will cause the IPsec Tunnel 1317 setup time to take longer than if the IPsec Tunnel setup was 1318 successful (and non-overlapping). For this reason, a unique pair 1319 of selector sets are required for IPsec Tunnel Setup Rate testing. 1321 Issues: A unique pair of selector sets are required for TPS testing. 1323 See Also: IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, 1324 IKE Setup Rate, IPsec Setup Rate 1326 9.2. Tunnel Rekeys Per Second (TRPS) 1328 Definition: A metric that quantifies the number of IKE Phase 1 or 1329 Phase 2 rekeys per second a DUT can correctly process. 1331 Discussion: This metric will be will be primary used with Tunnel 1332 Rekey behavior tests. 1334 TRPS will provide a metric used to see system behavior under 1335 stressful conditions where large volumes of SA's are being rekeyed 1336 at the same time or in a short timespan. 1338 Issues: N/A 1340 See Also: Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey 1341 Rate 1343 9.3. IPsec Tunnel Attempts Per Second (TAPS) 1345 Definition: A metric that quantifies the number of successful and 1346 unsuccessful IPsec Tunnel establishment requests per second. 1348 Discussion: This metric can be used to measure IKE DOS Resilience 1349 behavior. 1351 TAPS provides an important metric to validate the stability of an 1352 IPsec device, if stressed with valid (large number of IPsec tunnel 1353 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1354 any style) tunnel establishment requests. IPsec Tunnel setups 1355 offered to an IPsec devices can either fail due to lack of 1356 resources in the IPsec device to process all the requests or due 1357 to an IKE DOS attack (usually the former is a result of the 1358 latter). 1360 Issues: If the TAPS increases, the TPS usually decreases, due to 1361 burdening of the DUT with the DOS attack traffic. 1363 See Also: N/A 1365 10. Test Definitions 1367 10.1. Capacity 1369 10.1.1. IPsec Tunnel Capacity 1371 Definition: The maximum number of Active IPsec Tunnels that can be 1372 sustained on an IPsec Device. 1374 Discussion: This metric will represent the quantity of IPsec Tunnels 1375 that can be established on an IPsec Device that can forward 1376 traffic i.e. Active Tunnels. It will be a measure that indicates 1377 how many remote peers an IPsec Device can establish a secure 1378 connection with. For IPsec Tunnel Capacity, each IPsec SA is 1379 associated with exactly 1 IKE SA. 1381 Measurement Units: IPsec Tunnels 1383 Issues: N/A 1385 See Also: IPsec SA Capacity 1387 10.1.2. IPsec SA Capacity 1389 Definition: The maximum number of IPsec SA's that can be sustained 1390 on an IPsec Device. 1392 Discussion: This metric will represent the quantity of traffic flows 1393 a given IPsec Device can protect. In contrast with the IPsec 1394 Tunnel Capacity, the emphasis for this test lies on the number of 1395 IPsec SA's that can be established in the worst case scenario. 1396 This scenario would be a case where 1 IKE SA is used to negotiate 1397 multiple IPsec SA's. It is the maximum number of Active Tunnels 1398 that can be sustained by an IPsec Device where only 1 IKE SA is 1399 used to exchange keying material. 1401 Measurement Units: IPsec SA's 1403 Issues: N/A 1405 See Also: IPsec Tunnel Capacity 1407 10.2. Throughput 1409 10.2.1. IPsec Throughput 1411 Definition: The maximum rate through an Active Tunnel at which none 1412 of the offered frames are dropped by the device under test. 1414 Discussion: The IPsec Throughput is almost identically defined as 1415 Throughput in [RFC1242], section 3.17. The only difference is 1416 that the throughput is measured with a traffic flow getting 1417 encrypted and decrypted by an IPsec device. IPsec Throughput is 1418 an end-to-end measurement. 1420 Measurement Units: Packets per seconds (pps) 1422 Issues: N/A 1424 See Also: IPsec Encryption Throughput, IPsec Decryption Throughput 1426 10.2.2. IPsec Encryption Throughput 1428 Definition: The maximum encryption rate through an Active Tunnel at 1429 which none of the offered cleartext frames are dropped by the 1430 device under test. 1432 Discussion: Since encryption throughput is not necessarily equal to 1433 the decryption throughput, both of the forwarding rates must be 1434 measured independently. The independent forwarding rates have to 1435 measured with the help of an IPsec aware test device that can 1436 originate and terminate IPsec and IKE SA. As defined in 1437 [RFC1242], measurements should be taken with an assortment of 1438 frame sizes. 1440 Measurement Units: Packets per seconds (pps) 1442 Issues: In some cases packets are offered to an IPsec Device that 1443 have a framesize that is larger then the MTU of the ingress 1444 interface of the IPsec Tunnel that is transporting the packet. In 1445 this case fragmentation will be required before IPsec services are 1446 applied. 1448 In other cases, the packet is of a size very close to the MTU of 1449 the egress interface of the IPsec Tunnel. Here, the mere addition 1450 of the IPsec header will create enough overhead to make the IPsec 1451 packet larger then the MTU of the egress interface. In such 1452 instance, the original payload packet must be fragmented either 1453 before or after the IPsec overhead is applied. 1455 Note that the two aforementioned scenarios can happen 1456 simultaniously on a single packet, creating multiple small 1457 fragments. 1459 When measuring the IPsec Encryption Throughput, one has to 1460 consider that when probing with packets of a size near MTU's 1461 associated with the IPsec Tunnel, fragmentation may accor and the 1462 decrypting IPsec Device (either a tester or a corresponding IPsec 1463 peer) has to reassemble the IPsec and/or payload fragments to 1464 validate its content. 1466 The end points (i.e. hosts, subnets) should NOT see any fragments 1467 at ANY time. Only on the IPsec link, fragments MAY occur. 1469 See Also: IPsec Throughput, IPsec Decryption Throughput 1471 10.2.3. IPsec Decryption Throughput 1473 Definition: The maximum decryption rate through an Active Tunnel at 1474 which none of the offered encrypted frames are dropped by the 1475 device under test. 1477 Discussion: Since encryption throughput is not necessarily equal to 1478 the decryption throughput, both of the forwarding rates must be 1479 measured independently. 1481 The independent forwarding rates have to be measured with the help 1482 of an IPsec aware test device that can originate and terminate 1483 IPsec and IKE SA. As defined in [RFC1242], measurements should be 1484 taken with an assortment of frame sizes. 1486 Measurement Units: Packets per seconds (pps) 1488 Issues: When measuring the IPsec Decryption Throughput, one has to 1489 consider that it is likely that the encrypting IPsec Device has to 1490 fragment certain packets that have a frame size near MTU's 1491 associated with the IPsec Tunnel. 1493 The decrypting IPsec Device has to reassemble the IPsec and/or 1494 payload fragments to validate its content. 1496 The end points (i.e. hosts, subnets) should NOT see any fragments 1497 at ANY time. Only on the IPsec link, fragments MAY occur. 1499 See Also: IPsec Throughput, IPsec Encryption Throughput 1501 10.3. Latency 1503 10.3.1. IPsec Latency 1505 Definition: Time required to propagate a cleartext frame from the 1506 input interface of an initiator, through an Active Tunnel, to the 1507 output interface of the responder. 1509 Discussion: The IPsec Latency is the time interval starting when the 1510 end of the first bit of the cleartext frame reaches the input 1511 interface of the initiator and ending when the start of the first 1512 bit of the same cleartext frame is detected on the output 1513 interface of the responder. The frame has passed through an 1514 Active Tunnel between an initiator and a responder and has been 1515 through an encryption and decryption cycle. 1517 Measurement Units: Time units with enough precision to reflect 1518 latency measurement. 1520 Issues: N/A 1522 See Also: IPsec Encryption Latency, IPsec Decryption Latency 1524 10.3.2. IPsec Encryption Latency 1526 Definition: The IPsec Encryption Latency is the time interval 1527 starting when the end of the first bit of the cleartext frame 1528 reaches the input interface, through an Active Tunnel, and ending 1529 when the start of the first bit of the encrypted output frame is 1530 seen on the output interface. 1532 Discussion: IPsec Encryption Latency is the latency introduced when 1533 encrypting traffic through an IPsec tunnel. 1535 Like encryption/decryption throughput, it is not always the case 1536 that encryption latency equals the decryption latency. Therefore 1537 a distinction between the two has to be made in order to get a 1538 more accurate view of where the latency is the most pronounced. 1540 The independent encryption/decryption latencies have to be 1541 measured with the help of an IPsec aware test device that can 1542 originate and terminate IPsec and IKE SA. As defined in 1543 [RFC1242], measurements should be taken with an assortment of 1544 frame sizes. 1546 Measurement Units: Time units with enough precision to reflect 1547 latency measurement. 1549 Issues: N/A 1551 See Also: IPsec Latency, IPsec Decryption Latency 1553 10.3.3. IPsec Decryption Latency 1555 Definition: The IPsec decryption Latency is the time interval 1556 starting when the end of the first bit of the encrypted frame 1557 reaches the input interface, through an Active Tunnel, and ending 1558 when the start of the first bit of the decrypted output frame is 1559 seen on the output interface. 1561 Discussion: IPsec Decryption Latency is the latency introduced when 1562 decrypting traffic through an Active Tunnel. Like encryption/ 1563 decryption throughput, it is not always the case that encryption 1564 latency equals the decryption latency. Therefore a distinction 1565 between the two has to be made in order to get a more accurate 1566 view of where the latency is the most pronounced. 1568 The independent encryption/decryption latencies have to be 1569 measured with the help of an IPsec aware test device that can 1570 originate and terminate IPsec and IKE SA's. As defined in 1571 [RFC1242], measurements should be taken with an assortment of 1572 frame sizes. 1574 Measurement Units: Time units with enough precision to reflect 1575 latency measurement. 1577 Issues: N/A 1579 See Also: IPsec Latency, IPsec Encryption Latency 1581 10.3.4. Time To First Packet 1583 Definition: The Time To First Packet (TTFP) is the time required to 1584 process a cleartext packet from a traffic stream that requires 1585 encryption services when no IPsec Tunnel is present. 1587 Discussion: The Time To First Packet addresses the issue of 1588 responsiveness of an IPsec device by looking how long it takes to 1589 transmit a packet over Configured Tunnel. The Time To First 1590 Packet MUST include the time to set up the established tunnel, 1591 triggered by the traffic flow (both phase 1 and phase 2 setup 1592 times SHALL be included) and the time it takes to encrypt and 1593 decrypt the packet on a corresponding peer. In short it is the 1594 IPsec Tunnel setup time plus the propagation delay of the packet 1595 through the Active Tunnel. 1597 It must be noted that it is highly unlikely that the first packet 1598 of the traffic flow will be the packet that will be used to 1599 measure the TTFP. There MAY be several protocol layers in the 1600 stack before the tunnel is formed and the traffic is forwarded, 1601 hence several packets COULD be lost during negotiation, for 1602 example, ARP and/or IKE. 1604 Measurement Units: Time units with enough precision to reflect a 1605 TTFP measurement. 1607 Issues: Only relevant when using IKE for tunnel negotiation. 1609 10.4. Frame Loss 1611 10.4.1. IPsec Frame Loss 1613 Definition: Percentage of cleartext frames that should have been 1614 forwarded through an Active Tunnel under steady state (constant) 1615 load but were dropped before encryption or after decryption. 1617 Discussion: The IPsec Frame Loss is almost identically defined as 1618 Frame Loss Rate in [RFC1242], section 3.6. The only difference is 1619 that the IPsec Frame Loss is measured with a traffic flow getting 1620 encrypted and decrypted by an IPsec Device. IPsec Frame Loss is 1621 an end-to-end measurement. 1623 Measurement Units: Percent (%) 1625 Issues: N/A 1627 See Also: IPsec Encryption Frame Loss, IPsec Decryption Frame Loss 1629 10.4.2. IPsec Encryption Frame Loss 1631 Definition: Percentage of cleartext frames that should have been 1632 encrypted through an Active Tunnel under steady state (constant) 1633 load but were dropped. 1635 Discussion: A DUT will always have an inherent forwarding 1636 limitation. This will be more pronounced when IPsec is employed 1637 on the DUT. There is a possibility that the offered traffic rate 1638 at the Active Tunnel is too high to be transported through the 1639 Active Tunnel and not all cleartext packets will get encrypted. 1640 In that case, some percentage of the cleartext traffic will be 1641 dropped. This drop percentage is called the IPsec Encryption 1642 Frame Loss. 1644 Measurement Units: Percent (%) 1646 Issues: N/A 1648 See Also: IPsec Frame Loss, IPsec Decryption Frame Loss 1650 10.4.3. IPsec Decryption Frame Loss 1652 Definition: Percentage of encrypted frames that should have been 1653 decrypted through an Active Tunnel under steady state (constant) 1654 load but were dropped. 1656 Discussion: A DUT will also have an inherent forwarding limitation 1657 when decrypting packets. When Active Tunnel encrypted traffic is 1658 offered at a costant load, there might be a possibility that the 1659 IPsec Device that needs to decrypt the traffic will not be able to 1660 perfom this action on all of the packets due to limitations of the 1661 decryption performance. The percentage of encrypted frames that 1662 would get dropped under these conditions is called the IPsec 1663 Decryption Frame Loss. 1665 Measurement Units: Percent (%) 1667 Issues: N/A 1669 See Also: IPsec Frame Loss, IPsec Encryption Frame Loss 1671 10.4.4. IKE Phase 2 Rekey Frame Loss 1673 Definition: Number of frames dropped as a result of an inefficient 1674 IKE Phase 2 rekey. 1676 Discussion: Normal operation of an IPsec Device would require that a 1677 rekey does not create temporary IPsec Frame Loss of a traffic 1678 stream that is protected by the IKE Phase 2 SA's (i.e. IPsec 1679 SA's). Nevertheless there can be situations where IPsec Frame 1680 Loss occurs during this rekey process. 1682 This metric should be ideally zero but this may not be the case on 1683 IPsec Devices where IPsec funtionality is not a core feature. 1685 Measurement Units: Number of N-octet frames 1687 Issues: N/A 1689 See Also: IKE Phase 2 Rekey Rate 1691 10.5. Tunnel Setup Behavior 1693 10.5.1. IPsec Tunnel Setup Rate 1695 Definition: The maximum number of IPsec Tunnels per second that an 1696 IPsec Device can successfully establish. 1698 Discussion: The Tunnel Setup Rate SHOULD be measured at varying 1699 number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the 1700 DUT. Several factors may influence Tunnel Setup Rate, such as: 1701 TAPS rate, Background cleartext traffic load on the secure 1702 interface, Already established IPsec Tunnels, Authentication 1703 method such as pre-shared keys, RSA-encryption, RSA-signature, DSS 1704 Key sizes used (when using RSA/DSS). 1706 The Tunnel Setup Rate is an important factor to understand when 1707 designing networks using stateless failover of IPsec tunnels to a 1708 standby chassis. At the same time it can be important to set 1709 Connection and Admission control paramters in an IPsec device to 1710 prevent overloading the IPsec Device. 1712 Measurement Units: Tunnels Per Second (TPS) 1714 Issues: N/A 1716 See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec 1717 Tunnel Rekey Behavior 1719 10.5.2. IKE Phase 1 Setup Rate 1721 Definition: The maximum number of sucessful IKE Phase 1 SA's per 1722 second that an IPsec Device can establish. 1724 Discussion: The Phase 1 Setup Rate is a portion of the IPsec Tunnel 1725 Setup Rate. In the process of establishing an IPsec Tunnel, it is 1726 interesting to know what the limiting factor of the IKE Finite 1727 State Machine (FSM) is i.e. is it limited by the Phase 1 1728 processing delays or rather by the Phase 2 processing delays. 1730 Measurement Units: Tunnels Per Second (TPS) 1732 Issues: N/A 1734 See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec 1735 Tunnel Rekey Behavior 1737 10.5.3. IKE Phase 2 Setup Rate 1739 Definition: The maximum number of successful IKE Phase 2 SA's per 1740 second that an IPsec Device can Only relevant when using IKE 1741 establish. 1743 Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec 1744 Tunnel Setup Rate. For identical reasons why it is required to 1745 quantify the IKE Phase 1 Setup Rate, it is a good practice to know 1746 the processing delays involved in setting up an IKE Phase 2 SA for 1747 each direction of the protected traffic flow. 1749 IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of 1750 two IKE Phase 2 SA's. 1752 Note that once you have the IPsec Tunnel Setup Rate and either the 1753 IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can 1754 extrapolate the unmeasured metric. It is however highly 1755 RECOMMENDED to measure all three metrics since the IKE and IPsec 1756 SA establishment are two distinct and decoupled phases in the 1757 establishment of a Tunnel. 1759 Measurement Units: Tunnels Per Second (TPS) 1761 Issues: N/A 1763 See Also: IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec 1764 Tunnel Rekey Behavior 1766 10.6. IPsec Tunnel Rekey Behavior 1768 10.6.1. IKE Phase 1 Rekey Rate 1770 Definition: The number of IKE Phase 1 SA's that can be succesfully 1771 re-establish per second. 1773 Discussion: Although the IKE Phase 1 Rekey Rate has less impact on 1774 the forwarding behavior of traffic that requires security services 1775 then the IKE Phase 2 Rekey Rate, it can pose a large burden on the 1776 CPU or network processor of the IPsec Device. Due to the highly 1777 computational nature of a Phase 1 exchange, it may impact the 1778 stability of Active Tunnels in the network when the IPsec Device 1779 fails to properly rekey an IKE Phase 1 SA. 1781 Measurement Units: Tunnel Rekeys per second (TRPS) 1783 Issues: N/A 1785 See Also: IKE Phase 2 Rekey Rate 1787 10.6.2. IKE Phase 2 Rekey Rate 1789 Definition: The number of IKE Phase 2 SA's that can be succesfully 1790 re-negotiated per second. 1792 Discussion: Although many implementations will usually derive new 1793 keying material before the old keys expire, there may still be a 1794 period of time where frames get dropped before the IKE Phase 2 1795 tunnels are successfully re-established. There may also be some 1796 packet loss introduced when the handover of traffic is done from 1797 the expired IPsec SA's to the newly negotiated IPsec SA's. To 1798 measure the IKE Phase 2 rekey rate, the measurement will require 1799 an IPsec aware test device to act as a responder when negotiating 1800 the new IKE Phase 2 keying material. 1802 The test methodology report must specify if PFS is enabled in 1803 reported security context. 1805 Measurement Units: Tunnel Rekeys per second (TRPS) 1807 Issues: N/A 1809 See Also: IKE Phase 1 Rekey Rate 1811 10.7. IPsec Tunnel Failover Time 1813 Definition: Time required to recover all IPsec Tunnels on a stanby 1814 IPsec Device, after a catastrophic failure occurs on the active 1815 IPsec Device. 1817 Discussion: Recovery time required to re-establish or to engage all 1818 IPsec Tunnels and reroute all traffic on a standby node or other 1819 failsafe system after a failure has occurred in the original 1820 active DUT/SUT. Failure can include, but are not limited to, a 1821 catastrophic IPsec Device failure, a encryption engine failure, 1822 protocol failures and link outages. The recovery time is delta 1823 between the point of failure and the time the first packet is seen 1824 on the last restored IPsec Tunnel on the backup device. 1826 Measurement Units: Time units with enough precision to reflect IPsec 1827 Tunnel Failover Time. 1829 Issues: N/A 1831 10.8. DoS Attack Resiliency 1833 10.8.1. Phase 1 DoS Resiliency Rate 1835 Definition: The Phase 1 Denial of Service (DoS) Resilience Rate 1836 quantifies the rate of invalid or malicious IKE tunnels that can 1837 be directed at a DUT before the Responder ignores or rejects valid 1838 tunnel attempts. 1840 Discussion: Phase 1 DoS attacks can present themselves in various 1841 forms and do not necessarily have to have a malicious background. 1842 It is sufficient to make a typographical error in a shared secret 1843 in an IPsec Device to be susceptible to a large number of IKE 1844 attempts that need to be turned down. Due to the intense 1845 computational nature of an IKE exchange every single IKE tunnel 1846 attempt that has to be denied will take non-negligible CPU cycles 1847 in the IPsec Device. 1849 Depending on the quantity of these messages that have to be 1850 processed, a system might end up in a state that the burden on 1851 system resource performing key exchanges is high enough that all 1852 resources are consumed by this process. At this point it will be 1853 no longer possible to process a valid IKE tunnel setup request and 1854 thus a Phase 1 DoS Attack is in effect. 1856 The scope of the attack profile for this test will include 1857 mismatched pre-shared keys as well as invalid digital 1858 certificates. 1860 Measurement Units: Percentage of FailedTunnel Attempts Per Seconds 1861 (TAPS) 1863 Issues: N/A 1865 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate 1867 Definition: The Phase 2 Hash Mismatch Denial of Service (DoS) 1868 Resilience Rate quantifies the rate of invalid ESP/AH packets that 1869 a DUT can drop without affecting the traffic flow of valid ESP/AH 1870 packets. 1872 Discussion: Phase 2 DoS attacks can present themselves in various 1873 forms and do not necessarily have to have a malicious background, 1874 but usually are. Typical are cases where there is a true 1875 malicious intent in the ESP/AH traffic flow by e.g. having an 1876 invalid hash in the IPsec data packets. 1878 Depending on the quantity of these packets that have to be 1879 processed, a system might end up in a state that the burden on the 1880 IPsec Device becomes large enough that it will impact valid 1881 traffic flows. At this point it will be no longer possible to 1882 forward valid IPsec payload without packetloss and thus a Phase 2 1883 DoS Attack is in effect. 1885 Measurement Units: Packets per seconds (pps) 1887 Issues: N/A 1889 10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate 1891 Definition: The Phase 2 Anti Replay Attack Denial of Service (DoS) 1892 Resilience Rate quantifies the rate of replayed ESP/AH packets 1893 that a DUT can drop without affecting the traffic flow of valid 1894 ESP/AH packets. 1896 Discussion: Anti Replay protection is a cornerstone feature of the 1897 IPsec framework and can be found in both the AH as well as the ESP 1898 protocol. To better understand what the impact is of a replay 1899 attack on an IPsec device, a valid IPsec stream will be replayed 1900 and each packet of the stream will appear twice on the wire at 1901 different times where the second instance will be outside of the 1902 Anti Replay Window. 1904 Measurement Units: Replayed Packets per seconds (pps) 1906 Issues: N/A 1908 11. Security Considerations 1910 As this document is solely for the purpose of providing test 1911 benchmarking terminology and describes neither a protocol nor a 1912 protocol's implementation; there are no security considerations 1913 associated with this document. 1915 12. Acknowledgements 1917 The authors would like to acknowledge the following individuals for 1918 their participation of the compilation and editing of this document 1919 and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian 1920 Talbert, Yaron Sheffer and Al Morton. 1922 13. References 1924 13.1. Normative References 1926 [RFC1242] Bradner, S., "Benchmarking terminology for network 1927 interconnection devices", RFC 1242, July 1991. 1929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1930 Requirement Levels", BCP 14, RFC 2119, March 1997. 1932 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1933 Switching Devices", RFC 2285, February 1998. 1935 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 1936 Payload Compression Protocol (IPComp)", RFC 2393, 1937 December 1998. 1939 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1940 Internet Protocol", RFC 2401, November 1998. 1942 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 1943 RFC 2402, November 1998. 1945 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 1946 ESP and AH", RFC 2403, November 1998. 1948 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1949 ESP and AH", RFC 2404, November 1998. 1951 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 1952 Algorithm With Explicit IV", RFC 2405, November 1998. 1954 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1955 Payload (ESP)", RFC 2406, November 1998. 1957 [RFC2407] Piper, D., "The Internet IP Security Domain of 1958 Interpretation for ISAKMP", RFC 2407, November 1998. 1960 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 1961 Security Association and Key Management Protocol 1962 (ISAKMP)", RFC 2408, November 1998. 1964 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1965 (IKE)", RFC 2409, November 1998. 1967 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1968 Its Use With IPsec", RFC 2410, November 1998. 1970 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 1971 Document Roadmap", RFC 2411, November 1998. 1973 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1974 RFC 2412, November 1998. 1976 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1977 Algorithms", RFC 2451, November 1998. 1979 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1980 Network Interconnect Devices", RFC 2544, March 1999. 1982 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 1983 March 1999. 1985 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1986 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1987 RFC 2661, August 1999. 1989 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1990 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1991 March 2000. 1993 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1994 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1995 January 2005. 1997 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1998 Internet Protocol", RFC 4301, December 2005. 2000 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2001 December 2005. 2003 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2004 RFC 4303, December 2005. 2006 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2007 RFC 4306, December 2005. 2009 [RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- 2010 Based Method of Detecting Dead Internet Key Exchange (IKE) 2011 Peers", RFC 3706, February 2004. 2013 [I-D.ietf-ipsec-properties] 2014 Krywaniuk, A., "Security Properties of the IPsec Protocol 2015 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2016 July 2002. 2018 [FIPS.186-1.1998] 2019 National Institute of Standards and Technology, "Digital 2020 Signature Standard", FIPS PUB 186-1, December 1998, 2021 . 2023 13.2. Informative References 2025 [Designing Network Security] 2026 Kaeo, M., "Designing Network Security", ISBN: 1587051176, 2027 Published: November, 2004. 2029 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2030 Mechanism for Internet", from IEEE Proceedings of the 2031 1996 Symposium on Network and Distributed Systems 2032 Security, 2033 URI http://www.research.ibm.com/security/skeme.ps, 1996. 2035 Authors' Addresses 2037 Merike Kaeo 2038 Double Shot Security 2039 3518 Fremont Ave N #363 2040 Seattle, WA 98103 2041 USA 2043 Phone: +1(310)866-0165 2044 Email: kaeo@merike.com 2046 Tim Van Herck 2047 Cisco Systems 2048 170 West Tasman Drive 2049 San Jose, CA 95134-1706 2050 USA 2052 Phone: +1(408)853-2284 2053 Email: herckt@cisco.com 2054 Michele Bustos 2055 IXIA 2056 26601 W. Agoura Rd. 2057 Calabasas, CA 91302 2058 USA 2060 Phone: +1(818)444-3244 2061 Email: mbustos@ixiacom.com