# NIIST: NIST IPsec and IKE Simulation Tool

#### The design and Operations Guide

Version: niist-v0.2.0b (IKEv1)

Version: niist2-v0.3.1b (IKEv2)

# December 8, 2003

# Updated April 30, 2004

#  

[NIIST: NIST IPsec and IKE Simulation Tool
1](#niist-nist-ipsec-and-ike-simulation-tool)

[December 8, 2003 1](#december-8-2003)

[Updated April 30, 2004 1](#updated-april-30-2004)

[1. Introduction 3](#introduction)

[2. NIIST Overview 5](#niist-overview)

[2.1. Base software 5](#base-software)

[2.2. NIIST System Architecture 6](#niist-system-architecture)

[2.2.1. Security Policy Database 6](#security-policy-database)

[2.2.2. IP Key Management Module 7](#ip-key-management-module)

[2.2.3. IP Security Module 7](#ip-security-module)

[2.2.4. PF_Key Key Management API 7](#pf_key-key-management-api)

[3. Implementation Detail 9](#implementation-detail)

[3.1. Cryptographic Functions 9](#cryptographic-functions)

[3.2. Re-keying 9](#re-keying)

[3.2.1. Phase 1 SA Re-keying 9](#phase-1-sa-re-keying)

[3.2.2. Phase 2 SA Re-keying 10](#phase-2-sa-re-keying)

[3.3. Retransmission 11](#retransmission)

[4. NIIST (IKEv1) Configuration 12](#niist-ikev1-configuration)

[4.1. Modeling A Security Gateway 12](#modeling-a-security-gateway)

[4.2. Modeling Cryptographic Functions
14](#modeling-cryptographic-functions)

[4.3. Modeling IKE 15](#modeling-ike)

[4.3.1. IKE SPD 15](#ike-spd)

[4.3.2. IKE Configuration Parameters 16](#ike-configuration-parameters)

[4.4. Modeling IPSec 17](#modeling-ipsec)

[4.4.1. IPSec Configuration Parameters
20](#ipsec-configuration-parameters)

[Configuration Hint 20](#configuration-hint)

[5. NIISTv2 (IKEv2) Model 21](#niistv2-ikev2-model)

[5.1 IKEv2 Features 21](#ikev2-features)

[5.1.1 Re-Keying 21](#re-keying-1)

[5.1.2 Retransmission 21](#retransmission-1)

[5.1.3 Dead Peer Detection 21](#dead-peer-detection)

[5.1.4 Window Management 21](#window-management)

[5.2 Modeling A Security Gateway 22](#modeling-a-security-gateway-1)

[5.3 Modeling IKE 23](#modeling-ike-1)

[5.4 Modeling IPsec 24](#modeling-ipsec-1)

[6. NIIST Player 27](#niist-player)

[6.1 Main Window 27](#main-window)

[6.2 System Status Window 28](#system-status-window)

[6.3 SADB Window for A Gateway 29](#sadb-window-for-a-gateway)

[7. Conclusions 32](#conclusions)

#  {#section-1 .unnumbered}

#  

[Figure 1: SSFNet: Internet Modeling 5](#__RefHeading___Toc71429779)

[Figure 2: Overall NIIST System Architecture
6](#__RefHeading___Toc71429780)

[Figure 3: A Security Gateway Protocol Graph
12](#__RefHeading___Toc71429781)

[Figure 4: A Simple Security Gateway Model
13](#__RefHeading___Toc71429782)

[Figure 5: Example Specification for Cryptographic Processing Delay
14](#__RefHeading___Toc71429783)

[Figure 6: Part of the Specification for IKE Policy
15](#__RefHeading___Toc71429784)

[Figure 7: IKE Parameters 17](#__RefHeading___Toc71429785)

[Figure 8: Part of the Specification for IPSec Policy
19](#__RefHeading___Toc71429786)

[Figure 9: IPSec Parameters 20](#__RefHeading___Toc71429787)

[Figure 10: A Simple Security Gateway Model
23](#__RefHeading___Toc71429788)

[Figure 11: Part of the Specification for IKE Policy
24](#__RefHeading___Toc71429789)

[Figure 12: Part of the Specification for IPsec Policy
26](#__RefHeading___Toc71429790)

[Figure 13: NIISTPlayer Main Window 27](#__RefHeading___Toc71429791)

[Figure 14: System Status Window 28](#__RefHeading___Toc71429792)

[Figure 15: SADB Window for A Security Gateway
30](#__RefHeading___Toc71429793)

#   {#section-3 .unnumbered}

# 1. Introduction

The IETF IP Security Working Group has defined a set of IP security
protocols to provide cryptographic network security services to protect
datagrams in the Internet: this is IP security architecture \[RFC2401\],
IP security protocols (IPsec) \[RFC2402, RFC2406\], and Internet key
exchange protocols (IKEv1)\[RFC2407, RFC2408, RFC2409\].

To date, the IPSec protocol suite is fairly mature and has been
successfully developed and deployed to provide the VPN services between
security gateways. However, the integration of these security
technologies for building automated key management infrastructures is
becoming complex. This is particularly so in the areas of
interoperability, scalability, and analysis of protocol interactions in
large-scale networks. It is economically desirable to study and analyze
those issues listed above in an integrated security simulation
environment to help bring about improvements in, and deployment of those
technologies.

NIST has developed a NIST IPsec and IKE simulation tool (NIIST), which
includes the models of IPsec, IKE, Internet security policy and PF_Key
API. This would help study and investigate behavioral and relative
performance characteristics, including the issues of interoperability,
scalability and performance of interacting suite of security protocols
in large-scale IPsec-based VPN environments. The NIIST can also be used
to evaluate alternative strategies or techniques that address the
current open issues such as re-keying \[REKEYING\]. The NIIST also
provides the ability to parameterize IPsec VPN models such as security
policies, IPsec/IKE parameters, cryptographic transforms, and
operational processing options (e.g., re-keying techniques and packet
handling options), which allows the user to dynamically specify
alternate options in different environments.

Furthermore, the IETF IP security community is currently in the process
of defining version 2 of Internet key exchange protocol (IKEv2)
\[IKEv2\], aiming to resolve the complexities of the current IKE version
1 specification (IKEv1). We have also modeled the version 2 of IKE
\[IKEv2\] based on Revision 12, to enable the analysis of the relative
performance trade-offs between IKEv1 and IKEv2. This would also help
evaluate the behavioral characteristics of IKEv2.

This report describes the design, operations and modeling of NIIST for
both IKEv1 (*niist*) and IKEv2 (*niist2*). The remainder of this guide
is organized as follows: Section 2 describes the NIIST architecture and
an overview of its major components and functions. In Section 3, we
discuss the implementation details of some major features, which can
impact the overall behavior and performance of interacting protocols and
security systems, such as cryptographic algorithm processing, re-keying
and retransmission. Section 4 describes the modeling of security systems
and each component of the system. Section 5 discusses the IKEv2-specific
features and models of IKEv2 components included in NIISTv2. NIIST
player is described in Section 6. Finally, Section 7 gives our
conclusions.

# 2. NIIST Overview

## 2.1. Base software 

The NIIST is implemented in Java and integrated in the Scalable

Simulation Framework (SSF) \[SSF-WEB\] and SSF Network Model (SSFNet) to
provide an integrated Internet security modeling framework for
large-scale networks. The SSF \[SSF, SSF-WEB\] is a discrete,
event-driven, scalable modeling framework and SSFNet is a collection of
Internet modeling tools for simulating Internet protocols and networks
(as shown in Figure 1. It provides: 1) modeling of operating system
components such as protocols and packets; and 2) modeling of network
connectivity such as NIC (Network Interface Card), link, and queues. SSF
places particular emphasis in scalability and high-performance for
simulating very large networks \[SSF\]. To achieve these goals, the
message processing in SSF takes zero processing time within a specific
host or router. However, it provides a mechanism that allows the user to
advance logical time when needed.

![](media/image1.png){width="4.6875in" height="3.2402777777777776in"}

[]{#__RefHeading___Toc71429779 .anchor}Figure 1: SSFNet: Internet
Modeling

Each component and its parameters are configured using Domain

Modeling Language (DML). DML \[SSF-WEB\] is an object-oriented,
self-configurable, hierarchical, scalable parameter database for model
configuration. It allows efficient description of very large network
models.

## 2.2. NIIST System Architecture 

![](media/image2.png){width="5.999305555555556in"
height="4.577083333333333in"}

[]{#__RefHeading___Toc71429780 .anchor}Figure 2: Overall NIIST System
Architecture

As shown in Figure 2, NIIST consists of the four major components:

1.  IP security policy database (*SPD*);

2.  IP key management daemon (*IKE* *Manager*);

3.  IP security module (*IPSec Manager*); and

4.  PF_Key key management API (*IKE and IPSec Key Managers*).

These components are described below and their configuration
specifications are discussed in Section 4. Note that the modeling schema
for IKEv2 is somewhat different than that for IKEv1 to reflect the
changes made in IKEv2. Section 5 provides the IKEv2-specific
specifications for IKEv2 where the changes exist.

### 2.2.1. Security Policy Database

The Security Policy Database (SPD) specifies what services are to be
offered to IP traffic and in what mode of behavior. It is an ordered
list that is always searched from the beginning, so that matching of
packets against SPD entries is always deterministic. *IKE* and *IPSec*
maintain their own SPD independently. The SPDs in a security gateway are
on *per-interface, per-direction* basis with separate inbound and
outbound tables. A security policy schema is defined for both IKE and
IPSec to specify the local security policy. The user is responsible for
the total ordering of the list through a DML specification.

More detailed policy specifications are described in Section 4.

### 2.2.2. IP Key Management Module

The IP key management module (*IKEManager*) is used to negotiate IKE and
IPSec Security Associations with a peer. It manages Security Association
(SA) exchanges (a two-phase negotiation):

1.  Phase 1; and

2.  Phase 2.

*Phase 1* establishes an IKE SA through which the *Phase 2* negotiation
creates IPSec SAs. This module interacts with the IP security module
(resided in the kernel) through PF_KEY that is discussed in subsection
below. It manages the IKE SPD, and the SA state table by the system,
whose values of each entry are continuously updated as messages are
exchanged with the peer.

As described before, there are two versions of IKE (IKEv1 and IKEv2).
Both versions use a two-phase SA negotiation, but differ somewhat on
technical details such as, for example, the number of messages for each
exchange, the semantics of an SA (i.e., encoding and parsing of an SA
payload), mandatory use of a Delete message, and etc. The IKE SPD schema
used for IKEv1 and the configuration parameters used for both IKEv1 and
IKEv2 are described in Section 4. The IKEv2-specific specification is
discussed in Section 5.

### 2.2.3. IP Security Module 

The IP security module (*IPSecManager*) is used to provide IP security
services for a gateway or host. It examines every single inbound and
outbound packet to see if it requires secure communication and applies
the local security policy, if required. IPSec is modeled as the
extension of IP in this framework. It maintains inbound and outbound
SPDs and SADBs independently. The SADB hash table is managed by the
system. As discussed in the above Policy section, the SPD is an ordered
list and total ordering of the list is provided by the user.

Each entry of the SPD contains the entry identifier, one or more
selectors (e.g., traffic filtering mechanism), action to be applied, the
identifier of a remote gateway as a mechanism of the remote gateway
discovery, and attributes such as the *threshold* value and the mode of
encapsulation. The entry also contains multiple proposals and policies,
and SA attributes based on the local policy. Section xx describes the
schema and SA attributes in more detail.

### 2.2.4. PF_Key Key Management API 

The PF_Key key management API is a generic key socket API. It is used by
*IKEManager* to communicate with *IPSec* that resides in the kernel. The
SADB message sequence and message types are compliant to PF_Key Key
Management API, Version 2 \[RFC2367\]. It also partially supports the
PF_Key Extension \[PFKEY-EXT\], in which the kernel sends only a
specified policy reference to key management instead of the contents of
policy proposals for simplicity.

# 3. Implementation Detail

## 3.1. Cryptographic Functions 

As discussed in Section 2.1, message processing in SSF assumes no
logical time advance within a specific gateway or host. However,
cryptographic operations in security protocols can significantly impact
the behavior and performance of the overall system. We modeled their
impact on protocol functions and performance by incorporating
cryptographic processing delays. To model the performance impact of
these functions of security protocols, the processing time taken by
specific cryptographic algorithms along with digital signatures and
Diffie-Hellman exchange is simulated.

The cryptographic algorithm processing delay is computed as a function
of the performance (bytes/sec) of a specific cryptographic algorithm and
the size of a packet. A mechanism is provided for the user to
dynamically specify alternate cryptographic algorithms or even the same
cryptographic algorithm with different key lengths or block size, as
specified in Section 4.

## 3.2. Re-keying 

A single key (or keys) contained in a valid SA can be safely used for
encryption and authentication for a certain period of time or a certain
amount of bytes. The lifetime of an SA can be specified in terms of
elapsed time or number of bytes transmitted or both. When the lifetime
of a SA expires, the SA can be re-established depending upon the local
security policy.

A *threshold* is the percentage of the expiration of a SA lifetime, at
which time it triggers the re-negotiation of the current SA, depending
on the local security policy. Initially, the initiator starts Phase 1
followed by Phase 2. However, any security gateway can initiate the
re-keying negotiation, if required by the local security policy.

There are various techniques for SA re-keying and transfer (e.g., when
to set-up the new SA and when to remove the old SA). As pointed out in
\[REKEYING\], there is a potential interoperability problem in the Phase
2 negotiation due to the lack of a standardized re-keying mechanism
among alternative techniques. We modeled various techniques of re-keying
and transfer for both Phase1 and Phase 2. In this section, we describe
those re-keying and SA transfer techniques.

### 3.2.1. Phase 1 SA Re-keying

There are currently two mechanisms modeled for the phase 1 re-keying:

1.  Continuous channel mode; and

2.  Non-continuous channel mode.

For the continuous channel mode, a valid Phase 1 SA is always available
between two security gateways and is re-negotiated when *threshold* of
an existing SA triggers. The valid Phase 2 SAs currently belonging to
the expiring IKE SA are transferred to the newly created Phase 1 SA. The
non-continuous mode does not re-negotiate an expiring SA and removes the
SA if expired, independent of the Phase 2 SAs (allowing dangling Phase 2
SAs). A new Phase 1 SA is only created whenever needed such as when the
Phase 2 negotiation is required. Note that IKEv2 requires only
*continuous channel mode*.

### 3.2.2. Phase 2 SA Re-keying

When the *threshold* of an existing outbound SA (only outbound SAs are
allowed to be re-keyed) triggers a re-keying, *IPSecManager* sends a
SADB_ACQUIRE message to *IKEManager* that initiates the Phase 2
negotiation. Before sending a re-keying request, the IPSec module checks
to see if there already exists the new SA with the same policy criteria
as the original one.

We modeled various Phase 2 SA transfer techniques (discussed in
\[REKEYING\]) to examine the dynamic behavior and interoperability
issues with regard to re-keying between a pair of security gateways.

The following options are modeled:

-   *Delete message*: sets-up new SAs and removed old SAs when a
    *Delete* message for the old SA is received. The IKEv1 specifies
    that Delete messages are optional.

-   *Fixed delay*: sets-up new SAs and deletes old SAs when either
    receiving inbound traffic with the new SA or, in the absence of
    inbound traffic, after a fixed amount of time (e.g., 30s) has
    elapsed.

-   *Twice measured round trip time (RTT \* 2)*: sets-up after either
    receiving inbound traffic using the new SA or after twice the
    measured round trip time has elapsed. The *IKEManager* sends the
    kernel a SADB_UPDATE message with twice measured round trip time.

```{=html}
<!-- -->
```
-   *Immediate use*: new SAs are set-up and old SAs are removed
    immediately.

Once a replacement SA is received from *IKEManager*, *IPSecManager* then
performs the following SA transfer procedure:

As the SA responder, after having received 3rd Quick Mode message:

1.  Sets-up new inbound and outbound SAs;

2.  Deletes old outbound SA; and

3.  Deletes old inbound SA only when having received either a *Delete*
    message or *inbound* traffic with the new inbound SA.

As for the SA initiator, after sending 3rd Quick Mode message:

1.  Sets-up new inbound SA;

2.  Creates new outbound SA either in the presence of a *Delete* message
    or *inbound* traffic with new inbound SA or after a certain period
    of time in case no inbound user traffic with the new inbound SA
    exists.

## 3.3. Retransmission 

IKE uses the UDP protocol, which is inherently unreliable. To make

IKE reliable as specified in \[RFC2408\], the transmitting entity in
NIIST sets a retransmission timer and a retry counter when sending an
ISAKMP message. The retransmission timer values are dynamically adjusted
with the measured round trip time using exponential back-off.

Maintaining the retransmission timer in the responder can solve a
potential problem of packet loss of the last message of an exchange,
specifically for Phase 2 exchange. The sender of the last message of the
Phase 2 exchange (i.e., initiator) will know if the last message has
been received if the receiver does not re-send the previous message (it
means the receiver has received the last message). The sender keeps the
last message in case of retransmission.

# 4. NIIST (IKEv1) Configuration 

This section describes on how to model a security gateway and its
components under various network topologies, using DML that is discussed
in Section 2.1.

## 4.1. Modeling A Security Gateway

Figure 3 shows a security gateway protocol graph together with a host
behind it, and the relationship and communication path between two key
management modules (*IKEManager*) in a pair of security gateways. Any
router or host can be configured as a security gateway.

A security gateway (as shown in Figure 4) must specify a protocol graph
and security policy, including cryptographic functions (Section 4.2),
IKE security policy (Section 4.3) and IPSec policy (Section 4.4).

A protocol graph for the security gateway consists of a list of
protocols to be configured: *IKEManager* (an IKE demon),
*NiistSocketMaster* (PF_Key API module), *udpSessionMaster* and *IPSec*
(IP security module) (as shown Figure 4).

![](media/image3.png){width="5.992361111111111in" height="3.375in"}

[]{#__RefHeading___Toc71429781 .anchor}Figure 3: A Security Gateway
Protocol Graph

In security section of a security gateway (as shown in Figure 4), the
user can set an optional attribute *use_encrypt_delay* to indicate
whether or not the cryptographic delay is applied. The user is also
provided, for simplicity, an option of specifying global parameters for
both IKE and IPSec, as specified below. The user can also specify an SA
specific parameters related to SA lifetime in a specific SA policy, if
preferred.

The following attributes can be specified globally:

-   *ike\[ipsec\]\_lifetype*

-   *ike\[ipsec\]\_lifeduration*

-   *user_ike\[ipsec\]\_soft* a global flag that indicates whether or
    not the user provides soft_threshold and random_delay. If the value
    is false (default), the system-provided values are used.

-   *ike\[ipsec\]\_soft_threshold* the percentage (%) of expiration of
    lifetime of an existing SA, which triggers the re-negotiation of the
    SA for a replacement SA. The value of 0 means that no re-keying of
    the SA is allowed. The value of 100 means that the re-negotiation
    starts after the life duration of the existing SA has been expired.

-   *ike\[ipsec\]\_random_delay* It is used to adjust (jitter) the
    calculated soft time in order to prevent the simultaneous
    negotiation from both ends.

[]{#__RefHeading___Toc71429782 .anchor}Figure 4: A Simple Security
Gateway Model

## 4.2. Modeling Cryptographic Functions 

As discussed in Section 2, processing delay for the cryptographic
algorithm for encryption and authentication (*encrypt* and *auth*),
digital signatures (*signature_delay*) and DH exchange
(*DH_exchange_delay*) is modeled.

[]{#__RefHeading___Toc71429783 .anchor}Figure 5: Example Specification
for Cryptographic Processing Delay

The cryptographic algorithm processing delay is based on the function of
the packet size and performance of a specific cryptographic algorithm
provided with key length and block size. As shown in Figure

5, the cryptographic function specification (*cryptoEntry*) takes the
following attributes:

-   ***id*** the algorithm identifier.

-   ***use*** the location of a class that provides the cryptographic
    functions of the specific algorithm.

-   ***block_size*** the block size.

-   ***key_size*** the key size.

-   ***e_perf*** the performance of encryption in either bytes/sec,
    bytes/sec or Kbytes/sec.

-   ***d_perf*** the performance of decryption in either bytes/sec,
    kbytes/sec or Kbytes/sec.

The encryption and decryption performances are separated to provide
flexibility in anticipation of the need to test the performance
separately. The same value can be provided for both encryption and
decryption if the separate performance is not available. The user can
have an option to specify alternate cryptographic algorithms or even the
same cryptographic algorithm with different key lengths or block size,
as shown in Figure 5. If a security policy entry contains a new
algorithm (e.g., AES), then cryptographic functions can be dynamically
provided (*cryptoEntry*) for the new algorithm.

The digital signature delay (*signature_delay*) requires the following
attributes:

-   ***id*** the signature identifier (e.g., *RSA* for the RSA digital
    signature and *DSS* for DSA digital signature);

-   ***sign*** the delay time for signing; and

-   ***verify*** the delay time for verification.

-   

The following attributes are needed for DH delay (*DH_exchange_delay*):

-   ***id*** the DH group identifier (e.g., *group1* for MODP_768_G1,
    *group2* for MODP_1024_G2); and

```{=html}
<!-- -->
```
-   ***delay*** the delay time for the group.

## 4.3. Modeling IKE 

### 4.3.1. IKE SPD

Figure 6 shows the specification of IKE security policy.

[]{#__RefHeading___Toc71429784 .anchor}Figure 6: Part of the
Specification for IKE Policy

Each IKE SPD entry (*spdentry*) specifies the following attributes:

-   ***id:*** the identifier of the entry.

-   ***remoteSG:*** the remote security gateway as a means of
    discovering remote gateway.

-   ***ex_mode:*** the mode of exchange.

-   ***identity_type:*** the type of identity.

-   ***soft_threshold:*** specifies the percentage (%) of expiration of
    the life duration of an existing SA, which triggers the
    re-negotiation of the SA for a replacement SA. The value of 0 means
    that no re-keying of the SA is allowed. The value of 100 means that
    the re-negotiation starts after the life duration of the existing SA
    has been expired. Can be set either globally or locally.

-   ***policy:*** one or more policies with the attributes below.

```{=html}
<!-- -->
```
-   ***encrypt:*** the specified encryption algorithm.

-   ***hash:*** the specified authentication algorithm.

-   ***auth_method:*** the authentication method. *Pre-Shared* is
    currently supported.

-   ***lifetype:*** either time-based or byte-based. Can be set either
    globally or locally.

-   ***lifetime:*** the duration of the SA. Can be set either globally
    or locally.

The attribute *soft_threshold* is also associated with the parameter
*p1_rekeying_mode* below, which is automatically set to the value of 0
if *p1_rekeying_mode* is configured as *non-continuous*.

### 4.3.2. IKE Configuration Parameters 

Figure 7 shows the configurable DML attributes used in *the key
management module*:

[]{#__RefHeading___Toc71429785 .anchor}Figure 7: IKE Parameters

## 4.4. Modeling IPSec 

The IPSec module maintains separate inbound (*spd_inbound*) and outbound
(*spd_outbound*) SPD databases. As shown in Figure 8, each SPD entry

(*spdentry*) is specified in preferential order. The following are the
list of attributes:

-   ***id:*** the entry identifier.

-   ***selector:*** one or more selectors which is used to map traffic
    to a specific SA or SAs. The following selector parameters are
    defined:

```{=html}
<!-- -->
```
-   ***type:*** the selector parameter identifier. The parameters
    currently supported are *SRC_IP, DEST_IP, DEST_PORT, RC_PORT,
    TP_PROTOCOL*;

-   ***value_type**:* the type of the value: either the single value
    (*S*) or the range of values (*R*).

-   ***value*** or ***value_range:*** the specific value. If the value
    type is *R*, *value_range* must be used and the range of values must
    be provided.

```{=html}
<!-- -->
```
-   ***action:*** the specific action to be applied. The options are
    *apply, bypass, or discard*. If an SPD entry requires secure
    communication (*APPLY*), the entry must specify SA attributes as
    follows:

```{=html}
<!-- -->
```
-   ***encap_mode:*** the encapsulation mode. The *TUNNEL* mode is
    supported.

-   ***remoteSG:*** the remote security gateway.

-   ***usepfs:*** the use of pfs.

-   ***soft_threshold:*** the percentage value of expiration of the SA
    lifetime.

-   ***proposal:*** one or more proposals. These proposals are ORed in
    preferential order. A proposal specifies:

    -   ***protection*** one or more protections. If more than one
        protection is specified, those entries are ANDed, which is
        generally used when required both ESP and AH protections. A
        protection, in turn, specifies:

        -   ***protocol*** a security protocol to be used;

        -   ***policy*** one or more policies which are ORed in
            preferential order. A policy specified:

            -   encryption (***encrypt***) algorithm;

            -   authentication (***auth***) algorithm;

            -   life type (***lifetype***) (can be set either globally
                or locally); and

            -   life duration (***lifetime***) (can be set either
                globally or locally).

[]{#__RefHeading___Toc71429786 .anchor}Figure 8: Part of the
Specification for IPSec Policy

### 4.4.1. IPSec Configuration Parameters 

The DML configurable attributes used in *IP security module* are shown
in Figure 9.

[]{#__RefHeading___Toc71429787 .anchor}Figure 9: IPSec Parameters

### Configuration Hint

-   Inconsistent policies (e.g., Transform IDs) between two negotiating
    peers may end with a NULL pointer exception.

-   Using undefined attributes may cause a NULL pointer exception. For
    instance, ESP_AH is not defined, but used.

-   Use the reasonable values for some parameters/attributes such as:

    a.  IKE and IPsec *life duration* and *soft threshold*;

    b.  Link delay relative to IPsec life time;

    c.  SA lifetime and timer timeout values.

E.g., if *life duration* is shorter than the time takes to complete file
transfer and the threshold value is 0, an ftp application may end
abruptly with a max retransmission error.

# 5. NIISTv2 (IKEv2) Model 

This section describes modeling of IKEv2-specific features, mechanisms
and changes thereof. Unless otherwise specifically mentioned in this
section, the same techniques and mechanisms such as cryptographic
functions are used as described in Sections 3 and 4 for IKEv1.

## 5.1 IKEv2 Features

This section describes modeling of IKEv2-specific features, mechanisms
and changes thereof. NIIST IKEv2 is based on IETF IKEv2 Proposal
Revision 12. Unless otherwise specifically mentioned in this section,
the same techniques and mechanisms such as cryptographic functions are
used as described in IKEv1.

### 5.1.1 Re-Keying

Any security gateway can initiate the re-keying process depending upon
the local security policy. In IKEv2, SA lifetimes are not negotiated.
The user is provided an option of specifying global lifetime for both
IKE and IPsec. The user can also use the system default values.

The *IKE* module supports only *continuous channel mode* if the policy
requires. Once a new IKE SA is set-up, the new IKE SA inherits all the
valid child SAs of the old IKE SA. These child SAs can be accessed from
both the old and new SAs until the old SA expires. As for the *IPsec
re-keying*, a Delete message is used to set-up new SAs.

### 5.1.2 Retransmission

In IKEv2, the message initiator is responsible for retransmission of an
IKE request in case of no response for the request. The initiator sets a
retransmission timer and a retry count when sending an IKE request
message. The retransmission timer values are dynamically adjusted with
the measured round trip time using exponential backoff.

### 5.1.3 Dead Peer Detection

As a mechanism for dead peer detection, an IKE endpoint sends a NULL
query notify (i.e., IKE ping) message in the event of keep-alive
timeout. The SA responder sets an Inactivity timer to check half-open
connections when received an IKE SA initiation request.

### 5.1.4 Window Management

As specified in the IKEv2 specification, a security gateway as the
initiator can initiate one or more IKE requests up to an agreed upon
window size between peer gateways. The initiator maintains a couple of
queues:

-   Request send queue; and

-   Response send queue.

The *request send queue* keeps copies of all the requests previously
sent for retransmission in case it does not receive the matching
responses. The responder accepts and processes requests out of order and
maintains a *response send queue* that keeps copies of previously sent
responses equal to the negotiated window size. This is in preparation
for responding in case of retransmission requests from the initiator.

The Message ID counters are maintained for both requests and responses.
These counters increase as requests are generated and responses
received.

## 5.2 Modeling A Security Gateway

A new security policy schema for IKEv2, shown in Figure 10, is modeled
due to the protocol change. Since the SA lifetime is not included in
negotiating security attributes, the user is provided, for simplicity,
an option of specifying global lifetime for both IKE and IPsec, as
specified in Figure 10. The user can also specify an SA specific
lifetime in the SA policy section, if preferred. The following
attributes can be specified globally:

-   *ike\[ipsec\]\_lifetype*

-   *ike\[ipsec\]\_lifeduration*

-   *user_ike\[ipsec\]\_soft* a global flag that indicates whether or
    not the user provides soft_threshold and random_delay. If the value
    is false (default), the system-provided values are used.

-   *ike\[ipsec\]\_soft_threshold* the percentage (%) of expiration of
    lifetime of an existing SA, which triggers the re-negotiation of the
    SA for a replacement SA. The value of 0 means that no re-keying of
    the SA is allowed. The value of 100 means that the re-negotiation
    starts after the life duration of the existing SA has been expired.

-   *ike\[ipsec\]\_random_delay* It is used to adjust (jitter) the
    calculated soft time in order to prevent the simultaneous
    negotiation from both ends.

[]{#__RefHeading___Toc71429788 .anchor} Figure 10: A Simple Security
Gateway Model

## 5.3 Modeling IKE

Figure 11 shows the specification of IKEv2 security policy.

Each IKE entry (*spdentry*) specifies the following attributes:

-   ***id**:* the identifier of the entry.

-   ***nhi_remoteSG**:* the remove security gateway as a means of
    discovering remote gateway.

-   ***identity_type:*** the type of identity.

-   ***auth_method**:* the method of authentication used.

-   ***proposal:*** a proposal.

    -   ***protection:*** specifies a protocol *IKE* and consists of one
        or more policies which are ANDed when encoding. A preferential
        order is not required in this list.\
        A ***policy*** contains security policy with the following
        attributes:

        -   ***type:*** the type of transform. The supported transforms
            are:

            -   ***encrypt*** the encryption algorithm;

            -   ***prf*** the pseudo-random function (e.g., SHA1 or
                MD5);

            -   ***auth*** the integrity algorithm; and

            -   ***DH_group*** the Diffie-Hellman group (e.g.,
                MODP_1024_G2);

        ```{=html}
        <!-- -->
        ```
        -   ***id:*** the value of the specific transform defined by
            *type*. Multiple values can be provided, which are ORed in
            preferential order.

[]{#__RefHeading___Toc71429789 .anchor}Figure 11: Part of the
Specification for IKE Policy

## 

## 5.4 Modeling IPsec

As in the IKEv1, the IPsec module maintains separate inbound
(*spd_inbound*) and outbound (*spd_outbound*) SPD databases. As shown in
Figure xx, each SPD entry (*spdentry*) is specified in preferential
order. The following are the list of attributes:

-   ***id**:* the entry identifier.

-   ***selector**:* one or more selectors which is used to map traffic
    to a specific SA or SAs. The following selector parameters are
    defined:

    -   ***type**:* the selector parameter identifier. The parameters
        currently supported are *SRC_IP, DEST_IP, DEST_PORT, SRC_PORT,
        TP_PROTOCOL*.

    -   ***value_type**:* the type of the value: either the single value
        (*S*) or the range of values (*R*).

    -   ***value* or *value_range****:* the specific value. If the value
        type is *R*, *value_range* must be used and the range of values
        must be provided.

-   ***action:*** the specific action to be applied. If an SPD entry
    requires secure communication (*APPLY*), the entry must specify SA
    attributes as follows:

    -   ***encap_mode**:* the encapsulation mode. The TUNNEL mode is
        supported.

    -   ***remoteSG**:* the remote security gateway as a means of
        discovering remote gateway.

    -   ***sourceSG**:* IP address of the source SG to be used. This
        attribute is needed to support BGP.

    -   ***usepfs**:* the use of pfs.

    -   ***proposal**:* one or more proposals which are ORed in
        preferential order. A proposal specifies:

        -   ***protection**:* one or more protections. If more than one
            protection is specified, those entries are ANDed, which is
            generally used when required both ESP and AH protections. A
            protection, in turn, specifies:

            -   ***id**:* the protection identifier.

            -   ***protocol**:* a security protocol to be used (e.g.,
                ESP or AH);

            -   ***policy**:* one or more policies which are ANDed when
                encoding. A *policy* specifies the following attributes:

                -   ***type**:* the type of transform. The supported
                    transforms are:

                    -   ***encrypt**:* the encryption algorithm;

                    -   ***auth:*** the integrity algorithm

                -   ***id**:* one or more values of the specific
                    transform defined by *type*. The values of the
                    transform are ORed in preferential order.

[]{#__RefHeading___Toc71429790 .anchor}Figure : Part of the
Specification for IPsec Policy

# 6. NIIST Player 

The NIIST Player is a simulation animation tool that allows the user to
interactively browse the simulation log file and to dynamically
reconstruct and visualize the state of the Ipsec and IKE events from the
simulation results. The Player displays these events in sequence, in
chronological order and provides performance statistics that are also
dynamically displayed. It allows the user to freely move to specific
points in time or to step through the events one at a time.

## 6.1 Main Window

![](media/image4.png){width="4.166666666666667in"
height="4.760416666666667in"}

[]{#__RefHeading___Toc71429791 .anchor}Figure 13: NIISTPlayer Main
Window

The *main window*, as shown in Figure 13, allows the user to select
items he/she would like to see and to start/close the simulation. The
user can select *System Status Window* that is on as default and one or
more *security gateways*.

Upon pressing the *start* button, the selected items will open up the
corresponding frames. The *close* button exits the program.

## 6.2 System Status Window

The *System Status Window*, shown in Figure 14, displays all the events
including IKE and Ipsec events that occurred during the simulation run.

![](media/image5.jpeg){width="5.998611111111111in"
height="4.217361111111111in"}

[]{#__RefHeading___Toc71429792 .anchor}Figure 14: System Status Window

The System Status Window contains the following components:

-   **Slider**: is used to adjust the speed of display for each element
    to the table. If the slider is to the left of the middle of the
    slider, it sleeps anywhere from 30 to 210 microseconds. If the
    slider is to the right of the middle bar, the program sleeps
    anywhere from 670 to 1210 microseconds. The default (middle of the
    bar) is to sleep for about 210 microseconds.

-   **Start**: is used to continue the addition of elements to the table
    if the *Stop* or the *Step* button was previously pressed.

-   **Stop**: is used to suspend the addition of elements to the table
    temporarily.

-   **Step**: is used to add one element to the table, then awaits
    further user input.

-   **GoTo**: is used to select a specific point in time that the user
    would like to view. A dialog box is provided to enter the specific
    time. The program displays all of the times up to, and including the
    time requested. In addition, the next time in the sequence is also
    displayed, so the user can see what two events the time one entered
    falls between.

-   **Begin**: is used to move the view of the table from the current
    view to display the first element added to the table.

-   **End**: is used to move the view of the table from the current view
    to display the last element added to the table.

-   **The Text area**: is used to display the full information about the
    specific element if the user selects a specific element.

-   **The Ipsec and IKE tables**: displays the Ipsec and IKE events
    respectively.

    -   Each element for the Ipsec table provides the following:

        -   Time in seconds

        -   Local and remote gateway

        -   Status of the event

        -   Client initiator and client responder

        -   SPI

        -   Current SA ID

        -   Corresponding SA ID: if the current SA is for inbound, then
            the corresponding SA would be for outbound, and vice versa.

        -   Old SA ID

    -   Each element for the IKE table provides the following:

        -   Time in seconds

        -   Local and remote gateway

        -   State of the IKE exchange: phase 1, phase 2, new key or
            re-keying.

        -   Initiator and responder cookies

        -   Client initiator and client responder

        -   My SPI

        -   Peer SPI

        -   Message ID

## 6.3 SADB Window for A Gateway

The SADB Window (shown in Figure 15) shows a snapshot of the SA database
contained in the Ipsec module in a particular gateway that is chosen by
the user, from the Main Window.

![](media/image6.jpeg){width="6.250694444444444in" height="4.625in"}

[]{#__RefHeading___Toc71429793 .anchor}Figure 15: SADB Window for A
Security Gateway

The following Menus are available:

-   **File**: is used to close the window.

-   **Options**:

    -   **Go To**: is used to select a specific point in time that the
        user would like to view. A dialog box is provided to enter the
        specific time. The program displays all of the times up to, and
        including the time requested. In addition, the next time in the
        sequence is also displayed, so the user can see what two events
        the time one entered falls between.

    ```{=html}
    <!-- -->
    ```
    -   **Reset**: clears the widow.

    -   **Mode**: provides two options:

        -   **Show full data**: displays all the events in the
            simulation. All options are available in this mode.

        -   **Show current sa**: displays the events for the currently
            active SAs. The buttons **Start**, **Step** and **Next SA**
            are disabled in this mode. If one of those buttons is
            pressed, a pop-up message is displayed to change to the
            **Full** mode.

-   **Look Up**: the user can look-up SAs by either SPI or SA ID:

    -   **SPI**

    -   **SA ID**

Each window contains the following components:

-   **Slider**: is used to adjust the speed of display for each event to
    the table. The default is to display events based on a simulation
    time. If the slider is to the furthest left of the middle of the
    slider, the program displays the elements one after another, without
    regard to any simulation time ratio. The amount of time that the
    program sleeps when the slider in on simulation time and to the left
    is about from 10 ms to 10 times the difference between the current
    time just added and the next time that is going to be added. The
    default is 10 times the difference between the time just added and
    the time to be next added. When the slider is the right of the
    middle point, then the value is from 50 times the difference between
    the times, to 1000 times the difference between the times. When the
    time between two successive elements is very small (e.g., less than
    one second) or large (e.g., greater than 100 seconds), the program
    increases or decreases, respectively, the time between the addition
    of the elements.

```{=html}
<!-- -->
```
-   **Start**: is used to continue to add elements to the table if the
    **Stop** or **Step** button was previously pressed.

-   **Stop**: is used to suspend the addition of elements to the table
    temporarily.

-   **Step**: is used to add one element to the table, then awaits
    further user input.

-   **Next SA**: allows the user to move the next related event. When
    the button is pressed, the program moves to the next event involving
    the same two nodes from the highlighted element. This can be used to
    locate, for example, the completed or re-keyed SA from the new SA
    request.

-   **Begin**: is used to move the view of the table from the current
    view to display the first element added to the table.

-   **End**: is used to move the view of the table from the current view
    to display the last element added to the table.

-   **Table**: each element of the table provides the following:

    -   Time in seconds

    -   SA ID

    -   Status of the event

    -   Client initiator and client responder

    -   Peer IP address

    -   SPI

    -   Protocol

    -   Old SA ID

    -   SPD ID

    -   The encryption/integrity algorithm

-   **#SAs -- initial**: displays the current number of initial SAs

-   **rekeyed**: displays the current number of re-keyed SAs

-   **Avg Delay**: displays current average SA latency

-   **Pkt drop (no SA)**: displays the current number of packets dropped
    due to no SAs

-   **The Text area**: displays the full information about the specific
    element if the user selects a specific element.

# 7. Conclusions

In this report, we have described the design, operations and modeling of
NIIST that includes the most recent IETF specifications of IPSec, IKE
(both the current version 1 (NIISTv1) and a proposal for version 2
(NIISTv2)), security policy and PF_Key. The NIIST would help study and
investigate behavioral and performance characteristics, including the
issues of interoperability, scalability and performance of interacting
suite of security protocols in large-scale VPN environments. The NIIST
can also be used to evaluate alternative strategies or techniques of the
current open issues and proposed extensions to IPSec such as various
re-keying techniques and IPsec packet handling options.

**References**

\[RFC2401\] S. Kent and R. Atkinson, \"Security Architecture for the

Internet Protocol\", RFC 2401, November 1998.

\[RFC2402\] S. Kent and R. Atkinson, \"IP Authentication Header\",

RFC 2402, November 1998.

\[RFC2406\] S. Kent and R. Atkinson, \"IP Encapsulating Security

Payload (ESP)\", RFC 2406, November 1998.

\[RFC2407\] D. Piper, \"The Internet IP Security Domain of

Interpretation for ISAKMP\", RFC 2407, November 1998.

\[RFC2408\] D. Maughan, M. Shertler, M. Schneider, J. Turner,

\"Internet Security Association and Key Management Protocol

(ISAKMP)\", RFC 2408, November 1998.

\[RFC2409\] D. Harkins and D. Carrel, \"The Internet Key Exchange
(IKE)\",

RFC 2409, November 1998.

\[RFC2367\] D. McDonald, C. Metz and B. Phan, RFC2367, \"PF_KEY

Key Management API, Version 2\", July 1998.

\[PFKEY-EXT\] Jari Arkko, draft-arkko-pfkey-reference-00.txt, \"PF_KEY

Extensions for Reducing Policy Information in Kernel\'\',

July 14, 2000

\[REKEYING\] Tim Jenkins, draft-jenkins-ipsec-rekeying-06.txt,

\"IPsec Re-keying Issues\", May 3, 2000

\[SSF-WEB\] http://www.ssfnet.org/homePage.html

\[SSF\] J. Cowie, and et al, \`\`Towards Realistic Million-Node Internet

Simulations\'\', June, 1999.

\[IKEV2\] Charlie Kaufman, Editor, \`\`Internet Key Exchange (IKEv2)
Protocol\'\', draft-ietf-ipsec-ikev2-12.txt, January 6, 2004.

\[CERBERUS\] http://www.antd.nist.gov/itg/cerberus/