Skip to main content

4.4.1.1. Selectors

An SA may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Layer Protocol and related fields, e.g., ports), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair.

The following selector parameters MUST be supported by all IPsec implementations to facilitate control of SA granularity. Note that both Local and Remote addresses should either be IPv4 or IPv6, but not a mix of address types. Also, note that the Local/Remote port selectors (and ICMP message type and code, and Mobility Header type) may be labeled as OPAQUE to accommodate situations where these fields are inaccessible due to packet fragmentation.

Remote IP Address(es)

Type: IPv4 or IPv6

This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of:

  • A single IP address (via a trivial range)
  • A list of addresses (each a trivial range)
  • A range of addresses (low and high values, inclusive)
  • A list of ranges

Address ranges are used to support more than one remote system sharing the same SA, e.g., behind a security gateway.

Local IP Address(es)

Type: IPv4 or IPv6

This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of:

  • A single IP address (via a trivial range)
  • A list of addresses (each a trivial range)
  • A range of addresses (low and high values, inclusive)
  • A list of ranges

Address ranges are used to support more than one source system sharing the same SA, e.g., behind a security gateway. Local refers to the address(es) being protected by this implementation (or policy entry).

Note: The SPD does not include support for multicast address entries. To support multicast SAs, an implementation should make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries require a different structure, i.e., one cannot use the symmetric relationship associated with local and remote address values for unicast SAs in a multicast context. Specifically, outbound traffic directed to a multicast address on an SA would not be received on a companion, inbound SA with the multicast address as the source.

Next Layer Protocol

Source: IPv4 "Protocol" field or IPv6 "Next Header" field

Values: Individual protocol number, ANY, or (IPv6 only) OPAQUE

The Next Layer Protocol is whatever comes after any IP extension headers that are present. To simplify locating the Next Layer Protocol, there SHOULD be a mechanism for configuring which IPv6 extension headers to skip.

Default IPv6 extension headers to skip:

  • 0 (Hop-by-hop options)
  • 43 (Routing Header)
  • 44 (Fragmentation Header)
  • 60 (Destination Options)

Note: The default list does NOT include 51 (AH) or 50 (ESP). From a selector lookup point of view, IPsec treats AH and ESP as Next Layer Protocols.

Next Layer Protocol-Dependent Selectors

Several additional selectors depend on the Next Layer Protocol value:

Ports (TCP, UDP, SCTP, etc.)

If the Next Layer Protocol uses two ports (as do TCP, UDP, SCTP, and others), then there are selectors for Local and Remote Ports. Each of these selectors has a list of ranges of values.

Important: The Local and Remote ports may not be available in the case of receipt of a fragmented packet or if the port fields have been protected by IPsec (encrypted); thus, a value of OPAQUE also MUST be supported.

Fragmentation handling:

  • In a non-initial fragment, port values will not be available.
  • If a port selector specifies a value other than ANY or OPAQUE, it cannot match packets that are non-initial fragments.
  • If the SA requires a port value other than ANY or OPAQUE, an arriving fragment without ports MUST be discarded. (See Section 7, "Handling Fragments".)

Mobility Header Type

If the Next Layer Protocol is a Mobility Header, then there is a selector for IPv6 Mobility Header message type (MH type). This is an 8-bit value that identifies a particular mobility message.

Note: The MH type may not be available in the case of receipt of a fragmented packet. (See Section 7, "Handling Fragments".)

For IKE: The IPv6 Mobility Header message type (MH type) is placed in the most significant eight bits of the 16-bit local "port" selector.

ICMP Type and Code

If the Next Layer Protocol value is ICMP, then there is a 16-bit selector for the ICMP message type and code.

Structure:

  • Message Type: Single 8-bit value defining the type of an ICMP message, or ANY
  • ICMP Code: Single 8-bit value defining a specific subtype for an ICMP message

For IKE:

  • Message type is placed in the most significant 8 bits of the 16-bit selector
  • Code is placed in the least significant 8 bits

Allowed combinations:

  • Single type and a range of codes
  • Single type and ANY code
  • ANY type and ANY code

Matching algorithm: Given a policy entry with a range of Types (T-start to T-end) and a range of Codes (C-start to C-end), and an ICMP packet with Type t and Code c, an implementation MUST test for a match using:

(T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end

Note: The ICMP message type and code may not be available in the case of receipt of a fragmented packet. (See Section 7, "Handling Fragments".)

Name

Important: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address.

Named SPD entries are used in two ways:

Use Case 1: Responder (Access Control for Road Warriors)

A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors".

Process:

  1. The name used to match this field is communicated during the IKE negotiation in the ID payload.
  2. The initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation.
  3. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion.

Requirement: All IPsec implementations MUST support this use of names.

Supported name forms:

  • Fully Qualified Domain Name (FQDN)
  • Distinguished Name (DN)
  • RFC 822 email address
  • Key ID

Use Case 2: Initiator (Multi-User Identification)

A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). The initiator's IP source address (from inner IP header in tunnel mode) is used to replace the following if and when they are created:

  • Local address in the SPD cache entry
  • Local address in the outbound SAD entry
  • Remote address in the inbound SAD entry

Support: This use is optional for multi-user, native host implementations and not applicable to other implementations.

Note: This name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context.

Name in SPD Entries

An SPD entry can contain both a name (or a list of names) and also values for the Local or Remote IP address.

For case 1 (responder): The identifiers employed in named SPD entries are DNS names, distinguished names, or RFC 822 email addresses.

For case 2 (initiator): The name forms may be the same as for case 1, or may be a user ID (UID) or other local naming convention.

Important naming rules:

  • All SPD entries MUST be able to accommodate the forms of names defined above for responder use.
  • If an implementation allows SPD entries to be created using locally significant name forms for initiator use, this is a local matter.
  • An SPD entry that includes a name can be used only if the name resolves to a Local or Remote IP address, or if the name is used during IKE negotiation to match the ID payload.