[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

  Network Working Group                                  Michele Bustos
  INTERNET-DRAFT                                                   IXIA
  Expires in:  August 2003                                Tim Van Herck
                                                                  Cisco
                                                            Merike Kaeo
                                                           Merike, Inc.
  
                Terminology for Benchmarking IPsec Devices
                   <draft-ietf-bmwg-ipsec-term-00.txt>
  
  
  Status of this Memo
  
     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.
  
     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."
  
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
  
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
  
  
  Copyright Notice
  
     Copyright (C) The Internet Society (2003).  All Rights Reserved.
  
  
  Abstract
  
     This purpose of this document is to define terminology specific to
     measuring the performance of IPsec devices.  It builds upon the
     tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF
     Benchmarking Methodology Working Group (BMWG) documents used for
     benchmarking routers and switches.  This document seeks to extend
     these efforts specific to the IPsec paradigm.  The BMWG produces
     two major classes of documents: Benchmarking Terminology documents
     and Benchmarking Methodology documents. The Terminology documents
     present the benchmarks and other related terms. The Methodology
     documents define the procedures required to collect the benchmarks
     cited in the corresponding Terminology documents.
  
  
  
  Bustos, Van Herck & Kaeo                                   [Page 1]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
                            Table of Contents
  
  1. INTRODUCTION...................................................4
  1.1. IPsec Fundamentals...........................................4
  1.2. IPsec Operation..............................................6
  1.2.1.  Security Associations.....................................6
  1.2.2.  Key Management............................................6
  1.2.3.  Using the term 'Tunnel'...................................8
  2. DOCUMENT SCOPE.................................................8
  
  3. DEFINITION FORMAT..............................................8
  
  4. KEY WORDS TO REFLECT REQUIREMENTS..............................9
  
  5. EXISTING DEFINITIONS...........................................9
  
  6. TERM DEFINITIONS..............................................10
  6.1. IPsec.......................................................10
  6.2. IPsec Device................................................10
  6.3. ISAKMP......................................................11
  6.4. IKE.........................................................11
  6.5. Initiator...................................................12
  6.6. Responder...................................................12
  6.7. Security Association (SA)...................................13
  6.8. IKE Phase 1.................................................13
  6.8.1.  Phase 1 Main Mode........................................13
  6.8.2.  Phase 1 Aggressive Mode..................................14
  6.9. IKE Phase 2.................................................14
  6.9.1.  Phase 2 Quick Mode.......................................14
  6.9.2.  IPsec Tunnel.............................................15
  6.10. Compound Tunnels...........................................15
  6.10.1. Nested Tunnels...........................................15
  6.10.2. Transport Adjacency......................................16
  6.11. Transform Protocols........................................17
  6.11.1. Authentication protocols.................................17
  6.11.2. Encryption protocols.....................................17
  6.12. IPsec Protocols............................................18
  6.12.1. Authentication Header (AH)...............................18
  6.12.2. Encapsulated Security Payload (ESP)......................18
  6.13. Selectors..................................................19
  6.14. NAT Traversal (NAT-T)......................................19
  6.15. IP Compression.............................................20
  6.16. Security Context...........................................20
  6.17. Performance Metrics........................................21
  6.17.1. Tunnels Per Second (TPS).................................21
  6.17.2. Tunnel Flaps Per Second (TFPS)...........................21
  6.17.3. Tunnels Attempted Per Second (TAPS)......................22
  7. TEST TERMINOLOGY..............................................22
  7.1. Framesizes..................................................22
  7.1.1.  Layer3 Clear Framesize...................................22
  
  Bustos, Van Herck & Kaeo    [Page 2]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  7.1.2.  Layer3 Encrypted Framesize...............................22
  7.1.3.  Layer2 Clear Framesize...................................23
  7.1.4.  Layer2 encrypted framesize...............................24
  7.2. Internet Mix Traffic (IMIX).................................24
  7.3. Throughput..................................................25
  7.3.1.  IPsec Tunnel Throughput..................................25
  7.3.2.  IPsec Tunnel Encryption Throughput.......................25
  7.3.3.  IPsec Tunnel Decryption Throughput.......................26
  7.4. Latency.....................................................26
  7.4.1.  IPsec Tunnel Encryption Latency..........................26
  7.4.2.  IPsec Tunnel Decryption Latency..........................27
  7.4.3.  Time To First Packet (TTFP)..............................28
  7.5. Frame Loss Rate.............................................28
  7.5.1.  IPsec Tunnel Encryption Frame Loss Rate..................28
  7.5.2.  IPsec Tunnel Decryption Frame Loss Rate..................29
  7.6. Back-to-Back................................................29
  7.6.1.  Encryption Back-to-Back Frames...........................29
  7.6.2.  Decryption Back-to-back frames...........................29
  7.7. Tunnel Setup Rate Behavior..................................30
  7.7.1.  Tunnel Setup Rate........................................30
  7.7.2.  IKE Tunnel Setup Rate....................................30
  7.7.3.  IPsec Tunnel Setup Rate..................................31
  7.8. Tunnel Rekey................................................31
  7.8.1.  Phase 1 Rekey Time.......................................31
  7.8.2.  Phase 2 Rekey Time.......................................31
  7.9. Tunnel Flapping.............................................32
  7.9.1.  Tunnel Flap Rate.........................................32
  7.10. Tunnel Failover Time (TFT).................................33
  7.11. IKE DOS Resilience Rate....................................33
  8. SECURITY CONSIDERATIONS.......................................34
  
  9. ACKNOWLEDGEMENTS..............................................34
  
  10. CONTRIBUTORS.................................................34
  
  11. REFERENCES...................................................34
  
  12. CONTACT INFORMATION..........................................37
  
  13. FULL COPYRIGHT STATEMENT.....................................37
  
  
  
  
  
  
  
  
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 3]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
  1. Introduction
  
     Despite the need to secure communications over a public medium
     there is no standard method of performance measurement nor a
     standard in the terminology used to develop such hardware/software
     solutions.   This results in varied implementations which challenge
     interoperability and direct performance comparisons. Standardized
     IPsec terminology and performance test methodologies will enable
     users to decide if the IPsec device they select will withstand
     relatively heavy loads of secured traffic.
  
     To appropriately define the parameters and scope of this document,
     this section will give a brief overview of the IPsec standard.
  
  
  1.1. IPsec Fundamentals
  
     IPsec is a framework of open standards that provides data
     confidentiality, data integrity, and data authentication between
     participating peers. IPsec provides these security services at the
     IP layer.  IPsec uses IKE to handle negotiation of protocols and
     algorithms based on local policy, and to generate the encryption
     and authentication keys to be used.  IPsec can be used to protect
     one or more data flows between a pair of hosts, between a pair of
     security gateways, or between a security gateway and a host. The
     IPsec protocol suite set of standards is documented in RFC's 2401
     through 2412 and RFC 2451.  The reader is assumed to be familiar
     with these documents. Some Internet Drafts supersede these RFC's
     and will be taken into consideration. Mainly it will encompass
     current work in progress on NAT Traversal and updates to AH, ESP,
     and IKE.
  
     IPsec itself defines the following:
  
     Authentication Header (AH):
          A security protocol, defined in RFC 2402, which provides data
          authentication and optional anti-replay services. AH ensures
          the integrity and data origin authentication of the IP
          datagram as well as the invariant fields in the outer IP
          header.
  
     Encapsulating Security Payload (ESP):
          A security protocol, defined in RFC 2406, which provides
          confidentiality, data origin authentication, connectionless
          integrity, an anti-replay service and limited traffic flow
          confidentiality.  The set of services provided depends on
          options selected at the time of Security Association (SA)
          establishment and on the location of the implementation in a
          network topology. ESP authenticates only headers and data
          after the IP header.
  
  
  Bustos, Van Herck & Kaeo    [Page 4]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Internet Key Exchange (IKE):
          A hybrid protocol which implements Oakley and SKEME key
          exchanges inside the ISAKMP framework. While IKE can be used
          with other protocols, its initial implementation is with the
          IPsec protocol. IKE provides authentication of the IPsec
          peers, negotiates IPsec security associations, and establishes
          IPsec keys. Note that IKE is an optional protocol within the
          IPsec framework and keys can also be manually configured.
  
     The AH and ESP protocols each support two modes of operation:
     transport mode and tunnel mode.  In transport mode, two hosts
     provide protection primarily for upper-layer protocols. The
     cryptographic endpoints (where the encryption and decryption take
     place) are the source and destination of the data packet. In IPv4,
     a transport mode security protocol header appears immediately after
     the IP header and before any higher-layer protocols (such as TCP or
     UDP).
  
     In the case of AH in transport mode, all upper-layer information is
     protected, and all fields in the IPv4 header excluding the fields
     typically are modified in transit. The fields of the IPv4 header
     that are not included are, therefore, set to 0 before applying the
     authentication algorithm. These fields are as follows:
          o TOS
          o TTL
          o Header Checksum
          o Offset
          o Flags
  
     In the case of ESP in transport mode, security services are provide
     only for the higher-layer protocols, not for the IP header.  A
     tunnel is a vehicle for encapsulating packets inside a protocol
     that is understood at the entry and exit points of a given network.
     These entry and exit points are defined as tunnel interfaces.
  
     Tunnel mode can be supported by data packet endpoints as well as by
     intermediate security gateways. In tunnel mode, there is an "outer"
     IP header that specifies the IPsec processing destination, plus an
     "inner" IP header that specifies the ultimate destination for the
     packet. The source address in the outer IP header is the initiating
     cryptographic endpoint; the source address in the inner header is
     the true source address of the packet. The security protocol header
     appears after the outer IP header and before the inner IP header.
  
     If AH is employed in tunnel mode, portions of the outer IP header
     are given protection (those same fields as for transport mode,
     described earlier in this section), as well as all of the tunneled
     IP packet (that is, all of the inner IP header is protected as are
     the higher-layer protocols). If ESP is employed, the protection is
     afforded only to the tunneled packet, not to the outer header.
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 5]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  1.2. IPsec Operation
  1.2.1. Security Associations
  
     The concept of a Security Association (SA) is fundamental to IPsec.
     An SA is a relationship between two or more entities that describes
     how the entities will use security services to communicate
     securely. The SA includes: an encryption algorithm, an
     authentication algorithm and a shared session key.
  
     Because an SA is unidirectional, two SAs (one in each direction)
     are required to secure typical, bidirectional communication between
     two entities. The security services associated with an SA can be
     used for AH or ESP, but not for both. If both AH and ESP protection
     is applied to a traffic stream, two (or more) SAs are created for
     each direction to protect the traffic stream.
  
     The SA is uniquely identified by the security parameter index (SPI)
     [RFC2408].  When a system sends a packet that requires IPsec
     protection, it looks up the SA in its database and applies the
     specified processing and security protocol (AH/ESP), inserting the
     SPI from the SA into the IPsec header.  When the IPsec peer
     receives the packet, it looks up the SA in its database by
     destination address, protocol, and SPI and then processes the
     packet as required.
  
  1.2.2. Key Management
  
     IPsec uses cryptographic keys for authentication/integrity and
     encryption services. Both manual and automatic distribution of keys
     is supported. IKE is specified as the public-key-based approach for
     automatic key management.
  
     IKE authenticates each peer involved in IPsec, negotiates the
     security policy, and handles the exchange of session keys. IKE is a
     hybrid protocol, combining parts of the following protocols to
     negotiate and derive keying material for SAs in a secure and
     authenticated manner:
       o ISAKMP (Internet Security Association and Key Management
          Protocol), which provides a framework for authentication and
          key exchange but does not define them. ISAKMP is designed to
          be key exchange independent; that is, it is designed to
          support many different key exchanges.
       o Oakley, which describes a series of key exchanges, called
          modes, and details the services provided by each (for example,
          perfect forward secrecy for keys, identity protection, and
          authentication). [RFC 2412]
       o SKEME (Secure Key Exchange Mechanism for Internet), which
          describes a versatile key exchange technique that provides
          anonymity, reputability, and quick key refreshment.
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 6]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     IKE creates an authenticated, secure tunnel between two entities
     and then negotiates the security association for IPsec. This is
     performed in two phases.
  
     In Phase 1, the two unidirectional SA's establish a secure,
     authenticated channel with which to communicate.  Phase 1 has two
     distinct modes; Main Mode and Aggressive Mode.  Main Mode for Phase
     1 provides identity protection.  When identity protection is not
     needed, Aggressive Mode can be used.  The completion of Phase 1 an
     IKE SA is established.
  
     The following attributes are used by IKE and are negotiated as part
     of the IKE SA:
          o Encryption algorithm
          o Hash algorithm
          o Authentication method (can be digital signature, public-key
            encryption, or pre-shared key)
          o Information about a group on which to perform Diffie-
            Hellman
  
     After the attributes are negotiated, both parties must be
     authenticated to each other. IKE supports multiple authentication
     methods.  At this time, the following mechanisms are generally
     implemented:
       o Preshared keys.  The same key is pre-installed on each host.
          IKE peers authenticate each other by computing and sending a
          keyed hash of data that includes the preshared key.  If the
          receiving peer can independently create the same hash using
          its preshared key, it knows that both parties must share the
          same secret, and thus the other party is authenticated.
       o Public key cryptography. Each party generates a pseudo-random
          number (a nonce) and encrypts it and its ID using the other
          party's public key. The ability for each party to compute a
          keyed hash containing the other peer's nonce and ID, decrypted
          with the local private key, authenticates the parties to each
          other.  This method does not provide nonrepudiation; either
          side of the exchange could plausibly deny that it took part in
          the exchange.
       o Digital signature. Each device digitally signs a set of data
          and sends it to the other party.  This method is similar to
          the public-key cryptography approach except that it provides
          nonrepudiation.
  
     Note that both digital signature and public-key cryptography
     require the use of digital certificates to validate the
     public/private key mapping.  IKE allows the certificate to be
     accessed independently or by having the two devices explicitly
     exchange certificates as part of IKE.  Both parties must have a
     shared session key to encrypt the IKE tunnel.  The Diffie-Hellman
     protocol is used to agree on a common session key.
  
     In Phase 2 of the process, IPsec SAs are negotiated on behalf of
     services such as IPsec AH or ESP.  IPsec uses a different shared
  
  Bustos, Van Herck & Kaeo    [Page 7]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     key than does IKE.  The IPsec shared key can be derived by using
     Diffie-Hellman again or by refreshing the shared secret derived
     from the original Diffie-Hellman exchange that generated the IKE SA
     by hashing it with nonces.  After this step is complete, the IPsec
     SAs are established.  Now the data traffic can be exchanged with
     the negotiated IPsec parameters.  The completion of Phase 2 is
     called an IPsec SA.
  
  
  1.2.3. Using the term 'Tunnel'
  
     The term "tunnel" is often used in a variety of contexts.  To avoid
     any discrepancies, in this document we define the following
     distinctions between the word "tunnel":
  
     "IKE Tunnel": A bidirectional IKE Phase 1 SA, which is also
     referred to as ISAKMP SA.  It sets up a secure authenticated
     "control channel" for further IKE communications.
  
     "IPsec Tunnel": A bidirectional IKE Phase 2 SA, which is also
     referred to as an IPsec SA.  It creates the secure data exchange
     channel.
  
     "Tunnel": The combination of an IKE and an IPsec Tunnel
  
  
  2. Document Scope
  
     The primary focus of this document is to establish useful
     performance testing terminology for IPsec devices.  As such we want
     to constrain the terminology specified in this document to meet the
     requirements of the testing methodology.  The testing will be
     constrained to devices acting as IPsec gateways and will pertain to
     both IPsec tunnel and transport mode.
  
     What is specifically out of scope is any testing that pertains to
     interoperability and/or conformance issues. Additionally, any
     testing involving L2TP, GRE and 2547 (MPLS VPNs) is out of scope.
     It is also out of scope to deal with anything that does not
     specifically relate to the establishment and tearing down of IPsec
     tunnels.  It is assumed that all relevant networking parameters
     that facilitate in the running of these tests are pre-configured
     (this includes at a minimum ARP caches and routing tables).
     Pertinent to IKEv2, NAT Traversal has been included in the
     document, therefore NAT is not included in this document. All
     references to IKE connotate the inclusion of IKEv2 as well.
  
  3. Definition Format
     The definition format utilized by this document is described in RFC
     1242, Section 2.
  
     Term to be defined.
  
  
  Bustos, Van Herck & Kaeo    [Page 8]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Definition:
          The specific definition for the term.
  
     Discussion:
          A brief discussion of the term, its application, or other
          information that would build understanding.
  
     [Measurement units:]
          Units used to record measurements of this term. This field is
          mandatory where applicable. This field is optional in this
          document.
  
     [Issues:]
          List of issues or conditions that affect this term. This field
          can present items the may impact the term's related
          methodology or otherwise restrict its measurement procedures.
          This field is optional in this document.
  
     [See Also:]
          List of other terms that are relevant to the discussion of
          this term. This field is optional in this document.
  
  
  4. Key Words to Reflect Requirements
  
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",  "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL"
     in this document are to be interpreted as described in RFC 2119.
     RFC 2119 defines the use of these key words to help make the intent
     of standards track documents as clear as possible.  While this
     document uses these keywords, this document is not a standards
     track document.
  
  5. Existing Definitions
  
     It is recommended that readers consult RFCs 1242, 2544 and 2285
     before making use of this document.  These and other IETF
     Benchmarking Methodology Working Group (BMWG) router and switch
     documents contain several existing terms relevant to benchmarking
     the performance of IPsec devices.  The conceptual framework
     established in these earlier RFCs will be evident in this document.
  
     This document also draws on existing terminology defined in other
     BMWG documents. Examples include, but are not limited to:
  
          Throughput          [RFC 1242, section 3.17]
          Latency             [RFC 1242, section 3.8]
          Frame Loss Rate     [RFC 1242, section 3.6]
          Forwarding Rates    [RFC 2285, section 3.6]
          Loads               [RFC 2285, section 3.5]
     Note: "DUT/SUT" refers to a metric that may be applicable to a DUT
     (Device Under Test) or an SUT (System Under Test).
  
  
  Bustos, Van Herck & Kaeo    [Page 9]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  6. Term Definitions
  
  6.1. IPsec
  
     Definition:
          IP Security protocol suite which comprises a set of standards
          used to provide privacy and authentication services at the IP
          layer.
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
  
  6.2. IPsec Device
  
     Definition:
          Any implementation that has the ability to process data flows
          according to the IPsec protocol suite specifications.
  
     Discussion:
          Implementations come in many forms and shapes. Not only can
          they be grouped by 'external' properties (e.g. software vs.
          hardware implementations) but more important is the subtle
          differences that implementations may have with relation to the
          IPsec Protocol Suite. Not all implementations will cover all
          RFCs that encompass the IPsec Protocol Suite, but the majority
          will support a large subset of features described in the
          suite.
  
          In that context, any implementation, that supports basic IP
          layer security services as described in the IPsec protocol
          suite shall be called an æIPsec Device'.
  
     Issues:
          Due to the fragmented nature of the IPsec Protocol Suite RFCs,
          it is not unlikely that IPsec implementations will not be able
          to interoperate. Therefore it is important to know which
          features and options are implemented in the IPsec Device.
  
     See Also:
          IPsec
  
  
  
  
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 10]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  6.3. ISAKMP
  
     Definition:
          The Internet Security Association and Key Management Protocol,
          which provides a framework for authentication and key exchange
          but does not define them. ISAKMP is designed to be key
          exchange independent; that is, it is designed to support many
          different key exchanges. ISAKMP is defined in RFC 2407.
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
          IKE
  
  
  6.4. IKE
  
     Definition:
          A hybrid protocol, defined in RFC 2409, from the following 3
          protocols:
            o ISAKMP (Internet Security Association and Key Management
               Protocol), which provides a framework for authentication
               and key exchange but does not define them. ISAKMP is
               designed to be key exchange independent; that is, it is
               designed to support many different key exchanges.
            o Oakley, which describes a series of key exchanges, called
               modes, and details the services provided by each (for
               example, perfect forward secrecy for keys, identity
               protection, and authentication).  [RFC 2412]
            o SKEME (Secure Key Exchange Mechanism for Internet), which
               describes a versatile key exchange technique that
               provides anonymity, reputability, and quick key
               refreshment.
  
     Discussion:
          TBD
  
     Issues:
          During the first IPsec deployment experiences, many
          ambiguities were found in the original IKE specification,
          which lead to many interoperability problems. To resolve these
          issues, there is an ongoing effort to simplify the current IKE
          protocol and remove all unused features and options. This
          effort manifests itself in a new IKE version, called IKEv2.
          IKEv2 is an updated version of the current IKE stack and is
          code preserving a compatible with IKEv1.
  
     See Also:
          ISAKMP, Ipsec
  
  Bustos, Van Herck & Kaeo    [Page 11]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
  
  6.5. Initiator
  
     Definition:
          IPsec devices which start the negotiation of IKE Phase 1 and
          IKE Phase 2 tunnels.
  
     Discussion:
          When a traffic flow is offered at an IPSec device and it is
          determined that the flow must be protected, but there is no
          active tunnel yet, it is the responsibility of the IPSec
          device to start a negotiation process. This process will
          establish an IKE Phase 1 SA and one or more IKE phase 2 SA_s,
          eventually resulting in secured data transport. The device
          that takes the action to start this negotiation process will
          be called an Initiator.
  
  
     Issues:
          IPSec devices/implementations can always be both an initiator
          as well as a responder. The distinction is useful only from a
          test perspective.
  
  
     See Also:
          Responder
  
  
  6.6. Responder
  
     Definition:
  
          IPsec devices which reply to the incoming initiators IKE Phase
          1 and Phase 2 tunnel requests and process these messages in
          order to establish a tunnel.
  
  
     Discussion:
  
          When an initiator attempts to establish SAs with another IPsec
          device, this peer will need to evaluate the proposals made by
          the initiator and either accept or deny them. In the former
          case, the traffic flow will be decrypted according to the
          negotiated parameters. Such a device will be called a
          Responder_.
  
  
     Issues:
          IPSec devices/implementations can usually be both an initiator
          as well as a responder. The distinction is useful only from a
          test perspective.
  
  Bustos, Van Herck & Kaeo    [Page 12]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
  
     See Also:
          Initiator
  
  
  6.7. Security Association (SA)
  
     Definition:
          A simplex (unidirectional) logical connection, created for
          security purposes.  All traffic traversing an SA is provided
          the same security processing.  In IPsec, an SA is an Internet
          layer abstraction implemented through the use of AH or ESP.
          [RFC 2401]
  
     Discussion:
          A set of policy and key(s) used to protect information. It is
          a negotiation agreement between two IPsec devices,
          specifically the Initiator and Responder.
  
     Issues:
  
     See Also:
  
  
  
  6.8. IKE Phase 1
  
     Definition:
          The shared policy and key(s) used by negotiating peers to set
          up a secure authenticated "control channel" for further IKE
          communications.
  
     Discussion:
          TBD
  
     Issues:
          In other documents also referenced as ISAKMP SA or IKE SA.
  
     See Also:
          IKE, ISAKMP
  
  6.8.1. Phase 1 Main Mode
  
     Definition:
          Main Mode is an instantiation of the ISAKMP Identity Protect
          Exchange, defined in RFC 2409.
  
     Discussion:
          IKE Main Mode uses 3 separate message exchanges, for a total
          of 6 messages.  The first two messages negotiate policy; the
          next two exchange Diffie-Hellman public values and ancillary
  
  Bustos, Van Herck & Kaeo    [Page 13]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          data (e.g. nonces necessary for the exchange); and the last
          two messages authenticate the Diffie-Hellman Exchange. The
          authentication method negotiated as part of the initial IKE
          Phase 1 exchange influences the composition of the payloads
          but not their purpose.
  
     Issues:
  
     See Also:
          IKE, IKE Phase 1, Phase 1 Aggressive Mode
  
  6.8.2. Phase 1 Aggressive Mode
  
     Definition:
          Aggressive Mode is an instantiation of the ISAKMP Aggressive
          Exchange, defined in RFC 2409.
  
     Discussion:
          IKE Aggressive Mode uses 3 messages.  The first two messages
          negotiate policy, exchange Diffie-Hellman public values and
          ancillary data necessary for the exchange, and identities. In
          addition the second message authenticates the Responder. The
          third message authenticates the Initiator and provides a proof
          of participation in the exchange.
  
     Issues:
  
     See Also:
          IKE, IKE Phase 1, Phase 1 Main Mode
  
  
  6.9. IKE Phase 2
  
     Definition:
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
  
  
  6.9.1. Phase 2 Quick Mode
  
     Definition
          A SA negotiation and an exchange of nonces that provide replay
          protection.
  
     Discussion:
          Quick Mode is not a complete exchange itself (in that it is
          bound to a phase 1 exchange), but is used as part of the SA
  
  Bustos, Van Herck & Kaeo    [Page 14]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          negotiation process (phase 2) to derive keying material and
          negotiate shared policy for non-ISAKMP SA's.  The ISAKMP SA
          protects the information exchanged along with Quick Mode, i.e.
          all payloads except the ISAKMP header are encrypted.  Also, an
          optional Key Exchange payload can be exchanged to allow for an
          additional Diffie-Hellman exchange and exponentiation per
          Quick Mode.
  
     Issues:
  
     See Also:
  
  
  6.9.2. IPsec Tunnel
  
     Definition:
          A bidirectional IPsec SA that is set up as part of IKE phase
          2.  It creates the secure data exchange channel.
  
     Discussion:
          Manually established IPsec tunnels do exist, however, from a
          benchmarking perspective, they do not differ from IPsec
          tunnels that are negotiated by IKE. Note that some metrics
          will not be applicable due to the limited use of manually
          established IPsec tunnels.
  
     Issues:
  
     See Also:
  
  
  
  6.10.  Compound Tunnels
  
  6.10.1. Nested Tunnels
  
     Definition:
          An SA bundle consisting of two or more 'tunnel mode' SAs.
  
     Discussion:
          The process of nesting tunnels can theoretically be repeated
          multiple times (for example, tunnels can be many levels deep),
          but for all practical purposes, most implementations limit the
          level of nesting.
  
  
  
  
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 15]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          Nested tunnels can use a mix of AH and ESP encapsulated
          traffic.
  
          [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
            |         |                          |         |
            |         |                          |         |
            |         +----{SA1 (ESP tunnel)}----+         |
            |                                              |
            +--------------{SA2 (AH tunnel)}---------------+
  
          In the IP Cloud a packet would have a format like this:
  
          [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TR][ESP AUTH]
  
          Nested tunnels can be deployed to provide additional security
          on already protected traffic.  For example, the inner gateways
          (GW2 & GW3) are securing traffic between two branch offices
          and the outer gateways (GW1 & GW4) add an additional layer of
          security between departments within those branch offices.
  
  
  
     Issues:
  
     See Also:
          Transport adjacency, IPsec Tunnel
  
  6.10.2. Transport Adjacency
  
     Definition:
          An SA bundle consisting of two or more transport mode SAs.
  
     Discussion:
          Transport adjacency is a form of tunnel nesting.  In this case
          two or more transport mode IPsec tunnels are set side by side
          to enhance applied security properties.
  
          Transport adjacency can be used with a mix of AH and ESP
          tunnels although some combinations are not preferred. If AH
          and ESP are mixed, the ESP tunnel should always encapsulate
          the AH tunnel.  The reverse combination is a valid combination
          but doesn't make cryptographical sense.
  
          [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
            |         |                          |         |
            |         |                          |         |
            |         +--{SA1 (ESP transport)}---+         |
            |                                              |
            +-------------{SA2 (AH transport)}-------------+
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 16]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          In the IP cloud a packet would have a format like this:
  
          [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH]
  
  
     Issues:
  
     See Also:
          Nested tunnels, IPsec Tunnel
  
  
  6.11.  Transform Protocols
  
     Definition:
          Encryption and authentication algorithms that provide
          cryptograhical services to the IPsec Protocols.
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
          Authentication protocols, Encryption protocols
  
  6.11.1. Authentication protocols
  
     Definition:
          Algorithms which provide data integrity and data source
          authentication.
  
     Discussion:
          Authentication protocols provide no confidentiality.  Commonly
          used authentication algorithms/protocols are:
               o MD5-HMAC
               o SHA-HMAC
               o AES-HMAC
  
     Issues:
  
     See Also:
          Transform protocols, Encryption protocols
  
  6.11.2. Encryption protocols
  
     Definition:
          Algorithms which provide data confidentiality.
  
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 17]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Discussion:
          Encryption protocols provide no authentication.  Commonly used
          encryption algorithms/protocols are:
               o NULL encryption
               o DES-CBC
               o 3DES-CBC
               o AES-CBC
  
     Issues:
  
     See Also:
          Transform protocols, Authentication protocols
  
  
  6.12.  IPsec Protocols
  
  6.12.1. Authentication Header (AH)
  
     Definition:
          Provides authentication and data integrity (including replay
          protection) security services [RFC2402].
  
     Discussion:
          Original IPv4 packet:
          [IP ORIG][L4 HDR][PAYLOAD]
  
          In transport mode:
          [IP ORIG][AH][L4 HDR][PAYLOAD]
  
          In tunnel mode:
          [IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD]
  
     Issues:
  
     See Also:
          Transform protocols, IPsec protocols, Encapsulated Security
          Payload
  
  6.12.2. Encapsulated Security Payload (ESP)
  
     Definition:
          Provides three essential components needed for secure data
          exchange: authentication, integrity (including replay
          protection) and confidentiality [RFC2406].
  
     Discussion:
          Original IPv4 packet:
          [IP ORIG][L4 HDR][PAYLOAD]
  
          In transport mode:
          [IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
  
  
  Bustos, Van Herck & Kaeo    [Page 18]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          In tunnel mode:
          [IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
  
     Issues:
  
     See Also:
          Transform protocols, IPsec protocols, Authentication Header
  
  6.13.  Selectors
  
     Definition:
          A mechanism required to classify traffic flows when IPsec is
          used to protect traffic between networks which are proxied
          between two or more participating peers.  After
          classification, a decision can be made if the traffic needs to
          be encrypted/decrypted and how this should be done.
  
     Discussion:
          The selectors are a set of fields that will be extracted from
          the network and transport layer headers that provide the
          ability to classify the traffic flow and later associate it
          with an SA.
  
     Issues:
  
     See Also:
  
  
  
  6.14.  NAT Traversal (NAT-T)
  
     Definition:
          The capability to support IPsec functionality in the presence
          of NAT devices.
  
     Discussion:
          NAT-Traversal requires some modifications to IKE.
          Specifically, in phase 1, it requires detecting if the other
          end supports NAT-Traversal, and detecting if there are one or
          more NAT instances along the path from host to host.  In IKE
          Quick Mode, there is a need to negotiate the use of UDP
          encapsulated IPsec packets.
  
          NAT-T also describes how to transmit the original source and
          destination addresses to the other end if needed.  The
          original source and destination addresses are used in
          transport mode to incrementally update the TCP/IP checksums so
          that they will match after the NAT transform (The NAT cannot
          do this, because the TCP/IP checksum is inside the UDP
          encapsulated IPsec packet).
  
     Issues:
  
  Bustos, Van Herck & Kaeo    [Page 19]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
     See Also:
          IKE
  
  
  6.15.  IP Compression
  
     Definition:
          TBD [IPPCP RFC2393]
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
  
  
  
  6.16.  Security Context
  
     Definition:
          A security context is a collection of security parameters that
          describe the characteristics of the path that a tunnel will
          take, all of the tunnel parameters and the effects it has on
          the underlying protected traffic.  Security Context
          encompasses protocol suite and security policy(ies).
  
     Discussion:
          In order to fairly compare multiple IPsec devices it is
          imperative that an accurate overview is given of all security
          parameters that were used to establish tunnels and to secure
          the traffic between protected networks.  To avoid listing to
          much information when reporting metrics we have divided the
          security context into an IKE context and an IPsec context.
  
          When merely discussing the behavior of traffic flows through
          IPsec devices, an IPsec context MUST be provided.  In other
          cases the scope of a discussion or report may focus on a more
          broad set of behavioral characteristics of the IPsec device,
          the both and IPsec and an IKE context MUST be provided.
  
          The IPsec context MUST consist of the following elements:
               o Number of active IPsec tunnels
               o IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio)
               o IPsec protocol
               o IPsec mode (tunnel or transport)
               o Authentication protocol used by IPsec
               o Encryption protocol used by IPsec (if applicable)
               o IPsec SA lifetime (traffic and time based)
  
  
  
  Bustos, Van Herck & Kaeo    [Page 20]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          The IPsec context MAY also list:
               o Selectors
               o Fragmentation handling
  
          The IKE context MUST consist of the following elements:
               o Number of active IKE tunnels.
               o Authentication protocol used by IKE
               o Encryption protocol used by IKE
               o Key exchange mechanism (pre-shared key, Certificate,
                 etc)
               o Key size (if applicable)
               o Diffie-Hellman group
               o IKE SA lifetime (time based)
               o Keepalive, heartbeat or DPD values
               o Compression (IPPCP RFC2393)
               o PFS Diffie-Hellman group
  
          The IKE context MAY also list:
               o Phase 1 mode (main or aggressive)
               o Available bandwidth and latency to Certificate
                 Authority server (if applicable)
  
     Issues:
          A Security Context will be an important element in describing
          the environment where protected traffic is traveling through.
  
     See Also:
          IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase
          2, Selectors, IPsec Tunnel
  
  
  6.17.  Performance Metrics
  
  6.17.1. Tunnels Per Second (TPS)
  
     Definition:
          TBD
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
  
  
  6.17.2. Tunnel Flaps Per Second (TFPS)
  
     Definition:
          TBD
  
     Discussion:
  
  Bustos, Van Herck & Kaeo    [Page 21]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          TBD
  
     Issues:
  
     See Also:
  
  
  6.17.3. Tunnels Attempted Per Second (TAPS)
  
     Definition:
          TBD
  
     Discussion:
          TBD
  
     Issues:
  
     See Also:
  
  
  
  7. Test Terminology
  
  7.1. Framesizes
  
  7.1.1. Layer3 Clear Framesize
  
     Definition:
          The total size of the unencrypted L3 PDU.
  
     Discussion:
          In relation to IPsec this is the size of the IP header and
          its payload.  It SHALL NOT include any encapsulations that MAY
          be applied before the PDU is processed for encryption.  For
          example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload.
  
     Measurement units:
          Bytes
  
     Issues:
  
     See Also:
          Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
          Encrypted Framesize.
  
  
  7.1.2. Layer3 Encrypted Framesize
  
     Definition:
          The total size of the encrypted L3 PDU.
  
     Discussion:
  
  Bustos, Van Herck & Kaeo    [Page 22]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
          The size of the IP packet and its payload after encapsulations
          MAY be applied and the PDU is being processed by the
          transform. For example, after a tunnel mode ESP 3DES/SHA1
          transform has been applied, an unencrypted or clear Layer3
          framesize of 46 bytes becomes 96 bytes:
               20 bytes outer IP header (tunnel mode)
               4 bytes SPI (ESP header)
               4 bytes Sequence (ESP Header)
               8 bytes IV (IOS ESP-3DES)
               46 bytes payload
               0 bytes pad (ESP-3DES 64 bit)
               1 byte Pad length (ESP Trailer)
               1 byte Next Header (ESP Trailer)
               12 bytes ESP-HMAC SHA1 96 digest
  
     Measurement units:
          Bytes
  
     Issues:
  
     See Also:
          Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2
          Encrypted Framesize.
  
  
  7.1.3. Layer2 Clear Framesize
  
     Definition:
          The total size of the unencrypted L2 PDU.
  
     Discussion:
          This is the Layer 3 clear framesize plus the entire layer2
          overhead.  In the case of Ethernet this would be 18 bytes.
          For example, a 46 byte Layer3 clear framesize packet would
          become 64 bytes after Ethernet Layer2 overhead is added:
               6 bytes destination MAC address
               6 bytes source MAC address
               2 bytes length/type field
               46 bytes layer3 (IP) payload
               4 bytes FCS
  
     Measurement units:
          Bytes
  
     Issues:
          If it is not mentioned explicitly what kind of framesize is
          used, the layer2 clear framesize will be the default.
  
     See Also:
          Layer3 clear framesize, Layer2 encrypted framesize, Layer2
          encrypted framesize.
  
  
  
  Bustos, Van Herck & Kaeo    [Page 23]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  7.1.4. Layer2 encrypted framesize
  
     Definition:
          The total size of the encrypted L2 PDU.
  
     Discussion:
          This is the Layer 3 encrypted framesize plus all the Layer2
          overhead. In the case of Ethernet this would be 18 bytes.  For
          example, a 96 byte Layer3 encrypted framesize packet would
          become 114 bytes after Ethernet Layer2 overhead is added:
               6 bytes destination mac address
               6 bytes source mac address
               2 bytes length/type field
               96 bytes layer3 (IPsec) payload
               4 bytes FCS
  
     Measurement units:
          Bytes
  
     Issues:
  
     See Also:
          Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2
          Clear Framesize
  
  
  7.2. Internet Mix Traffic (IMIX)
  
     Definition:
          A traffic pattern consisting of a preset mixture of framesizes
          used to emulate real-world traffic scenarios in a testing
          environment.
  
     Discussion:
          IMIX traffic patterns can be used to measure different
          forwarding behaviors of the IPsec device with pseudo live
          traffic.
  
          Several facilities, including the National Laboratory for
          Applied Network Research, have collected and reported traffic
          distribution by monitoring live Internet links.  The study
          concluded that in a simulation environment, a small mix of
          packets in a preset ratio can resemble to a certain degree the
          live traffic that was monitored during the study. One of the
          mixes is called (simple) IMIX and consists of 7 parts 64 byte
          packets,  4  parts  570  byte  packets  and  1  1518  byte
          packet.[IMIX]
  
  
     Measurement units:
          TBD
  
  
  Bustos, Van Herck & Kaeo    [Page 24]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Issues:
          The ratio of frame sizes sent and traffic distribution to be
          determined by the test methodology.
  
     See Also:
  
  
  
  7.3. Throughput
  
  7.3.1. IPsec Tunnel Throughput
  
     Definition:
          The forwarding rate through an established IKE/IPsec tunnel at
          which none of the offered frames are dropped by the device
          under test.
  
     Discussion:
          The IPsec Tunnel Throughput is almost identically defined as
          Throughput in RFC 1242, section 3.17.  The only difference is
          that the throughput is measured with a traffic flow that is
          getting encrypted and decrypted by an IPsec device.  The
          Tunnel Throughput is an end-to-end measurement and is intended
          to characterize end-user forwarding behavior.
  
          The metric can be represented in two variants depending on
          where the in the SUT the measurement is taken.  One can look
          at throughput from a cleartext point of view i.e. find the
          forwarding rate where clearpackets no longer get dropped.
          This forwarding rate can be recalculated with an encrypted
          framesize to represent the encryption forwarding rate.  The
          latter is the preferred method of representation.
  
     Measurement units:
          Packets per seconds (pps), Mbps
  
     Issues:
  
     See Also:
  
  
  7.3.2. IPsec Tunnel Encryption Throughput
  
     Definition:
          The maximum encryption rate through an established IPsec
          tunnel at which none of the offered cleartext frames are
          dropped by the device under test.
  
     Discussion:
          Since it is not necessarily the case that the encryption
          throughput is equal to the decryption throughput, both of the
          forwarding rates must be measured independently.
  
  Bustos, Van Herck & Kaeo    [Page 25]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
          The independent forwarding rates have to be measured with the
          help of an IPsec aware test device that can originate and
          terminate IPsec and IKE tunnels.  As defined in RFC 1242,
          measurements should be taken with an assortment of frame
          sizes.
  
     Measurement units:
          Packets per seconds (pps), Mbps
  
     Issues:
  
     See Also:
  
  
  7.3.3. IPsec Tunnel Decryption Throughput
  
     Definition:
          The maximum decryption rate through an established IPsec
          tunnel at which none of the offered encrypted frames are
          dropped by the device under test.
  
     Discussion:
          Since it is not necessarily the case that the encryption
          throughput is equal to the decryption throughput, both of the
          forwarding rates must be measured independently.
  
          The independent forwarding rates have to be measured with the
          help of an IPsec aware test device that can originate and
          terminate IPsec tunnels. As defined in RFC 1242, measurements
          should be taken with an assortment of frame sizes.
  
     Measurement units:
          Packets per seconds (pps), Mbps
  
     Issues:
          Recommended test frame sizes will be addressed in future
          methodology document.
  
     See Also:
  
  
  7.4. Latency
  
  7.4.1. IPsec Tunnel Encryption Latency
  
     Definition:
          The IPsec Tunnel Encryption Latency is the time interval
          starting when the end of the first bit of the cleartext frame
          reaches the input interface, through an established IPsec
          tunnel, and ending when the start of the first bit of the
          encrypted output frame is seen on the output interface.
  
  Bustos, Van Herck & Kaeo    [Page 26]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
     Discussion:
          IPsec Tunnel Encryption latency is the latency that is
          introduced when encrypting traffic through an established
          IPsec tunnel.
  
          Like encryption/decryption throughput, it is not always the
          case that encryption latency equals the decryption latency.
          Therefore a distinction between the two has to be made in
          order to get a more accurate view of where the latency is the
          most pronounced.
  
          The independent encryption/decryption latencies have to be
          measured with the help of an IPsec aware test device that can
          originate and terminate IPsec and IKE tunnels. As defined in
          RFC 1242, measurements should be taken with an assortment of
          frame sizes.
  
     Measurement units:
          Time units with enough precision to reflect latency
          measurement.
  
     Issues:
  
     See Also:
  
  
  7.4.2. IPsec Tunnel Decryption Latency
  
     Definition:
          The IPsec Tunnel decryption Latency is the time interval
          starting when the end of the first bit of the encrypted frame
          reaches the input interface, through an established IPsec
          tunnel, and ending when the start of the first bit of the
          decrypted output frame is seen on the output interface.
  
     Discussion:
          IPsec Tunnel decryption latency is the latency that is
          introduced when decrypting traffic through an established
          IPsec tunnel.  Like encryption/decryption throughput, it is
          not always the case that encryption latency equals the
          decryption latency.  Therefore a distinction between the two
          has to be made in order to get a more accurate view of where
          the latency is the most pronounced.
  
          The independent encryption/decryption latencies have to be
          measured with the help of an IPsec aware test device that can
          originate and terminate IPsec and IKE tunnels.  As defined in
          RFC 1242, measurements should be taken with an assortment of
          frame sizes.
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 27]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Measurement units:
          Time units with enough precision to reflect latency
          measurement.
  
     Issues:
  
     See Also:
  
  
  7.4.3. Time To First Packet (TTFP)
  
     Definition:
          The Time To First Packet (TTFP) is the time required to
          process a cleartext packet when no tunnel is present.
  
     Discussion:
          The TTFP addresses the issue of responsiveness of an IPsec
          device by looking how long it take to transmit a packet over a
          not yet established tunnel path.  The TTFP MUST include the
          time to set up the tunnel that is triggered by the traffic
          flow (both phase 1 and phase 2 setup times are included) and
          the time it takes to encrypt and decrypt the packet on a
          corresponding peer.
  
          It must be noted that it is highly unlikely that the first
          packet of the traffic flow will be the packet that will be
          used to measure the TTFP.  There MAY be several protocol
          layers in the stack before the tunnel is formed.  Traffic is
          forwarded and several packets could be lost during
          negotiation, for example, ARP and/or IKE.
  
     Measurement units:
          Time units with enough precision to reflect a TTFP
          measurement.
  
     Issues:
  
     See Also:
  
  
  7.5. Frame Loss Rate
  
  7.5.1. IPsec Tunnel Encryption Frame Loss Rate
  
     Definition:
          Percentage of cleartext frames that should have been encrypted
          through an established IPsec tunnel under steady state
          (constant)load but were dropped.
  
     Discussion:
          TBD
  
  
  Bustos, Van Herck & Kaeo    [Page 28]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Measurement units:
          Percent (%)
  
     Issues:
  
     See Also:
  
  
  7.5.2. IPsec Tunnel Decryption Frame Loss Rate
  
     Definition:
          Percentage of encrypted frames that should have been decrypted
          through an established IPsec tunnel under steady state
          (constant)load but were dropped.
  
     Discussion:
          TBD
  
     Measurement units:
          Percent (%)
  
     Issues:
  
     See Also:
  
  
  7.6. Back-to-Back
  
  7.6.1. Encryption Back-to-Back Frames
  
     Definition:
          The number of cleartext frames, offered at a constant load
          that can be sent through an established IPsec tunnel without
          losing a single encrypted frame.
  
     Discussion:
          TBD
  
     Measurement units:
          Frames
  
     Issues:
  
     See Also:
          Decryption Back-to-back frames
  
  
  7.6.2. Decryption Back-to-back frames
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 29]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
     Definition:
          The number of encrypted frames, offered at a constant load,
          that can be sent through an established IPsec tunnel without
          losing a single cleartext frame.
  
     Discussion:
          TBD
  
     Measurement units:
          Frames
  
     Issues:
  
     See Also:
          Encryption back-to-back frames
  
  7.7. Tunnel Setup Rate Behavior
  
  7.7.1. Tunnel Setup Rate
  
     Definition:
          The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per
          second that an IPsec device can successfully establish.
  
     Discussion:
          The tunnel setup rate SHOULD be measured at varying number of
          established tunnels on the DUT.
  
     Measurement units:
          Tunnels per second (TPS)
     Issues:
  
     See Also:
  
  
  7.7.2. IKE Tunnel Setup Rate
  
     Definition:
          The maximum number of IKE tunnels per second that an IPsec
          device can be observed to successfully establish.
  
     Discussion:
          The tunnel setup rate SHOULD be measured at varying number of
          established tunnels on the DUT.
  
     Measurement units:
          Tunnels per second (TPS)
  
     Issues:
  
  
  
  Bustos, Van Herck & Kaeo    [Page 30]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     See Also:
          Rekey Time
  
  7.7.3. IPsec Tunnel Setup Rate
  
     Definition:
          The maximum number of IPsec tunnels per second that a IPsec
          device can be observed to successfully establish.
  
     Discussion:
          The tunnel setup rate SHOULD be measured at varying number of
          established tunnels on the DUT.
  
  
     Measurement units:
          Tunnels per second (TPS)
  
     Issues:
  
     See Also:
          Tunnel Rekey
  
  
  7.8. Tunnel Rekey
  
  7.8.1. Phase 1 Rekey Time
  
     Definition:
          The interval necessary for a particular Phase 1 to re-
          establish after the previous Phase 1 lifetime [hard or soft]
          has expired.
  
     Discussion:
          TBD
  
     Measurement units:
          Time units with enough precision to reflect rekey time
          measurement.
  
     Issues:
  
     See Also:
          Phase 2 Rekey Time, Tunnel Flapping
  
  7.8.2. Phase 2 Rekey Time
  
     Definition:
          The interval necessary for a particular Phase 2 to re-
          establish after the previous Phase 2 lifetime [hard or soft]
          has expired.
  
  
  
  Bustos, Van Herck & Kaeo    [Page 31]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Discussion:
          TBD
  
     Measurement units:
          Time units with enough precision to reflect rekey time
          measurement.
  
     Issues:
  
     See Also:
          Phase 1 Rekey Time , Tunnel Flapping
  
  
  
  7.9. Tunnel Flapping
  
     Definition:
          A behavior observed where a tunnel is dropped and then re-
          established with the same parameters.
  
     Discussion:
          TBD
  
     Measurement units:
          TBD
  
     Issues:
  
     See Also:
          Phase 1 Rekey Time, Phase 2 Rekey Time
  
  7.9.1. Tunnel Flap Rate
  
    Definition:
          The number of times per second a tunnel is dropped and re-
          established.
  
     Discussion:
          TBD
  
     Measurement units:
          Tunnel flaps per second (TFPS)
  
     Issues:
  
     See Also:
          Phase 1 Rekey Time, Phase 2 Rekey Time
  
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 32]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  7.10.  Tunnel Failover Time (TFT)
  
     Definition:
          Recovery time required to re-establish all tunnels on a
          standby node or other failsafe system after a tunnel failing
          event has occurred, such as a catastrophic IPsec device
          failure, including all traffic that previously ran through
          those tunnels.  The recovery time is delta between the point
          of failure and when the first packet is seen on the last
          restored tunnel on the backup device.
  
     Discussion:
          TBD
  
     Measurement units:
          Tunnel flaps per second (TFPS)
  
     Issues:
  
     See Also:
          Tunnel Flapping
  
  
  7.11.  IKE DOS Resilience Rate
  
     Definition:
          The IKE Denial Of Service (DOS) Resilience Rate provides a
          rate of invalid or mismatching IKE tunnels setup attempts at
          which it is no longer possible to set up a valid IKE tunnel.
  
     Discussion:
          The IKE DOS Resilience Rate will provide a metric to how
          robust and hardened an IPsec device is against malicious
          attempts to set up a tunnel.
  
          IKE DOS attacks can pose themselves in various forms and do
          not necessarily have to have a malicious background.  It is
          sufficient to make a typographical error in a shared secret in
          an IPsec aggregation device to be susceptible to a large
          number of IKE attempts that need to be turned down.  Due to
          the intense computational nature of an IKE exchange every
          single IKE tunnel attempt that has to be denied will take a
          non-negligible time an a CPU in the IPsec device.
  
          Depending on how many of these messages have to be processed,
          a system might end up in a state that it is only doing key
          exchanges and burdening the CPU for any other processes that
          might be running in the IPsec device.  At this point it will
          be no longer be possible to process a valid IKE tunnel setup
          request and thus IKE DOS is in effect.
  
  
  
  Bustos, Van Herck & Kaeo    [Page 33]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
     Measurement units:
          Tunnel attempts per second (TAPS)
  
     Issues:
  
     See Also:
  
  8. Security Considerations
  
     As this document is solely for the purpose of providing test
     benchmarking terminology and describes neither a protocol nor a
     protocol's implementation; there are no security considerations
     associated with this document.
  
  
  9. Acknowledgements
  
     The authors would like to acknowledge the following individual for
     their help and participation of the compilation and editing of this
     document û Debby Stopp, Ixia.
  
  
  10. Contributors
  
     The authors would like to acknowledge the following individual for
     their help and contributions to this document û Sunil Kalidindi,
     Ixia.
  
  
  11. References
  
  Normative References
  
   [RFC1242]  Bradner, S., "Benchmarking terminology for network
          interconnection devices", RFC 1242, July 1991.
  
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.
  
   [RFC2285]  Mandeville, R., "Benchmarking Terminology for LAN
          Switching Devices", RFC 2285, February 1998.
  
   [RFC2393]  Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP
          Payload Compression Protocol (IPComp)", RFC 2393, December
          1998.
  
   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
          Internet Protocol", RFC 2401, November 1998.
  
   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
          2402, November 1998.
  
  
  
  Bustos, Van Herck & Kaeo    [Page 34]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
          Payload (ESP)", RFC 2406, November 1998.
  
   [RFC2407]  Piper, D., "The Internet IP Security Domain of
          Interpretation for ISAKMP", RFC 2407, November 1998.
  
   [RFC2408]  Maughan, D., Schneider, M. and M. Schertler, "Internet
          Security Association and Key Management Protocol(ISAKMP)", RFC
          2408, November 1998.
  
   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
          (IKE)", RFC 2409, November 1998.
  
   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
          2412, November 1998.
  
   [RFC2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
          Algorithms", RFC 2451, November 1998.
  
   [RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
          Network Interconnect Devices", RFC 2544, March 1999.
  
   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
          1999.
  
   [SKEME]  Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
          Mechanism for Internet", from IEEE Proceedings of the 1996
          Symposium on Network and Distributed Systems Security, URL
          http://www.research.ibm.com/security/skeme.ps, 1996.
  
   [IMIX] National Library for Applied Network Research (NLANR),
          February 2001, ANI-9807479
  
  Informative References
  
   [RFC2403]  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
          ESP and AH", RFC 2403, November 1998.
  
   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
          ESP and AH", RFC 2404, November 1998.
  
   [RFC2405]  Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
          Algorithm With Explicit IV", RFC 2405, November 1998.
  
   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
          Its Use With IPsec", RFC 2410, November 1998.
  
   [RFC2411]  Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
          Document Roadmap", RFC 2411, November 1998.
  
   [I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2)
          Protocol",draft-ietf-ipsec-ikev2-04 (work in progress),
          January 2003.
  
  Bustos, Van Herck & Kaeo    [Page 35]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  
   [I-D.ietf-ipsec-nat-reqts] Aboba, B. and W. Dixon, "IPsec-NAT
          Compatibility Requirements", draft-ietf-ipsec-nat-reqts-03
          (work in progress), January 2003.
  
   [I-D.ietf-ipsec-nat-t-ike] Kivinen, T., "Negotiation of NAT-Traversal
          in the IKE", draft-ietf-ipsec-nat-t-ike-05 (work in
          progress),January 2003.
  
   [I-D.ietf-ipsec-properties] Krywaniuk, A., "Security Properties of
          the IPsec Protocol Suite", draft-ietf-ipsec-properties-02
          (work in progress), July 2002.
  
   [I-D.ietf-ipsec-udp-encaps] Huttunen, A., "UDP Encapsulation of IPsec
          Packets", draft-ietf-ipsec-udp-encaps-06 (work in progress)
  
   [FIPS.186-1.1998]  National Institute of Standards and Technology,
          "Digital Signature Standard", FIPS PUB 186-1, December 1998,
          <http://csrc.nist.gov/fips/fips1861.pdf>.
  
   [Hu95]  Huitema, C., "Routing in the Internet", Prentice Hall, 1995.
          January 2003.
  
  
  
  Bustos, Van Herck & Kaeo    [Page 36]


  INTERNET-DRAFT   Terminology for Benchmarking IPsec Devices Aug. 2003
  
  
  12. Contact Information
  
     Michele Bustos
     IXIA
     26601 W. Agoura Rd.
     Calabasas, CA  91302
     USA
  
     Phone: 818 444 3244
     Email: mbustos@ixiacom.com
  
     Tim Van Herck
     Cisco Systems
     170 W. Tasman Drive
     San Jose, CA 95134-1706
     USA
  
     Phone: 408 527 2461
     Email: herckt@cisco.com
  
     Merike Kaeo
     123 Ross Street
     Santa Cruz, CA 95060
     USA
  
     Phone: 831 818 4864
     Email: kaeo@merike.com
  
  
  13. Full Copyright Statement
  
     "Copyright (C) The Internet Society (2003). All Rights Reserved.
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implementation may be prepared, copied,
     published and distributed, in whole or in part, without restriction
     of any kind, provided that the above copyright notice and this
     paragraph are included on all such copies and derivative works.
     However, this document itself may not be modified in any way, such
     as by removing the copyright notice or references to the Internet
     Society or other Internet organizations, except as needed for the
     purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards process
     must be followed, or as required to translate it into.ö
  
  
  
  
  
  
  
  
  
  
  Bustos, Van Herck & Kaeo    [Page 37]
  

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/