idnits 2.17.1 draft-ietf-bmwg-ipsec-term-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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.) ** There are 39 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2004) is 7345 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 1094, but not defined == Missing Reference: 'GW2' is mentioned on line 1094, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 1094, but not defined == Missing Reference: 'GW3' is mentioned on line 1094, but not defined == Missing Reference: 'GW4' is mentioned on line 1094, but not defined == Missing Reference: 'ESP' is mentioned on line 1268, but not defined == Missing Reference: 'AH' is mentioned on line 1235, but not defined == Missing Reference: 'IP' is mentioned on line 1102, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 1268, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 1268, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 1268, but not defined == Missing Reference: 'IP ORIG' is mentioned on line 1268, but not defined == Missing Reference: 'L4 HDR' is mentioned on line 1268, but not defined == Missing Reference: 'IP NEW' is mentioned on line 1268, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1330, but not defined == Unused Reference: 'RFC2119' is defined on line 2287, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 2303, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 2306, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 2309, but no explicit reference was found in the text == Unused Reference: 'RFC2408' is defined on line 2318, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 2325, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 2328, but no explicit reference was found in the text == Unused Reference: 'RFC2451' is defined on line 2334, but no explicit reference was found in the text == Unused Reference: 'RFC2547' is defined on line 2340, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 2343, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-udp-encaps' is defined on line 2353, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-nat-reqts' is defined on line 2358, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2363, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 ** Downref: Normative reference to an Informational RFC: RFC 2285 ** Obsolete normative reference: RFC 2393 (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Informational RFC: RFC 2544 ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-07 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-07 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-nat-reqts (ref. 'I-D.ietf-ipsec-nat-reqts') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipsec-properties' == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-dpd-02 Summary: 17 errors (**), 0 flaws (~~), 35 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group M. Bustos 3 Internet-Draft IXIA 4 Expires: August 30, 2004 T. Van Herck 5 Cisco Systems, Inc. 6 M. Kaeo 7 Merike, Inc. 8 March 2004 10 Terminology for Benchmarking IPSec Devices 11 draft-ietf-bmwg-ipsec-term-03 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This purpose of this document is to define terminology specific to 42 measuring the performance of IPsec devices. It builds upon the 43 tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF 44 Benchmarking Methodology Working Group (BMWG) documents used for 45 benchmarking routers and switches. This document seeks to extend 46 these efforts specific to the IPsec paradigm. The BMWG produces two 47 major classes of documents: Benchmarking Terminology documents and 48 Benchmarking Methodology documents. The Terminology documents present 49 the benchmarks and other related terms. The Methodology documents 50 define the procedures required to collect the benchmarks cited in the 51 corresponding Terminology documents. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . 4 57 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 58 2.1.1 Security Associations . . . . . . . . . . . . . . . . . . 6 59 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Definition Format . . . . . . . . . . . . . . . . . . . . 8 62 5. Key Words to Reflect Requirements . . . . . . . . . . . . 9 63 6. Existing Benchmark Definitions . . . . . . . . . . . . . . 9 64 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.3.2 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . 12 70 7.3.3 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . 13 71 7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . 14 73 7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15 74 7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 16 76 7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . . . 17 77 7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . . . 18 79 7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . . . 18 80 7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 19 82 7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . 20 83 7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . . . 21 85 7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . . . 21 86 7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . . . 22 87 7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23 88 7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 23 89 7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 24 90 7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25 91 7.9.1 Authentication Protocols . . . . . . . . . . . . . . . . . 25 92 7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 26 93 7.10 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 26 94 7.10.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 27 95 7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 28 96 7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 28 97 7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . . 29 98 7.13 Security Context . . . . . . . . . . . . . . . . . . . . . 30 99 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32 100 8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 101 8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 32 102 8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 33 103 8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34 104 9. Performance Metrics . . . . . . . . . . . . . . . . . . . 35 105 9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35 106 9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 35 107 9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36 108 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . 36 109 10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36 110 10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . . . . 36 111 10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37 112 10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 38 113 10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . . . . 38 115 10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 39 116 10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 40 117 10.2.4 Time To First Packet . . . . . . . . . . . . . . . . . . . 41 118 10.3 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 41 119 10.3.1 IPSec Tunnel Frame Loss Rate . . . . . . . . . . . . . . . 41 120 10.3.2 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 42 121 10.3.3 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 43 122 10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 44 123 10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . . . . 44 124 10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . . . . 44 125 10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . . . . 45 126 10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 46 127 10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 46 128 10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . . . 46 129 10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . . . 47 130 10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 47 131 10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 47 132 10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 48 133 10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 49 134 10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 49 135 11. Security Considerations . . . . . . . . . . . . . . . . . 50 136 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50 137 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 50 138 Normative References . . . . . . . . . . . . . . . . . . . 50 139 Informative References . . . . . . . . . . . . . . . . . . 52 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 141 Intellectual Property and Copyright Statements . . . . . . 54 143 1. Introduction 145 Despite the need to secure communications over a public medium there 146 is no standard method of performance measurement nor a standard in 147 the terminology used to develop such hardware/software solutions. 148 This results in varied implementations which challenge 149 interoperability and direct performance comparisons. Standarized 150 IPsec terminology and performance test methodologies will enable 151 users to decide if the IPsec device they select will withstand 152 relatively heavy loads of secured traffic. 154 To appropriately define the parameters and scope of this 155 document,this section will give a brief overview of the IPsec 156 standard: 158 2. IPsec Fundamentals 160 IPsec is a framework of open standards that provides data 161 confidentiality, data integrity, and data authenticity between 162 participating peers. IPsec provides these security services at the IP 163 layer. IPsec uses IKE to handle negotiation of protocols and 164 algorithms based on local policy, and to generate the encryption and 165 authentication keys to be used. IPsec can be used to protect one or 166 more data flows between a pair of hosts, between a pair of security 167 gateways, or between a security gateway and a host. The IPsec 168 protocol suite set of standards is documented in RFC's 2401 through 169 2412 and RFC 2451. The reader is assumed to be familiar with these 170 documents. Some Internet Drafts supersede these RFC's and will be 171 taken into consideration. 173 IPsec itself defines the following: 175 Authentication Header (AH): A security protocol, defined in 176 [RFC2402], which provides data authentication and optional 177 anti-replay services. AH ensures the integrity and data origin 178 authentication of the IP datagram as well as the invariant fields in 179 the outer IP header. 181 Encapsulating Security Payload (ESP): A security protocol, defined in 182 [RFC2406], which provides confidentiality, data origin 183 authentication, connectionless integrity, an anti-replay service and 184 limited traffic flow confidentiality. The set of services provided 185 depends on options selected at the time of Security Association (SA) 186 establishment and on the location of the implementation in a network 187 topology. ESP authenticates only headers and data after the IP 188 header. 190 Internet Key Exchange (IKE): A hybrid protocol which implements 191 Oakley and SKEME key exchanges inside the ISAKMP framework. While IKE 192 can be used with other protocols, its initial implementation is with 193 the IPsec protocol. IKE provides authentication of the IPsec peers, 194 negotiates IPsec security associations, and establishes IPsec keys. 196 The AH and ESP protocols each support two modes of operation: 197 transport mode and tunnel mode. In transport mode, two hosts provide 198 protection primarily for upper-layer protocols. The cryptographic 199 endpoints (where the encryption and decryption take place) are the 200 source and destination of the data packet. In IPv4, a transport mode 201 security protocol header appears immediately after the IP header and 202 before any higher-layer protocols (such as TCP or UDP). 204 In the case of AH in transport mode, all upper-layer information is 205 protected, and all fields in the IPv4 header excluding the fields 206 typically are modified in transit. The fields of the IPv4 header that 207 are not included are, therefore, set to 0 before applying the 208 authentication algorithm. These fields are as follows: 210 * TOS 211 * TTL 212 * Header Checksum 213 * Offset 214 * Flags 216 In the case of ESP in transport mode, security services are provide 217 only for the higher-layer protocols, not for the IP header. A tunnel 218 is a vehicle for encapsulating packets inside a protocol that is 219 understood at the entry and exit points of a given network. These 220 entry and exit points are defined as tunnel interfaces. 222 Tunnel mode can be supported by data packet endpoints as well as by 223 intermediate security gateways. In tunnel mode, there is an "outer" 224 IP header that specifies the IPsec processing destination, plus an 225 "inner" IP header that specifies the ultimate destination for the 226 packet. The source address in the outer IP header is the initiating 227 cryptographic endpoint; the source address in the inner header is the 228 true source address of the packet. The security protocol header 229 appears after the outer IP header and before the inner IP header. 231 If AH is employed in tunnel mode, portions of the outer IP header are 232 given protection (those same fields as for transport mode, described 233 earlier in this section), as well as all of the tunneled IP packet 234 (that is, all of the inner IP header is protected as are the 235 higher-layer protocols). If ESP is employed, the protection is 236 afforded only to the tunneled packet, not to the outer header. 238 2.1 IPsec Operation 240 2.1.1 Security Associations 242 The concept of a Security Association (SA) is fundamental to IPsec. 243 An SA is a relationship between two or more entities that describes 244 how the entities will use security services to communicate securely. 245 The SA includes: an encryption algorithm, an authentication algorithm 246 and a shared session key. 248 Because an SA is unidirectional, two SAs (one in each direction) are 249 required to secure typical, bidirectional communication between two 250 entities. The security services associated with an SA can be used for 251 AH or ESP, but not for both. If both AH and ESP protection is applied 252 to a traffic stream, two (or more) SAs are created for each direction 253 to protect the traffic stream. 255 The SA is uniquely identified by the security parameter index (SPI) 256 [RFC2406]. When a system sends a packet that requires IPsec 257 protection, it looks up the SA in its database and applies the 258 specified processing and security protocol (AH/ESP), inserting the 259 SPI from the SA into the IPsec header. When the IPsec peer receives 260 the packet, it looks up the SA in its database by destination 261 address, protocol, and SPI and then processes the packet as required. 263 2.1.2 Key Management 265 IPsec uses cryptographic keys for authentication/integrity and 266 encryption services. Both manual and automatic distribution of keys 267 is supported. IKE is specified as the public-key-based approach for 268 automatic key management. 270 IKE authenticates each peer involved in IPsec, negotiates the 271 security policy, and handles the exchange of session keys. IKE is a 272 hybrid protocol, combining parts of the following protocols to 273 negotiate and derive keying material for SAs in a secure and 274 authenticated manner: 276 1. ISAKMP (Internet Security Association and Key Management 277 Protocol), which provides a framework for authentication and key 278 exchange but does not define them. ISAKMP is designed to be key 279 exchange independent; it is designed to support many different 280 key exchanges. 282 2. Oakley, which describes a series of key exchanges, called modes, 283 and details the services provided by each (for example, perfect 284 forward secrecy for keys, identity protection, and 285 authentication). [RFC2412] 287 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 288 describes a versatile key exchange technique that provides 289 anonymity, reputability, and quick key refreshment. 291 IKE creates an authenticated, secure tunnel between two entities and 292 then negotiates the security association for IPsec. This is performed 293 in two phases. 295 In Phase 1, the two unidirectional SA's establish a secure, 296 authenticated channel with which to communicate. Phase 1 has two 297 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 298 provides identity protection. When identity protection is not needed, 299 Aggressive Mode can be used. The completion of Phase 1 an IKE SA is 300 established. 302 The following attributes are used by IKE and are negotiated as part 303 of the IKE SA: 305 o Encryption algorithm. 307 o Hash algorithm. 309 o Authentication method (digital signature, public-key encryption, 310 or pre-shared key). 312 o Diffie-Hellman group information. 314 After the attributes are negotiated, both parties must be 315 authenticated to each other. IKE supports multiple authentication 316 methods. At this time, the following mechanisms are generally 317 implemented: 319 o Preshared keys. The same key is pre-installed on each host. IKE 320 peers authenticate each other by computing and sending a keyed 321 hash of data that includes the preshared key. If the receiving 322 peer can independently create the same hash using its preshared 323 key, it knows that both parties must share the same secret, and 324 thus the other party is authenticated. 326 o Public key cryptography. Each party generates a pseudo-random 327 number (a nonce) and encrypts it and its ID using the other 328 party's public key. The ability for each party to compute a keyed 329 hash containing the other peer's nonce and ID, decrypted with the 330 local private key, authenticates the parties to each other. This 331 method does not provide nonrepudiation; either side of the 332 exchange could plausibly deny that it took part in the exchange. 334 o Digital signature. Each device digitally signs a set of data and 335 sends it to the other party. This method is similar to the 336 public-key cryptography approach except that it provides 337 nonrepudiation. 339 Note that both digital signature and public-key cryptography require 340 the use of digital certificates to validate the public/private key 341 mapping. IKE allows the certificate to be accessed independently or 342 by having the two devices explicitly exchange certificates as part of 343 IKE. Both parties must have a shared session key to encrypt the IKE 344 tunnel. The Diffie-Hellman protocol is used to agree on a common 345 session key. 347 In Phase 2 of the process, IPsec SAs are negotiated on behalf of 348 services such as IPsec AH or ESP. IPsec uses a different shared key 349 than does IKE. The IPsec shared key can be derived by using 350 Diffie-Hellman again or by refreshing the shared secret derived from 351 the original Diffie-Hellman exchange that generated the IKE SA by 352 hashing it with nonces. After this step is complete, the IPsec SAs 353 are established. Now the data traffic can be exchanged with the 354 negotiated IPsec parameters. The completion of Phase 2 is called an 355 IPsec SA. 357 3. Document Scope 359 The primary focus of this document is to establish useful performance 360 testing terminology for IPsec devices that support IKEv1. We want to 361 constrain the terminology specified in this document to meet the 362 requirements of the Methodology for Benchmarking IPSec Devices 363 documented test methodologies. The testing will be constrained to 364 devices acting as IPsec gateways and will pertain to both IPsec 365 tunnel and transport mode. 367 Any testing involving interoperability and/or conformance issues, 368 L2TP, GRE, RFC 2547 (MPLS VPNs), multicast, and anything that does 369 not specifically relate to the establishment and tearing down of 370 IPsec tunnels is specifically out of scope. It is assumed that all 371 relevant networking parameters that facilitate in the running of 372 these tests are pre-configured (this includes at a minimum ARP caches 373 and routing tables). This document will encompass updates to AH, ESP 374 and NAT Traversal. Since NAT traversal has been included in the 375 document, NAT is not included in this document. 377 4. Definition Format 379 The definition format utilized by this document is described in 380 [RFC1242], Section 2. 382 Term to be defined. 384 Definition: 386 The specific definition for the term. 388 Discussion: 390 A brief discussion of the term, its application, or other 391 information that would build understanding. 393 Issues: 395 List of issues or conditions that affect this term. This field can 396 present items the may impact the term's related methodology or 397 otherwise restrict its measurement procedures. 399 [Measurement units:] 401 Units used to record measurements of this term. This field is 402 mandatory where applicable. This field is optional in this 403 document. 405 [See Also:] 407 List of other terms that are relevant to the discussion of this 408 term. This field is optional in this document. 410 5. Key Words to Reflect Requirements 412 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 413 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 414 document are to be interpreted as described in RFC 2119. RFC 2119 415 defines the use of these key words to help make the intent of 416 standards track documents as clear as possible. While this document 417 uses these keywords, this document is not a standards track document. 419 6. Existing Benchmark Definitions 421 It is recommended that readers consult [RFC1242], [RFC2544] and 422 [RFC2285] before making use of this document. These and other IETF 423 Benchmarking Methodology Working Group (BMWG) router and switch 424 documents contain several existing terms relevant to benchmarking the 425 performance of IPsec devices. The conceptual framework established in 426 these earlier RFCs will be evident in this document. 428 This document also draws on existing terminology defined in other 429 BMWG documents. Examples include, but are not limited to: 431 Throughput [RFC 1242, section 3.17] 432 Latency [RFC 1242, section 3.8] 433 Frame Loss Rate [RFC 1242, section 3.6] 434 Forwarding Rates [RFC 2285, section 3.6] 435 Loads [RFC 2285, section 3.5] 437 Note: "DUT/SUT" refers to a metric that may be applicable to a DUT 438 (Device Under Test) or an SUT (System Under Test). 440 7. Definitions 442 7.1 IPsec 444 Definition: 446 IPsec or IP Security protocol suite which comprises a set of 447 standards used to provide security services at the IP layer. 449 Discussion: 451 IPsec is a framework of protocols that offer authentication, 452 authenticity and encryption services to the IP and/or upper layer 453 protocols. The major components of the protocol suite are IKE, 454 used for key exchanges, and IPsec protocols such as AH and ESP, 455 which use the exchanged keys to protect payload traffic. 457 Issues: 459 N/A 461 See Also: 463 IPsec Device, IKE, ISAKMP, ESP, AH 465 7.2 ISAKMP 467 Definition: 469 The Internet Security Association and Key Management Protocol, 470 which provides a framework for authentication and key exchange but 471 does not define them. ISAKMP is designed to be key exchange 472 independent; it is designed to support many different key 473 exchanges. ISAKMP is defined in [RFC2407]. 475 Discussion: 477 Though ISAKMP is only a framework for the IPsec standard key 478 management protocol, it is often misused and interchanged with the 479 term 'IKE', which is an implementation of ISAKMP. 481 Issues: 483 When implementations refer to the term 'ISAKMP SA' it refers to an 484 IKE Phase 1 SA. 486 See Also: 488 IKE, Security Association 490 7.3 IKE 492 Definition: 494 A hybrid key management protocol that allows secure negotiation of 495 IPsec SA paramters. 497 Discussion: 499 A hybrid protocol, defined in [RFC2409], from the following 3 500 protocols: 502 * ISAKMP (Internet Security Association and Key Management 503 Protocol), which provides a framework for authentication and 504 key exchange but does not define them. ISAKMP is designed to be 505 key exchange independent; it is designed to support many 506 different key exchanges. 508 * Oakley, which describes a series of key exchanges, called 509 modes, and details the services provided by each (for example, 510 perfect forward secrecy for keys, identity protection, and 511 authentication). [RFC2412] 513 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 514 describes a versatile key exchange technique that provides 515 anonymity, reputability, and quick key refreshment. 517 Note that IKE is an optional protocol within the IPsec framework. 518 Tunnels may also be manually configured i.e. the administrator 519 will provide keys that will be associated with the Phase 2 SA's as 520 long as the IPsec Tunnel is configured. This method is the most 521 basic mechanism to establish an IPsec tunnel between two IPsec 522 devices but it also decreases the level of protection since the 523 keys are not changing as they normally would during an IKE phase 2 524 rekey which is controlled by the IKE protocol. 526 Issues: 528 During the first IPsec deployment experiences, ambiguities were 529 found in the IKEv1 specification, which lead to interoperability 530 problems. To resolve these issues, IKEv1 is being updated by 531 IKEv2. 533 See Also: 535 ISAKMP, IPsec, Security Association 537 7.3.1 IKE Phase 1 539 Definition: 541 The shared policy and key(s) used by negotiating peers to set up a 542 secure authenticated "control channel" for further IKE 543 communications. 545 Discussion: 547 Note that IKE is an optional protocol within the IPsec framework 548 and keys can also be manually configured. 550 Issues: 552 In other documents often referenced as ISAKMP SA or IKE SA. 554 See Also: 556 IKE, ISAKMP 558 7.3.2 Phase 1 Main Mode 560 Definition: 562 Main Mode is an instantiation of the ISAKMP Identity Protect 563 Exchange, defined in [RFC2409]. Upon successful completion it 564 results in the establishment of an IKE Phase 1 SA. 566 Discussion: 568 IKE Main Mode use 3 distinct message pairs, for a total of 6 569 messages. The first two messages negotiate policy; the next two 570 represent Diffie-Hellman public values and ancillary data (e.g. 571 nonces); and the last two messages authenticate the Diffie-Hellman 572 Exchange. The authentication method negotiated as part of the 573 initial IKE Phase 1 influence the composition of the payloads but 574 not their purpose. 576 Issues: 578 N/A 580 See Also: 582 ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 584 7.3.3 Phase 1 Aggressive Mode 586 Definition: 588 Aggressive Mode is an instantiation of the ISAKMP Aggressive 589 Exchange, defined in [RFC2409]. Upon successful completion it 590 results in the establishment of an IKE Phase 1 SA. 592 Discussion: 594 IKE Aggressive Mode uses 3 messages. The first two messages 595 negotiate policy, exchange Diffie-Hellman public values and 596 ancillary data necessary for the exchange, and identities. In 597 addition the second message authenticates the Responder. The third 598 message authenticates the Initiator and provides proof of 599 participation in the exchange. 601 Issues: 603 For IKEv1 the standard specifies that all implementations use both 604 main and agressive mode, however, it is common to use only main 605 mode. 607 See Also: 609 ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 611 7.3.4 IKE Phase 2 612 Definition: 614 ISAKMP phase which upon successful completion establishes the 615 shared keys used by the negotiating peers to set up a secure "data 616 channel" for IPsec. 618 Discussion: 620 The main purpose of Phase 2 is to produce the key for the IPsec 621 tunnel. Phase 2 is also used to regenerate the key being used for 622 IPsec (called "rekeying"), as well as for exchanging informational 623 messages. 625 Issues: 627 In other documents also referenced as IPsec SA. 629 See Also: 631 IKE Phase 1, ISAKMP, IKE 633 7.3.5 Phase 2 Quick Mode 635 Definition: 637 Quick Mode is an instanciation of IKE Phase 2. After successful 638 completion it will result in one or typically two or more IPsec 639 SA's 641 Discussion: 643 Quick Mode is not a complete exchange itself (it is bound to a 644 phase 1 exchange), but is used as part of the SA negotiation 645 process (phase 2) to derive keying material and negotiate shared 646 policy for non-ISAKMP SA's. The ISAKMP SA protects the information 647 exchanged along with Quick Mode, i.e. all payloads except the 648 ISAKMP header are encrypted. Also, an optional Key Exchange 649 payload can be exchanged to allow for an additional Diffie-Hellman 650 exchange, PFS and exponentiation per Quick Mode. 652 Issues: 654 N/A 656 See Also: 658 ISAKMP, IKE, IKE Phase 2 660 7.4 Security Association (SA) 662 Definition: 664 A simplex (unidirectional) logical connection that links a traffic 665 flow to a set of security parameters. All traffic traversing an SA 666 is provided the same security processing and will be subjected to 667 a common set of encryption and/or authentication algorithms. In 668 IPsec, an SA is an Internet layer abstraction implemented through 669 the use of AH or ESP as defined in [RFC2401]. 671 Discussion: 673 A set of policy and key(s) used to protect information. It is a 674 negotiation agreement between two IPsec devices, specifically the 675 Initiator and Responder. 677 Issues: 679 N/A 681 See Also: 683 Initiator, Responder 685 7.5 Selectors 687 Definition: 689 A mechanism used for the classification of traffic flows that 690 require encryption and/or authentication services. 692 Discussion: 694 The selectors are a set of fields that will be extracted from the 695 network and transport layer headers that provide the ability to 696 classify the traffic flow and associate it with an SA. 698 After classification, a decision can be made if the traffic needs 699 to be encrypted/decrypted and how this should be done depending on 700 the SA linked to the traffic flow. Simply put, selectors classify 701 IP packets that require IPsec processing and those packets that 702 must be passed along without any intervention of the IPsec 703 framework. 705 Selectors are flexible objects that can match on ranges of source 706 and destination addresses and ranges of source and destination 707 ports. 709 Issues: 711 Both sides must agree exactly on both the networks being 712 protected, and they both must agree on how to describe the 713 networks (range, subnet, addresses). This is a common point of 714 non-interoperability. 716 7.6 IPsec Device 718 Definition: 720 Any implementation that has the ability to process data flows 721 according to the IPsec protocol suite specifications. 723 Discussion: 725 Implementations can be grouped by 'external' properties (e.g. 726 software vs. hardware implementations) but more important is the 727 subtle differences that implementations may have with relation to 728 the IPsec Protocol Suite. Not all implementations will cover all 729 RFC's that encompass the IPsec Protocol Suite, but the majority 730 will support a large subset of features described in the suite, 731 nor will all implementations utilize all of the cryptographic 732 functions listed in the RFCs. 734 In that context, any implementation, that supports basic IP layer 735 security services as described in the IPsec protocol suite shall 736 be called an IPsec Device. 738 Issues: 740 Due to the fragmented nature of the IPsec Protocol Suite RFC's, it 741 is possible that IPsec implementations will not be able to 742 interoperate. Therefore it is important to know which features and 743 options are implemented in the IPsec Device. 745 See Also: 747 IPsec 749 7.6.1 Initiator 751 Definition: 753 An IPsec devices which starts the negotiation of IKE Phase 1 and 754 Phase 2 tunnels. 756 Discussion: 758 When a traffic flow is offered at an IPSec device and it is 759 determined that the flow must be protected, but there is no IPsec 760 tunnel to send the traffic through, it is the responsibility of 761 the IPsec device to start a negotiation process that will 762 instantiate the IPsec tunnel. This process will establish an IKE 763 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 764 eventually resulting in secured data transport. The device that 765 takes the action to start this negotiation process will be called 766 an Initiator. 768 Issues: 770 IPsec devices/implementations can always be both an initiator as 771 well as a responder. The distinction is useful from a test 772 perspective. 774 See Also: 776 Responder, IKE, IPsec 778 7.6.2 Responder 780 Definition: 782 An IPsec devices which replies to incoming IKE Phase 1 and Phase 2 783 tunnel requests and process these messages in order to establish a 784 tunnel. 786 Discussion: 788 When an initiator attempts to establish SAs with another IPsec 789 device, this peer will need to evaluate the proposals made by the 790 initiator and either accept or deny them. In the former case, the 791 traffic flow will be decrypted according to the negotiated 792 parameters. Such a device will be called a Responder. 794 Issues: 796 IPsec devices/implementations can usually be both an initiator as 797 well as a responder. The distinction is useful from a test 798 perspective. 800 See Also: 802 Initiator, IKE 804 7.6.3 IPsec Client 806 Definition: 808 IPsec Devices that will only act as an Initiator. 810 Discussion: 812 In some situations it is not needed or prefered to have an IPsec 813 device respond to an inbound tunnel request. In the case of e.g. 814 road warriors or home office scenarios the only property needed 815 from the IPsec device is the ability to securely connect to a 816 remote private network. The IPsec Client will set up one or more 817 Tunnels to an IPSec Server on the network that needs to be 818 accessed and to provide the required security services. An IPsec 819 client will silently drop and ignore any inbound tunnel requests. 820 IPsec clients are generally used to connect remote users in a 821 secure fashion over the Internet to a private network. 823 Issues: 825 N/A 827 See Also: 829 IPsec device, IPsec Server, Initiator, Responder 831 7.6.4 IPsec Server 833 Definition: 835 IPSec Devices that can both act as an Initiator as well as a 836 Responder. 838 Discussion: 840 IPSec Servers are mostly positioned at private network edges and 841 provide several functions : 843 Responds to tunnel setup request from IPSec Clients. 845 Responds to tunnel setup request from other IPSec devices/ 846 Initiators. 848 Initiate tunnels to other IPSec servers inside or outside the 849 private network. 851 Issues: 853 IPsec Servers are also sometimes referred to as 'VPN 854 Concentrators'. 856 See Also: 858 IPsec Device, IPsec Client, Initiator, Responder 860 7.7 Tunnels 862 The term "tunnel" is often used in a variety of contexts. To avoid 863 any discrepancies, in this document, the following distinctions have 864 been defined : 866 7.7.1 IKE Tunnel 868 Definition: 870 One simplex Phase 1 IKE SA 872 Discussion: 874 An IKE Tunnel between IPSec devices facilitates a mechanism for 875 secure negotiation of Phase 1 properties and Phase 2 SA's needed 876 for protected data transport. The initiator may choose which mode 877 to start the negotiation of the IKE Tunnel in. This can be either 878 main mode or aggressive mode. 880 Issues: 882 Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel. 884 See Also: 886 Tunnel, IPsec Tunnel, Security Association, IKE, IKE Phase 1 888 7.7.2 IPsec Tunnel 890 Definition: 892 One or more Phase 2 SA's that are negotiated in conjuntion with an 893 IKE Tunnel. 895 Discussion: 897 In the case of simplex communication, a single phase 2 SA. 899 In the more likely case where bidirectional communication is 900 needed it is a pair (2) of Phase 2 SA's. The two SA's are used to 901 secure inbound and outbound traffic. 903 Not in all situations is it required to have an existing IKE 904 Tunnel in order to negotiate IPsec Tunnel properties and 905 parameters. Manually keyed tunnels allow the set up of IPsec 906 Tunnels without the need of the IKE protocol. 908 Issues: 910 Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be 911 multiple). 913 See Also: 915 Tunnel, IKE Tunnel, Security Association, IKE, IKE Phase 2 917 7.7.3 Tunnel 919 Definition: 921 The combination of an IKE Tunnel and an IPsec Tunnel 923 Discussion: 925 In the majority of the cases IPsec is used to protect 926 bidirectional traffic flows. Unless stated otherwise a 'Tunnel' 927 will be defined as a single Phase 1 SA and two Phase 2 SA's that 928 are associated with the Phase 1 SA. 930 Issues: 932 If only a single Phase 2 SA or more then two Phase 2 SA's have 933 been negotiated through a single IKE Tunnel, then this specific 934 ratio must be mentioned and the term 'Tunnel' MUST NOT be used in 935 this context. 937 See Also: 939 IKE Tunnel, IPsec Tunnel 941 7.7.4 Configured Tunnel 943 Definition: 945 A tunnel that is present in the IPSec device's configuration but 946 does not have any entries in the SAD i.e. SA's. 948 Discussion: 950 Several steps are required before a Tunnel can be used to actually 951 transport traffic. The very first step is to configure the tunnel 952 in the IPsec device. In that way packet classification can make a 953 decision if it is required to start negotiating SA's. At this time 954 there are no SA's associated with the Tunnel and no traffic is 955 going through the IPsec device that matches the Selectors, which 956 would instantiate the Tunnel. 958 A Configured Tunnel is also a tunnel that has relinquished all 959 it's SA's and is not transmitting data anymore. To be more 960 specific, when an Established or an Active Tunnel is terminated 961 due to either an administrative action or an IKE event that teared 962 down the tunnel, the tunnel will be back in a solely configured 963 state. 965 Issues: 967 N/A 969 See Also: 971 Tunnel, Established Tunnel, Active Tunnel 973 7.7.5 Established Tunnel 974 Definition: 976 A Tunnel that has completed Phase 1 and Phase 2 SA negotiations 977 but is otherwise idle. 979 Discussion: 981 A second step needed to ensure that a Tunnel can transport data is 982 to complete the Phase 1 and Phase 2 negotiations. After the packet 983 classification process has asserted that a packet requires 984 security services, the negotation is started to obtain both Phase 985 1 and Phase 2 SA's. After this is completed the tunnel is called 986 'Established'. Note that at this time there is still no traffic 987 flowing through the Tunnel. Just enough packet(s) have been sent 988 to the IPsec device that matched the selectors and triggered the 989 Tunnel setup. This may also be acomplished by an administrative 990 command to connect the Tunnel, in which case the Tunnel is not 991 triggered by any positive packet classification. 993 Issues: 995 In the case of manually keyed tunnels, there is no distinction 996 between a Configured Tunnel or an Established Tunnel since there 997 is no negotiation required with these type of Tunnels and the 998 Tunnel is Established at time of Configuration since all keying 999 information is known at that point. 1001 See Also: 1003 Tunnel, Configured Tunnel, Active Tunnel 1005 7.7.6 Active Tunnel 1007 Definition: 1009 A tunnel that has completed Phase 1 and Phase 2 SA negotiations 1010 and is transmitting data. 1012 Discussion: 1014 When a Tunnel is Established and it is transporting traffic, the 1015 tunnel is called 'Active'. 1017 Issues: 1019 The distinction between an Active Tunnel and Configured/ 1020 Established Tunnel is made in the context of manual keyed Tunnels. 1021 In this case it would be possible to have an Established tunnel on 1022 an IPsec device which has no counterpart on it's corresponding 1023 peer. This will lead to encrypted traffic flows which will be 1024 discarded on the receiving peer. Only if both peers have an 1025 Established Tunnel that shows evidence of traffic transport, it 1026 may be called an Active Tunnel. 1028 See Also: 1030 Tunnel, Configured Tunnel, Established Tunnel 1032 7.8 Iterated Tunnels 1034 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 1035 The bundles are divided into two major groups : 1037 7.8.1 Nested Tunnels 1039 Definition: 1041 An SA bundle consisting of two or more 'tunnel mode' SA's. 1043 Discussion: 1045 The process of nesting tunnels can theoretically be repeated 1046 multiple times (for example, tunnels can be many levels deep), but 1047 for all practical purposes, most implementations limit the level 1048 of nesting. Nested tunnels can use a mix of AH and ESP 1049 encapsulated traffic. 1051 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1052 | | | | 1053 | | | | 1054 | +----{SA1 (ESP tunnel)}----+ | 1055 | | 1056 +--------------{SA2 (AH tunnel)}---------------+ 1058 In the IP Cloud a packet would have a format like this : 1059 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 1061 Nested tunnels can be deployed to provide additional security on 1062 already secured traffic. A typical example of this would be that 1063 the inner gateways (GW2 and GW3) are securing traffic between two 1064 branch offices and the outer gateways (GW1 & GW4) add an 1065 additional layer of security between departments within those 1066 branch offices. 1068 Issues: 1070 N/A 1072 See Also: 1074 Transport Adjacency, IPsec Tunnel 1076 7.8.2 Transport Adjacency 1078 Definition: 1080 An SA bundle consisting of two or more transport mode SA's. 1082 Discussion: 1084 Transport adjacency is a form of tunnel nesting. In this case two 1085 or more transport mode IPsec tunnels are set side by side to 1086 enhance applied security properties. 1088 Transport adjacency can be used with a mix of AH and ESP tunnels 1089 although some combinations are not preferred. If AH and ESP are 1090 mixed, the ESP tunnel should always encapsulate the AH tunnel. The 1091 reverse combination is a valid combination but doesn't make 1092 cryptographical sense. 1094 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 1095 | | | | 1096 | | | | 1097 | +------{SA1 (ESP transport)}--------+ | 1098 | | 1099 +-------------{SA2 (AH transport)}--------------+ 1101 In the IP Cloud a packet would have a format like this : 1102 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 1104 Issues: 1106 This is rarely used. 1108 See Also: 1110 Nested Tunnels, IPsec Tunnel 1112 7.9 Transform protocols 1114 Definition: 1116 Encryption and authentication algorithms that provide 1117 cryptograhical services to the IPsec Protocols. 1119 Discussion: 1121 Some algorithms run significantly slower than others. For example, 1122 TripleDES encryption is one third as fast as DES encryption. 1124 Issues: 1126 N/A 1128 See Also: 1130 Authentication protocols, Encryption protocols 1132 7.9.1 Authentication Protocols 1134 Definition: 1136 Algorithms which provide data integrity and data source 1137 authentication. 1139 Discussion: 1141 Authentication protocols provide no confidentiality. Commonly used 1142 authentication algorithms/protocols are: 1144 * MD5-HMAC 1145 * SHA-HMAC 1146 * AES-HMAC 1148 Issues: 1150 SHA-HMAC is thought to be more secure than MD5-HMAC and is often 1151 used. AES-HMAC is still fairly new and not in common use yet. 1153 See Also: 1155 Transform protocols, Encryption protocols 1157 7.9.2 Encryption Protocols 1159 Definition: 1161 Algorithms which provide data confidentiality. 1163 Discussion: 1165 Encryption protocols provide no authentication. Commonly used 1166 encryption algorithms/protocols are: 1168 * NULL encryption 1169 * DES-CBC 1170 * 3DES-CBC 1171 * AES-CBC 1173 Issues: 1175 Null option is a valid encryption mechanism although it reverts to 1176 use of IPsec back to message authenticity but only for upper layer 1177 protocols, and is commonly used. 1179 DES has been officially deprecated by NIST, though it is still 1180 mandated RFC and is still commonly implemented and used due to 1181 it's speed advantage over 3DES. 1183 See Also: 1185 Transform protocols, Authentication protocols 1187 7.10 IPSec Protocols 1189 Definition: 1191 A suite of protocols which provide a framework of open standards 1192 that provides data confidentiality, data integrity, and data 1193 authenticity between participating peers at the IP layer. The 1194 IPsec protocol suite set of standards is documented in RFC's 2401 1195 through 2412 and RFC 2451. 1197 Discussion: 1199 The IPsec Protocol suite is modular and forward compatible. The 1200 protocols that comprise the IPsec protocol suite can be replaced 1201 with new versions of those protocols as the older versions become 1202 obsolete. For example, IKEv2 will soon replace IKEv1. 1204 Issues: 1206 N/A 1208 See Also: 1210 AH, ESP 1212 7.10.1 Authentication Header (AH) 1214 Definition: 1216 Provides authentication and data integrity (including replay 1217 protection) security services [RFC2402]. 1219 Discussion: 1221 The AH protocol supports both modes of operation; tunnel mode and 1222 transport mode. If AH is employed in tunnel mode, portions of the 1223 outer IP header are given protection, as well as all of the 1224 tunneled IP packet (that is, all of the inner IP header is 1225 protected as are the higher-layer protocols). In the case of AH in 1226 transport mode, all upper-layer information is protected, and all 1227 fields in the IPv4 header excluding the fields typically are 1228 modified in transit. 1230 Original IPv4 packet : 1231 [IP ORIG][L4 HDR][PAYLOAD] 1232 In transport mode : 1233 [IP ORIG][AH][L4 HDR][PAYLOAD] 1234 In tunnel mode : 1235 [IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD] 1237 Issues: 1239 AH is rarely used/implemented. 1241 See Also: 1243 Transform protocols, IPsec protocols, Encapsulated Security 1244 Payload 1246 7.10.2 Encapsulated Security Payload (ESP) 1248 Definition: 1250 Provides three essential components needed for secure data 1251 exchange: authentication, integrity (including replay protection) 1252 and confidentiality as defined in [RFC2406]. 1254 Discussion: 1256 The ESP protocol supports both modes of operation i.e. tunnel mode 1257 and transport mode. If ESP is employed in tunnel mode, the 1258 protection is afforded only to the tunneled packet, not to the 1259 outer header. In the case of ESP in transport mode, security 1260 services are provided only for the higher-layer protocols, not for 1261 the IP header. 1263 Original IPv4 packet : 1264 [IP ORIG][L4 HDR][PAYLOAD] 1265 In transport mode : 1266 [IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] 1267 In tunnel mode : 1268 [IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] 1270 Issues: 1272 N/A 1274 See Also: 1276 Transform protocols, IPsec protocols, Authentication Header 1278 7.11 NAT Traversal (NAT-T) 1280 Definition: 1282 The capability to support IPsec functionality in the presence of 1283 NAT devices. 1285 Discussion: 1287 NAT-Traversal requires some modifications to IKE as defined in 1288 [I-D.ietf-ipsec-nat-t-ike]. Specifically, in phase 1, it requires 1289 detecting if the other end supports NAT-Traversal, and detecting 1290 if there are one or more NAT instances along the path from host to 1291 host. In IKE Quick Mode, there is a need to negotiate the use of 1292 UDP encapsulated IPsec packets. 1294 NAT-T also describes how to transmit the original source and 1295 destination addresses to the corresponding IPsec Device. The 1296 original source and destination addresses are used in transport 1297 mode to incrementally update the TCP/IP checksums so that they 1298 will match after the NAT transform (The NAT cannot do this, 1299 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1300 packet). 1302 Issues: 1304 N/A 1306 See Also: 1308 IKE 1310 7.12 IP Compression 1312 Definition: 1314 A mechanism as defined in [RFC2393] that reduces the size of the 1315 payload that needs to be encrypted. 1317 Discussion: 1319 IP payload compression is a protocol to reduce the size of IP 1320 datagrams. This protocol will increase the overall communication 1321 performance between a pair of communicating hosts/gateways 1322 ("nodes") by compressing the datagrams, provided the nodes have 1323 sufficient computation power, through either CPU capacity or a 1324 compression coprocessor, and the communication is over slow or 1325 congested links. 1327 IP payload compression is especially useful when encryption is 1328 applied to IP datagrams. Encrypting the IP datagram causes the 1329 data to be random in nature, rendering compression at lower 1330 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1331 ineffective. If both compression and encryption are required, 1332 compression must be applied before encryption. 1334 Issues: 1336 N/A 1338 7.13 Security Context 1340 Definition: 1342 A security context is a collection of security parameters that 1343 describe the characteristics of the path that a tunnel will take, 1344 all of the tunnel parameters and the effects it has on the 1345 underlying protected traffic. Security Context encompasses 1346 protocol suite and security policy(ies). 1348 Discussion: 1350 In order to fairly compare multiple IPsec devices it is imperative 1351 that an accurate overview is given of all security parameters that 1352 were used to establish tunnels and to secure the traffic between 1353 protected networks. Security Context is not a metric; it is 1354 included to accurately reflect the test environment variables when 1355 reporting the methodology results. To avoid listing too much 1356 information when reporting metrics, we have divided the security 1357 context into an IKE context and an IPsec context. 1359 When merely discussing the behavior of traffic flows through IPsec 1360 devices, an IPsec context MUST be provided. In other cases the 1361 scope of a discussion or report may focus on a more broad set of 1362 behavioral characteristics of the IPsec device, the both and IPsec 1363 and an IKE context MUST be provided. 1365 The IPsec context MUST consist of the following elements: 1367 * Number of IPsec tunnels 1369 * IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio) 1371 * IPsec protocol 1373 * IPsec mode (tunnel or transport) 1375 * Authentication protocol used by IPsec 1377 * Encryption protocol used by IPsec (if applicable) 1379 * IPsec SA lifetime (traffic and time based) 1380 The IPsec Context MAY also list: 1382 * Selectors 1384 * Fragmentation handling 1386 The IKE Context MUST consist of the following elements: 1388 * Number of IKE tunnels. 1390 * Authentication protocol used by IKE 1392 * Encryption protocol used by IKE 1394 * Key exchange mechanism (pre-shared key, certificate authority, 1395 etc ...) 1397 * Key size (if applicable) 1399 * Diffie-Hellman group 1401 * IKE SA lifetime (time based) 1403 * Keepalive, heartbeat or DPD values [DPD] 1405 * IP Compression [RFC2393] 1407 * PFS Diffie-Hellman group 1409 The IKE context MAY also list: 1411 * Phase 1 mode (main or aggressive) 1413 * Available bandwidth and latency to Certificate Authority server 1414 (if applicable) 1416 Issues: 1418 A Security Context will be an important element in describing the 1419 environment where protected traffic is traveling through. 1421 See Also: 1423 IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, 1424 Selectors, IPsec Tunnel 1426 8. Framesizes 1428 8.1 Layer3 clear framesize 1430 Definition: 1432 The total size of the unencrypted L3 PDU. 1434 Discussion: 1436 In relation to IPsec this is the size of the IP header and it�s 1437 payload. It SHALL NOT include any encapsulations that MAY be 1438 applied before the PDU is processed for encryption. 1440 For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload. 1442 Measurement Units: 1444 Bytes 1446 Issues: 1448 N/A 1450 See Also: 1452 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1453 Encrypted Framesize. 1455 8.2 Layer3 encrypted framesize 1457 Definition: 1459 The total size of the encrypted L3 PDU. 1461 Discussion: 1463 The size of the IP packet and it�s payload after encapsulations 1464 MAY be applied and the PDU is being processed by the transform. 1466 For example, after a tunnel mode ESP 3DES/SHA1 transform has been 1467 applied an unencrypted or clear layer3 framesize of 46 bytes 1468 Becomes 96 bytes: 1470 20 bytes outer IP header (tunnel mode) 1471 4 bytes SPI (ESP header) 1472 4 bytes Sequence (ESP Header) 1473 8 bytes IV (IOS ESP-3DES) 1474 46 bytes payload 1475 0 bytes pad (ESP-3DES 64 bit) 1476 1 byte Pad length (ESP Trailer) 1477 1 byte Next Header (ESP Trailer) 1478 12 bytes ESP-HMAC SHA1 96 digest 1480 Measurement Units: 1482 Bytes 1484 Issues: 1486 N/A 1488 See Also: 1490 Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted 1491 Framesize. 1493 8.3 Layer2 clear framesize 1495 Definition: 1497 The total size of the unencrypted L2 PDU. 1499 Discussion: 1501 This is the Layer 3 clear framesize plus all the layer2 overhead. 1502 In the case of Ethernet this would be 18 bytes. 1504 For example, a 46 byte Layer3 clear framesize packet would become 1505 64 Bytes after Ethernet Layer2 overhead is added: 1507 6 bytes destination mac address 1508 6 bytes source mac address 1509 2 bytes length/type field 1510 46 bytes layer3 (IP) payload 1511 4 bytes FCS 1513 Measurement Units: 1515 Bytes 1517 Issues: 1519 If it is not mentioned explicitly what kind of framesize is used, 1520 the layer2 clear framesize will be the default. 1522 See Also: 1524 Layer3 clear framesize, Layer2 encrypted framesize, Layer2 1525 encrypted framesize. 1527 8.4 Layer2 encrypted framesize 1529 Definition: 1531 The total size of the encrypted L2 PDU. 1533 Discussion: 1535 This is the Layer 3 encrypted framesize plus all the layer2 1536 overhead. In the case of Ethernet this would be 18 bytes. 1538 For example, a 96 byte Layer3 encrypted framesize packet would 1539 become 114 bytes after Ethernet Layer2 overhead is added: 1541 6 bytes destination mac address 1542 6 bytes source mac address 1543 2 bytes length/type field 1544 96 bytes layer3 (IPsec) payload 1545 4 bytes FCS 1547 Measurement Units: 1549 Bytes 1551 Issues: 1553 N/A 1555 See Also: 1557 Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear 1558 Framesize 1560 9. Performance Metrics 1562 9.1 Tunnels Per Second (TPS) 1564 Definition: 1566 The measurement unit for the Tunnel Setup Rate tests. The rate 1567 that Tunnels are established per second. 1569 Discussion: 1571 According to [RFC2401] two tunnels cannot be established between 1572 the same gateways with the same selectors. This is to prevent 1573 overlapping tunnels. If overlapping tunnels are attempted, the 1574 error will take longer than if the tunnel setup was successful. 1575 For this reason, a unique pair of selector sets are required for 1576 TPS testing. 1578 Issues: 1580 A unique pair of selector sets are required for TPS testing. 1582 See Also: 1584 Tunnel Setup Rate Behavior, Tunnel Setup Rate, IKE Setup Rate, 1585 IPsec Setup Rate 1587 9.2 Tunnel Rekeys Per Seconds (TRPS) 1589 Definition: 1591 A metric that quantifies the number of IKE or IPsec Tunnel rekey's 1592 per seconds a DUT can correctly process. 1594 Discussion: 1596 This metric will be will be primary used with Tunnel Rekey 1597 behavior tests. 1599 TRPS will provide a metric used to see system behavior under 1600 stressful conditions where large volumes of tunnels are being 1601 rekeyed at the same time or in a short timespan. 1603 Issues: 1605 N/A 1607 See Also: 1609 Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate 1611 9.3 Tunnel Attempts Per Second (TAPS) 1613 Definition: 1615 A metric that quantifies the number of successful and unsuccessful 1616 tunnel (both Phase 1 or Phase 2) establishment requests per 1617 second. 1619 Discussion: 1621 This metric can be used to measure IKE DOS Resilience behavior 1622 test. 1624 TAPS provides an important metric to validate the stability of a 1625 platform, if stressed with valid (large number of IPsec tunnel 1626 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1627 any style) tunnel establishment requests. 1629 Issues: 1631 If the TAPS increases, the TPS usually decreases, due to burdening 1632 of the DUT with the DOS attack traffic. 1634 10. Test Definitions 1636 10.1 Throughput 1638 10.1.1 Tunnel Throughput 1640 Definition: 1642 The maximum rate through an IPsec tunnel at which none of the 1643 offered frames are dropped by the device under test. 1645 Discussion: 1647 The IPsec Tunnel Throughput is almost identically defined as 1648 Throughput in [RFC1242], section 3.17. The only difference is that 1649 the throughput is measured with a traffic flow getting encrypted 1650 and decrypted by an IPsec device. IPsec Tunnel Throughput is an 1651 end-to-end measurement. 1653 The metric can be represented in two variantions depending on 1654 where measurement is taken in the SUT. One can look at throughput 1655 from a cleartext point of view i.e. find the maximum rate where 1656 clearpackets no longer get dropped. This resulting rate can be 1657 recalculated with an encrypted framesize to represent the 1658 encryption throughput rate. The latter is the preferred method of 1659 representation. 1661 Measurement Units: 1663 Packets per seconds (pps), Mbps 1665 Issues: 1667 N/A 1669 See Also: 1671 IPsec Encryption Throughput, IPsec Decryption Throughput 1673 10.1.2 IPsec Encryption Throughput 1675 Definition: 1677 The maximum encryption rate through an IPsec tunnel at which none 1678 of the offered cleartext frames are dropped by the device under 1679 test. 1681 Discussion: 1683 Since encryption throughput is not necessarily equal to the 1684 decryption throughput, both of the forwarding rates must be 1685 measured independently. The independent forwarding rates have to 1686 measured with the help of an IPsec aware test device that can 1687 originate and terminate IPsec and IKE tunnels. As defined in 1688 [RFC1242], measurements should be taken with an assortment of 1689 frame sizes. 1691 Measurement Units: 1693 Packets per seconds (pps), Mbps 1695 Issues: 1697 N/A 1699 See Also: 1701 IPsec Tunnel Throughput, IPsec Decryption Throughput 1703 10.1.3 IPsec Decryption Throughput 1705 Definition: 1707 The maximum decryption rate through an IPsec tunnel at which none 1708 of the offered encrypted frames are dropped by the device under 1709 test. 1711 Discussion: 1713 Since encryption throughput is not necessarily equal to the 1714 decryption throughput, both of the forwarding rates must be 1715 measured independently. 1717 The independent forwarding rates have to be measured with the help 1718 of an IPsec aware test device that can originate and terminate 1719 IPsec and IKE tunnels. As defined in [RFC1242], measurements 1720 should be taken with an assortment of frame sizes. 1722 Measurement Units: 1724 Packets per seconds (pps), Mbps 1726 Issues: 1728 Recommended test frame sizes will be addressed in future 1729 methodology document. 1731 See Also: 1733 IPsec Tunnel Throughput, IPsec Encryption Throughput 1735 10.2 Latency 1737 10.2.1 Tunnel Latency 1739 Definition: 1741 Time required to propagate a cleartext frame from the input 1742 interface of an initiator, through an IPsec Tunnel, to the output 1743 interface of the responder. 1745 Discussion: 1747 The Tunnel Latency is the time interval starting when the end of 1748 the first bit of the cleartext frame reaches the input interface 1749 of the initiator and ending when the start of the first bit of the 1750 same cleartext frame is detected on the output interface of the 1751 responder. The frame has passed through an IPsec Tunnel between an 1752 initiator and a responder and has been through an encryption and 1753 decryption cycle. 1755 Measurement Units: 1757 Time units with enough precision to reflect latency measurement. 1759 Issues: 1761 N/A 1763 See Also: 1765 IPsec Tunnel Encryption Latency, IPsec Tunnel Decryption Latency 1767 10.2.2 IPsec Tunnel Encryption Latency 1769 Definition: 1771 The IPsec Tunnel Encryption Latency is the time interval starting 1772 when the end of the first bit of the cleartext frame reaches the 1773 input interface, through an IPsec tunnel, and ending when the 1774 start of the first bit of the encrypted output frame is seen on 1775 the output interface. 1777 Discussion: 1779 IPsec Tunnel Encryption latency is the latency introduced when 1780 encrypting traffic through an IPsec tunnel. 1782 Like encryption/decryption throughput, it is not always the case 1783 that encryption latency equals the decryption latency. Therefore a 1784 distinction between the two has to be made in order to get a more 1785 accurate view of where the latency is the most pronounced. 1787 The independent encryption/decryption latencies have to be 1788 measured with the help of an IPsec aware test device that can 1789 originate and terminate IPsec and IKE tunnels. As defined in 1790 [RFC1242], measurements should be taken with an assortment of 1791 frame sizes. 1793 Measurement Units: 1795 Time units with enough precision to reflect latency measurement. 1797 Issues: 1799 N/A 1801 See Also: 1803 IPsec Tunnel Latency, IPsec Tunnel Decryption Latency 1805 10.2.3 IPsec Tunnel Decryption Latency 1807 Definition: 1809 The IPsec Tunnel decryption Latency is the time interval starting 1810 when the end of the first bit of the encrypted frame reaches the 1811 input interface, through an IPsec tunnel, and ending when the 1812 start of the first bit of the decrypted output frame is seen on 1813 the output interface. 1815 Discussion: 1817 IPsec Tunnel decryption latency is the latency introduced when 1818 decrypting traffic through an IPsec tunnel. Like encryption/ 1819 decryption throughput, it is not always the case that encryption 1820 latency equals the decryption latency. Therefore a distinction 1821 between the two has to be made in order to get a more accurate 1822 view of where the latency is the most pronounced. 1824 The independent encryption/decryption latencies have to be 1825 measured with the help of an IPsec aware test device that can 1826 originate and terminate IPsec and IKE tunnels. As defined in 1827 [RFC1242], measurements should be taken with an assortment of 1828 frame sizes. 1830 Measurement Units: 1832 Time units with enough precision to reflect latency measurement. 1834 Issues: 1836 N/A 1838 See Also: 1840 IPsec Tunnel Latency, IPsec Tunnel Encryption Latency 1842 10.2.4 Time To First Packet 1844 Definition: 1846 The Time To First Packet (TTFP) is the time required process an 1847 cleartext packet when no tunnel is present. 1849 Discussion: 1851 The TTFP addresses the issue of responsiveness of an IPsec device 1852 by looking how long it take to transmit a packet over a not yet 1853 established tunnel path. The TTFP MUST include the time to set up 1854 the tunnel, triggered by the traffic flow (both phase 1 and phase 1855 2 setup times are included) and the time it takes to encrypt and 1856 decrypt the packet on a corresponding peer. 1858 It must be noted that it is highly unlikely that the first packet 1859 of the traffic flow will be the packet that will be used to 1860 measure the TTFP. There MAY be several protocol layers in the 1861 stack before the tunnel is formed and the traffic is forwarded, 1862 hence several packets COULD be lost during negotiation, for 1863 example, ARP and/or IKE. 1865 Measurement Units: 1867 Time units with enough precision to reflect a TTFP measurement. 1869 Issues: 1871 N/A 1873 10.3 Frame Loss Rate 1875 10.3.1 IPSec Tunnel Frame Loss Rate 1876 Definition: 1878 Percentage of cleartext frames that should have been forwarded 1879 through a Tunnel under steady state (constant) load but were 1880 dropped before encryption or after decryption. 1882 Discussion: 1884 The IPsec Tunnel Frame Loss Rate is almost identically defined as 1885 Frame Loss Rate in [RFC1242], section 3.6. The only difference is 1886 that the IPsec Tunnel Frame Loss Rate is measured with a traffic 1887 flow getting encrypted and decrypted by an IPsec device. IPsec 1888 Tunnel Frame Loss Rate is an end-to-end measurement. 1890 Measurement Units: 1892 Percent (%) 1894 Issues: 1896 N/A 1898 See Also: 1900 IPsec Tunnel Encryption Frame Loss Rate, IPsec Tunnel Decryption 1901 Frame Loss Rate 1903 10.3.2 IPsec Tunnel Encryption Frame Loss Rate 1905 Definition: 1907 Percentage of cleartext frames that should have been encrypted 1908 through an IPsec tunnel under steady state (constant) load but 1909 were dropped. 1911 Discussion: 1913 DUT's will always have an inherent forwarding limitation. This 1914 will be more pronounced when IPsec is employed on the DUT. The 1915 moment that a Tunnel is established and traffic is offered at a 1916 given rate that will flow through that tunnel, there is a 1917 possibility that the offered traffic rate at the tunnel is too 1918 high to be transported through the IPsec tunnel and not all 1919 cleartext packets will get encrypted. In that case, some 1920 percentage of the cleartext traffic will be dropped. This drop 1921 percentage is called the IPsec Tunnel Encryption Frame Loss Rate. 1923 Measurement Units: 1925 Percent (%) 1927 Issues: 1929 N/A 1931 See Also: 1933 IPsec Tunnel Frame Loss Rate, IPsec Tunnel Decryption Frame Loss 1934 Rate 1936 10.3.3 IPsec Tunnel Decryption Frame Loss Rate 1938 Definition: 1940 Percentage of encrypted frames that should have been decrypted 1941 through an IPsec tunnel under steady state (constant) load but 1942 were dropped. 1944 Discussion: 1946 A DUT will also have an inherent forwarding limitation when 1947 decrypting packets. When established tunnel encrypted traffic is 1948 offered at a costant load, there might be a possibility that the 1949 IPsec Device that needs to decrypt the traffic will not be able to 1950 perfom this action on all of the packets due to limitations of the 1951 decryption performance. The percentage of encrypted frames that 1952 would get dropped under these conditions is called the IPsec 1953 Tunnel Decryption Frame Loss Rate. 1955 Measurement Units: 1957 Percent (%) 1959 Issues: 1961 N/A 1963 See Also: 1965 IPsec Tunnel Frame Loss Rate, IPsec Tunnel Encryption Frame Loss 1966 Rate 1968 10.4 Back-to-back Frames 1970 10.4.1 Tunnel Back-to-back Frames 1972 Definition: 1974 A burst of cleartext frames, offered at a constant load that can 1975 be sent through an IPsec tunnel without losing a single cleartext 1976 frame after decryption. 1978 Discussion: 1980 The Tunnel Back-to-back Frames is almost identically defined as 1981 Back-to-back in [RFC1242], section 3.1. The only difference is 1982 that the Tunnel Back-to-back Frames is measured with a traffic 1983 flow getting encrypted and decrypted by an IPsec device. Tunnel 1984 Back-to-back Frames is an end-to-end measurement. 1986 Measurement Units: 1988 Number of N-octet frames in burst. 1990 Issues: 1992 Recommended test frame sizes will be addressed in future 1993 methodology document. 1995 See Also: 1997 Encryption Back-to-back frames, Decryption Back-to-back frames 1999 10.4.2 Encryption Back-to-back Frames 2001 Definition: 2003 A burst of cleartext frames, offered at a constant load that can 2004 be sent through an IPsec tunnel without losing a single encrypted 2005 frame. 2007 Discussion: 2009 Encryption back-to-back frames is the measure of the maximum burst 2010 size that a device can handle for encrypting traffic that it 2011 receives as plaintext. Since it is not necessarily the case that 2012 the maximum burst size a DUT can handle for encryption is equal to 2013 the maximum burst size a DUT can handle for decryption, both of 2014 these capabilities must be measured independently. The encryption 2015 back-to-back frame measurement has to be measured with the help of 2016 an IPsec aware test device that can decrypt the traffic to 2017 determine the validity of the encrypted frames. 2019 Measurement Units: 2021 Number of N-octet frames in burst. 2023 Issues: 2025 Recommended test frame sizes will be addressed in future 2026 methodology document. 2028 See Also: 2030 Tunnel Back-to-back frames, Decryption Back-to-back frames 2032 10.4.3 Decryption Back-to-back Frames 2034 Definition: 2036 The number of encrypted frames, offered at a constant load, that 2037 can be sent through an IPsec tunnel without losing a single 2038 cleartext frame. 2040 Discussion: 2042 Decryption back-to-back frames is the measure of the maximum burst 2043 size that a device can handle for decrypting traffic that it 2044 receives as encrypted traffic. Since it is not necessarily the 2045 case that the maximum burst size a DUT can handle for decryption 2046 is equal to the maximum burst size a DUT can handle for 2047 encryption, both of these capabilities must be measured 2048 independently. The decryption back-to-back frame measurement has 2049 to be measured with the help of an IPsec aware test device that 2050 can determine the validity of the decrypted frames. 2052 Measurement Units: 2054 Number of N-octet frames in burst. 2056 Issues: 2058 Recommended test frame sizes will be addressed in future 2059 methodology document. 2061 See Also: 2063 Tunnel Back-to-back frames, Encryption back-to-back frames 2065 10.5 Tunnel Setup Rate Behavior 2067 10.5.1 Tunnel Setup Rate 2069 Definition: 2071 The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second 2072 that an IPsec device can successfully establish. 2074 Discussion: 2076 The tunnel setup rate SHOULD be measured at varying number of 2077 tunnels on the DUT. Several factors may influence Tunnel Setup 2078 Rate, such as: TAPS rate, Background Load on crypto link (clear 2079 traffic), Already established tunnels, Authentication method: 2080 pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used 2081 (when using RSA/DSS) 2083 Measurement Units: 2085 Tunnels Per Second (TPS) 2087 Issues: 2089 N/A 2091 See Also: 2093 IKE Setup Rate, IPsec Setup Rate 2095 10.5.2 Phase 1 Setup Rate 2097 Definition: 2099 The maximum number of IKE tunnels per second that an IPsec device 2100 can be observed to successfully establish. 2102 Discussion: 2104 The tunnel setup rate SHOULD be measured at varying number of 2105 tunnels on the DUT. 2107 Measurement Units: 2109 Tunnels Per Second (TPS) 2111 Issues: 2113 N/A 2115 See Also: 2117 Tunnel Setup Rate, IPsec Setup Rate 2119 10.5.3 Phase 2 Setup Rate 2121 Definition: 2123 The maximum number of IPsec tunnels per second that a IPsec device 2124 can be observed to successfully establish. 2126 Discussion: 2128 The tunnel setup rate SHOULD be measured at varying number of 2129 tunnels on the DUT. 2131 Measurement Units: 2133 Tunnels Per Second (TPS) 2135 Issues: 2137 N/A 2139 See Also: 2141 Tunnel Rekey 2143 10.6 Tunnel Rekey 2145 10.6.1 Phase 1 Rekey Rate 2147 Definition: 2149 The interval necessary for a particular Phase 1 to re-establish 2150 after the previous Phase 1 lifetime (hard or soft) has expired. 2152 Discussion: 2154 Although many implementations will usually derive new keying 2155 material before the old keys expire, there may still be a period 2156 of time where frames get dropped before the phase 1 and subsequent 2157 phase 2 tunnels are successfully (re)established. To measure the 2158 phase 1 rekey rate, the measurement will require an IPsec aware 2159 test device to act as a responder when negotiating the new phase 1 2160 key. 2162 Measurement Units: 2164 Time units with enough precision to reflect rekey rate 2165 measurement. 2167 Issues: 2169 N/A 2171 See Also: 2173 Phase 2 Rekey Rate 2175 10.6.2 Phase 2 Rekey Rate 2177 Definition: 2179 The interval necessary for a particular Phase 2 to re-establish 2180 after the previous Phase 2 lifetime (hard or soft) has expired. 2182 Discussion: 2184 The test methodology report must specify if PFS is enabled in 2185 reported security context. 2187 Measurement Units: 2189 Time units with enough precision to reflect rekey rate 2190 measurement. 2192 Issues: 2194 N/A 2196 See Also: 2198 Phase 1 Rekey Rate 2200 10.7 Tunnel Failover Time (TFT) 2202 Definition: 2204 Time required to recover all tunnels on a stanby IPsec device, 2205 after a catastrophic failure occurs on the active IPsec device. 2207 Discussion: 2209 Recovery time required to re-establish all tunnels and reroute all 2210 traffic on a standby node or other failsafe system after a failure 2211 has occurred. Failure can include but are not limited to a 2212 catastrophic IPsec Device failure, a encryption engine failure, 2213 link outage. The recovery time is delta between the point of 2214 failure and the time the first packet is seen on the last restored 2215 tunnel on the backup device. 2217 Measurement Units: 2219 Time units with enough precision to reflect Tunnel Failover Time. 2221 Issues: 2223 N/A 2225 10.8 IKE DOS Resilience Rate 2227 Definition: 2229 The IKE Denial Of Service (DOS) Resilience Rate provides a rate of 2230 invalid or mismatching IKE tunnels setup attempts at which it is 2231 no longer possible to set up a valid IKE tunnel. 2233 Discussion: 2235 The IKE DOS Resilience Rate will provide a metric to how robust 2236 and hardened an IPsec device is against malicious attempts to set 2237 up a tunnel. 2239 IKE DOS attacks can pose themselves in various forms and do not 2240 necessarily have to have a malicious background. It is sufficient 2241 to make a typographical error in a shared secret in an IPsec 2242 aggregation device to be susceptible to a large number of IKE 2243 attempts that need to be turned down. Due to the intense 2244 computational nature of an IKE exchange every single IKE tunnel 2245 attempt that has to be denied will take a non-negligible time an a 2246 CPU in the IPsec device. 2248 Depending on how many of these messages have to be processed, a 2249 system might end up in a state that it is only doing key exchanges 2250 and burdening the CPU for any other processes that might be 2251 running in the IPsec device. At this point it will be no longer 2252 possible to process a valid IKE tunnel setup request and thus IKE 2253 DOS is in effect. 2255 Measurement Units: 2257 Tunnel Attempts Per Seconds (TAPS) 2259 Issues: 2261 N/A 2263 11. Security Considerations 2265 As this document is solely for the purpose of providing test 2266 benchmarking terminology and describes neither a protocol nor a 2267 protocol's implementation; there are no security considerations 2268 associated with this document. 2270 12. Acknowledgements 2272 The authors would like to acknowledge the following individual for 2273 their help and participation of the compilation and editing of this 2274 document: Debby Stopp, Ixia. 2276 13. Contributors 2278 The authors would like to acknowledge the following individual for 2279 their significant help, guidance, and contributions to this document: 2280 Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. 2282 Normative References 2284 [RFC1242] Bradner, S., "Benchmarking terminology for network 2285 interconnection devices", RFC 1242, July 1991. 2287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2288 Requirement Levels", BCP 14, RFC 2119, March 1997. 2290 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 2291 Switching Devices", RFC 2285, February 1998. 2293 [RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP 2294 Payload Compression Protocol (IPComp)", RFC 2393, December 2295 1998. 2297 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2298 Internet Protocol", RFC 2401, November 1998. 2300 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2301 2402, November 1998. 2303 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2304 ESP and AH", RFC 2403, November 1998. 2306 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2307 ESP and AH", RFC 2404, November 1998. 2309 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 2310 Algorithm With Explicit IV", RFC 2405, November 1998. 2312 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2313 Payload (ESP)", RFC 2406, November 1998. 2315 [RFC2407] Piper, D., "The Internet IP Security Domain of 2316 Interpretation for ISAKMP", RFC 2407, November 1998. 2318 [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet 2319 Security Association and Key Management Protocol 2320 (ISAKMP)", RFC 2408, November 1998. 2322 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2323 (IKE)", RFC 2409, November 1998. 2325 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2326 Its Use With IPsec", RFC 2410, November 1998. 2328 [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 2329 Document Roadmap", RFC 2411, November 1998. 2331 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2332 2412, November 1998. 2334 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2335 Algorithms", RFC 2451, November 1998. 2337 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 2338 Network Interconnect Devices", RFC 2544, March 1999. 2340 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 2341 1999. 2343 [I-D.ietf-ipsec-ikev2] 2344 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2345 draft-ietf-ipsec-ikev2-12 (work in progress), January 2346 2004. 2348 [I-D.ietf-ipsec-nat-t-ike] 2349 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 2350 draft-ietf-ipsec-nat-t-ike-07 (work in progress), 2351 September 2003. 2353 [I-D.ietf-ipsec-udp-encaps] 2354 Huttunen, A., "UDP Encapsulation of IPsec Packets", 2355 draft-ietf-ipsec-udp-encaps-07 (work in progress), 2356 November 2003. 2358 [I-D.ietf-ipsec-nat-reqts] 2359 Aboba, B. and W. Dixon, "IPsec-NAT Compatibility 2360 Requirements", draft-ietf-ipsec-nat-reqts-06 (work in 2361 progress), October 2003. 2363 [I-D.ietf-ipsec-properties] 2364 Krywaniuk, A., "Security Properties of the IPsec Protocol 2365 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2366 July 2002. 2368 [FIPS.186-1.1998] 2369 National Institute of Standards and Technology, "Digital 2370 Signature Standard", FIPS PUB 186-1, December 1998, 2371 . 2373 Informative References 2375 [Designing Network Security] 2376 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2377 Published: May 07, 1999; Copyright: 1999, 1999. 2379 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2380 Mechanism for Internet", from IEEE Proceedings of the 2381 1996 Symposium on Network and Distributed Systems 2382 Security, URI http://www.research.ibm.com/security/ 2383 skeme.ps, 1996. 2385 [DPD] "DPD draft-ietf-ipsec-dpd-02", , URI http://www.ietf.org/ 2386 internet-drafts/draft-ietf-ipsec-dpd-02.txt. 2388 Authors' Addresses 2390 Michele Bustos 2391 IXIA 2392 26601 W. Agoura Rd. 2393 Calabasas, CA 91302 2394 US 2396 Phone: +1 (818)444-3244 2397 EMail: mbustos@ixiacom.com 2399 Tim Van Herck 2400 Cisco Systems, Inc. 2401 170 West Tasman Drive 2402 San Jose, CA 95134-1706 2403 US 2405 Phone: +1 (408)527-2461 2406 EMail: herckt@cisco.com 2408 Merike Kaeo 2409 Merike, Inc. 2410 123 Ross Street 2411 Santa Cruz, CA 95060 2412 US 2414 Phone: +1 (831)818-4864 2415 EMail: kaeo@merike.com 2417 Intellectual Property Statement 2419 The IETF takes no position regarding the validity or scope of any 2420 intellectual property or other rights that might be claimed to 2421 pertain to the implementation or use of the technology described in 2422 this document or the extent to which any license under such rights 2423 might or might not be available; neither does it represent that it 2424 has made any effort to identify any such rights. Information on the 2425 IETF's procedures with respect to rights in standards-track and 2426 standards-related documentation can be found in BCP-11. Copies of 2427 claims of rights made available for publication and any assurances of 2428 licenses to be made available, or the result of an attempt made to 2429 obtain a general license or permission for the use of such 2430 proprietary rights by implementors or users of this specification can 2431 be obtained from the IETF Secretariat. 2433 The IETF invites any interested party to bring to its attention any 2434 copyrights, patents or patent applications, or other proprietary 2435 rights which may cover technology that may be required to practice 2436 this standard. Please address the information to the IETF Executive 2437 Director. 2439 Full Copyright Statement 2441 Copyright (C) The Internet Society (2004). All Rights Reserved. 2443 This document and translations of it may be copied and furnished to 2444 others, and derivative works that comment on or otherwise explain it 2445 or assist in its implementation may be prepared, copied, published 2446 and distributed, in whole or in part, without restriction of any 2447 kind, provided that the above copyright notice and this paragraph are 2448 included on all such copies and derivative works. However, this 2449 document itself may not be modified in any way, such as by removing 2450 the copyright notice or references to the Internet Society or other 2451 Internet organizations, except as needed for the purpose of 2452 developing Internet standards in which case the procedures for 2453 copyrights defined in the Internet Standards process must be 2454 followed, or as required to translate it into languages other than 2455 English. 2457 The limited permissions granted above are perpetual and will not be 2458 revoked by the Internet Society or its successors or assignees. 2460 This document and the information contained herein is provided on an 2461 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2462 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2463 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2464 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2465 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2467 Acknowledgment 2469 Funding for the RFC Editor function is currently provided by the 2470 Internet Society.