3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol in addition to what is specified in [RFC2407], [RFC2408], [RFC2409], [RFC3947], and [RFC4301] for IKEv1, or [RFC4306] for IKEv2. The described organization is provided to explain how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with the behavior described in this document.

The following main data elements are required by any implementation:

  • Main mode security association database (MMSAD): A database that contains the operational state for each MM SA. The entry for each MM SA contains the following data elements.

    For each IKE MM SA, the following information MUST be maintained:

    • All states that are necessary for managing a standard IKE MM SA as defined in [RFC2409] appendix A for IKEv1 and [RFC4306] section 3.3.2 for IKEv2.

    • All states that are necessary for management of other IKE extensions for the SA, as specified in this section and in sections 3.2.1, 3.3.1, 3.4.1, 3.5.1, 3.6.1, 3.7.1, 3.8.1 for IKEv1 only, and 3.10.1 for IKEv2 only.

      The MMSAD MUST be indexed by the local and peer IP addresses and the initiator and responder (1) cookies found in the ISAKMP header, as specified in [RFC2408].

  • Peer authorization database (PAD): The PAD and its management operations are specified in [RFC4301] section 4.4.3. This specification does not extend that definition. The PAD that is referred to in this specification contains rules that describe if and how IKE negotiates SAs with a remote peer, as specified in [RFC4301].

    All states that are necessary for the management of IKE extensions are described in section 3.4.1 for IKEv1 only.

    The PAD MUST be looked up by using tuples that are composed of local and remote IP addresses.

  • Security policy database (SPD): The SPD and its management operations are specified in [RFC4301] section 4.4.1. The SPD that is referred to in this specification contains rules that describe if and how IPsec protection is applied to inbound or outbound IP traffic. The SPD MUST be looked up by using tuples that are composed of flow information (that is, source and destination IP addresses, port numbers, and protocol) for the packet.

    All states that are necessary for management of IKE extensions are described in section 3.7.1 for IKEv1 only.

  • Security association database (SAD): The SAD contains the parameters of each QM SA. The SAD and its management operations are specified in [RFC4301] section 4.4.2.

    All states that are necessary for management of IKE extensions are described in section 3.7.1 for IKEv1 only.

  • Connection state table: Stores a set of connection entries. These connection entries correspond to active TCP/UDP/ICMP or protocol-only connections.

    The possible connection entries are:

    • V4 TCP/UDP state entry: {IPv4 source address {DWORD}, IPv4 destination address {DWORD}, IP protocol {DWORD}, source port {DWORD}, destination port {DWORD}}.

    • V6 TCP/UDP state entry: {IPv6 source address {16 bytes}, IPv6 destination address {16 bytes}, IP protocol {DWORD}, source port {DWORD}, destination port {DWORD}}.

    • V4 ICMP state entry: {IPv4 source address {DWORD}, IPv4 destination address {DWORD}, IP protocol {DWORD}, ICMP type {DWORD}, ICMP code {DWORD}}, as defined in [RFC792].

    • V6 ICMP state entry: {IPv6 source address {16 bytes}, IPv6 destination address {16 bytes}, IP protocol {DWORD}, ICMP type {DWORD}, ICMP code {DWORD}}, as defined in [RFC792].

    • V4 protocol-only state entry: {IPv4 source address {DWORD}, IPv4 destination address {DWORD}, IP protocol {DWORD}}.

    • V6 protocol-only state entry: {IPv6 source address {16 bytes}, IPv6 destination address {16 bytes}, IP protocol {DWORD}}.

      All states that are necessary for management of IKE extensions are described in section 3.7.1 for IKEv1 only.

    • Other states: Additional states are defined in section 3.9.1 and section 3.11.1.

Note The preceding conceptual data can be implemented by using a variety of techniques. Any data structure that stores the preceding conceptual data can be used in the implementation.