idnits 2.17.1 draft-ietf-bmwg-ipsec-term-09.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 2119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2143. 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.) ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 (July 8, 2007) is 6109 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 905, but not defined == Missing Reference: 'GW2' is mentioned on line 905, but not defined == Missing Reference: 'IP CLOUD' is mentioned on line 905, but not defined == Missing Reference: 'GW3' is mentioned on line 905, but not defined == Missing Reference: 'GW4' is mentioned on line 905, but not defined == Missing Reference: 'ESP' is mentioned on line 913, but not defined == Missing Reference: 'AH' is mentioned on line 913, but not defined == Missing Reference: 'IP' is mentioned on line 913, but not defined == Missing Reference: 'PAYLOAD' is mentioned on line 913, but not defined == Missing Reference: 'ESP TRAILER' is mentioned on line 913, but not defined == Missing Reference: 'ESP AUTH' is mentioned on line 913, but not defined == Missing Reference: 'RFC1962' is mentioned on line 1107, but not defined == Unused Reference: 'RFC2119' is defined on line 1964, but no explicit reference was found in the text == Unused Reference: 'RFC2403' is defined on line 1980, but no explicit reference was found in the text == Unused Reference: 'RFC2404' is defined on line 1983, but no explicit reference was found in the text == Unused Reference: 'RFC2405' is defined on line 1986, but no explicit reference was found in the text == Unused Reference: 'RFC2410' is defined on line 2002, but no explicit reference was found in the text == Unused Reference: 'RFC2411' is defined on line 2005, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-ikev2' is defined on line 2044, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipsec-properties' is defined on line 2054, 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: 19 errors (**), 0 flaws (~~), 22 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group M. Kaeo 3 Internet-Draft Double Shot Security 4 Expires: January 9, 2008 T. Van Herck 5 Cisco Systems 6 M. Bustos 7 IXIA 8 July 8, 2007 10 Terminology for Benchmarking IPsec Devices 11 draft-ietf-bmwg-ipsec-term-09 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 January 9, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This purpose of this document is to define terminology specific to 45 measuring the performance of IPsec devices. It builds upon the 46 tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF 47 Benchmarking Methodology Working Group (BMWG) documents used for 48 benchmarking routers and switches. This document seeks to extend 49 these efforts specific to the IPsec paradigm. The BMWG produces two 50 major classes of documents: Benchmarking Terminology documents and 51 Benchmarking Methodology documents. The Terminology documents 52 present the benchmarks and other related terms. The Methodology 53 documents define the procedures required to collect the benchmarks 54 cited in the corresponding Terminology documents. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.1. Security Associations . . . . . . . . . . . . . . . . 7 63 3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 8 64 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10 66 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 11 67 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13 72 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13 73 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13 74 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14 75 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14 76 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 15 77 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 16 80 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 17 81 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 17 82 7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 17 83 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 18 85 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 18 86 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 19 87 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 19 88 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 20 89 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 20 90 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 21 91 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 21 92 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 22 93 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 22 94 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 23 95 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23 96 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24 97 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25 98 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25 99 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26 100 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28 102 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29 103 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30 104 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30 105 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 30 106 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 31 107 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 108 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 10.1.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . 31 110 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 32 111 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32 112 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32 113 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 33 114 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 34 115 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 34 117 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 35 118 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 35 119 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 36 120 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 37 121 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 37 122 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 37 123 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 37 124 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 38 125 10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 38 126 10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 38 127 10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 39 128 10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 39 129 10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 40 130 10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 40 131 10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 40 132 10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 41 133 10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 41 134 10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 41 135 10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 42 136 10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 42 137 10.9. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 43 138 10.9.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 43 139 10.9.2. Phase 2 DoS Resiliency Rate . . . . . . . . . . . . . 43 140 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 141 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 143 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 144 13.2. Informative References . . . . . . . . . . . . . . . . . . 47 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 146 Intellectual Property and Copyright Statements . . . . . . . . . . 48 148 1. Introduction 150 Despite the need to secure communications over a public medium there 151 is no standard method of performance measurement nor a standard in 152 the terminology used to develop such hardware and software solutions. 153 This results in varied implementations which challenge 154 interoperability and direct performance comparisons. Standardized 155 IPsec terminology and performance test methodologies will enable 156 users to determine if the IPsec device they select will withstand 157 loads of secured traffic that meet their requirements. 159 To appropriately define the parameters and scope of this document, 160 this section will give a brief overview of the IPsec standard: 162 2. Document Scope 164 The primary focus of this document is to establish useful performance 165 testing terminology for IPsec devices that support manual keying and 166 IKEv1. We want to constrain the terminology specified in this 167 document to meet the requirements of the Methodology for Benchmarking 168 IPsec Devices documented test methodologies. 170 Both IPv4 and IPv6 addressing will be taken into consideration. 172 The testing will be constrained to: 174 o Devices acting as IPsec gateways whose tests will pertain to both 175 IPsec tunnel and transport mode. 177 o Devices acting as IPsec end-hosts whose tests will pertain to both 178 IPsec tunnel and transport mode. 180 Any testing involving interoperability and/or conformance issues, 181 L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and 182 anything that does not specifically relate to the establishment and 183 tearing down of IPsec tunnels is specifically out of scope. It is 184 assumed that all relevant networking parameters that facilitate in 185 the running of these tests are pre-configured (this includes at a 186 minimum ARP caches, routing tables, neighbor tables, etc ...). 188 A separate document will be written specifically to address testing 189 using the updated IKEv2 specification. Due to the dependency on 190 IKEv2 of the updated IPsec architecture document [RFC4301], this 191 document and the companion IPsec Benchmarking Methodology document 192 will be based on the older IPsec architecture standard [RFC2401]. 194 3. IPsec Fundamentals 196 IPsec is a framework of open standards that provides data 197 confidentiality, data integrity, and data origin authenticity between 198 participating peers. IPsec provides these security services at the 199 IP layer. IPsec uses IKE to handle negotiation of protocols and 200 algorithms based on local policy, and to generate the encryption and 201 authentication keys to be used. IPsec can be used to protect one or 202 more data flows between a pair of hosts, between a pair of security 203 gateways, or between a security gateway and a host. The IPsec 204 protocol suite set of standards is documented in RFC's [RFC2401] 205 through [RFC2412] and [RFC2451]. At this time [RFC4301] updates 206 [RFC2401] (IPsec Architecture), [RFC4302] updates [RFC2402] (AH) and 207 [RFC4303] updates [RFC2406] (ESP) and [RFC4306] updates [RFC2409] 208 (IKE).The reader is assumed to be familiar with these documents. 210 IPsec itself defines the following: 212 Authentication Header (AH): A security protocol, defined in 213 [RFC4302], which provides data authentication and optional anti- 214 replay services. AH ensures the integrity and data origin 215 authentication of the IP datagram as well as the invariant fields in 216 the outer IP header. 218 Encapsulating Security Payload (ESP): A security protocol, defined in 219 [RFC4303], which provides confidentiality, data origin 220 authentication, connectionless integrity, an anti-replay service and 221 limited traffic flow confidentiality. The set of services provided 222 depends on options selected at the time of Security Association (SA) 223 establishment and on the location of the implementation in a network 224 topology. ESP authenticates only headers and data after the IP 225 header. 227 Internet Key Exchange (IKE): A hybrid protocol which implements 228 Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP 229 framework. While IKE can be used with other protocols, its initial 230 implementation is with the IPsec protocol. IKE provides 231 authentication of the IPsec peers, negotiates IPsec security 232 associations, and establishes IPsec keys. 234 The AH and ESP protocols each support two modes of operation: 235 transport mode and tunnel mode. In transport mode, two hosts provide 236 protection primarily for upper-layer protocols. The cryptographic 237 endpoints (where the encryption and decryption take place) are the 238 source and destination of the data packet. In IPv4, a transport mode 239 security protocol header appears immediately after the IP header and 240 before any higher-layer protocols (such as TCP or UDP). In IPv6, the 241 security protocol header appears after the base IP header and 242 selected extension headers. It may appear before or after 243 destination options but must appear before next layer protocols 244 (e.g., TCP, UDP, SCTP) 246 In the case of AH in transport mode, security services are provided 247 to selected portions of the IP header preceding the AH header, 248 selected portions of extension headers, and selected options 249 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 250 IPv6 Destination extension headers). Any fields in these headers/ 251 extension headers which are modified in transit are set to 0 before 252 applying the authentication algorithm. If a field is mutable, but 253 its value at the receiving IPsec peer is predictable, then that value 254 is inserted into the field before applying the cryptographic 255 algorithm. 257 In the case of ESP in transport mode, security services are provide 258 only for the higher-layer protocols, not for the IP header or any 259 extension headers preceding the ESP header. 261 A tunnel is a vehicle for encapsulating packets inside a protocol 262 that is understood at the entry and exit points of a given network. 263 These entry and exit points are defined as tunnel interfaces. 265 Both the AH and ESP protocols can be used in tunnel mode for data 266 packet endpoints as well as by intermediate security gateways. In 267 tunnel mode, there is an "outer" IP header that specifies the IPsec 268 processing destination, plus an "inner" IP header that specifies the 269 ultimate destination for the packet. The source address in the outer 270 IP header is the initiating cryptographic endpoint; the source 271 address in the inner header is the true source address of the packet. 272 The security protocol header appears after the outer IP header and 273 before the inner IP header. 275 If AH is employed in tunnel mode, portions of the new outer IP header 276 are given protection (those same fields as for transport mode, 277 described earlier in this section), as well as all of the tunneled IP 278 packet (that is, all of the inner IP header is protected as are the 279 higher-layer protocols). If ESP is employed, the protection is 280 afforded only to the tunneled packet, not to the new outer IP header. 282 3.1. IPsec Operation 284 3.1.1. Security Associations 286 The concept of a Security Association (SA) is fundamental to IPsec. 287 An SA is a relationship between two or more entities that describes 288 how the entities will use security services to communicate. The SA 289 includes: an encryption algorithm, an authentication algorithm and a 290 shared session key. 292 Because an SA is unidirectional, two SA's (one in each direction) are 293 required to secure typical, bidirectional communication between two 294 entities. The security services associated with an SA can be used 295 for AH or ESP, but not for both. If both AH and ESP protection is 296 applied to a traffic stream, two (or more) SA's are created for each 297 direction to protect the traffic stream. 299 The SA is uniquely identified by the Security Parameter Index (SPI) 300 [RFC2406]. When a system sends a packet that requires IPsec 301 protection, it looks up the SA in its database and applies the 302 specified processing and security protocol (AH/ESP), inserting the 303 SPI from the SA into the IPsec header. When the IPsec peer receives 304 the packet, it looks up the SA in its database by destination 305 address, protocol, and SPI and then processes the packet as required. 307 3.1.2. Key Management 309 IPsec uses cryptographic keys for authentication, integrity and 310 encryption services. Both manual provisioning and automatic 311 distribution of keys is supported. IKE is specified as the public- 312 key-based approach for automatic key management. 314 IKE authenticates each peer involved in IPsec, negotiates the 315 security policy, and handles the exchange of session keys. IKE is a 316 hybrid protocol, combining parts of the following protocols to 317 negotiate and derive keying material for SA's in a secure and 318 authenticated manner: 320 1. ISAKMP [RFC2408] (Internet Security Association and Key 321 Management Protocol), which provides a framework for 322 authentication and key exchange but does not define them. ISAKMP 323 is designed to be key exchange independent; it is designed to 324 support many different key exchanges. 326 2. Oakley [RFC2412], which describes a series of key exchanges, 327 called modes, and details the services provided by each (for 328 example, perfect forward secrecy for keys, identity protection, 329 and authentication). 331 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 332 describes a versatile key exchange technique that provides 333 anonymity, reputability, and quick key refreshment. 335 IKE creates an authenticated, secure tunnel between two entities and 336 then negotiates the security association for IPsec. In the original 337 IKE specification [RFC2409], this is performed in two phases. 339 In Phase 1, the two unidirectional SA's establish a secure, 340 authenticated channel with which to communicate. Phase 1 has two 341 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 342 provides identity protection. When identity protection is not 343 needed, Aggressive Mode can be used. The completion of Phase 1 is 344 called an IKE SA. 346 The following attributes are used by IKE and are negotiated as part 347 of the IKE SA: 349 o Encryption algorithm. 351 o Hash algorithm. 353 o Authentication method (digital signature, public-key encryption or 354 pre-shared key). 356 o Diffie-Hellman group information. 358 After the attributes are negotiated, both parties must be 359 authenticated to each other. IKE supports multiple authentication 360 methods. The following mechanisms are generally implemented: 362 o Pre-shared keys: The same key is pre-installed on each host. IKE 363 peers authenticate each other by computing and sending a keyed 364 hash of data that includes the pre-shared key. If the receiving 365 peer can independently create the same hash using its preshared 366 key, it knows that both parties must share the same secret, and 367 thus the other party is authenticated. 369 o Public key cryptography: Each party generates a pseudo-random 370 number (a nonce) and encrypts it and its ID using the other 371 party's public key. The ability for each party to compute a keyed 372 hash containing the other peer's nonce and ID, decrypted with the 373 local private key, authenticates the parties to each other. This 374 method does not provide nonrepudiation; either side of the 375 exchange could plausibly deny that it took part in the exchange. 377 o Digital signature: Each device digitally signs a set of data and 378 sends it to the other party. This method is similar to the 379 public-key cryptography approach except that it provides 380 nonrepudiation. 382 Note that both digital signature and public-key cryptography require 383 the use of digital certificates to validate the public/private key 384 mapping. IKE allows the certificate to be accessed independently or 385 by having the two devices explicitly exchange certificates as part of 386 IKE. Both parties must have a shared session key to encrypt the IKE 387 tunnel. The Diffie-Hellman protocol is used to agree on a common 388 session key. 390 In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's 391 will be called IPsec SA's. These IPsec SA's use a different shared 392 key than that used for the IKE_SA. The IPsec SA shared key can be 393 derived by using Diffie-Hellman again or by refreshing the shared key 394 derived from the original Diffie-Hellman exchange that generated the 395 IKE_SA by hashing it with nonces. Once the shared key is derived and 396 additional communication parameters are negotiated, the IPsec SA's 397 are established and traffic can be exchanged using the negotiated 398 parameters. 400 4. Definition Format 402 The definition format utilized by this document is described in 403 [RFC1242], Section 2. 405 Term to be defined. 407 Definition: The specific definition for the term. 409 Discussion: A brief discussion of the term, its application, or 410 other information that would build understanding. 412 Issues: List of issues or conditions that affect this term. This 413 field can present items the may impact the term's related 414 methodology or otherwise restrict its measurement procedures. 416 [Measurement units:] Units used to record measurements of this term. 417 This field is mandatory where applicable. This field is optional 418 in this document. 420 [See Also:] List of other terms that are relevant to the discussion 421 of this term. This field is optional in this document. 423 5. Key Words to Reflect Requirements 425 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 426 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 427 document are to be interpreted as described in RFC 2119. RFC 2119 428 defines the use of these key words to help make the intent of 429 standards track documents as clear as possible. While this document 430 uses these keywords, this document is not a standards track document. 432 6. Existing Benchmark Definitions 434 It is recommended that readers consult [RFC1242], [RFC2544] and 435 [RFC2285] before making use of this document. These and other IETF 436 Benchmarking Methodology Working Group (BMWG) router and switch 437 documents contain several existing terms relevant to benchmarking the 438 performance of IPsec devices. The conceptual framework established 439 in these earlier RFC's will be evident in this document. 441 This document also draws on existing terminology defined in other 442 BMWG documents. Examples include, but are not limited to: 444 Throughput [RFC 1242, section 3.17] 445 Latency [RFC 1242, section 3.8] 446 Frame Loss Rate [RFC 1242, section 3.6] 447 Forwarding Rates [RFC 2285, section 3.6] 448 Loads [RFC 2285, section 3.5] 450 7. Definitions 452 7.1. IPsec 454 Definition: IPsec or IP Security protocol suite which comprises a 455 set of standards used to provide security services at the IP 456 layer. 458 Discussion: IPsec is a framework of protocols that offer 459 authentication, integrity and encryption services to the IP and/or 460 upper layer protocols. The major components of the protocol suite 461 are IKE, used for key exchanges, and IPsec protocols such as AH 462 and ESP, which use the exchanged keys to protect payload traffic. 464 Issues: N/A 466 See Also: IPsec Device, IKE, ISAKMP, ESP, AH 468 7.2. ISAKMP 470 Definition: The Internet Security Association and Key Management 471 Protocol, which provides a framework for authentication and key 472 exchange but does not define them. ISAKMP is designed to be key 473 exchange independent; it is designed to support many different key 474 exchanges. ISAKMP is defined in [RFC2407]. 476 Discussion: Though ISAKMP is only a framework for the IPsec standard 477 key management protocol, it is often misused and interchanged with 478 the term 'IKE', which is an implementation of ISAKMP. 480 Issues: When implementations refer to the term 'ISAKMP SA', it 481 refers to an IKE Phase 1 SA. 483 See Also: IKE, Security Association 485 7.3. IKE 487 Definition: A hybrid key management protocol that provides 488 authentication of the IPsec peers, negotiates IPsec SAs and 489 establishes IPsec keys. 491 Discussion: A hybrid protocol, defined in [RFC2409], from the 492 following 3 protocols: 494 * ISAKMP (Internet Security Association and Key Management 495 Protocol), which provides a framework for authentication and 496 key exchange but does not define them. ISAKMP is designed to 497 be key exchange independent; it is designed to support many 498 different key exchanges. 500 * Oakley, which describes a series of key exchanges, called 501 modes, and details the services provided by each (for example, 502 perfect forward secrecy for keys, identity protection, and 503 authentication). [RFC2412] 505 * [SKEME] (Secure Key Exchange Mechanism for Internet), which 506 describes a versatile key exchange technique that provides 507 anonymity, reputability, and quick key refreshment. 509 Note that IKE is an optional protocol within the IPsec framework. 510 IPsec SAs may also be manually configured. Manual keying is the 511 most basic mechanism to establish IPsec SAs between two IPsec 512 devices. However, it is not a scalable solution and often 513 manually configured keys are not changed on a periodic basis which 514 reduces the level of protection since the keys are effectively 515 static and as a result are more prone to various attacks. When 516 IKE is employed as a key management protocol, the keys are 517 automatically renegotiated on a user-defined basis (time and/or 518 traffic volume based) as part of the IKE rekeying mechanism. 520 Issues: During the first IPsec deployment experiences, ambiguities 521 were found in the IKEv1 specification, which lead to 522 interoperability problems. To resolve these issues, IKEv1 is 523 being updated by IKEv2. 525 See Also: ISAKMP, IPsec, Security Association 527 7.3.1. IKE Phase 1 529 Definition: The shared policy and key(s) used by negotiating peers 530 to establish a secure authenticated "control channel" for further 531 IKE communications. 533 Discussion: The IPsec framework mandates that SPI's are used to 534 secure payload traffic. If IKE is employed all SPI information 535 will be exchanged between the IPsec devices. This has to be done 536 in a secure fashion and for that reason IKE will set up a secure 537 "control channel" over which it can exchange this information. 539 Note that IKE is an optional protocol within the IPsec framework 540 and that SPI information can also be manually configured. 542 Issues: In some documents often referenced as ISAKMP SA or IKE SA. 544 See Also: IKE, ISAKMP 546 7.3.2. IKE Phase 1 Main Mode 548 Definition: Main Mode is an instantiation of the ISAKMP Identity 549 Protect Exchange, defined in [RFC2409]. Upon successful 550 completion it results in the establishment of an IKE Phase 1 SA. 552 Discussion: IKE Main Mode use 3 distinct message pairs, for a total 553 of 6 messages. The first two messages negotiate policy; the next 554 two represent Diffie-Hellman public values and ancillary data 555 (e.g. nonces); and the last two messages authenticate the Diffie- 556 Hellman Exchange. The authentication method negotiated as part of 557 the initial IKE Phase 1 influence the composition of the payloads 558 but not their purpose. 560 Issues: N/A 562 See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 564 7.3.3. IKE Phase 1 Aggressive Mode 566 Definition: Aggressive Mode is an instantiation of the ISAKMP 567 Aggressive Exchange, defined in [RFC2409]. Upon successful 568 completion it results in the establishment of an IKE Phase 1 SA. 570 Discussion: IKE Aggressive Mode uses 3 messages. The first two 571 messages negotiate policy, exchange Diffie-Hellman public values 572 and ancillary data necessary for the exchange, and identities. In 573 addition the second message authenticates the Responder. The 574 third message authenticates the Initiator and provides proof of 575 participation in the exchange. 577 Issues: For IKEv1 the standard specifies that all implementations 578 use both main and agressive mode, however, it is common to use 579 only main mode. 581 See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 583 7.3.4. IKE Phase 2 585 Definition: ISAKMP phase which upon successful completion 586 establishes the shared keys used by the negotiating peers to set 587 up a secure "data channel" for IPsec. 589 Discussion: The main purpose of Phase 2 is to produce the key for 590 the IPsec tunnel. Phase 2 is also used for exchanging 591 informational messages. 593 Issues: In other documents also referenced as IPsec SA. 595 See Also: IKE Phase 1, ISAKMP, IKE 597 7.3.5. Phase 2 Quick Mode 599 Definition: Quick Mode is an instanciation of IKE Phase 2. After 600 successful completion it will result in one or typically two or 601 more IPsec SA's 603 Discussion: Quick Mode is used to negotiate the SA's and keys that 604 will be used to protect the user data. Three different messages 605 are exchanged, which are protected by the security parameters 606 negotiated by the IKE phase 1 exchange. An additional Diffie- 607 Hellman exchange may be performed if PFS (Perfect Forward Secrecy) 608 is enabled. 610 Issues: N/A 612 See Also: ISAKMP, IKE, IKE Phase 2 614 7.4. Security Association (SA) 616 Definition: A set of policy and key(s) used to protect traffic flows 617 that require authentication and/or encryption services. It is a 618 negotiation agreement between two IPsec devices, specifically the 619 Initiator and Responder. 621 Discussion: A simplex (unidirectional) logical connection that links 622 a traffic flow to a set of security parameters. All traffic 623 traversing an SA is provided the same security processing and will 624 be subjected to a common set of encryption and/or authentication 625 algorithms. In IPsec, an SA is an Internet layer abstraction 626 implemented through the use of AH or ESP as defined in [RFC2401]. 628 Issues: N/A 630 See Also: Initiator, Responder 632 7.5. Selectors 634 Definition: A mechanism used for the classification of traffic flows 635 that require authentication and/or encryption services. 637 Discussion: The selectors are a set of fields that will be extracted 638 from the network and transport layer headers that provide the 639 ability to classify the traffic flow and associate it with an SA. 641 After classification, a decision can be made if the traffic needs 642 to be encrypted/decrypted and how this should be done depending on 643 the SA linked to the traffic flow. Simply put, selectors classify 644 IP packets that require IPsec processing and those packets that 645 must be passed along without any intervention of the IPsec 646 framework. 648 Selectors are flexible objects that can match on ranges of source 649 and destination addresses and ranges of source and destination 650 ports. 652 Issues: Both sides must agree exactly on both the networks being 653 protected, and they both must agree on how to describe the 654 networks (range, subnet, addresses). This is a common point of 655 non-interoperability. 657 7.6. IPsec Device 658 Definition: Any implementation that has the ability to process data 659 flows according to the IPsec protocol suite specifications. 661 Discussion: Implementations can be grouped by 'external' properties 662 (e.g. software vs. hardware implementations) but more important is 663 the subtle differences that implementations may have with relation 664 to the IPsec Protocol Suite. Not all implementations will cover 665 all RFC's that encompass the IPsec Protocol Suite, but the 666 majority will support a large subset of features described in the 667 suite, nor will all implementations utilize all of the 668 cryptographic functions listed in the RFC's. 670 In that context, any implementation, that supports basic IP layer 671 security services as described in the IPsec protocol suite shall 672 be called an IPsec Device. 674 Issues: Due to the fragmented nature of the IPsec Protocol Suite 675 RFC's, it is possible that IPsec implementations will not be able 676 to interoperate. Therefore it is important to know which features 677 and options are implemented in the IPsec Device. 679 See Also: IPsec 681 7.6.1. Initiator 683 Definition: An IPsec device which starts the negotiation of IKE 684 Phase 1 and IKE Phase 2 SAs. 686 Discussion: When a traffic flow is offered at an IPsec device and it 687 is determined that the flow must be protected, but there is no 688 IPsec tunnel to send the traffic through, it is the responsibility 689 of the IPsec device to start a negotiation process that will 690 instantiate the IPsec tunnel. This process will establish an IKE 691 Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, 692 eventually resulting in secured data transport. The device that 693 takes the action to start this negotiation process will be called 694 an Initiator. 696 Issues: IPsec devices/implementations can be both an initiator as 697 well as a responder. The distinction is useful from a test 698 perspective. 700 See Also: Responder, IKE, IPsec 702 7.6.2. Responder 704 Definition: An IPsec device which replies to incoming IKE Phase 1 705 and IKE Phase 2 requests and processes these messages in order to 706 establish an IPsec tunnel. 708 Discussion: When an initiator attempts to establish SA's with 709 another IPsec device, this peer will need to evaluate the 710 proposals made by the initiator and either accept or deny them. 711 In the former case, the traffic flow will be decrypted according 712 to the negotiated parameters. Such a device will be called a 713 Responder. 715 Issues: IPsec devices/implementations can usually be both an 716 initiator as well as a responder. The distinction is useful from 717 a test perspective. 719 See Also: Initiator, IKE 721 7.6.3. IPsec Client 723 Definition: IPsec Devices that will only act as an Initiator. 725 Discussion: In some situations it is not needed or prefered to have 726 an IPsec device respond to an inbound IKE SA or IPsec SA request. 727 In the case of e.g. road warriors or home office scenarios the 728 only property needed from the IPsec device is the ability to 729 securely connect to a remote private network. The IPsec Client 730 will initiate one or more IPsec tunnels to an IPsec Server on the 731 network that needs to be accessed and to provide the required 732 security services. An IPsec client will silently drop and ignore 733 any inbound IPsec tunnel requests. IPsec clients are generally 734 used to connect remote users in a secure fashion over the Internet 735 to a private network. 737 Issues: N/A 739 See Also: IPsec device, IPsec Server, Initiator, Responder 741 7.6.4. IPsec Server 743 Definition: IPsec Devices that can both act as an Initiator as well 744 as a Responder. 746 Discussion: IPsec Servers are mostly positioned at private network 747 edges and provide several functions: 749 * Responds to IPsec tunnel setup request from IPsec Clients. 751 * Responds to IPsec tunnel setup request from other IPsec devices 752 (Initiators). 754 * Initiate IPsec tunnels to other IPsec servers inside or outside 755 the private network. 757 Issues: IPsec Servers are also sometimes referred to as 'VPN 758 Concentrators'. 760 See Also: IPsec Device, IPsec Client, Initiator, Responder 762 7.7. Tunnels 764 The term "tunnel" is often used in a variety of contexts. To avoid 765 any discrepancies, in this document, the following distinctions have 766 been defined: 768 7.7.1. IPsec Tunnel 770 Definition: The combination of an IKE Phase 1 SA and a pair of IKE 771 Phase 2 SA's. 773 Discussion: An IPsec Tunnel will be defined as a single (1) Phase 1 774 SA and a pair (2) Phase 2 SA's. This construct will allow 775 bidirectional traffic to be passed between two IPsec Devices where 776 the traffic can benefit form the services offered in the IPsec 777 framework. 779 Issues: Since it is implied that a Phase 1 SA is used, an IPsec 780 Tunnel will be by definition a dynamically negotiated secured 781 link. If manual keying is used to enable secure data transport, 782 then this link will merely be referred to as a pair of IPsec SA's. 784 It is very likely that more then one pair of Phase 2 SA's are 785 associated with a single Phase 1 SA. Also in this case, the IPsec 786 Tunnel definition WILL NOT apply. Instead the ratio between Phase 787 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella 788 term of "IPsec Tunnel" MUST NOT be used in this context. 790 See Also: IKE Phase 1, IKE Phase 2 792 7.7.2. Configured Tunnel 793 Definition: An IPsec tunnel or a pair of IPsec SAs in the case of 794 manual keying that is provisioned in the IPsec device's 795 configuration. 797 Discussion: Several steps are required before IPsec can be used to 798 actually transport traffic. The very first step is to configure 799 the IPsec Tunnel (or IPsec SAs in the case of manual keying) in 800 the IPsec device. When using IKE there are no SA's associated 801 with the IPsec Tunnel and no traffic is going through the IPsec 802 device that matches the Selectors, which would instantiate the 803 IPsec Tunnel. When using either manual keying or IKE, a 804 configured tunnel will not have a populated SADB. 806 Issues: When using IKE, a configured tunnel will not have any SA's 807 while with manual keying, the SAs will have simply been configured 808 but not populated in the SADB. 810 See Also: IPsec Tunnel, Established Tunnel, Active Tunnel 812 7.7.3. Established Tunnel 814 Definition: An IPsec device that has a populated SADB and is ready 815 to provide security services to the appropriate traffic. 817 Discussion: When using IKE, a second step needed to ensure that an 818 IPsec Tunnel can transport data is to complete the Phase 1 and 819 Phase 2 negotiations. After the packet classification process has 820 asserted that a packet requires security services, the negotation 821 is started to obtain both Phase 1 and Phase 2 SAs. After this is 822 completed and the SADB is populated, the IPsec Tunnel is called 823 'Established'. Note that at this time there is still no traffic 824 flowing through the IPsec Tunnel. Just enough packet(s) have been 825 sent to the IPsec device that matched the selectors and triggered 826 the IPsec Tunnel setup to result in a populated SADB. In the case 827 of manual keying, populating the SADB is accomplished by a 828 separate administrative command. 830 Issues: N/A 832 See Also: IPsec Tunnel, Configured Tunnel, Active Tunnel 834 7.7.4. Active Tunnel 836 Definition: An IPsec device that is forwarding secured data. 838 Discussion: When a Tunnel is Established and it is transporting 839 traffic that is authenticated and/or encrypted, the tunnel is 840 called 'Active'. 842 Issues: The distinction between an Active Tunnel and Configured/ 843 Established Tunnel is made in the context of manual keyed Tunnels. 844 In this case it would be possible to have an Established tunnel on 845 an IPsec device which has no counterpart on it's corresponding 846 peer. This will lead to encrypted traffic flows which will be 847 discarded on the receiving peer. Only if both peers have an 848 Established Tunnel that shows evidence of traffic transport, it 849 may be called an Active Tunnel. 851 See Also: IPsec Tunnel, Configured Tunnel, Established Tunnel 853 7.8. Iterated Tunnels 855 Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. 856 The bundles are divided into two major groups : 858 7.8.1. Nested Tunnels 860 Definition: An SA bundle consisting of two or more 'tunnel mode' 861 SA's. 863 Discussion: The process of nesting tunnels can theoretically be 864 repeated multiple times (for example, tunnels can be many levels 865 deep), but for all practical purposes, most implementations limit 866 the level of nesting. Nested tunnels can use a mix of AH and ESP 867 encapsulated traffic. 869 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 870 | | | | 871 | | | | 872 | +----{SA1 (ESP tunnel)}----+ | 873 | | 874 +--------------{SA2 (AH tunnel)}---------------+ 876 In the IP Cloud a packet would have a format like this : 877 [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] 879 Nested tunnels can be deployed to provide additional security on 880 already secured traffic. A typical example of this would be that 881 the inner gateways (GW2 and GW3) are securing traffic between two 882 branch offices and the outer gateways (GW1 & GW4) add an 883 additional layer of security between departments within those 884 branch offices. 886 Issues: N/A 888 See Also: Transport Adjacency, IPsec Tunnel 890 7.8.2. Transport Adjacency 892 Definition: An SA bundle consisting of two or more transport mode 893 SA's. 895 Discussion: Transport adjacency is a form of tunnel nesting. In 896 this case two or more transport mode IPsec tunnels are set side by 897 side to enhance applied security properties. 899 Transport adjacency can be used with a mix of AH and ESP tunnels 900 although some combinations are not preferred. If AH and ESP are 901 mixed, the ESP tunnel should always encapsulate the AH tunnel. 902 The reverse combination is a valid combination but doesn't make 903 cryptographical sense. 905 [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] 906 | | | | 907 | | | | 908 | +------{SA1 (ESP transport)}--------+ | 909 | | 910 +-------------{SA2 (AH transport)}--------------+ 912 In the IP Cloud a packet would have a format like this : 913 [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] 915 Issues: This is rarely used in the way it is depicted. It is more 916 common, but still not likely, that SA's are established from 917 different gateways as depicted in the Nested Tunnels figure. The 918 packet format in the IP Cloud would remain unchanged. 920 See Also: Nested Tunnels, IPsec Tunnel 922 7.9. Transform protocols 924 Definition: Encryption and authentication algorithms that provide 925 cryptograhic services to the IPsec Protocols. 927 Discussion: Some algorithms run significantly slower than others. A 928 decision for which algorithm to use is usually based on the 929 tradeoff between performance and security strength. For example, 930 3DES encryption is generally slower then DES encryption. 932 Issues: N/A 934 See Also: Authentication protocols, Encryption protocols 936 7.9.1. Authentication Protocols 938 Definition: Algorithms which provide data integrity and data source 939 authentication. 941 Discussion: Authentication protocols provide no confidentiality. 942 Commonly used authentication algorithms/protocols are: 944 * MD5-HMAC 945 * SHA-HMAC 946 * AES-HMAC 948 Issues: N/A 950 See Also: Transform protocols, Encryption protocols 952 7.9.2. Encryption Protocols 954 Definition: Algorithms which provide data confidentiality. 956 Discussion: Encryption protocols provide no authentication. 957 Commonly used encryption algorithms/protocols are: 959 * NULL encryption 960 * DES-CBC 961 * 3DES-CBC 962 * AES-CBC 964 Issues: The null-encryption option is a valid encryption mechanism 965 to provide an alternative to using AH. There is no 966 confidentiality protection with null-encryption. Note also that 967 when using ESP null-encryption the authentication and integrity 968 services only apply for the upper layer protocols and not for the 969 IP header itself. 971 DES has been officially deprecated by NIST, though it is still 972 mandated by the IPsec framework and is still commonly implemented 973 and used due to it's speed advantage over 3DES. AES will be the 974 successor of 3DES due to its superior encryption and performance 975 advantage. 977 See Also: Transform protocols, Authentication protocols 979 7.10. IPsec Protocols 981 Definition: A suite of protocols which provide a framework of open 982 standards that provides data origin confidentiality, data 983 integrity, and data origin authenticity between participating 984 peers at the IP layer. The original IPsec protocol suite set of 985 standards is documented in [RFC2401] through [RFC2412] and 986 [RFC2451]. At this time [RFC4301] updates [RFC2401] (IPsec 987 Architecture), [RFC4302] updates [RFC2402] (AH) and [RFC4303] 988 updates [RFC2406] (ESP) 990 Discussion: The IPsec Protocol suite is modular and forward 991 compatible. The protocols that comprise the IPsec protocol suite 992 can be replaced with new versions of those protocols as the older 993 versions become obsolete. For example, IKEv2 will soon replace 994 IKEv1. 996 Issues: N/A 998 See Also: AH, ESP 1000 7.10.1. Authentication Header (AH) 1002 Definition: Provides data origin authentication and data integrity 1003 (including replay protection) security services as defined in 1004 [RFC4302]. 1006 Discussion: The AH protocol supports two modes of operation i.e. 1007 tunnel mode and transport mode. 1009 In transport mode, AH is inserted after the IP header and before a 1010 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any 1011 other IPsec headers that have already been inserted. In the 1012 context of IPv4, this calls for placing AH after the IP header 1013 (and any options that it contains), but before the next layer 1014 protocol. In the IPv6 context, AH is viewed as an end-to-end 1015 payload, and thus should appear after hop-by-hop, routing, and 1016 fragmentation extension headers. The destination options 1017 extension header(s) could appear before or after or both before 1018 and after the AH header depending on the semantics desired. 1020 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1021 source and destination addresses, while an "outer" IP header 1022 contains the addresses of the IPsec "peers," e.g., addresses of 1023 security gateways. In tunnel mode, AH protects the entire inner 1024 IP packet, including the entire inner IP header. The position of 1025 AH in tunnel mode, relative to the outer IP header, is the same as 1026 for AH in transport mode. 1028 Issues: AH is rarely used to secure traffic over the Internet. 1030 See Also: Transform protocols, IPsec protocols, Encapsulated 1031 Security Payload 1033 7.10.2. Encapsulated Security Payload (ESP) 1035 Definition: Provides data origin authentication, data integrity 1036 (including replayprotection) and data confidentiality as defined 1037 in [RFC4303]. 1039 Discussion: The ESP protocol supports two modes of operation i.e. 1040 tunnel mode and transport mode. 1042 In transport mode, ESP is inserted after the IP header and before 1043 a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context 1044 of IPv4, this translates to placing ESP after the IP header (and 1045 any options that it contains), but before the next layer protocol. 1046 In the IPv6 context, ESP is viewed as an end-to-end payload, and 1047 thus should appear after hop-by-hop, routing, and fragmentation 1048 extension headers. Destination options extension header(s) could 1049 appear before, after, or both before and after the ESP header 1050 depending on the semantics desired. However, since ESP protects 1051 only fields after the ESP header, it generally will be desirable 1052 to place the destination options header(s) after the ESP header. 1054 In tunnel mode, the "inner" IP header carries the ultimate (IP) 1055 source and destination addresses, while an "outer" IP header 1056 contains the addresses of the IPsec "peers", e.g., addresses of 1057 security gateways. Mixed inner and outer IP versions are allowed, 1058 i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP 1059 protects the entire inner IP packet, including the entire inner IP 1060 header. The position of ESP in tunnel mode, relative to the outer 1061 IP header, is the same as for ESP in transport mode. 1063 Issues: N/A 1064 See Also: Transform protocols, IPsec protocols, Authentication 1065 Header 1067 7.11. NAT Traversal (NAT-T) 1069 Definition: The capability to support IPsec functionality in the 1070 presence of NAT devices. 1072 Discussion: NAT-Traversal requires some modifications to IKE as 1073 defined in [RFC3947]. Specifically, in phase 1, it requires 1074 detecting if the other end supports NAT-Traversal, and detecting 1075 if there are one or more NAT instances along the path from host to 1076 host. In IKE Quick Mode, there is a need to negotiate the use of 1077 UDP encapsulated IPsec packets. 1079 NAT-T also describes how to transmit the original source and 1080 destination addresses to the corresponding IPsec Device. The 1081 original source and destination addresses are used in transport 1082 mode to incrementally update the TCP/IP checksums so that they 1083 will match after the NAT transform (The NAT cannot do this, 1084 because the TCP/IP checksum is inside the UDP encapsulated IPsec 1085 packet). 1087 Issues: N/A 1089 See Also: IKE, ISAKMP, IPsec Device 1091 7.12. IP Compression 1093 Definition: A mechanism as defined in [RFC2393] that reduces the 1094 size of the payload that needs to be encrypted. 1096 Discussion: IP payload compression is a protocol to reduce the size 1097 of IP datagrams. This protocol will increase the overall 1098 communication performance between a pair of communicating hosts/ 1099 gateways ("nodes") by compressing the datagrams, provided the 1100 nodes have sufficient computation power, through either CPU 1101 capacity or a compression coprocessor, and the communication is 1102 over slow or congested links. 1104 IP payload compression is especially useful when encryption is 1105 applied to IP datagrams. Encrypting the IP datagram causes the 1106 data to be random in nature, rendering compression at lower 1107 protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) 1108 ineffective. If both compression and encryption are required, 1109 compression must be applied before encryption. 1111 Issues: N/A 1113 See Also: IKE, ISAKMP, IPsec Device 1115 7.13. Security Context 1117 Definition: A security context is a collection of security 1118 parameters that describe the characteristics of the path that an 1119 IPsec Tunnel will take, all of the IPsec Tunnel parameters and the 1120 effects it has on the underlying protected traffic. Security 1121 Context encompasses protocol suite and security policy. 1123 Discussion: In order to fairly compare multiple IPsec devices it is 1124 imperative that an accurate overview is given of all security 1125 parameters that were used to establish the IPsec Tunnels or 1126 manually created SAs and to secure the traffic between protected 1127 networks. Security Context is not a metric; it is included to 1128 accurately reflect the test environment variables when reporting 1129 the methodology results. To avoid listing too much information 1130 when reporting metrics, we have divided the security context into 1131 an IKE context and an IPsec context. 1133 When merely discussing the behavior of traffic flows through IPsec 1134 devices, an IPsec context MUST be provided. In other cases the 1135 scope of a discussion or report may focus on a more broad set of 1136 behavioral characteristics of the IPsec device, in which case both 1137 an IPsec and an IKE context MUST be provided. 1139 The IPsec context MUST consist of the following elements: 1141 * Manual Keyed Tunnels versus IKE negotiated Tunnels 1143 * Number of IPsec Tunnels or IPsec SA's 1145 * IPsec protocol (AH or ESP) 1147 * IPsec protocol mode (tunnel or transport) 1149 * Authentication algorithm used by AH/ESP 1151 * Encryption algoritm used ESP (if applicable) 1153 * IPsec SA lifetime (traffic and time based) 1154 The IPsec Context MAY also list: 1156 * Selectors 1158 * Fragmentation handling 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 used 1193 - SA Lifetime (part of IPsec context) 1195 * Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd] 1197 * IP Compression [RFC2393] 1198 The IKE context MUST also list: 1200 * Phase 1 mode (main or aggressive) 1202 * Available bandwidth and latency to Certificate Authority server 1203 (if applicable) 1205 Issues: A Security Context will be an important element in 1206 describing the environment where protected traffic is traveling 1207 through. 1209 See Also: IPsec Protocols, Transform Protocols, IKE Phase 1, IKE 1210 phase 2, Selectors, IPsec Tunnel 1212 8. Framesizes 1214 8.1. Layer3 clear framesize 1216 Definition: The total size of the unencrypted L3 PDU. 1218 Discussion: In relation to IPsec this is the size of the IP header 1219 and its payload. It SHALL NOT include any encapsulations that MAY 1220 be applied before the PDU is processed for encryption. 1222 IPv4 example: 46 bytes PDU = 20 bytes IP header + 26 bytes 1223 payload. 1225 The following table represents the min/max packet sizes for a 1226 variety of IP packet types, including raw IPv6, IPv6 with typical 1227 transport headers, and IPv6 with IPsec. 1229 MIN MAX 1230 IPv6 40 1500* 1231 IPv6+UDP 48 1232 IPv6+TCP 60 1233 ICMPv6 88 1234 IPv6+AH+C 64 (transport mode compressed) 1235 IPv6+ESP+C 74 (transport mode compressed 1236 IPv6+T+AH+C 70 (tunnel mode compressed) 1237 IPv6+T+ESP+C 80 (tunnel mode compressed) 1239 Given robust header compression (ROHC), the minimum packet size is 1240 derived as follows, e.g., for tunnel mode ESP: 1242 IPv6 40 bytes 1243 IPsec 34 (ESP, 192-bit ICV) 1244 -+ 1245 IPv6 |- 6 byte ROHC of tunnel and transport headers 1246 TCP | 1247 -+ 1248 total ----------------- 1249 80 bytes 1251 This 80 bytes assumes that the TCP payload is 0 bytes; it may be 1 1252 byte (e.g., data sent reliably but with "NAGLE" off). Similar 1253 ROHC sizes result from UDP sources. 1255 Measurement Units: Bytes 1257 Issues: N/A 1259 See Also: Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 1260 Encrypted Framesize. 1262 8.2. Layer3 encrypted framesize 1264 Definition: The total size of the encrypted L3 PDU. 1266 Discussion: The size of the IP packet and its payload after 1267 encapsulations MAY be applied and the PDU is being processed by 1268 the transform. 1270 For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform 1271 has been applied an unencrypted or clear layer3 framesize of 46 1272 bytes Becomes 96 bytes: 1274 20 bytes outer IP header (tunnel mode) 1275 4 bytes SPI (ESP header) 1276 4 bytes Sequence (ESP Header) 1277 8 bytes IV (IOS ESP-3DES) 1278 46 bytes payload 1279 0 bytes pad (ESP-3DES 64 bit) 1280 1 byte Pad length (ESP Trailer) 1281 1 byte Next Header (ESP Trailer) 1282 12 bytes ESP-HMAC SHA1 96 digest 1284 Measurement Units: Bytes 1286 Issues: N/A 1288 See Also: Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 1289 Encrypted Framesize. 1291 9. Performance Metrics 1293 9.1. IPsec Tunnels Per Second (TPS) 1295 Definition: The measurement unit for the IPsec Tunnel Setup Rate 1296 tests. The rate at which IPsec Tunnels are established per 1297 second. 1299 Discussion: According to [RFC2401] two IPsec Tunnels cannot be 1300 established between the same gateways with the same selectors. 1301 This is to prevent overlapping IPsec Tunnels. If overlapping 1302 IPsec Tunnels are attempted, the error will cause the IPsec Tunnel 1303 setup time to take longer than if the IPsec Tunnel setup was 1304 successful. For this reason, a unique pair of selector sets are 1305 required for IPsec Tunnel Setup Rate testing. 1307 Issues: A unique pair of selector sets are required for TPS testing. 1309 See Also: IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, 1310 IKE Setup Rate, IPsec Setup Rate 1312 9.2. Tunnel Rekeys Per Seconds (TRPS) 1314 Definition: A metric that quantifies the number of IKE Phase 1 or 1315 Phase 2 rekeys per seconds a DUT can correctly process. 1317 Discussion: This metric will be will be primary used with Tunnel 1318 Rekey behavior tests. 1320 TRPS will provide a metric used to see system behavior under 1321 stressful conditions where large volumes of SA's are being rekeyed 1322 at the same time or in a short timespan. 1324 Issues: N/A 1326 See Also: Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey 1327 Rate 1329 9.3. IPsec Tunnel Attempts Per Second (TAPS) 1331 Definition: A metric that quantifies the number of successful and 1332 unsuccessful IPsec Tunnel establishment requests per second. 1334 Discussion: This metric can be used to measure IKE DOS Resilience 1335 behavior test. 1337 TAPS provides an important metric to validate the stability of an 1338 IPsec device, if stressed with valid (large number of IPsec tunnel 1339 establishments per seconds or TPS) or invalid (IKE DOS attacks of 1340 any style) tunnel establishment requests. IPsec Tunnel setups 1341 offered to an IPsec devices can either fail due to lack of 1342 resources in the IPsec device to process all the requests or due 1343 to an IKE DOS attack (usually the former is a result of the 1344 latter). 1346 Issues: If the TAPS increases, the TPS usually decreases, due to 1347 burdening of the DUT with the DOS attack traffic. 1349 See Also: N/A 1351 10. Test Definitions 1353 10.1. Capacity 1355 10.1.1. IKE SA Capacity 1357 Definition: The maximum number of IKE SA's that can be sustained on 1358 an IPsec Device. 1360 Discussion: This metric will represent the quantity of peer a given 1361 IPsec device can establish. It is the maximum number of Active 1362 Tunnels that can be sustained by an IPsec Device. 1364 Measurement Units: IKE SA's 1366 Issues: N/A 1368 See Also: IPsec SA Capacity 1370 10.1.2. IPsec SA Capacity 1372 Definition: The maximum number of IPsec SA's that can be sustained 1373 on an IPsec Device. 1375 Discussion: This metric will represent the quantity of traffic flows 1376 a given IPsec Device can protect. In contrast with the IKE SA 1377 Capacity, the emphasis for this test lies on the number of IPsec 1378 SA's that can be established in the worst case scenario. This 1379 scenario would be a case where 1 IKE SA is used to negotiate 1380 multiple IPsec SA's. It is the maximum number of Active Tunnels 1381 that can be sustained by an IPsec Device where only 1 IKE SA is 1382 used to exchange keying material. 1384 Measurement Units: IPsec SA's 1386 Issues: N/A 1388 See Also: IKE SA Capacity 1390 10.2. Throughput 1392 10.2.1. IPsec Throughput 1394 Definition: The maximum rate through an Active Tunnel at which none 1395 of the offered frames are dropped by the device under test. 1397 Discussion: The IPsec Throughput is almost identically defined as 1398 Throughput in [RFC1242], section 3.17. The only difference is 1399 that the throughput is measured with a traffic flow getting 1400 encrypted and decrypted by an IPsec device. IPsec Throughput is 1401 an end-to-end measurement. 1403 The metric can be represented in two variantions depending on 1404 where measurement is taken in the SUT. One can look at throughput 1405 from a cleartext point of view i.e. find the maximum rate where 1406 clearpackets no longer get dropped. This resulting rate can be 1407 recalculated with an encrypted framesize to represent the 1408 encryption throughput rate. The latter is the preferred method of 1409 representation and shall be called the IPsec Throughput. 1411 Measurement Units: Packets per seconds (pps) 1413 Issues: N/A 1415 See Also: IPsec Encryption Throughput, IPsec Decryption Throughput 1417 10.2.2. IPsec Encryption Throughput 1419 Definition: The maximum encryption rate through an Active Tunnel at 1420 which none of the offered cleartext frames are dropped by the 1421 device under test. 1423 Discussion: Since encryption throughput is not necessarily equal to 1424 the decryption throughput, both of the forwarding rates must be 1425 measured independently. The independent forwarding rates have to 1426 measured with the help of an IPsec aware test device that can 1427 originate and terminate IPsec and IKE SA. As defined in 1428 [RFC1242], measurements should be taken with an assortment of 1429 frame sizes. 1431 Measurement Units: Packets per seconds (pps) 1433 Issues: In some cases packets are offered to an IPsec Device that 1434 have a framesize that is larger then the MTU of the ingress 1435 interface of the IPsec Tunnel that is transporting the packet. In 1436 this case fragmentation will be required before IPsec services are 1437 applied. 1439 In other cases, the packet is of a size very close to the MTU of 1440 the egress interface of the IPsec Tunnel. Here, the mere addition 1441 of the IPsec header will create enough overhead to make the IPsec 1442 packet larger then the MTU of the egress interface. In such 1443 instance, the original payload packet must be fragmented either 1444 before or after the IPsec overhead is applied. 1446 Note that the two aforementioned scenario's can happen 1447 simultaniously on a single packet, creating multiple small 1448 fragments. 1450 When measuring the IPsec Encryption Throughput, one has to 1451 consider that when probing with packets of a size near MTU's 1452 associated with the IPsec Tunnel, fragmentation may accor and the 1453 decrypting IPsec Device (either a tester or a corresponding IPsec 1454 peer) has to reassemble the IPsec and/or payload fragments to 1455 validate its content. 1457 The end points (i.e. hosts, subnets) should NOT see any fragments 1458 at ANY time. Only on the IPsec link, fragments MAY occur. 1460 See Also: IPsec Throughput, IPsec Decryption Throughput 1462 10.2.3. IPsec Decryption Throughput 1464 Definition: The maximum decryption rate through an Active Tunnel at 1465 which none of the offered encrypted frames are dropped by the 1466 device under test. 1468 Discussion: Since encryption throughput is not necessarily equal to 1469 the decryption throughput, both of the forwarding rates must be 1470 measured independently. 1472 The independent forwarding rates have to be measured with the help 1473 of an IPsec aware test device that can originate and terminate 1474 IPsec and IKE SA. As defined in [RFC1242], measurements should be 1475 taken with an assortment of frame sizes. 1477 Measurement Units: Packets per seconds (pps) 1479 Issues: When measuring the IPsec Decryption Throughput, one has to 1480 consider that it is likely that the encrypting IPsec Device has to 1481 fragment certain packets that have a frame size near MTU's 1482 associated with the IPsec Tunnel. 1484 The decrypting IPsec Device has to reassemble the IPsec and/or 1485 payload fragments to validate its content. 1487 The end points (i.e. hosts, subnets) should NOT see any fragments 1488 at ANY time. Only on the IPsec link, fragments MAY occur. 1490 See Also: IPsec Throughput, IPsec Encryption Throughput 1492 10.3. Latency 1494 10.3.1. IPsec Latency 1496 Definition: Time required to propagate a cleartext frame from the 1497 input interface of an initiator, through an Active Tunnel, to the 1498 output interface of the responder. 1500 Discussion: The IPsec Latency is the time interval starting when the 1501 end of the first bit of the cleartext frame reaches the input 1502 interface of the initiator and ending when the start of the first 1503 bit of the same cleartext frame is detected on the output 1504 interface of the responder. The frame has passed through an 1505 Active Tunnel between an initiator and a responder and has been 1506 through an encryption and decryption cycle. 1508 Measurement Units: Time units with enough precision to reflect 1509 latency measurement. 1511 Issues: N/A 1513 See Also: IPsec Encryption Latency, IPsec Decryption Latency 1515 10.3.2. IPsec Encryption Latency 1517 Definition: The IPsec Encryption Latency is the time interval 1518 starting when the end of the first bit of the cleartext frame 1519 reaches the input interface, through an Active Tunnel, and ending 1520 when the start of the first bit of the encrypted output frame is 1521 seen on the output interface. 1523 Discussion: IPsec Encryption Latency is the latency introduced when 1524 encrypting traffic through an IPsec tunnel. 1526 Like encryption/decryption throughput, it is not always the case 1527 that encryption latency equals the decryption latency. Therefore 1528 a distinction between the two has to be made in order to get a 1529 more accurate view of where the latency is the most pronounced. 1531 The independent encryption/decryption latencies have to be 1532 measured with the help of an IPsec aware test device that can 1533 originate and terminate IPsec and IKE SA. As defined in 1534 [RFC1242], measurements should be taken with an assortment of 1535 frame sizes. 1537 Measurement Units: Time units with enough precision to reflect 1538 latency measurement. 1540 Issues: N/A 1542 See Also: IPsec Latency, IPsec Decryption Latency 1544 10.3.3. IPsec Decryption Latency 1546 Definition: The IPsec decryption Latency is the time interval 1547 starting when the end of the first bit of the encrypted frame 1548 reaches the input interface, through an Active Tunnel, and ending 1549 when the start of the first bit of the decrypted output frame is 1550 seen on the output interface. 1552 Discussion: IPsec Decryption Latency is the latency introduced when 1553 decrypting traffic through an Active Tunnel. Like encryption/ 1554 decryption throughput, it is not always the case that encryption 1555 latency equals the decryption latency. Therefore a distinction 1556 between the two has to be made in order to get a more accurate 1557 view of where the latency is the most pronounced. 1559 The independent encryption/decryption latencies have to be 1560 measured with the help of an IPsec aware test device that can 1561 originate and terminate IPsec and IKE SA's. As defined in 1562 [RFC1242], measurements should be taken with an assortment of 1563 frame sizes. 1565 Measurement Units: Time units with enough precision to reflect 1566 latency measurement. 1568 Issues: N/A 1570 See Also: IPsec Latency, IPsec Encryption Latency 1572 10.3.4. Time To First Packet 1574 Definition: The Time To First Packet (TTFP) is the time required to 1575 process a cleartext packet from a traffic stream that requires 1576 encryption services when no IPsec Tunnel is present. 1578 Discussion: The Time To First Packet addresses the issue of 1579 responsiveness of an IPsec device by looking how long it takes to 1580 transmit a packet over Configured Tunnel. The Time To First 1581 Packet MUST include the time to set up the established tunnel, 1582 triggered by the traffic flow (both phase 1 and phase 2 setup 1583 times SHALL be included) and the time it takes to encrypt and 1584 decrypt the packet on a corresponding peer. In short it is the 1585 IPsec Tunnel setup time plus the propagation delay of the packet 1586 through the Active Tunnel. 1588 It must be noted that it is highly unlikely that the first packet 1589 of the traffic flow will be the packet that will be used to 1590 measure the TTFP. There MAY be several protocol layers in the 1591 stack before the tunnel is formed and the traffic is forwarded, 1592 hence several packets COULD be lost during negotiation, for 1593 example, ARP and/or IKE. 1595 Measurement Units: Time units with enough precision to reflect a 1596 TTFP measurement. 1598 Issues: Only relevant when using IKE for tunnel negotiation. 1600 10.4. Frame Loss 1602 10.4.1. IPsec Frame Loss 1604 Definition: Percentage of cleartext frames that should have been 1605 forwarded through an Active Tunnel under steady state (constant) 1606 load but were dropped before encryption or after decryption. 1608 Discussion: The IPsec Frame Loss is almost identically defined as 1609 Frame Loss Rate in [RFC1242], section 3.6. The only difference is 1610 that the IPsec Frame Loss is measured with a traffic flow getting 1611 encrypted and decrypted by an IPsec Device. IPsec Frame Loss is 1612 an end-to-end measurement. 1614 Measurement Units: Percent (%) 1616 Issues: N/A 1618 See Also: IPsec Encryption Frame Loss, IPsec Decryption Frame Loss 1620 10.4.2. IPsec Encryption Frame Loss 1622 Definition: Percentage of cleartext frames that should have been 1623 encrypted through an Active Tunnel under steady state (constant) 1624 load but were dropped. 1626 Discussion: A DUT will always have an inherent forwarding 1627 limitation. This will be more pronounced when IPsec is employed 1628 on the DUT. There is a possibility that the offered traffic rate 1629 at the Active Tunnel is too high to be transported through the 1630 Active Tunnel and not all cleartext packets will get encrypted. 1631 In that case, some percentage of the cleartext traffic will be 1632 dropped. This drop percentage is called the IPsec Encryption 1633 Frame Loss. 1635 Measurement Units: Percent (%) 1637 Issues: N/A 1639 See Also: IPsec Frame Loss, IPsec Decryption Frame Loss 1641 10.4.3. IPsec Decryption Frame Loss 1642 Definition: Percentage of encrypted frames that should have been 1643 decrypted through an Active Tunnel under steady state (constant) 1644 load but were dropped. 1646 Discussion: A DUT will also have an inherent forwarding limitation 1647 when decrypting packets. When Active Tunnel encrypted traffic is 1648 offered at a costant load, there might be a possibility that the 1649 IPsec Device that needs to decrypt the traffic will not be able to 1650 perfom this action on all of the packets due to limitations of the 1651 decryption performance. The percentage of encrypted frames that 1652 would get dropped under these conditions is called the IPsec 1653 Decryption Frame Loss. 1655 Measurement Units: Percent (%) 1657 Issues: N/A 1659 See Also: IPsec Frame Loss, IPsec Encryption Frame Loss 1661 10.4.4. IKE Phase 2 Rekey Frame Loss 1663 Definition: Number of frames dropped as a result of an inefficient 1664 IKE Phase 2 rekey. 1666 Discussion: Normal operation of an IPsec Device would require that a 1667 rekey does not create temporary IPsec Frame Loss of a traffic 1668 stream that is protected by the IKE Phase 2 SA's (i.e. IPsec 1669 SA's). Nevertheless there can be situations where IPsec Frame 1670 Loss occurs during this rekey process. 1672 This metric should be ideally zero but this may not be the case on 1673 IPsec Devices where IPsec funtionality is not a core feature. 1675 Measurement Units: Number of N-octet frames 1677 Issues: N/A 1679 See Also: IKE Phase 2 Rekey Rate 1681 10.5. Back-to-back Frames 1683 10.5.1. IPsec Back-to-back Frames 1685 Definition: A burst of cleartext frames, offered at a constant load 1686 that can be sent through an Active Tunnel without losing a single 1687 cleartext frame after decryption. 1689 Discussion: The IPsec Back-to-back Frames is almost identically 1690 defined as Back-to-back in [RFC1242], section 3.1. The only 1691 difference is that the IPsec Back-to-back Frames is measured with 1692 a traffic flow getting encrypted and decrypted by an IPsec Device. 1693 IPsec Back-to-back Frames is an end-to-end measurement. 1695 Measurement Units: Number of N-octet frames in burst. 1697 Issues: Recommended test frame sizes will be addressed in 1698 methodology document. 1700 See Also: IPsec Encryption Back-to-back frames, IPsec Decryption 1701 Back-to-back frames 1703 10.5.2. IPsec Encryption Back-to-back Frames 1705 Definition: A burst of cleartext frames, offered at a constant load 1706 that can be sent through an Active Tunnel without losing a single 1707 encrypted frame. 1709 Discussion: IPsec Encryption back-to-back frames is the measure of 1710 the maximum burst size that an IPsec Device can handle for 1711 encrypting traffic that it receives as plaintext. Since it is not 1712 necessarily the case that the maximum burst size a DUT can handle 1713 for encryption is equal to the maximum burst size a DUT can handle 1714 for decryption, both of these capabilities must be measured 1715 independently. The IPsec Encryption Back-to-back frame 1716 measurement has to be measured with the help of an IPsec aware 1717 test device that can decrypt the traffic to determine the validity 1718 of the encrypted frames. 1720 Measurement Units: Number of N-octet frames in burst. 1722 Issues: Recommended test frame sizes will be addressed in future 1723 methodology document. 1725 See Also: IPsec Back-to-back frames, IPsec Decryption Back-to-back 1726 frames 1728 10.5.3. IPsec Decryption Back-to-back Frames 1730 Definition: The number of encrypted frames, offered at a constant 1731 load, that can be sent through an Active Tunnel without losing a 1732 single cleartext frame. 1734 Discussion: IPsec Decryption Back-to-back frames is the measure of 1735 the maximum burst size that an IPsec Device can handle for 1736 decrypting traffic that it receives as encrypted traffic. Since 1737 it is not necessarily the case that the maximum burst size a DUT 1738 can handle for decryption is equal to the maximum burst size a DUT 1739 can handle for encryption, both of these capabilities must be 1740 measured independently. The IPsec Decryption Back-to-back frame 1741 measurement has to be measured with the help of an IPsec aware 1742 testdevice that can determine the validity of the decrypted 1743 frames. 1745 Measurement Units: Number of N-octet frames in burst. 1747 Issues: Recommended test frame sizes will be addressed in 1748 methodology document. 1750 See Also: IPsec Back-to-back frames, IPsec Encryption back-to-back 1751 frames 1753 10.6. Tunnel Setup Behavior 1755 10.6.1. IPsec Tunnel Setup Rate 1757 Definition: The maximum number of IPsec Tunnels per second that an 1758 IPsec Device can successfully establish. 1760 Discussion: The Tunnel Setup Rate SHOULD be measured at varying 1761 number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the 1762 DUT. Several factors may influence Tunnel Setup Rate, such as: 1763 TAPS rate, Background cleartext traffic load on the secure 1764 interface, Already established IPsec Tunnels, Authentication 1765 method such as pre-shared keys, RSA-encryption, RSA-signature, DSS 1766 Key sizes used (when using RSA/DSS). 1768 Measurement Units: Tunnels Per Second (TPS) 1770 Issues: N/A 1772 See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec 1773 Tunnel Rekey Behavior 1775 10.6.2. IKE Phase 1 Setup Rate 1777 Definition: The maximum number of sucessful IKE Phase 1 SA's per 1778 second that an IPsec Device can establish. 1780 Discussion: The Phase 1 Setup Rate is a portion of the IPsec Tunnel 1781 Setup Rate. In the process of establishing an IPsec Tunnel, it is 1782 interesting to know what the limiting factor of the IKE Finite 1783 State Machine (FSM) is i.e. is it limited by the Phase 1 1784 processing delays or rather by the Phase 2 processing delays. 1786 Measurement Units: Tunnels Per Second (TPS) 1788 Issues: N/A 1790 See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec 1791 Tunnel Rekey Behavior 1793 10.6.3. IKE Phase 2 Setup Rate 1795 Definition: The maximum number of successfully IKE Phase 2 SA's per 1796 second that an IPsec Device can Only relevant when using IKE 1797 establish. 1799 Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec 1800 Tunnel Setup Rate. For identical reasons why it is required to 1801 quantify the IKE Phase 1 Setup Rate, it is a good practice to know 1802 the processing delays involved in setting up an IKE Phase 2 SA for 1803 each direction of the protected traffic flow. 1805 IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of 1806 two IKE Phase 2 SA's. 1808 Note that once you have the IPsec Tunnel Setup Rate and either the 1809 IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can 1810 extrapolate the unmeasured metric. It is however highly 1811 RECOMMENDED to measure all three metrics. 1813 Measurement Units: Tunnels Per Second (TPS) 1815 Issues: N/A 1817 See Also: IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec 1818 Tunnel Rekey Behavior 1820 10.7. IPsec Tunnel Rekey Behavior 1822 10.7.1. IKE Phase 1 Rekey Rate 1824 Definition: The number of IKE Phase 1 SA's that can be succesfully 1825 re-establish per second. 1827 Discussion: Although the IKE Phase 1 Rekey Rate has less impact on 1828 the forwarding behavior of traffic that requires security services 1829 then the IKE Phase 2 Rekey Rate, it can pose a large burden on the 1830 CPU or network processor of the IPsec Device. Due to the highly 1831 computational nature of a Phase 1 exchange, it may impact the 1832 stability of Active Tunnels in the network when the IPsec Device 1833 fails to properly rekey an IKE Phase 1 SA. 1835 Measurement Units: Tunnel Rekeys per second (TRPS) 1837 Issues: N/A 1839 See Also: IKE Phase 2 Rekey Rate 1841 10.7.2. IKE Phase 2 Rekey Rate 1843 Definition: The number of IKE Phase 2 SA's that can be succesfully 1844 re-negotiated per second. 1846 Discussion: Although many implementations will usually derive new 1847 keying material before the old keys expire, there may still be a 1848 period of time where frames get dropped before the IKE Phase 2 1849 tunnels are successfully re-established. There may also be some 1850 packet loss introduced when the handover of traffic is done from 1851 the expired IPsec SA's to the newly negotiated IPsec SA's. To 1852 measure the IKE Phase 2 rekey rate, the measurement will require 1853 an IPsec aware test device to act as a responder when negotiating 1854 the new IKE Phase 2 keying material. 1856 The test methodology report must specify if PFS is enabled in 1857 reported security context. 1859 Measurement Units: Tunnel Rekeys per second (TRPS) 1861 Issues: N/A 1863 See Also: IKE Phase 1 Rekey Rate 1865 10.8. IPsec Tunnel Failover Time 1867 Definition: Time required to recover all IPsec Tunnels on a stanby 1868 IPsec Device, after a catastrophic failure occurs on the active 1869 IPsec Device. 1871 Discussion: Recovery time required to re-establish all IPsec Tunnels 1872 and reroute all traffic on a standby node or other failsafe system 1873 after a failure has occurred in the DUT/SUT. Failure can include 1874 but are not limited to a catastrophic IPsec Device failure, a 1875 encryption engine failure, link outage, etc ... . The recovery 1876 time is delta between the point of failure and the time the first 1877 packet is seen on the last restored IPsec Tunnel on the backup 1878 device. 1880 Measurement Units: Time units with enough precision to reflect IPsec 1881 Tunnel Failover Time. 1883 Issues: N/A 1885 10.9. DoS Attack Resiliency 1887 10.9.1. Phase 1 DoS Resiliency Rate 1889 Definition: The Phase 1 Denial of Service (DoS) Resilience Rate 1890 quantifies the rate of invalid or malicious IKE tunnels that can 1891 be directed at a DUT before the Responder stops accepting valid 1892 tunnel attempts. 1894 Discussion: Phase 1 DoS attacks can present themselves in various 1895 forms and do not necessarily have to have a malicious background. 1896 It is sufficient to make a typographical error in a shared secret 1897 in an IPsec Device to be susceptible to a large number of IKE 1898 attempts that need to be turned down. Due to the intense 1899 computational nature of an IKE exchange every single IKE tunnel 1900 attempt that has to be denied will take non-negligible CPU cycles 1901 in the IPsec Device. 1903 Depending on the quantity of these messages that have to be 1904 processed, a system might end up in a state that the burden on the 1905 CPU of doing key exchanges is high enough that the entire CPU is 1906 consumed by this process. At this point it will be no longer 1907 possible to process a valid IKE tunnel setup request and thus a 1908 Phase 1 DoS Attack is in effect. 1910 The scope of the attack profile for this test will include 1911 mismatched pre-shared keys as well as invalid digital 1912 certificates. 1914 Measurement Units: Tunnel Attempts Per Seconds (TAPS) 1916 Issues: N/A 1918 10.9.2. Phase 2 DoS Resiliency Rate 1919 Definition: The Phase 2 Denial of Service (DoS) Resilience Rate 1920 quantifies the rate of invalid ESP/AH packets that a DUT can drop 1921 without affecting the traffic flow of valid ESP/AH packets. 1923 Discussion: Phase 2 DoS attacks can present themselves in various 1924 forms and do not necessarily have to have a malicious background, 1925 but usually are. A well know case where there is no malicious 1926 intent is when packets are dropped due to anti-replay errors, 1927 which can be caused by applying a queueing mechanism after 1928 encryption. More typical are cases where there is a true 1929 malicious intent in the ESP/AH traffic flow by e.g. having an 1930 invalid hash in the IPsec data packets. 1932 Depending on the quantity of these packets that have to be 1933 processed, a system might end up in a state that the burden on the 1934 IPsec Device becomes large enough that it will impact valid 1935 traffic flows. At this point it will be no longer possible to 1936 forward valid IPsec payload without packetloss and thus a Phase 2 1937 DoS Attack is in effect. 1939 Measurement Units: Packets per seconds (pps) 1941 Issues: N/A 1943 11. Security Considerations 1945 As this document is solely for the purpose of providing test 1946 benchmarking terminology and describes neither a protocol nor a 1947 protocol's implementation; there are no security considerations 1948 associated with this document. 1950 12. Acknowledgements 1952 The authors would like to acknowledge the following individual for 1953 their participation of the compilation and editing of this document 1954 and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian 1955 Talbert. 1957 13. References 1959 13.1. Normative References 1961 [RFC1242] Bradner, S., "Benchmarking terminology for network 1962 interconnection devices", RFC 1242, July 1991. 1964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1965 Requirement Levels", BCP 14, RFC 2119, March 1997. 1967 [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN 1968 Switching Devices", RFC 2285, February 1998. 1970 [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP 1971 Payload Compression Protocol (IPComp)", RFC 2393, 1972 December 1998. 1974 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1975 Internet Protocol", RFC 2401, November 1998. 1977 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 1978 RFC 2402, November 1998. 1980 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 1981 ESP and AH", RFC 2403, November 1998. 1983 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1984 ESP and AH", RFC 2404, November 1998. 1986 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 1987 Algorithm With Explicit IV", RFC 2405, November 1998. 1989 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 1990 Payload (ESP)", RFC 2406, November 1998. 1992 [RFC2407] Piper, D., "The Internet IP Security Domain of 1993 Interpretation for ISAKMP", RFC 2407, November 1998. 1995 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 1996 Security Association and Key Management Protocol 1997 (ISAKMP)", RFC 2408, November 1998. 1999 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2000 (IKE)", RFC 2409, November 1998. 2002 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 2003 Its Use With IPsec", RFC 2410, November 1998. 2005 [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security 2006 Document Roadmap", RFC 2411, November 1998. 2008 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 2009 RFC 2412, November 1998. 2011 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2012 Algorithms", RFC 2451, November 1998. 2014 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 2015 Network Interconnect Devices", RFC 2544, March 1999. 2017 [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, 2018 March 1999. 2020 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 2021 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 2022 RFC 2661, August 1999. 2024 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2025 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2026 March 2000. 2028 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 2029 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 2030 January 2005. 2032 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2033 Internet Protocol", RFC 4301, December 2005. 2035 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2036 December 2005. 2038 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2039 RFC 4303, December 2005. 2041 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2042 RFC 4306, December 2005. 2044 [I-D.ietf-ipsec-ikev2] 2045 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2046 draft-ietf-ipsec-ikev2-17 (work in progress), 2047 October 2004. 2049 [I-D.ietf-ipsec-dpd] 2050 Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- 2051 Based Method of Detecting Dead IKE Peers", 2052 draft-ietf-ipsec-dpd-04 (work in progress), October 2003. 2054 [I-D.ietf-ipsec-properties] 2055 Krywaniuk, A., "Security Properties of the IPsec Protocol 2056 Suite", draft-ietf-ipsec-properties-02 (work in progress), 2057 July 2002. 2059 [FIPS.186-1.1998] 2060 National Institute of Standards and Technology, "Digital 2061 Signature Standard", FIPS PUB 186-1, December 1998, 2062 . 2064 13.2. Informative References 2066 [Designing Network Security] 2067 Kaeo, M., "Designing Network Security", ISBN: 1578700434, 2068 Published: May 07, 1999; Copyright: 1999, 1999. 2070 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 2071 Mechanism for Internet", from IEEE Proceedings of the 2072 1996 Symposium on Network and Distributed Systems 2073 Security, 2074 URI http://www.research.ibm.com/security/skeme.ps, 1996. 2076 Authors' Addresses 2078 Merike Kaeo 2079 Double Shot Security 2080 3518 Fremont Ave N #363 2081 Seattle, WA 98103 2082 USA 2084 Phone: +1(310)866-0165 2085 Email: kaeo@merike.com 2087 Tim Van Herck 2088 Cisco Systems 2089 170 West Tasman Drive 2090 San Jose, CA 95134-1706 2091 USA 2093 Phone: +1(408)853-2284 2094 Email: herckt@cisco.com 2096 Michele Bustos 2097 IXIA 2098 26601 W. Agoura Rd. 2099 Calabasas, CA 91302 2100 USA 2102 Phone: +1(818)444-3244 2103 Email: mbustos@ixiacom.com 2105 Full Copyright Statement 2107 Copyright (C) The IETF Trust (2007). 2109 This document is subject to the rights, licenses and restrictions 2110 contained in BCP 78, and except as set forth therein, the authors 2111 retain all their rights. 2113 This document and the information contained herein are provided on an 2114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2116 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2117 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2118 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2121 Intellectual Property 2123 The IETF takes no position regarding the validity or scope of any 2124 Intellectual Property Rights or other rights that might be claimed to 2125 pertain to the implementation or use of the technology described in 2126 this document or the extent to which any license under such rights 2127 might or might not be available; nor does it represent that it has 2128 made any independent effort to identify any such rights. Information 2129 on the procedures with respect to rights in RFC documents can be 2130 found in BCP 78 and BCP 79. 2132 Copies of IPR disclosures made to the IETF Secretariat and any 2133 assurances of licenses to be made available, or the result of an 2134 attempt made to obtain a general license or permission for the use of 2135 such proprietary rights by implementers or users of this 2136 specification can be obtained from the IETF on-line IPR repository at 2137 http://www.ietf.org/ipr. 2139 The IETF invites any interested party to bring to its attention any 2140 copyrights, patents or patent applications, or other proprietary 2141 rights that may cover technology that may be required to implement 2142 this standard. Please address the information to the IETF at 2143 ietf-ipr@ietf.org. 2145 Acknowledgment 2147 Funding for the RFC Editor function is provided by the IETF 2148 Administrative Support Activity (IASA).