Skip to main content

4.4.1.2. Structure of an SPD Entry

This section contains a prose description of an SPD entry. Also, Appendix C provides an example of an ASN.1 definition of an SPD entry.

IKE Compatibility Considerations​

This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKEv2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKEv2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKEv2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired.

IMPORTANT: Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics.

Management Interface Considerations​

The management GUI can offer the user other forms of data entry and display, e.g., the option of using address prefixes as well as ranges, and symbolic names for protocols, ports, etc. (Do not confuse the use of symbolic names in a management interface with the SPD selector "Name".)

Note: Remote/Local apply only to IP addresses and ports, not to ICMP message type/code or Mobility Header type. Also, if the reserved, symbolic selector value OPAQUE or ANY is employed for a given selector type, only that value may appear in the list for that selector, and it must appear only once in the list for that selector.

Note: ANY and OPAQUE are local syntax conventions -- IKEv2 negotiates these values via the ranges indicated below:

ANY:     start = 0        end = <max>
OPAQUE:  start = <max>    end = 0

SPD Entry Fields​

An SPD is an ordered list of entries each of which contains the following fields.

o Name​

A list of IDs. This quasi-selector is optional. The forms that MUST be supported are described above in Section 4.4.1.1 under "Name".

o PFP flags​

One per traffic selector. A given flag, e.g., for Next Layer Protocol, applies to the relevant selector across all "selector sets" (see below) contained in an SPD entry. When creating an SA, each flag specifies for the corresponding traffic selector whether to instantiate the selector from the corresponding field in the packet that triggered the creation of the SA or from the value(s) in the corresponding SPD entry (see Section 4.4.1, "How to Derive the Values for an SAD Entry"). Whether a single flag is used for, e.g., source port, ICMP type/code, and MH type, or a separate flag is used for each, is a local matter.

There are PFP flags for:

  • Local Address
  • Remote Address
  • Next Layer Protocol
  • Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
  • Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)

o One to N selector sets​

These correspond to the "condition" for applying a particular IPsec action. Each selector set contains:

  • Local Address
  • Remote Address
  • Next Layer Protocol
  • Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
  • Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)

Note: The "next protocol" selector is an individual value (unlike the local and remote IP addresses) in a selector set entry. This is consistent with how IKEv2 negotiates the Traffic Selector (TS) values for an SA. It also makes sense because one may need to associate different port fields with different protocols. It is possible to associate multiple protocols (and ports) with a single SA by specifying multiple selector sets for that SA.

o Processing info​

Which action is required -- PROTECT, BYPASS, or DISCARD. There is just one action that goes with all the selector sets, not a separate action for each set. If the required processing is PROTECT, the entry contains the following information.

Processing Information Fields (for PROTECT):

  • IPsec mode -- tunnel or transport

  • (if tunnel mode) local tunnel address -- For a non-mobile host, if there is just one interface, this is straightforward; if there are multiple interfaces, this must be statically configured. For a mobile host, the specification of the local address is handled externally to IPsec.

  • (if tunnel mode) remote tunnel address -- There is no standard way to determine this. See 4.5.3, "Locating a Security Gateway".

  • Extended Sequence Number -- Is this SA using extended sequence numbers?

  • stateful fragment checking -- Is this SA using stateful fragment checking? (See Section 7 for more details.)

  • Bypass DF bit (T/F) -- applicable to tunnel mode SAs

  • Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs

  • IPsec protocol -- AH or ESP

  • algorithms -- which ones to use for AH, which ones to use for ESP, which ones to use for combined mode, ordered by decreasing priority

Note: It is a local matter as to what information is kept with regard to handling extant SAs when the SPD is changed.

Last updated on