NIST IPSec and IKE Simulation Tool

Features Supported

Note: the names of attributes and parameters used in this section are mainly based on IKEv1, unless otherwise stated. IKEv2 may use the new terminology. IKEv1- and IKEv2-specific features are specified next to that feature/parameter.

The followings are a list of the major features of IKEv1 and IKEv2 implemented in NIIST:

• a single value (S)
• range of values (R)
• wildcard (*) (W)
  It is also considered to be wildcard if no specific selector type entry is provided in a dml input file.

• IP source address (IPv4): S, R, W
• IP destination address (IPv4): S, R, W
• source port: S, W
• destination port: S, W
• transport protocol: S

• Phase 1
• Phase 2
• Informational (Delete messages are implemented and Notify messages partially implemented)

• Security Association Payload
• Proposal Payload
• Transform Payload
• TrafficSelector Payload (IKEv2)
• Identification Payload
• Delete Payload
• Nonce Payload
• Notification Payload
• Key Exchange Payload
• Authentication Payload (IKEv2)

• single IP address (IPv4)
• range of IP addresses

• IPSEC situation definition: SIT_IDENTITY_ONLY (IKEv1)
• Security protocol: ISAKMP (IKEv1) or IKE (IKEv2)
• ISAKMP transform: KEY_IKE
• Cryptographic algorithms (encryption, authentication)
  • AES
  • 3DES (default)
  • SHA1 (default)
  • any other algorithms as long as the performance of those algorithms are provided.
• Authentication method:
  • preshared secret key (IKEv1)
  • Digital Signatures (IKEv2)
• SA life type: SECONDS (IKEv1)
• SA life duration (IKEv1)

• Security protocol:
  • ESP
    • Transform:
      ESP_AES
      ESP_3DES (default)
      any other algorithms available.
    • Authentication algorithm:
      HMAC_MD5
      HMAC_SHA1
  • AH
    • Transform:
      AH_MD5 (default)
      AH_SHA1
• Encapsulation mode: TUNNEL (IKEv1)
• SA life type: SECONDS (IKEv1)
• SA life duration (IKEv1)

NIIST Limitations and Known Bugs

Cryptographic Security Services:
The size of secure messages (IKE or IPSec) generated in the framework (specifically after encryption) may not reflect the exact actual size of the ciphertext created in real implementations since no actual cryptographic security functionalities are implemented. However, the difference between clear and secure messages would be minimal and overall protocol behavior would remain the same. The user can have an option to specify the performance of different cryptographic algorithms or even the same cryptographic algorithm with different key/block sizes.

IKE Key Generation
Actual key exchange is not implemented, however, DH exchange processing delay is modeled.

Inconsistent Transform IDs between peers
May generate NullPointerException.

Informational Exchange During SA Negotiation
NIIST supports an SA negotiation that includes multiple proposals. The initiator can offer a list of security policy from the local SPD (in decreasing preference order) for potential SAs to the responder. The responder can select potential proposals based on its own local policy. If any of proposals offered does not match to the responder's local policy, the simulation ends abruptly without proper error messages. This problem will soon be solved once Informational Exchange is fully implemented.

No Operating Processing Delay
As with the SSFNet, NIIST processes a message with no logical-time advance, i.e., the message is simultaneously processed from the user level protocol to a network device driver except the cryptographic fucntion delay, if provided.

SA Bundling
SA bundle for iterated tunneling with the same endpoints for the SAs is partially implemented and have not been tested.