Advanced IPsec/IKE Policy Features

Jump to: navigation, search

Table of Contents >> IPsec/IKE Programmer's Reference

IPsec Policy Opaque Data Support

Treck provides an alternative API that allows the user to add an IPsec policy that contains user-defined opaque data. To add a policy with opaque data use tfPolicyAddWithUserData(). This API is only enabled by defining TM_IPSEC_POLICY_USER_DATA at compile time.


64-bit Support

IPsec supports both 32-bit and 64-bit sequence numbers and SA lifetime values. Both features are optionally enabled through the use of macros.

64-bit Sequence Numbers (negotiation only)

IPsec sequence numbers can be extended from 32-bits to 64-bits. To enable this feature, define TM_IPSEC_USE_64BIT_SEQ_NO in <trsystem.h>.

Enabling 64-bit sequence numbers will add a new flag to the ttPolicyContentInString structure’s pctstrRuleFlags data member that signals the use of 64-bit sequence numbers.

From trsecapi.h:

#define TM_PFLAG_64BIT_SEQ_NO 0x10000 /* bit 16 */
Warning Warning: This feature requires the remote peer to use 64-bit sequence numbers.


64-bit SA Lifetimes

SA lifetime attributes can be negotiated using 64-bit values. To enable this feature, define TM_USE_IPSEC_64BIT_KB_LIFETIMES in <trsystem.h>.


This macro modifies the user-level policy content structure such that lifetime values change from 32-bit data types to 64-bit data types.

From trsecapi.h:

typedef struct tsPolicyContentInString
{
…
#ifdef TM_USE_IPSEC_64BIT_KB_LIFETIMES
ttUser64Bit pctstrLifeKbytes;
#else /* TM_USE_IPSEC_64BIT_KB_LIFETIMES */
ttUser32Bit pctstrLifeKbytes;
#endif /* TM_USE_IPSEC_64BIT_KB_LIFETIMES */
…
} ttPolicyContentInString;
From trsocket.h:
#ifndef TM_USER_64BIT_TYPE
typedef struct tsUser64Bit
{
ttUser32Bit uu64high;
ttUser32Bit uu64low;
} ttUser64Bit;
typedef ttUser64Bit TM_FAR * ttUser64BitPtr;
#endif /* TM_USER_64BIT_TYPE */

When enabled, phase 2 SA KB lifetime attributes will use the 64-bit length qualifier thus allowing proper lifetime negotiation with enabled peers. Subsequent SA expiration logic will use the extended lifetime values.


Note Note: 64-bit lifetime fields are used only when required. Thus, a peer may offer a 32-bit value which will then be used. Also, an offer with a value that fits in 32-bits results in 32-bit negotiation.

Simultaneous Rekey Optimizations

Many IKE implementations suffer from the inability to gracefully handle the case when two peers try to rekey the same SA simultaneously. Treck incorporates a simple comparison of cookies to determine which peer should become the "master" of the renegotiation, however this can only take place when the remote peer also implements this same logic. At the present time, the stack will only perform this optimization when communicating with another peer running an instance of the Treck stack.

Vendor ID Payload

The Treck stack makes use of the Vendor ID Payload to determine the author of the remote peer's stack. The Vendor ID Payload is an optional feature which can be enabled by defining TM_USE_IKE_VENDOR_ATTR in trsystem.h:

This adds a new flag to the ttPolicyContentInString structure's pctstrRuleFlags data member that signals the required inclusion of the Vendor ID Payload. From <trsecapi.h>:

#define TM_IKE_TRECK 0x0100 /* Treck IKE Vendor ID */

The Treck Vendor ID is the MD5 has of the following string:

Treck Inc. IKE version 4
VID: 03EB06CCB6C1DB9AE994483FD52C2A9D
Note Note: The Vendor ID Payload is automatically enabled when using NAT-T or Dead Peer Detection as it is required for both features.

Vendor ID Processing

When two Treck stacks are attempting to rekey the same SA at the same time, the ISAKMP cookies are compared. The peer with the lower-valued cookie will become the "owner" of the rekey process while the higher-valued cookie owner will discontinue the attempt to initiate the rekey (and thus respond). This avoids the many complications associated with managing a simultaneous rekey of the same SA (or set of SAs).

Dead Peer Detection (DPD)

Dead Peer Detection or DPD (RFC 3706) provides a mechanism for a local IKE peer to detect non-responsive remote IKE peers for which exist active Phase 1 or Phase 2 SAs. Without such detection, one or more communicating nodes may be sending IPsec traffic into a "black hole" until the SAs expire. This consumes resources which may have otherwise been freed given knowledge of the communication lapse and also provides each node with the opportunity to more quickly re-establish communication once the possibility exists.

The feature can be enabled by defining TM_USE_IKE_DPD in <trsystem.h>.

When DPD is enabled, IKE Policy configuration provides parametric configuration which governs behavior.


Note Note: Dead Peer Detection requires that IKE Policies be in use (TM_USE_IKE_POLICIES).


IKE Policy DPD Attributes

For each individual IKE Policy, DPD can be enabled or disabled by setting the following flag in the ikpsAttributes data member of the ttIkePolicyInString structure during IKE Policy creation.

