The NIIST is implemented in Java and integrated in the Scalable Simulation Framework (SSF) and SSF Network Model (SSFNet) to provide an integrated Internet security modeling framework in a large-scale network. The SSF is a discrete, event-driven, scalable modeling framework and SSFNet is a collection of Internet modeling tools for simulating Internet protocols and networks. SSF places particular emphasis in scalability and high-performance for simulating very large networks. 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.
As shown in diagram below, NIIST consists of the following major components:
Note that there are two version of IKE (IKEv1 and IKEv2). Both versions use a two-phase SA negotiations, but differ somewhat on technical details such as, for example, the number of messages for each exchange, the semantics of SAs (i.e., encoding and parsing of an SA payload), mandatory use of a Delete message, and etc. Also, IKEv2 provides the ability to piggyback setup of a Phase 2 SA on the initial Phase 1 exchange;
The followng functionalities are based on IKEv1. The IKEv2-specific features are discussed in Config IKEv2
As discussed in Base Software, message processing in SSF assumes no logical time advance within a specific gateway or host. However, cryptographic operations in security protocols can impact the behavior and performance of the overall system. We modeled their impact on protocol functions and performance by allowing cryptographic processing delay. To model 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 single key (or keys) contained in a valid SA can be safely used for encryption and authentication for a certain period of time. 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 verious 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 IPSec Rekeying Issues (draft expired), there is a potential interoperability problem in the Phase 2 negotiation due to the lack of a standardized re-keying mechanism among alternative techniques and various processors with different processing power and network bandwidth. We modeled various techniques of re-keying and transfer for both Phase1 and Phase 2.
IKE (Phase 1) SA Re-keying
There are currently two mechanisms modeled for the phase 1 re-keying:
For the continuous channel mode, a valid IKE SA is always available between two security gateways and is re-negotiated when threshold of an existing SA triggers. The valid IPSec SAs currently belonging to the expiring IKE SA are all transferred to the newly created IKE SA. The non-continuous mode does not re-negotiate an expiring SA and removes the SA if expired, independent of the IPSec SAs (allowing dangling IPSec SAs). A new IKE SA is only created whenever needed such as when the Phase 2 negotiation is required.
IPSec (Phase 2) SA Re-keying
When the threshold of an existing outbound SA (only outbound SAs are allowed to re-key) triggers a re-keying, IPSecManager sends a SADB_ACQUIRE message to IKEManager which initiates the Quick Mode negotiation. When a corresponding Phase 1 SA is not already set-up, IKEManager initiates the Phase 1 negotiation first before starting Phase 2. 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 IPSec SA transfer techniques (as discussed in IPSec Rekeying Issues) (draft expired) to examine the dynamic behavior and interoperability issues with regard to re-keying between peer gateways having different processing and network bandwidth. The following options are considered:
DeleteMsg uses Delete messages to remove old SAs and to set-up new SAs. In Fixed delay, re-keyed SAs are set-up for use when either receiving inbound traffic with the new SA or a fixed amount of time (the user-provided value: 30 seconds as default) has elapsed after the completion of SA re-negotiation, in the absence of incoming user traffic. As for twice measured RTT, re-keyed SAs are set-up for use when either receiving inbound traffic with the new SA or a twice the measured RTT has elapsed, in the absence of incoming user traffic, instead of waiting for a certain fixed amount of time as in the fixed dalay above. immediateUse sets-up new SAs and removes old SAs immediately. immediateUse is included only for the performance comparison.
IKE uses the UDP protocol, which is inherently unreliable. To make IKE reliable as specified in rfc2408, the transmitting entity in NIIST (i.e., initiator) sets a retransmission timer and a retry counter on each IKE request. The retransmission timer values are dynamically adjusted with the measured round trip time using exponential backoff.
In NIIST for IKEv1, however, both the initiator and the responder sets a
retransmission timer when sending IKE messages. 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, since the phase 2 exchange requires the odd number of
(3) messages.
The sender of the last message of 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). In this technique, however, the sender must keep
the last message even if the retransmission timer is not set in case
of retransmission.