idnits 2.17.1 draft-ietf-bmwg-ipsec-term-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2070. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2094. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2285], [RFC1242], [RFC2544]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2008) is 5886 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 898, but not defined == Missing Reference: 'GW2' is mentioned on line 898, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 898, but not defined == Missing Reference: 'GW3' is mentioned on line 898, but not defined == Missing Reference: 'GW4' is mentioned on line 898, but not defined == Missing Reference: 'ESP' is mentioned on line 906, but not defined == Missing Reference: 'AH' is mentioned on line 906, but not defined == Missing Reference: 'IP' is mentioned on line 906, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 906, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 906, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 906, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1100, but not defined == Unused Reference: 'RFC2119' is defined on line 1915, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 1931, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 1934, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 1937, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 1953, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 1956, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 1995, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2005, 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-dpd (ref. 'I-D.ietf-ipsec-dpd') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipsec-properties' Summary: 18 errors (**), 0 flaws (~~), 22 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group M. Kaeo 3 Internet-Draft Double Shot Security 4 Expires: September 2, 2008 T. Van Herck 5 Cisco Systems 6 M. Bustos 7 IXIA 8 March 2008 10 Terminology for Benchmarking IPsec Devices 11 draft-ietf-bmwg-ipsec-term-10 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 2, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This purpose of this document is to define terminology specific to 45 measuring the performance of IPsec devices. It builds upon the 46 tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF 47 Benchmarking Methodology Working Group (BMWG) documents used for 48 benchmarking routers and switches. This document seeks to extend 49 these efforts specific to the IPsec paradigm. The BMWG produces two 50 major classes of documents: Benchmarking Terminology documents and 51 Benchmarking Methodology documents. The Terminology documents 52 present the benchmarks and other related terms. The Methodology 53 documents define the procedures required to collect the benchmarks 54 cited in the corresponding Terminology documents. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1. Security Associations . . . . . . . . . . . . . . . . 6 63 3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 7 64 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 9 66 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 9 67 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 12 72 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 12 73 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 12 74 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 13 75 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 13 76 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 14 77 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 15 80 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 16 81 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 16 82 7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 16 83 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 17 85 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 17 86 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 18 87 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 18 88 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 19 89 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 19 90 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 20 91 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 20 92 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 21 93 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 21 94 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 22 95 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 22 96 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 23 97 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 24 98 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 24 99 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 25 100 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 27 102 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 28 103 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 29 104 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 29 105 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 29 106 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 29 107 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 30 108 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 30 110 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 30 111 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 31 112 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 31 113 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 31 114 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 32 115 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 33 116 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 33 117 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 33 118 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 34 119 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 35 120 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 35 121 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 35 122 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 36 123 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 36 124 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 37 125 10.5. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 37 126 10.5.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 37 127 10.5.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 38 128 10.5.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 38 129 10.6. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 39 130 10.6.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 39 131 10.6.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 39 132 10.7. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 40 133 10.8. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 40 134 10.8.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 40 135 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . 41 136 10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . 41 137 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 138 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 139 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 140 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 141 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 143 Intellectual Property and Copyright Statements . . . . . . . . . . 46 145 1. Introduction 147 Despite the need to secure communications over a public medium there 148 is no standard method of performance measurement nor a standard in 149 the terminology used to develop such hardware and software solutions. 150 This results in varied implementations which challenge 151 interoperability and direct performance comparisons. Standardized 152 IPsec terminology and performance test methodologies will enable 153 users to determine if the IPsec device they select will withstand 154 loads of secured traffic that meet their requirements. 156 To appropriately define the parameters and scope of this document, 157 this section will give a brief overview of the IPsec standard. 159 2. Document Scope 161 The primary focus of this document is to establish useful performance 162 testing terminology for IPsec devices that support manual keying and 163 IKEv1. A seperate document will be written specifically to address 164 testing using the updated IKEv2 specification. The terminology 165 specified in this document is constrained to meet the requirements of 166 the Methodology for Benchmarking IPsec Devices documented test 167 methodologies. 169 Both IPv4 and IPv6 addressing will be taken into consideration. 171 The testing will be constrained to: 173 o Devices acting as IPsec gateways whose tests will pertain to both 174 IPsec tunnel and transport mode. 176 o Devices acting as IPsec end-hosts whose tests will pertain to both 177 IPsec tunnel and transport mode. 179 Any testing involving interoperability and/or conformance issues, 180 L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and 181 anything that does not specifically relate to the establishment and 182 tearing down of IPsec tunnels is specifically out of scope. It is 183 assumed that all relevant networking parameters that facilitate in 184 the running of these tests are pre-configured (this includes at a 185 minimum ARP caches, routing tables, neighbor tables, etc ...). 187 3. IPsec Fundamentals 189 IPsec is a framework of open standards that provides data 190 confidentiality, data integrity, and data origin authenticity between 191 participating peers. IPsec provides these security services at the 192 IP layer. IPsec uses IKE to handle negotiation of protocols and 193 algorithms based on local policy, and to generate the encryption and 194 authentication keys to be used. IPsec can be used to protect one or 195 more data flows between a pair of hosts, between a pair of security 196 gateways, or between a security gateway and a host. The IPsec 197 protocol suite set of standards is documented in RFC's [RFC2401] 198 through [RFC2412] and [RFC2451]. At this time [RFC4301] updates 199 [RFC2401] (IPsec Architecture), [RFC4302] updates [RFC2402] (AH) and 200 [RFC4303] updates [RFC2406] (ESP) and [RFC4306] updates [RFC2409] 201 (IKE).The reader is assumed to be familiar with these documents. 203 IPsec itself defines the following: 205 Authentication Header (AH): A security protocol, defined in 206 [RFC4302], which provides data authentication and optional anti- 207 replay services. AH ensures the integrity and data origin 208 authentication of the IP datagram as well as the invariant fields in 209 the outer IP header. 211 Encapsulating Security Payload (ESP): A security protocol, defined in 212 [RFC4303], which provides confidentiality, data origin 213 authentication, connectionless integrity, an anti-replay service and 214 limited traffic flow confidentiality. The set of services provided 215 depends on options selected at the time of Security Association (SA) 216 establishment and on the location of the implementation in a network 217 topology. ESP authenticates only headers and data after the IP 218 header. 220 Internet Key Exchange (IKE): A hybrid protocol which implements 221 Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP 222 framework. While IKE can be used with other protocols, its initial 223 implementation is with the IPsec protocol. IKE provides 224 authentication of the IPsec peers, negotiates IPsec security 225 associations, and establishes IPsec keys. 227 The AH and ESP protocols each support two modes of operation: 228 transport mode and tunnel mode. In transport mode, two hosts provide 229 protection primarily for upper-layer protocols. The cryptographic 230 endpoints (where the encryption and decryption take place) are the 231 source and destination of the data packet. In IPv4, a transport mode 232 security protocol header appears immediately after the IP header and 233 before any higher-layer protocols (such as TCP or UDP). In IPv6, the 234 security protocol header appears after the base IP header and 235 selected extension headers. It may appear before or after 236 destination options but must appear before next layer protocols 237 (e.g., TCP, UDP, SCTP) 238 In the case of AH in transport mode, security services are provided 239 to selected portions of the IP header preceding the AH header, 240 selected portions of extension headers, and selected options 241 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 242 IPv6 Destination extension headers). Any fields in these headers/ 243 extension headers which are modified in transit are set to 0 before 244 applying the authentication algorithm. If a field is mutable, but 245 its value at the receiving IPsec peer is predictable, then that value 246 is inserted into the field before applying the cryptographic 247 algorithm. 249 In the case of ESP in transport mode, security services are provide 250 only for the higher-layer protocols, not for the IP header or any 251 extension headers preceding the ESP header. 253 A tunnel is a vehicle for encapsulating packets inside a protocol 254 that is understood at the entry and exit points of a given network. 255 These entry and exit points are defined as tunnel interfaces. 257 Both the AH and ESP protocols can be used in tunnel mode for data 258 packet endpoints as well as by intermediate security gateways. In 259 tunnel mode, there is an "outer" IP header that specifies the IPsec 260 processing destination, plus an "inner" IP header that specifies the 261 ultimate destination for the packet. The source address in the outer 262 IP header is the initiating cryptographic endpoint; the source 263 address in the inner header is the true source address of the packet. 264 The security protocol header appears after the outer IP header and 265 before the inner IP header. 267 If AH is employed in tunnel mode, portions of the new outer IP header 268 are given protection (those same fields as for transport mode, 269 described earlier in this section), as well as all of the tunneled IP 270 packet (that is, all of the inner IP header is protected as are the 271 higher-layer protocols). If ESP is employed, the protection is 272 afforded only to the tunneled packet, not to the new outer IP header. 274 3.1. IPsec Operation 276 3.1.1. Security Associations 278 The concept of a Security Association (SA) is fundamental to IPsec. 279 An SA is a relationship between two or more entities that describes 280 how the entities will use security services to communicate. The SA 281 includes: an encryption algorithm, an authentication algorithm and a 282 shared session key. 284 Because an SA is unidirectional, two SA's (one in each direction) are 285 required to secure typical, bidirectional communication between two 286 entities. The security services associated with an SA can be used 287 for AH or ESP, but not for both. If both AH and ESP protection are 288 applied to a traffic stream, two (or more) SA's are created for each 289 direction to protect the traffic stream. 291 The SA is uniquely identified by the Security Parameter Index (SPI) 292 [RFC2406]. When a system sends a packet that requires IPsec 293 protection, it looks up the SA in its database and applies the 294 specified processing and security protocol (AH/ESP), inserting the 295 SPI from the SA into the IPsec header. When the IPsec peer receives 296 the packet, it looks up the SA in its database by destination 297 address, protocol, and SPI and then processes the packet as required. 299 3.1.2. Key Management 301 IPsec uses cryptographic keys for authentication, integrity and 302 encryption services. Both manual provisioning and automatic 303 distribution of keys are supported. IKE is specified as the public- 304 key-based approach for automatic key management. 306 IKE authenticates each peer involved in IPsec, negotiates the 307 security policy, and handles the exchange of session keys. IKE is a 308 hybrid protocol, combining parts of the following protocols to 309 negotiate and derive keying material for SA's in a secure and 310 authenticated manner: 312 1. ISAKMP [RFC2408] (Internet Security Association and Key 313 Management Protocol), which provides a framework for 314 authentication and key exchange but does not define them. ISAKMP 315 is designed to be key exchange independent; it is designed to 316 support many different key exchanges. 318 2. Oakley [RFC2412], which describes a series of key exchanges, 319 called modes, and details the services provided by each (for 320 example, perfect forward secrecy for keys, identity protection, 321 and authentication). 323 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 324 describes a versatile key exchange technique that provides 325 anonymity, reputability, and quick key refreshment. 327 IKE creates an authenticated, secure tunnel between two entities and 328 then negotiates the security association for IPsec. In the original 329 IKE specification [RFC2409], this is performed in two phases. 331 In Phase 1, the two unidirectional SA's establish a secure, 332 authenticated channel with which to communicate. Phase 1 has two 333 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 334 provides identity protection. When identity protection is not 335 needed, Aggressive Mode can be used. The completion of Phase 1 is 336 called an IKE SA. 338 The following attributes are used by IKE and are negotiated as part 339 of the IKE SA: 341 o Encryption algorithm. 343 o Hash algorithm. 345 o Authentication method (digital signature, public-key encryption or 346 pre-shared key). 348 o Diffie-Hellman group information. 350 After the attributes are negotiated, both parties must be 351 authenticated to each other. IKE supports multiple authentication 352 methods. The following mechanisms are generally implemented: 354 o Pre-shared keys: The same key is pre-installed on each host. IKE 355 peers authenticate each other by computing and sending a keyed 356 hash of data that includes the pre-shared key. If the receiving 357 peer can independently create the same hash using its preshared 358 key, it knows that both parties must share the same secret, and 359 thus the other party is authenticated. 361 o Public key cryptography: Each party generates a pseudo-random 362 number (a nonce) and encrypts it and its ID using the other 363 party's public key. The ability for each party to compute a keyed 364 hash containing the other peer's nonce and ID, decrypted with the 365 local private key, authenticates the parties to each other. This 366 method does not provide nonrepudiation; either side of the 367 exchange could plausibly deny that it took part in the exchange. 369 o Digital signature: Each device digitally signs a set of data and 370 sends it to the other party. This method is similar to the 371 public-key cryptography approach except that it provides 372 nonrepudiation. 374 Note that both digital signature and public-key cryptography require 375 the use of digital certificates to validate the public/private key 376 mapping. IKE allows the certificate to be accessed independently or 377 by having the two devices explicitly exchange certificates as part of 378 IKE. Both parties must have a shared session key to encrypt the IKE 379 tunnel. The Diffie-Hellman protocol is used to agree on a common 380 session key. 382 In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's 383 will be called IPsec SA's. These IPsec SA's use a different shared 384 key than that used for the IKE_SA. The IPsec SA shared key can be 385 derived by using Diffie-Hellman again or by refreshing the shared key 386 derived from the original Diffie-Hellman exchange that generated the 387 IKE_SA by hashing it with nonces. Once the shared key is derived and 388 additional communication parameters are negotiated, the IPsec SA's 389 are established and traffic can be exchanged using the negotiated 390 parameters. 392 4. Definition Format 394 The definition format utilized by this document is described in 395 [RFC1242], Section 2. 397 Term to be defined. 399 Definition: The specific definition for the term. 401 Discussion: A brief discussion of the term, its application, or 402 other information that would build understanding. 404 Issues: List of issues or conditions that affect this term. This 405 field can present items the may impact the term's related 406 methodology or otherwise restrict its measurement procedures. 408 Measurement units: (OPTIONAL) Units used to record measurements of 409 this term. This field is mandatory where applicable. This field 410 is optional in this document. 412 See Also: (OPTIONAL) List of other terms that are relevant to the 413 discussion of this term. This field is optional in this document. 415 5. Key Words to Reflect Requirements 417 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 418 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 419 document are to be interpreted as described in RFC 2119. RFC 2119 420 defines the use of these key words to help make the intent of 421 standards track documents as clear as possible. While this document 422 uses these keywords, this document is not a standards track document. 424 6. Existing Benchmark Definitions 426 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 RFC's 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 7. Definitions 445 7.1. IPsec 447 Definition: IPsec or IP Security protocol suite which comprises a 448 set of standards used to provide security services at the IP 449 layer. 451 Discussion: IPsec is a framework of protocols that offer 452 authentication, integrity and encryption services to the IP and/or 453 upper layer protocols. The major components of the protocol suite 454 are IKE, used for key exchanges, and IPsec protocols such as AH 455 and ESP, which use the exchanged keys to protect payload traffic. 457 Issues: N/A 459 See Also: IPsec Device, IKE, ISAKMP, ESP, AH 461 7.2. ISAKMP 463 Definition: The Internet Security Association and Key Management 464 Protocol, which provides a framework for authentication and key 465 exchange but does not define them. ISAKMP is designed to be key 466 exchange independent; it is designed to support many different key 467 exchanges. ISAKMP is defined in [RFC2407]. 469 Discussion: Though ISAKMP is only a framework for the IPsec standard 470 key management protocol, it is often misused and interchanged with 471 the term 'IKE', which is an implementation of ISAKMP. 473 Issues: When implementations refer to the term 'ISAKMP SA', it 474 refers to an IKE Phase 1 SA. 476 See Also: IKE, Security Association 478 7.3. IKE 480 Definition: A hybrid key management protocol that provides 481 authentication of the IPsec peers, negotiates IPsec SA's and 482 establishes IPsec keys. 484 Discussion: A hybrid protocol, defined in [RFC2409], from the 485 following 3 protocols: 487 * ISAKMP (Internet Security Association and Key Management 488 Protocol), which provides a framework for authentication and 489 key exchange but does not define them. ISAKMP is designed to 490 be key exchange independent; it is designed to support many 491 different key exchanges. 493 * Oakley, which describes a series of key exchanges, called 494 modes, and details the services provided by each (for example, 495 perfect forward secrecy for keys, identity protection, and 496 authentication). [RFC2412] 498 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 499 describes a versatile key exchange technique that provides 500 anonymity, reputability, and quick key refreshment. 502 Note that IKE is an optional protocol within the IPsec framework. 503 IPsec SA's may also be manually configured. Manual keying is the 504 most basic mechanism to establish IPsec SA's between two IPsec 505 devices. However, it is not a scalable solution and often 506 manually configured keys are not changed on a periodic basis which 507 reduces the level of protection since the keys are effectively 508 static and as a result are more prone to various attacks. When 509 IKE is employed as a key management protocol, the keys are 510 automatically renegotiated on a user-defined basis (time and/or 511 traffic volume based) as part of the IKE rekeying mechanism. 513 Issues: During the first IPsec deployment experiences, ambiguities 514 were found in the IKEv1 specification, which lead to 515 interoperability problems. To resolve these issues, IKEv1 is 516 being updated by IKEv2. 518 See Also: ISAKMP, IPsec, Security Association 520 7.3.1. IKE Phase 1 522 Definition: The shared policy and key(s) used by negotiating peers 523 to establish a secure authenticated "control channel" for further 524 IKE communications. 526 Discussion: The IPsec framework mandates that SPI's are used to 527 secure payload traffic. If IKE is employed all SPI information 528 will be exchanged between the IPsec devices. This has to be done 529 in a secure fashion and for that reason IKE will set up a secure 530 "control channel" over which it can exchange this information. 532 Note that IKE is an optional protocol within the IPsec framework 533 and that SPI information can also be manually configured. 535 Issues: In some documents often referenced as ISAKMP SA or IKE SA. 537 See Also: IKE, ISAKMP 539 7.3.2. IKE Phase 1 Main Mode 541 Definition: Main Mode is an instantiation of the ISAKMP Identity 542 Protect Exchange, defined in [RFC2409]. Upon successful 543 completion it results in the establishment of an IKE Phase 1 SA. 545 Discussion: IKE Main Mode use 3 distinct message pairs, for a total 546 of 6 messages. The first two messages negotiate policy; the next 547 two represent Diffie-Hellman public values and ancillary data 548 (e.g. nonces); and the last two messages authenticate the Diffie- 549 Hellman Exchange. The authentication method negotiated as part of 550 the initial IKE Phase 1 influence the composition of the payloads 551 but not their purpose. 553 Issues: N/A 555 See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 557 7.3.3. IKE Phase 1 Aggressive Mode 559 Definition: Aggressive Mode is an instantiation of the ISAKMP 560 Aggressive Exchange, defined in [RFC2409]. Upon successful 561 completion it results in the establishment of an IKE Phase 1 SA. 563 Discussion: IKE Aggressive Mode uses 3 messages. The first two 564 messages negotiate policy, exchange Diffie-Hellman public values 565 and ancillary data necessary for the exchange, and identities. In 566 addition the second message authenticates the Responder. The 567 third message authenticates the Initiator and provides proof of 568 participation in the exchange. 570 Issues: For IKEv1 the standard specifies that all implementations 571 use both main and agressive mode, however, it is common to use 572 only main mode. 574 See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 576 7.3.4. IKE Phase 2 578 Definition: ISAKMP phase which upon successful completion 579 establishes the shared keys used by the negotiating peers to set 580 up a secure "data channel" for IPsec. 582 Discussion: The main purpose of Phase 2 is to produce the key for 583 the IPsec tunnel. Phase 2 is also used for exchanging 584 informational messages. 586 Issues: In other documents also referenced as IPsec SA. 588 See Also: IKE Phase 1, ISAKMP, IKE 590 7.3.5. Phase 2 Quick Mode 592 Definition: Quick Mode is an instanciation of IKE Phase 2. After 593 successful completion it will result in one or typically two or 594 more IPsec SA's 596 Discussion: Quick Mode is used to negotiate the SA's and keys that 597 will be used to protect the user data. Three different messages 598 are exchanged, which are protected by the security parameters 599 negotiated by the IKE phase 1 exchange. An additional Diffie- 600 Hellman exchange may be performed if PFS (Perfect Forward Secrecy) 601 is enabled. 603 Issues: N/A 605 See Also: ISAKMP, IKE, IKE Phase 2 607 7.4. Security Association (SA) 609 Definition: A set of policy and key(s) used to protect traffic flows 610 that require authentication and/or encryption services. It is a 611 negotiation agreement between two IPsec devices, specifically the 612 Initiator and Responder. 614 Discussion: A simplex (unidirectional) logical connection that links 615 a traffic flow to a set of security parameters. All traffic 616 traversing an SA is provided the same security processing and will 617 be subjected to a common set of encryption and/or authentication 618 algorithms. In IPsec, an SA is an Internet layer abstraction 619 implemented through the use of AH or ESP as defined in [RFC2401]. 621 Issues: N/A 623 See Also: Initiator, Responder 625 7.5. Selectors 627 Definition: A mechanism used for the classification of traffic flows 628 that require authentication and/or encryption services. 630 Discussion: The selectors are a set of fields that will be extracted 631 from the network and transport layer headers that provide the 632 ability to classify the traffic flow and associate it with an SA. 634 After classification, a decision can be made if the traffic needs 635 to be encrypted/decrypted and how this should be done depending on 636 the SA linked to the traffic flow. Simply put, selectors classify 637 IP packets that require IPsec processing and those packets that 638 must be passed along without any intervention of the IPsec 639 framework. 641 Selectors are flexible objects that can match on ranges of source 642 and destination addresses and ranges of source and destination 643 ports. 645 Issues: Both sides must agree exactly on both the networks being 646 protected, and they both must agree on how to describe the 647 networks (range, subnet, addresses). This is a common point of 648 non-interoperability. 650 7.6. IPsec Device 651 Definition: Any implementation that has the ability to process data 652 flows according to the IPsec protocol suite specifications. 654 Discussion: Implementations can be grouped by 'external' properties 655 (e.g. software vs. hardware implementations) but more important is 656 the subtle differences that implementations may have with relation 657 to the IPsec Protocol Suite. Not all implementations will cover 658 all RFC's that encompass the IPsec Protocol Suite, but the 659 majority will support a large subset of features described in the 660 suite, nor will all implementations utilize all of the 661 cryptographic functions listed in the RFC's. 663 In that context, any implementation, that supports basic IP layer 664 security services as described in the IPsec protocol suite shall 665 be called an IPsec Device. 667 Issues: Due to the fragmented nature of the IPsec Protocol Suite 668 RFC's, it is possible that IPsec implementations will not be able 669 to interoperate. Therefore it is important to know which features 670 and options are implemented in the IPsec Device. 672 See Also: IPsec 674 7.6.1. Initiator 676 Definition: An IPsec device which starts the negotiation of IKE 677 Phase 1 and IKE Phase 2 SA's. 679 Discussion: When a traffic flow is offered at an IPsec device and it 680 is determined that the flow must be protected, but there is no 681 IPsec tunnel to send the traffic through, it is the responsibility 682 of the IPsec device to start a negotiation process that will 683 instantiate the IPsec tunnel. This process will establish an IKE 684 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 685 eventually resulting in secured data transport. The device that 686 takes the action to start this negotiation process will be called 687 an Initiator. 689 Issues: IPsec devices/implementations can be both an initiator as 690 well as a responder. The distinction is useful from a test 691 perspective. 693 See Also: Responder, IKE, IPsec 695 7.6.2. Responder 697 Definition: An IPsec device which replies to incoming IKE Phase 1 698 and IKE Phase 2 requests and processes these messages in order to 699 establish an IPsec tunnel. 701 Discussion: When an initiator attempts to establish SA's with 702 another IPsec device, this peer will need to evaluate the 703 proposals made by the initiator and either accept or deny them. 704 In the former case, the traffic flow will be decrypted according 705 to the negotiated parameters. Such a device will be called a 706 Responder. 708 Issues: IPsec devices/implementations can usually be both an 709 initiator as well as a responder. The distinction is useful from 710 a test perspective. 712 See Also: Initiator, IKE 714 7.6.3. IPsec Client 716 Definition: IPsec Devices that will only act as an Initiator. 718 Discussion: In some situations it is not needed or prefered to have 719 an IPsec device respond to an inbound IKE SA or IPsec SA request. 720 In the case of e.g. road warriors or home office scenarios the 721 only property needed from the IPsec device is the ability to 722 securely connect to a remote private network. The IPsec Client 723 will initiate one or more IPsec tunnels to an IPsec Server on the 724 network that needs to be accessed and to provide the required 725 security services. An IPsec client will silently drop and ignore 726 any inbound IPsec tunnel requests. IPsec clients are generally 727 used to connect remote users in a secure fashion over the Internet 728 to a private network. 730 Issues: N/A 732 See Also: IPsec device, IPsec Server, Initiator, Responder 734 7.6.4. IPsec Server 736 Definition: IPsec Devices that can both act as an Initiator as well 737 as a Responder. 739 Discussion: IPsec Servers are mostly positioned at private network 740 edges and provide several functions: 742 * Responds to IPsec tunnel setup request from IPsec Clients. 744 * Responds to IPsec tunnel setup request from other IPsec devices 745 (Initiators). 747 * Initiate IPsec tunnels to other IPsec servers inside or outside 748 the private network. 750 Issues: IPsec Servers are also sometimes referred to as 'VPN 751 Concentrators'. 753 See Also: IPsec Device, IPsec Client, Initiator, Responder 755 7.7. Tunnels 757 The term "tunnel" is often used in a variety of contexts. To avoid 758 any discrepancies, in this document, the following distinctions have 759 been defined: 761 7.7.1. IPsec Tunnel 763 Definition: The combination of an IKE Phase 1 SA and a single pair 764 of IKE Phase 2 SA's. 766 Discussion: An IPsec Tunnel will be defined as a single (1) Phase 1 767 SA and a pair (2) Phase 2 SA's. This construct will allow 768 bidirectional traffic to be passed between two IPsec Devices where 769 the traffic can benefit form the services offered in the IPsec 770 framework. 772 Issues: Since it is implied that a Phase 1 SA is used, an IPsec 773 Tunnel will be by definition a dynamically negotiated secured 774 link. If manual keying is used to enable secure data transport, 775 then this link will merely be referred to as a pair of IPsec SA's. 777 It is very likely that more then one pair of Phase 2 SA's are 778 associated with a single Phase 1 SA. Also in this case, the IPsec 779 Tunnel definition WILL NOT apply. Instead the ratio between Phase 780 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella 781 term of "IPsec Tunnel" MUST NOT be used in this context. 783 See Also: IKE Phase 1, IKE Phase 2 785 7.7.2. Configured Tunnel 786 Definition: An IPsec tunnel or a pair of IPsec SA's in the case of 787 manual keying that is provisioned in the IPsec device's 788 configuration. 790 Discussion: Several steps are required before IPsec can be used to 791 actually transport traffic. The very first step is to configure 792 the IPsec Tunnel (or IPsec SA's in the case of manual keying) in 793 the IPsec device. When using IKE there are no SA's associated 794 with the IPsec Tunnel and no traffic is going through the IPsec 795 device that matches the Selectors, which would instantiate the 796 IPsec Tunnel. When using either manual keying or IKE, a 797 configured tunnel will not have a populated SADB. 799 Issues: When using IKE, a configured tunnel will not have any SA's 800 while with manual keying, the SA's will have simply been 801 configured but not populated in the SADB. 803 See Also: IPsec Tunnel, Established Tunnel, Active Tunnel 805 7.7.3. Established Tunnel 807 Definition: An IPsec device that has a populated SADB and is ready 808 to provide security services to the appropriate traffic. 810 Discussion: When using IKE, a second step needed to ensure that an 811 IPsec Tunnel can transport data is to complete the Phase 1 and 812 Phase 2 negotiations. After the packet classification process has 813 asserted that a packet requires security services, the negotation 814 is started to obtain both Phase 1 and Phase 2 SA's. After this is 815 completed and the SADB is populated, the IPsec Tunnel is called 816 'Established'. Note that at this time there is still no traffic 817 flowing through the IPsec Tunnel. Just enough packet(s) have been 818 sent to the IPsec device that matched the selectors and triggered 819 the IPsec Tunnel setup to result in a populated SADB. In the case 820 of manual keying, populating the SADB is accomplished by a 821 separate administrative command. 823 Issues: N/A 825 See Also: IPsec Tunnel, Configured Tunnel, Active Tunnel 827 7.7.4. Active Tunnel 829 Definition: An IPsec device that is forwarding secured data. 831 Discussion: When a Tunnel is Established and it is transporting 832 traffic that is authenticated and/or encrypted, the tunnel is 833 called 'Active'. 835 Issues: The distinction between an Active Tunnel and Configured/ 836 Established Tunnel is made in the context of manual keyed Tunnels. 837 In this case it would be possible to have an Established tunnel on 838 an IPsec device which has no counterpart on it's corresponding 839 peer. This will lead to encrypted traffic flows which will be 840 discarded on the receiving peer. Only if both peers have an 841 Established Tunnel that shows evidence of traffic transport, it 842 may be called an Active Tunnel. 844 See Also: IPsec Tunnel, Configured Tunnel, Established Tunnel 846 7.8. Iterated Tunnels 848 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 849 The bundles are divided into two major groups : 851 7.8.1. Nested Tunnels 853 Definition: An SA bundle consisting of two or more 'tunnel mode' 854 SA's. 856 Discussion: The process of nesting tunnels can theoretically be 857 repeated multiple times (for example, tunnels can be many levels 858 deep), but for all practical purposes, most implementations limit 859 the level of nesting. Nested tunnels can use a mix of AH and ESP 860 encapsulated traffic. 862 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 863 | | | | 864 | | | | 865 | +----{SA1 (ESP tunnel)}----+ | 866 | | 867 +--------------{SA2 (AH tunnel)}---------------+ 869 In the IP Cloud a packet would have a format like this : 870 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 872 Nested tunnels can be deployed to provide additional security on 873 already secured traffic. A typical example of this would be that 874 the inner gateways (GW2 and GW3) are securing traffic between two 875 branch offices and the outer gateways (GW1 & GW4) add an 876 additional layer of security between departments within those 877 branch offices. 879 Issues: N/A 881 See Also: Transport Adjacency, IPsec Tunnel 883 7.8.2. Transport Adjacency 885 Definition: An SA bundle consisting of two or more transport mode 886 SA's. 888 Discussion: Transport adjacency is a form of tunnel nesting. In 889 this case two or more transport mode IPsec tunnels are set side by 890 side to enhance applied security properties. 892 Transport adjacency can be used with a mix of AH and ESP tunnels 893 although some combinations are not preferred. If AH and ESP are 894 mixed, the ESP tunnel should always encapsulate the AH tunnel. 895 The reverse combination is a valid combination but doesn't make 896 cryptographical sense. 898 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 899 | | | | 900 | | | | 901 | +------{SA1 (ESP transport)}--------+ | 902 | | 903 +-------------{SA2 (AH transport)}--------------+ 905 In the IP Cloud a packet would have a format like this : 906 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 908 Issues: This is rarely used in the way it is depicted. It is more 909 common, but still not likely, that SA's are established from 910 different gateways as depicted in the Nested Tunnels figure. The 911 packet format in the IP Cloud would remain unchanged. 913 See Also: Nested Tunnels, IPsec Tunnel 915 7.9. Transform protocols 917 Definition: Encryption and authentication algorithms that provide 918 cryptograhic services to the IPsec Protocols. 920 Discussion: Some algorithms run significantly slower than others. A 921 decision for which algorithm to use is usually based on the 922 tradeoff between performance and security strength. For example, 923 3DES encryption is generally slower then DES encryption. 925 Issues: N/A 927 See Also: Authentication protocols, Encryption protocols 929 7.9.1. Authentication Protocols 931 Definition: Algorithms which provide data integrity and data source 932 authentication. 934 Discussion: Authentication protocols provide no confidentiality. 935 Commonly used authentication algorithms/protocols are: 937 * MD5-HMAC 938 * SHA-HMAC 939 * AES-HMAC 941 Issues: N/A 943 See Also: Transform protocols, Encryption protocols 945 7.9.2. Encryption Protocols 947 Definition: Algorithms which provide data confidentiality. 949 Discussion: Encryption protocols provide no authentication. 950 Commonly used encryption algorithms/protocols are: 952 * NULL encryption 953 * DES-CBC 954 * 3DES-CBC 955 * AES-CBC 957 Issues: The null-encryption option is a valid encryption mechanism 958 to provide an alternative to using AH. There is no 959 confidentiality protection with null-encryption. Note also that 960 when using ESP null-encryption the authentication and integrity 961 services only apply for the upper layer protocols and not for the 962 IP header itself. 964 DES has been officially deprecated by NIST, though it is still 965 mandated by the IPsec framework and is still commonly implemented 966 and used due to it's speed advantage over 3DES. AES will be the 967 successor of 3DES due to its superior encryption and performance 968 advantage. 970 See Also: Transform protocols, Authentication protocols 972 7.10. IPsec Protocols 974 Definition: A suite of protocols which provide a framework of open 975 standards that provides data origin confidentiality, data 976 integrity, and data origin authenticity between participating 977 peers at the IP layer. The original IPsec protocol suite set of 978 standards is documented in [RFC2401] through [RFC2412] and 979 [RFC2451]. At this time [RFC4301] updates [RFC2401] (IPsec 980 Architecture), [RFC4302] updates [RFC2402] (AH) and [RFC4303] 981 updates [RFC2406] (ESP) 983 Discussion: The IPsec Protocol suite is modular and forward 984 compatible. The protocols that comprise the IPsec protocol suite 985 can be replaced with new versions of those protocols as the older 986 versions become obsolete. For example, IKEv2 will soon replace 987 IKEv1. 989 Issues: N/A 991 See Also: AH, ESP 993 7.10.1. Authentication Header (AH) 995 Definition: Provides data origin authentication and data integrity 996 (including replay protection) security services as defined in 997 [RFC4302]. 999 Discussion: The AH protocol supports two modes of operation i.e. 1000 tunnel mode and transport mode. 1002 In transport mode, AH is inserted after the IP header and before a 1003 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any 1004 other IPsec headers that have already been inserted. In the 1005 context of IPv4, this calls for placing AH after the IP header 1006 (and any options that it contains), but before the next layer 1007 protocol. In the IPv6 context, AH is viewed as an end-to-end 1008 payload, and thus should appear after hop-by-hop, routing, and 1009 fragmentation extension headers. The destination options 1010 extension header(s) could appear before or after or both before 1011 and after the AH header depending on the semantics desired. 1013 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1014 source and destination addresses, while an "outer" IP header 1015 contains the addresses of the IPsec "peers," e.g., addresses of 1016 security gateways. In tunnel mode, AH protects the entire inner 1017 IP packet, including the entire inner IP header. The position of 1018 AH in tunnel mode, relative to the outer IP header, is the same as 1019 for AH in transport mode. 1021 Issues: AH is rarely used to secure traffic over the Internet. 1023 See Also: Transform protocols, IPsec protocols, Encapsulated 1024 Security Payload 1026 7.10.2. Encapsulated Security Payload (ESP) 1028 Definition: Provides data origin authentication, data integrity 1029 (including replayprotection) and data confidentiality as defined 1030 in [RFC4303]. 1032 Discussion: The ESP protocol supports two modes of operation i.e. 1033 tunnel mode and transport mode. 1035 In transport mode, ESP is inserted after the IP header and before 1036 a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context 1037 of IPv4, this translates to placing ESP after the IP header (and 1038 any options that it contains), but before the next layer protocol. 1039 In the IPv6 context, ESP is viewed as an end-to-end payload, and 1040 thus should appear after hop-by-hop, routing, and fragmentation 1041 extension headers. Destination options extension header(s) could 1042 appear before, after, or both before and after the ESP header 1043 depending on the semantics desired. However, since ESP protects 1044 only fields after the ESP header, it generally will be desirable 1045 to place the destination options header(s) after the ESP header. 1047 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1048 source and destination addresses, while an "outer" IP header 1049 contains the addresses of the IPsec "peers", e.g., addresses of 1050 security gateways. Mixed inner and outer IP versions are allowed, 1051 i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP 1052 protects the entire inner IP packet, including the entire inner IP 1053 header. The position of ESP in tunnel mode, relative to the outer 1054 IP header, is the same as for ESP in transport mode. 1056 Issues: N/A 1057 See Also: Transform protocols, IPsec protocols, Authentication 1058 Header 1060 7.11. NAT Traversal (NAT-T) 1062 Definition: The capability to support IPsec functionality in the 1063 presence of NAT devices. 1065 Discussion: NAT-Traversal requires some modifications to IKE as 1066 defined in [RFC3947]. Specifically, in phase 1, it requires 1067 detecting if the other end supports NAT-Traversal, and detecting 1068 if there are one or more NAT instances along the path from host to 1069 host. In IKE Quick Mode, there is a need to negotiate the use of 1070 UDP encapsulated IPsec packets. 1072 NAT-T also describes how to transmit the original source and 1073 destination addresses to the corresponding IPsec Device. The 1074 original source and destination addresses are used in transport 1075 mode to incrementally update the TCP/IP checksums so that they 1076 will match after the NAT transform (The NAT cannot do this, 1077 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1078 packet). 1080 Issues: N/A 1082 See Also: IKE, ISAKMP, IPsec Device 1084 7.12. IP Compression 1086 Definition: A mechanism as defined in [RFC2393] that reduces the 1087 size of the payload that needs to be encrypted. 1089 Discussion: IP payload compression is a protocol to reduce the size 1090 of IP datagrams. This protocol will increase the overall 1091 communication performance between a pair of communicating hosts/ 1092 gateways ("nodes") by compressing the datagrams, provided the 1093 nodes have sufficient computation power, through either CPU 1094 capacity or a compression coprocessor, and the communication is 1095 over slow or congested links. 1097 IP payload compression is especially useful when encryption is 1098 applied to IP datagrams. Encrypting the IP datagram causes the 1099 data to be random in nature, rendering compression at lower 1100 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1101 ineffective. If both compression and encryption are required, 1102 compression must be applied before encryption. 1104 Issues: N/A 1106 See Also: IKE, ISAKMP, IPsec Device 1108 7.13. Security Context 1110 Definition: A security context is a collection of security 1111 parameters that describe the characteristics of the path that an 1112 IPsec Tunnel will take, all of the IPsec Tunnel parameters and the 1113 effects it has on the underlying protected traffic. Security 1114 Context encompasses protocol suite and security policy. 1116 Discussion: In order to fairly compare multiple IPsec devices it is 1117 imperative that an accurate overview is given of all security 1118 parameters that were used to establish the IPsec Tunnels or 1119 manually created SA's and to secure the traffic between protected 1120 networks. Security Context is not a metric. It is included to 1121 accurately reflect the test environment variables when reporting 1122 the methodology results. To avoid listing too much information 1123 when reporting metrics, the Security Context is divided into an 1124 IKE context and an IPsec context. 1126 When merely discussing the behavior of traffic flows through IPsec 1127 devices, an IPsec context MUST be provided. In other cases the 1128 scope of a discussion or report may focus on a more broad set of 1129 behavioral characteristics of the IPsec device, in which case both 1130 an IPsec and an IKE context MUST be provided. 1132 The IPsec context MUST consist of the following elements: 1134 * Manual Keyed Tunnels versus IKE negotiated Tunnels 1136 * Number of IPsec Tunnels or IPsec SA's 1138 * IPsec protocol (AH or ESP) 1140 * IPsec protocol mode (tunnel or transport) 1142 * Authentication algorithm used by AH/ESP 1144 * Encryption algoritm used ESP (if applicable) 1146 * IPsec SA lifetime (traffic and time based) 1148 * Anti Replay Window Size (Assumed to be 64 packets if not 1149 specified) 1151 The IPsec Context MAY also list: 1153 * Selectors 1155 * Fragmentation handling (assumed to be post-encryption when not 1156 mentioned) 1158 * PMTUD (assumed disabled when not mentioned) 1160 The IKE Context MUST consist of the following elements: 1162 * Number of IPsec Tunnels. 1164 + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable) 1166 + IKE Phase 1 parameters 1168 - Authentication algorithm 1170 - Encryption algorithm 1172 - DH-Group 1174 - SA lifetime (traffic and time based) 1176 - Authentication mechanism (pre-shared key, RSA-sig, 1177 certificate, etc) 1179 + IKE Phase 2 parameters 1181 - IPsec protocol (part of IPsec context) 1183 - IPsec protocol mode (part of IPsec context) 1185 - Authentication algorithm (part of IPsec context) 1187 - Encryption algorithm (part of IPsec context) 1189 - DH-Group 1191 - PFS Group used 1193 - SA Lifetime (part of IPsec context) 1195 * Use of IKE Keepalive or DPD, as defined in 1196 [I-D.ietf-ipsec-dpd], and its interval and retry values 1197 (assumed disabled when not mentioned). 1199 * IP Compression [RFC2393] 1201 The IKE context MUST also list: 1203 * Phase 1 mode (main or aggressive) 1205 * Available bandwidth and latency to Certificate Authority server 1206 (if applicable) 1208 Issues: A Security Context will be an important element in 1209 describing the environment where protected traffic is traveling 1210 through. 1212 See Also: IPsec Protocols, Transform Protocols, IKE Phase 1, IKE 1213 phase 2, Selectors, IPsec Tunnel 1215 8. Framesizes 1217 8.1. Layer3 clear framesize 1219 Definition: The total size of the unencrypted L3 PDU. 1221 Discussion: In relation to IPsec this is the size of the IP header 1222 and its payload. It SHALL NOT include any encapsulations that MAY 1223 be applied before the PDU is processed for encryption. 1225 IPv4 example: For a 64 byte Ethernet packet, the IPv4 Layer3 PDU 1226 is calculated as: 1228 L3 PDU = 64 bytes - L2 Ethernet Header (18 bytes) 1229 = 46 bytes PDU 1230 = 20 bytes IPv4 header + 26 bytes payload. 1232 IPv6 example: For a 64 byte Ethernet packet, the IPv6 Layer3 PDU 1233 is calculated as: 1235 L3 PDU = 64 bytes - L2 Ethernet Header (18 bytes) 1236 = 46 bytes PDU 1237 = 40 bytes IPv6 base header + 6 bytes payload. 1239 Measurement Units: Bytes 1241 Issues: N/A 1242 See Also: Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1243 Encrypted Framesize. 1245 8.2. Layer3 encrypted framesize 1247 Definition: The total size of the encrypted L3 PDU. 1249 Discussion: The size of the IP packet and its payload after 1250 encapsulations MAY be applied and the PDU is being processed by 1251 the transform. 1253 For example, when using a tunnel mode ESP 3DES/SHA1 transform to 1254 protect an unencrypted IPv4 L3 PDU of 46 bytes, the L3 encrypted 1255 framesize becomes 96 bytes: 1257 20 bytes outer IPv4 header (Tunnel mode) 1258 4 bytes SPI (ESP Header) 1259 4 bytes Sequence (ESP Header) 1260 8 bytes IV (IOS ESP-3DES) 1261 46 bytes payload (Original IPv4 L3 PDU) 1262 0 bytes pad (ESP-3DES 64 bit) 1263 1 byte Pad length (ESP Trailer) 1264 1 byte Next Header (ESP Trailer) 1265 12 bytes ESP-HMAC SHA1 96 digest 1267 For the same example but protecting an unencrypted IPv6 L3 PDU of 1268 46 bytes, the L3 framesize becomes 116 bytes: 1270 40 bytes outer IPv6 header (Tunnel mode) 1271 4 bytes SPI (ESP Extension Header) 1272 4 bytes Sequence (ESP Extension Header) 1273 8 bytes IV (IOS ESP-3DES) 1274 46 bytes payload (Original IPv6 L3 PDU) 1275 0 bytes pad (ESP-3DES 64 bit) 1276 1 byte Pad length (ESP Trailer) 1277 1 byte Next Header (ESP Trailer) 1278 12 bytes ESP-HMAC SHA1 96 digest 1280 Measurement Units: Bytes 1282 Issues: N/A 1284 See Also: Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 1285 Encrypted Framesize. 1287 9. Performance Metrics 1289 9.1. IPsec Tunnels Per Second (TPS) 1291 Definition: The measurement unit for the IPsec Tunnel Setup Rate 1292 tests. The rate at which IPsec Tunnels are established per 1293 second. 1295 Discussion: According to [RFC2401] two IPsec Tunnels cannot be 1296 established between the same gateways with the same selectors. 1297 This is to prevent overlapping IPsec Tunnels. If overlapping 1298 IPsec Tunnels are attempted, the error will cause the IPsec Tunnel 1299 setup time to take longer than if the IPsec Tunnel setup was 1300 successful. For this reason, a unique pair of selector sets are 1301 required for IPsec Tunnel Setup Rate testing. 1303 Issues: A unique pair of selector sets are required for TPS testing. 1305 See Also: IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, 1306 IKE Setup Rate, IPsec Setup Rate 1308 9.2. Tunnel Rekeys Per Seconds (TRPS) 1310 Definition: A metric that quantifies the number of IKE Phase 1 or 1311 Phase 2 rekeys per seconds a DUT can correctly process. 1313 Discussion: This metric will be will be primary used with Tunnel 1314 Rekey behavior tests. 1316 TRPS will provide a metric used to see system behavior under 1317 stressful conditions where large volumes of SA's are being rekeyed 1318 at the same time or in a short timespan. 1320 Issues: N/A 1322 See Also: Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey 1323 Rate 1325 9.3. IPsec Tunnel Attempts Per Second (TAPS) 1327 Definition: A metric that quantifies the number of successful and 1328 unsuccessful IPsec Tunnel establishment requests per second. 1330 Discussion: This metric can be used to measure IKE DOS Resilience 1331 behavior test. 1333 TAPS provides an important metric to validate the stability of an 1334 IPsec device, if stressed with valid (large number of IPsec tunnel 1335 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1336 any style) tunnel establishment requests. IPsec Tunnel setups 1337 offered to an IPsec devices can either fail due to lack of 1338 resources in the IPsec device to process all the requests or due 1339 to an IKE DOS attack (usually the former is a result of the 1340 latter). 1342 Issues: If the TAPS increases, the TPS usually decreases, due to 1343 burdening of the DUT with the DOS attack traffic. 1345 See Also: N/A 1347 10. Test Definitions 1349 10.1. Capacity 1351 10.1.1. IPsec Tunnel Capacity 1353 Definition: The maximum number of Active IPsec Tunnels that can be 1354 sustained on an IPsec Device. 1356 Discussion: This metric will represent the quantity of IPsec Tunnels 1357 that can be establish on an IPsec Device that can forward traffic 1358 i.e. Active Tunnels. It will be a measure that indicates how 1359 many remote peers an IPsec Device can establish a secure 1360 connection with. 1362 Measurement Units: IPsec Tunnels 1364 Issues: N/A 1366 See Also: IPsec SA Capacity 1368 10.1.2. IPsec SA Capacity 1370 Definition: The maximum number of IPsec SA's that can be sustained 1371 on an IPsec Device. 1373 Discussion: This metric will represent the quantity of traffic flows 1374 a given IPsec Device can protect. In contrast with the IPsec 1375 Tunnel Capacity, the emphasis for this test lies on the number of 1376 IPsec SA's that can be established in the worst case scenario. 1377 This scenario would be a case where 1 IKE SA is used to negotiate 1378 multiple IPsec SA's. It is the maximum number of Active Tunnels 1379 that can be sustained by an IPsec Device where only 1 IKE SA is 1380 used to exchange keying material. 1382 Measurement Units: IPsec SA's 1384 Issues: N/A 1386 See Also: IPsec Tunnel Capacity 1388 10.2. Throughput 1390 10.2.1. IPsec Throughput 1392 Definition: The maximum rate through an Active Tunnel at which none 1393 of the offered frames are dropped by the device under test. 1395 Discussion: The IPsec Throughput is almost identically defined as 1396 Throughput in [RFC1242], section 3.17. The only difference is 1397 that the throughput is measured with a traffic flow getting 1398 encrypted and decrypted by an IPsec device. IPsec Throughput is 1399 an end-to-end measurement. 1401 The metric can be represented in two variantions depending on 1402 where measurement is taken in the SUT. One can look at throughput 1403 from a cleartext point of view i.e. find the maximum rate where 1404 clearpackets no longer get dropped. This resulting rate can be 1405 recalculated with an encrypted framesize to represent the 1406 encryption throughput rate. The latter is the preferred method of 1407 representation and shall be called the IPsec Throughput. 1409 Measurement Units: Packets per seconds (pps) 1411 Issues: N/A 1413 See Also: IPsec Encryption Throughput, IPsec Decryption Throughput 1415 10.2.2. IPsec Encryption Throughput 1417 Definition: The maximum encryption rate through an Active Tunnel at 1418 which none of the offered cleartext frames are dropped by the 1419 device under test. 1421 Discussion: Since encryption throughput is not necessarily equal to 1422 the decryption throughput, both of the forwarding rates must be 1423 measured independently. The independent forwarding rates have to 1424 measured with the help of an IPsec aware test device that can 1425 originate and terminate IPsec and IKE SA. As defined in 1426 [RFC1242], measurements should be taken with an assortment of 1427 frame sizes. 1429 Measurement Units: Packets per seconds (pps) 1431 Issues: In some cases packets are offered to an IPsec Device that 1432 have a framesize that is larger then the MTU of the ingress 1433 interface of the IPsec Tunnel that is transporting the packet. In 1434 this case fragmentation will be required before IPsec services are 1435 applied. 1437 In other cases, the packet is of a size very close to the MTU of 1438 the egress interface of the IPsec Tunnel. Here, the mere addition 1439 of the IPsec header will create enough overhead to make the IPsec 1440 packet larger then the MTU of the egress interface. In such 1441 instance, the original payload packet must be fragmented either 1442 before or after the IPsec overhead is applied. 1444 Note that the two aforementioned scenario's can happen 1445 simultaniously on a single packet, creating multiple small 1446 fragments. 1448 When measuring the IPsec Encryption Throughput, one has to 1449 consider that when probing with packets of a size near MTU's 1450 associated with the IPsec Tunnel, fragmentation may accor and the 1451 decrypting IPsec Device (either a tester or a corresponding IPsec 1452 peer) has to reassemble the IPsec and/or payload fragments to 1453 validate its content. 1455 The end points (i.e. hosts, subnets) should NOT see any fragments 1456 at ANY time. Only on the IPsec link, fragments MAY occur. 1458 See Also: IPsec Throughput, IPsec Decryption Throughput 1460 10.2.3. IPsec Decryption Throughput 1462 Definition: The maximum decryption rate through an Active Tunnel at 1463 which none of the offered encrypted frames are dropped by the 1464 device under test. 1466 Discussion: Since encryption throughput is not necessarily equal to 1467 the decryption throughput, both of the forwarding rates must be 1468 measured independently. 1470 The independent forwarding rates have to be measured with the help 1471 of an IPsec aware test device that can originate and terminate 1472 IPsec and IKE SA. As defined in [RFC1242], measurements should be 1473 taken with an assortment of frame sizes. 1475 Measurement Units: Packets per seconds (pps) 1477 Issues: When measuring the IPsec Decryption Throughput, one has to 1478 consider that it is likely that the encrypting IPsec Device has to 1479 fragment certain packets that have a frame size near MTU's 1480 associated with the IPsec Tunnel. 1482 The decrypting IPsec Device has to reassemble the IPsec and/or 1483 payload fragments to validate its content. 1485 The end points (i.e. hosts, subnets) should NOT see any fragments 1486 at ANY time. Only on the IPsec link, fragments MAY occur. 1488 See Also: IPsec Throughput, IPsec Encryption Throughput 1490 10.3. Latency 1492 10.3.1. IPsec Latency 1494 Definition: Time required to propagate a cleartext frame from the 1495 input interface of an initiator, through an Active Tunnel, to the 1496 output interface of the responder. 1498 Discussion: The IPsec Latency is the time interval starting when the 1499 end of the first bit of the cleartext frame reaches the input 1500 interface of the initiator and ending when the start of the first 1501 bit of the same cleartext frame is detected on the output 1502 interface of the responder. The frame has passed through an 1503 Active Tunnel between an initiator and a responder and has been 1504 through an encryption and decryption cycle. 1506 Measurement Units: Time units with enough precision to reflect 1507 latency measurement. 1509 Issues: N/A 1511 See Also: IPsec Encryption Latency, IPsec Decryption Latency 1513 10.3.2. IPsec Encryption Latency 1515 Definition: The IPsec Encryption Latency is the time interval 1516 starting when the end of the first bit of the cleartext frame 1517 reaches the input interface, through an Active Tunnel, and ending 1518 when the start of the first bit of the encrypted output frame is 1519 seen on the output interface. 1521 Discussion: IPsec Encryption Latency is the latency introduced when 1522 encrypting traffic through an IPsec tunnel. 1524 Like encryption/decryption throughput, it is not always the case 1525 that encryption latency equals the decryption latency. Therefore 1526 a distinction between the two has to be made in order to get a 1527 more accurate view of where the latency is the most pronounced. 1529 The independent encryption/decryption latencies have to be 1530 measured with the help of an IPsec aware test device that can 1531 originate and terminate IPsec and IKE SA. As defined in 1532 [RFC1242], measurements should be taken with an assortment of 1533 frame sizes. 1535 Measurement Units: Time units with enough precision to reflect 1536 latency measurement. 1538 Issues: N/A 1540 See Also: IPsec Latency, IPsec Decryption Latency 1542 10.3.3. IPsec Decryption Latency 1544 Definition: The IPsec decryption Latency is the time interval 1545 starting when the end of the first bit of the encrypted frame 1546 reaches the input interface, through an Active Tunnel, and ending 1547 when the start of the first bit of the decrypted output frame is 1548 seen on the output interface. 1550 Discussion: IPsec Decryption Latency is the latency introduced when 1551 decrypting traffic through an Active Tunnel. Like encryption/ 1552 decryption throughput, it is not always the case that encryption 1553 latency equals the decryption latency. Therefore a distinction 1554 between the two has to be made in order to get a more accurate 1555 view of where the latency is the most pronounced. 1557 The independent encryption/decryption latencies have to be 1558 measured with the help of an IPsec aware test device that can 1559 originate and terminate IPsec and IKE SA's. As defined in 1560 [RFC1242], measurements should be taken with an assortment of 1561 frame sizes. 1563 Measurement Units: Time units with enough precision to reflect 1564 latency measurement. 1566 Issues: N/A 1568 See Also: IPsec Latency, IPsec Encryption Latency 1570 10.3.4. Time To First Packet 1572 Definition: The Time To First Packet (TTFP) is the time required to 1573 process a cleartext packet from a traffic stream that requires 1574 encryption services when no IPsec Tunnel is present. 1576 Discussion: The Time To First Packet addresses the issue of 1577 responsiveness of an IPsec device by looking how long it takes to 1578 transmit a packet over Configured Tunnel. The Time To First 1579 Packet MUST include the time to set up the established tunnel, 1580 triggered by the traffic flow (both phase 1 and phase 2 setup 1581 times SHALL be included) and the time it takes to encrypt and 1582 decrypt the packet on a corresponding peer. In short it is the 1583 IPsec Tunnel setup time plus the propagation delay of the packet 1584 through the Active Tunnel. 1586 It must be noted that it is highly unlikely that the first packet 1587 of the traffic flow will be the packet that will be used to 1588 measure the TTFP. There MAY be several protocol layers in the 1589 stack before the tunnel is formed and the traffic is forwarded, 1590 hence several packets COULD be lost during negotiation, for 1591 example, ARP and/or IKE. 1593 Measurement Units: Time units with enough precision to reflect a 1594 TTFP measurement. 1596 Issues: Only relevant when using IKE for tunnel negotiation. 1598 10.4. Frame Loss 1600 10.4.1. IPsec Frame Loss 1602 Definition: Percentage of cleartext frames that should have been 1603 forwarded through an Active Tunnel under steady state (constant) 1604 load but were dropped before encryption or after decryption. 1606 Discussion: The IPsec Frame Loss is almost identically defined as 1607 Frame Loss Rate in [RFC1242], section 3.6. The only difference is 1608 that the IPsec Frame Loss is measured with a traffic flow getting 1609 encrypted and decrypted by an IPsec Device. IPsec Frame Loss is 1610 an end-to-end measurement. 1612 Measurement Units: Percent (%) 1614 Issues: N/A 1616 See Also: IPsec Encryption Frame Loss, IPsec Decryption Frame Loss 1618 10.4.2. IPsec Encryption Frame Loss 1620 Definition: Percentage of cleartext frames that should have been 1621 encrypted through an Active Tunnel under steady state (constant) 1622 load but were dropped. 1624 Discussion: A DUT will always have an inherent forwarding 1625 limitation. This will be more pronounced when IPsec is employed 1626 on the DUT. There is a possibility that the offered traffic rate 1627 at the Active Tunnel is too high to be transported through the 1628 Active Tunnel and not all cleartext packets will get encrypted. 1629 In that case, some percentage of the cleartext traffic will be 1630 dropped. This drop percentage is called the IPsec Encryption 1631 Frame Loss. 1633 Measurement Units: Percent (%) 1635 Issues: N/A 1637 See Also: IPsec Frame Loss, IPsec Decryption Frame Loss 1639 10.4.3. IPsec Decryption Frame Loss 1641 Definition: Percentage of encrypted frames that should have been 1642 decrypted through an Active Tunnel under steady state (constant) 1643 load but were dropped. 1645 Discussion: A DUT will also have an inherent forwarding limitation 1646 when decrypting packets. When Active Tunnel encrypted traffic is 1647 offered at a costant load, there might be a possibility that the 1648 IPsec Device that needs to decrypt the traffic will not be able to 1649 perfom this action on all of the packets due to limitations of the 1650 decryption performance. The percentage of encrypted frames that 1651 would get dropped under these conditions is called the IPsec 1652 Decryption Frame Loss. 1654 Measurement Units: Percent (%) 1656 Issues: N/A 1657 See Also: IPsec Frame Loss, IPsec Encryption Frame Loss 1659 10.4.4. IKE Phase 2 Rekey Frame Loss 1661 Definition: Number of frames dropped as a result of an inefficient 1662 IKE Phase 2 rekey. 1664 Discussion: Normal operation of an IPsec Device would require that a 1665 rekey does not create temporary IPsec Frame Loss of a traffic 1666 stream that is protected by the IKE Phase 2 SA's (i.e. IPsec 1667 SA's). Nevertheless there can be situations where IPsec Frame 1668 Loss occurs during this rekey process. 1670 This metric should be ideally zero but this may not be the case on 1671 IPsec Devices where IPsec funtionality is not a core feature. 1673 Measurement Units: Number of N-octet frames 1675 Issues: N/A 1677 See Also: IKE Phase 2 Rekey Rate 1679 10.5. Tunnel Setup Behavior 1681 10.5.1. IPsec Tunnel Setup Rate 1683 Definition: The maximum number of IPsec Tunnels per second that an 1684 IPsec Device can successfully establish. 1686 Discussion: The Tunnel Setup Rate SHOULD be measured at varying 1687 number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the 1688 DUT. Several factors may influence Tunnel Setup Rate, such as: 1689 TAPS rate, Background cleartext traffic load on the secure 1690 interface, Already established IPsec Tunnels, Authentication 1691 method such as pre-shared keys, RSA-encryption, RSA-signature, DSS 1692 Key sizes used (when using RSA/DSS). 1694 The Tunnel Setup Rate is an important factor to understand when 1695 designing networks using statless failover of IPsec tunnels to a 1696 standby chassis. At the same time it can be important to set 1697 Connection and Admission control paramters in an IPsec device to 1698 prevent overloading the IPsec Device. 1700 Measurement Units: Tunnels Per Second (TPS) 1701 Issues: N/A 1703 See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec 1704 Tunnel Rekey Behavior 1706 10.5.2. IKE Phase 1 Setup Rate 1708 Definition: The maximum number of sucessful IKE Phase 1 SA's per 1709 second that an IPsec Device can establish. 1711 Discussion: The Phase 1 Setup Rate is a portion of the IPsec Tunnel 1712 Setup Rate. In the process of establishing an IPsec Tunnel, it is 1713 interesting to know what the limiting factor of the IKE Finite 1714 State Machine (FSM) is i.e. is it limited by the Phase 1 1715 processing delays or rather by the Phase 2 processing delays. 1717 Measurement Units: Tunnels Per Second (TPS) 1719 Issues: N/A 1721 See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec 1722 Tunnel Rekey Behavior 1724 10.5.3. IKE Phase 2 Setup Rate 1726 Definition: The maximum number of successfully IKE Phase 2 SA's per 1727 second that an IPsec Device can Only relevant when using IKE 1728 establish. 1730 Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec 1731 Tunnel Setup Rate. For identical reasons why it is required to 1732 quantify the IKE Phase 1 Setup Rate, it is a good practice to know 1733 the processing delays involved in setting up an IKE Phase 2 SA for 1734 each direction of the protected traffic flow. 1736 IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of 1737 two IKE Phase 2 SA's. 1739 Note that once you have the IPsec Tunnel Setup Rate and either the 1740 IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can 1741 extrapolate the unmeasured metric. It is however highly 1742 RECOMMENDED to measure all three metrics since the IKE and IPsec 1743 SA establishment are two distinct and decoupled phases in the 1744 establishment of a Tunnel. 1746 Measurement Units: Tunnels Per Second (TPS) 1748 Issues: N/A 1750 See Also: IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec 1751 Tunnel Rekey Behavior 1753 10.6. IPsec Tunnel Rekey Behavior 1755 10.6.1. IKE Phase 1 Rekey Rate 1757 Definition: The number of IKE Phase 1 SA's that can be succesfully 1758 re-establish per second. 1760 Discussion: Although the IKE Phase 1 Rekey Rate has less impact on 1761 the forwarding behavior of traffic that requires security services 1762 then the IKE Phase 2 Rekey Rate, it can pose a large burden on the 1763 CPU or network processor of the IPsec Device. Due to the highly 1764 computational nature of a Phase 1 exchange, it may impact the 1765 stability of Active Tunnels in the network when the IPsec Device 1766 fails to properly rekey an IKE Phase 1 SA. 1768 Measurement Units: Tunnel Rekeys per second (TRPS) 1770 Issues: N/A 1772 See Also: IKE Phase 2 Rekey Rate 1774 10.6.2. IKE Phase 2 Rekey Rate 1776 Definition: The number of IKE Phase 2 SA's that can be succesfully 1777 re-negotiated per second. 1779 Discussion: Although many implementations will usually derive new 1780 keying material before the old keys expire, there may still be a 1781 period of time where frames get dropped before the IKE Phase 2 1782 tunnels are successfully re-established. There may also be some 1783 packet loss introduced when the handover of traffic is done from 1784 the expired IPsec SA's to the newly negotiated IPsec SA's. To 1785 measure the IKE Phase 2 rekey rate, the measurement will require 1786 an IPsec aware test device to act as a responder when negotiating 1787 the new IKE Phase 2 keying material. 1789 The test methodology report must specify if PFS is enabled in 1790 reported security context. 1792 Measurement Units: Tunnel Rekeys per second (TRPS) 1794 Issues: N/A 1796 See Also: IKE Phase 1 Rekey Rate 1798 10.7. IPsec Tunnel Failover Time 1800 Definition: Time required to recover all IPsec Tunnels on a stanby 1801 IPsec Device, after a catastrophic failure occurs on the active 1802 IPsec Device. 1804 Discussion: Recovery time required to re-establish or to engage all 1805 IPsec Tunnels and reroute all traffic on a standby node or other 1806 failsafe system after a failure has occurred in the original 1807 active DUT/SUT. Failure can include, but are not limited to, a 1808 catastrophic IPsec Device failure, a encryption engine failure, 1809 protocol failures and link outages. The recovery time is delta 1810 between the point of failure and the time the first packet is seen 1811 on the last restored IPsec Tunnel on the backup device. 1813 Measurement Units: Time units with enough precision to reflect IPsec 1814 Tunnel Failover Time. 1816 Issues: N/A 1818 10.8. DoS Attack Resiliency 1820 10.8.1. Phase 1 DoS Resiliency Rate 1822 Definition: The Phase 1 Denial of Service (DoS) Resilience Rate 1823 quantifies the rate of invalid or malicious IKE tunnels that can 1824 be directed at a DUT before the Responder stops accepting valid 1825 tunnel attempts. 1827 Discussion: Phase 1 DoS attacks can present themselves in various 1828 forms and do not necessarily have to have a malicious background. 1829 It is sufficient to make a typographical error in a shared secret 1830 in an IPsec Device to be susceptible to a large number of IKE 1831 attempts that need to be turned down. Due to the intense 1832 computational nature of an IKE exchange every single IKE tunnel 1833 attempt that has to be denied will take non-negligible CPU cycles 1834 in the IPsec Device. 1836 Depending on the quantity of these messages that have to be 1837 processed, a system might end up in a state that the burden on 1838 system resource performing key exchanges is high enough that all 1839 resources are consumed by this process. At this point it will be 1840 no longer possible to process a valid IKE tunnel setup request and 1841 thus a Phase 1 DoS Attack is in effect. 1843 The scope of the attack profile for this test will include 1844 mismatched pre-shared keys as well as invalid digital 1845 certificates. 1847 Measurement Units: Tunnel Attempts Per Seconds (TAPS) 1849 Issues: N/A 1851 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate 1853 Definition: The Phase 2 Hash Mismatch Denial of Service (DoS) 1854 Resilience Rate quantifies the rate of invalid ESP/AH packets that 1855 a DUT can drop without affecting the traffic flow of valid ESP/AH 1856 packets. 1858 Discussion: Phase 2 DoS attacks can present themselves in various 1859 forms and do not necessarily have to have a malicious background, 1860 but usually are. Typical are cases where there is a true 1861 malicious intent in the ESP/AH traffic flow by e.g. having an 1862 invalid hash in the IPsec data packets. 1864 Depending on the quantity of these packets that have to be 1865 processed, a system might end up in a state that the burden on the 1866 IPsec Device becomes large enough that it will impact valid 1867 traffic flows. At this point it will be no longer possible to 1868 forward valid IPsec payload without packetloss and thus a Phase 2 1869 DoS Attack is in effect. 1871 Measurement Units: Packets per seconds (pps) 1873 Issues: N/A 1875 10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate 1877 Definition: The Phase 2 Anti Replay Attack Denial of Service (DoS) 1878 Resilience Rate quantifies the rate of replayed ESP/AH packets 1879 that a DUT can drop without affecting the traffic flow of valid 1880 ESP/AH packets. 1882 Discussion: Anti Replay protection is a cornerstone feature of the 1883 IPsec framework and can be found in both the AH as well as the ESP 1884 protocol. To better understand what the impact is of a replay 1885 attack on an IPsec device, a valid IPsec stream will be replayed 1886 and each packet of the stream will appear twice on the wire at 1887 different times where the second instance will be outside of the 1888 Anti Replay Window. 1890 Measurement Units: Replayed Packets per seconds (pps) 1892 Issues: N/A 1894 11. Security Considerations 1896 As this document is solely for the purpose of providing test 1897 benchmarking terminology and describes neither a protocol nor a 1898 protocol's implementation; there are no security considerations 1899 associated with this document. 1901 12. Acknowledgements 1903 The authors would like to acknowledge the following individual for 1904 their participation of the compilation and editing of this document 1905 and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian 1906 Talbert. 1908 13. References 1910 13.1. Normative References 1912 [RFC1242] Bradner, S., "Benchmarking terminology for network 1913 interconnection devices", RFC 1242, July 1991. 1915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1916 Requirement Levels", BCP 14, RFC 2119, March 1997. 1918 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1919 Switching Devices", RFC 2285, February 1998. 1921 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 1922 Payload Compression Protocol (IPComp)", RFC 2393, 1923 December 1998. 1925 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1926 Internet Protocol", RFC 2401, November 1998. 1928 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 1929 RFC 2402, November 1998. 1931 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 1932 ESP and AH", RFC 2403, November 1998. 1934 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1935 ESP and AH", RFC 2404, November 1998. 1937 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 1938 Algorithm With Explicit IV", RFC 2405, November 1998. 1940 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1941 Payload (ESP)", RFC 2406, November 1998. 1943 [RFC2407] Piper, D., "The Internet IP Security Domain of 1944 Interpretation for ISAKMP", RFC 2407, November 1998. 1946 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 1947 Security Association and Key Management Protocol 1948 (ISAKMP)", RFC 2408, November 1998. 1950 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1951 (IKE)", RFC 2409, November 1998. 1953 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1954 Its Use With IPsec", RFC 2410, November 1998. 1956 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 1957 Document Roadmap", RFC 2411, November 1998. 1959 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 1960 RFC 2412, November 1998. 1962 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1963 Algorithms", RFC 2451, November 1998. 1965 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 1966 Network Interconnect Devices", RFC 2544, March 1999. 1968 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 1969 March 1999. 1971 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1972 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1973 RFC 2661, August 1999. 1975 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1976 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1977 March 2000. 1979 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1980 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1981 January 2005. 1983 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1984 Internet Protocol", RFC 4301, December 2005. 1986 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1987 December 2005. 1989 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1990 RFC 4303, December 2005. 1992 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1993 RFC 4306, December 2005. 1995 [I-D.ietf-ipsec-ikev2] 1996 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1997 draft-ietf-ipsec-ikev2-17 (work in progress), 1998 October 2004. 2000 [I-D.ietf-ipsec-dpd] 2001 Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- 2002 Based Method of Detecting Dead IKE Peers", 2003 draft-ietf-ipsec-dpd-04 (work in progress), October 2003. 2005 [I-D.ietf-ipsec-properties] 2006 Krywaniuk, A., "Security Properties of the IPsec Protocol 2007 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2008 July 2002. 2010 [FIPS.186-1.1998] 2011 National Institute of Standards and Technology, "Digital 2012 Signature Standard", FIPS PUB 186-1, December 1998, 2013 . 2015 13.2. Informative References 2017 [Designing Network Security] 2018 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2019 Published: May 07, 1999; Copyright: 1999, 1999. 2021 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2022 Mechanism for Internet", from IEEE Proceedings of the 2023 1996 Symposium on Network and Distributed Systems 2024 Security, 2025 URI http://www.research.ibm.com/security/skeme.ps, 1996. 2027 Authors' Addresses 2029 Merike Kaeo 2030 Double Shot Security 2031 3518 Fremont Ave N #363 2032 Seattle, WA 98103 2033 USA 2035 Phone: +1(310)866-0165 2036 Email: kaeo@merike.com 2038 Tim Van Herck 2039 Cisco Systems 2040 170 West Tasman Drive 2041 San Jose, CA 95134-1706 2042 USA 2044 Phone: +1(408)853-2284 2045 Email: herckt@cisco.com 2047 Michele Bustos 2048 IXIA 2049 26601 W. Agoura Rd. 2050 Calabasas, CA 91302 2051 USA 2053 Phone: +1(818)444-3244 2054 Email: mbustos@ixiacom.com 2056 Full Copyright Statement 2058 Copyright (C) The IETF Trust (2008). 2060 This document is subject to the rights, licenses and restrictions 2061 contained in BCP 78, and except as set forth therein, the authors 2062 retain all their rights. 2064 This document and the information contained herein are provided on an 2065 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2066 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2067 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2068 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2069 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2070 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2072 Intellectual Property 2074 The IETF takes no position regarding the validity or scope of any 2075 Intellectual Property Rights or other rights that might be claimed to 2076 pertain to the implementation or use of the technology described in 2077 this document or the extent to which any license under such rights 2078 might or might not be available; nor does it represent that it has 2079 made any independent effort to identify any such rights. Information 2080 on the procedures with respect to rights in RFC documents can be 2081 found in BCP 78 and BCP 79. 2083 Copies of IPR disclosures made to the IETF Secretariat and any 2084 assurances of licenses to be made available, or the result of an 2085 attempt made to obtain a general license or permission for the use of 2086 such proprietary rights by implementers or users of this 2087 specification can be obtained from the IETF on-line IPR repository at 2088 http://www.ietf.org/ipr. 2090 The IETF invites any interested party to bring to its attention any 2091 copyrights, patents or patent applications, or other proprietary 2092 rights that may cover technology that may be required to implement 2093 this standard. Please address the information to the IETF at 2094 ietf-ipr@ietf.org. 2096 Acknowledgment 2098 Funding for the RFC Editor function is provided by the IETF 2099 Administrative Support Activity (IASA).