When this flag is set, the following ttIkePolicyInString data members must contain valid configuration data:

  • ikpsDpdWorryMetric This contains the amount of time, in seconds, that the local peer waits before becoming "worried" that a peer may have died. When the local peer becomes "worried", an R-U-THERE Notification message is sent.
  • ikpsDpdRetransDelay This contains the amount of time, in milliseconds, before an unacknowledged R-U-THERE Notification message is retransmitted.
  • ikpsDpdRetransLimit This contains the number of retransmissions required before the local peer decides that the remote peer is dead. When this takes place, all associated Phase 1 and Phase 2 SAs are removed.
  • ikpsDpdMode This contains the Dead Peer Detection Mode which must be either TM_IKE_DPD_PERIODIC or TM_IKE_DPD_ON_DEMAND.


DPD Processing

Dead Peer Detection operates in one of two modes as determined by the value of ikpsDpdMode:

TM_IKE_DPD_PERIODIC This mode instructs the local peer to send an R-U-THERE Notification message every ikpsDpdWorryMetric seconds.

TM_IKE_DPD_ON_DEMAND This mode instructs the local peer to send an R-U-THERE Notification message only when there is data to send the remote peer and the ikpsDpdWorryMetric seconds have passed since the last Notification was sent. This allows long idle periods to be free of the Notification message traffic.

Dead Peer Detection can also be configured such that it will respond to remote peer R-U-THERE Notification messages without generating those of its own. This implies recognition of remote peer's need to have knowledge of liveliness however does not require knowledge of the remote peer's liveliness locally. This is achieved by setting the ikpsDpdWorryMetric to 0.


Note Note: Dead Peer Detection is not supported in conjunction with ISAKMP Phase 1 Perfect Forward Secrecy (PFS).

IP Compression

IKE provides for negotiation of IP Compression algorithms. However, IPsec and the required cryptography support is not currently implemented. For the time being, leave TM_USE_IPSEC_IPCOMP undefined in <trsystem.h>.

ESP/UDP Encapsulation with NAT-Traversal

IPsec, a "portless" protocol, is inherently incompatible with Network Address Translation (NAT). However, RFC 3948 describes a method for encapsulating ESP inside UDP packets for both IPv4 and IPv6. RFC 3947 describes the mechanism by which IKE is used to discover both the existence of NAT devices between IPsec peers and the way in which they negotiate encapsulation. Together these protocol enhancements allow IPsec peers to operate when one or more Network Address Translation devices lie in the path. More background information can be found in RFC 3715.

Requirements

RFC 3947 and RFC 3948 require the following for NAT-Traversal:

  • IKE must be used for both device discovery and negotiation; manual SAs are not supported.
  • NAT-Traversal is compatible with ESP only; AH is not supported.
  • In order for an IPsec peer to discern between IKE and ESP packets, IKE must not set the ESP SPI field to 0.
  • UDP Encapsulated ESP packets use the same port number as that used for IKE.
IKE Phase 1 Modifications for NAT-Traversal

To support NAT-Traversal, IKE:

  • Detects whether the negotiating peer supports NAT
  • Detects whether one or more NAT devices exists between the peers (NAT Discovery payload)

To support NAT-Traversal, IKE Quick Mode:

  • Negotiates the use of UDP encapsulated IPsec packets
  • Transmits the original source and destination addresses to the peer (NAT Original Address payload). This allows the host to update the decrypted ULP checksum if necessary (NAT cannot access the transport mode checksum).

Using UDP Encapsulation with ESP and NAT-Traversal

UDP Encapsulation with ESP and NAT-Traversal requires the use of IKE Policies. IKE Policies can be enabled by defining TM_USE_IKE_POLICES in <trsystem.h>.

NAT-T must also be enabled by defining TM_USE_NATT in <trsystem.h>.

NAT-Traversal requires the use of keep alive messages which keep NAT mappings from expiring. The default time interval, in seconds, is 20 seconds. This can be changed to 5 seconds, for example, by adding the following macro to <trsystem.h>:

#define TM_IKE_NATT_KA_INTERVAL 5

When this value is set to 0, however, the NAT-T keep alive timer is not started.

IKE Policy NAT-T Attributes

NAT-Traversal can be enabled/disabled for each individual IKE Policy. This is done by setting the following flag in the ikpsAttributes data member of the ttIkePolicyInString structure during IKE Policy creation:

TM_IKE_NATT This flag must be set to enable NAT-T.

When this flag is set, the following ttIkePolicyInString data member must contain the time interval, in seconds, for the NAT-Traversal keep alive:

ikpsNattKAInterval This value contains the time interval, in seconds, between NAT-Traversal keep alive messages. When NAT devices are detected between peers, these keep alive messages are sent to make sure NAT mappings do not expire. Set this to 0 to use the default value provided by TM_IKE_NATT_KA_INTERVAL.
IPsec Policy Requirements for NAT-T Transport Mode Only

With NAT-T, 2 remote hosts A and B behind a NAT router implementing port mapping will appear to have the same IP addresses to the public side host H. Using the remote IP address as a selector on host H is not enough to distinguish between traffic to and from host A and host B. It is therefore necessary to require that traffic also match on the remote port and protocol when an SA is created on host H.

This can be done by setting the appropriate flags in the policy content. From ttPolicyContent:

typedef struct tsPolicyContent{
...
/* AH|ESP, tunnel|transport, policy|packet determination */
ttUser32Bit pctRuleFlags;
...
} ttPolicyContent;

For NAT-T to function properly insure that pctRuleFlags includes the following:

  • TM_PFLAG_RPT_PACKET This flag indicates that SAs should be compared/created with the remote port from the packet rather than from the policy.
  • TM_PFLAG_PROTO_PACKET This flag indicates that SAs should be compared/created with the protocol value from the packet rather than from the policy.


Table of Contents >> IPsec/IKE Programmer's Reference