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