13.2. ISAKMP

Although we needn't bother to examine the OAKLEY and SKEME protocols in detail, it is important to have a thorough understanding of ISAKMP because it provides the underlying mechanisms and message formats that IKE uses. ISAKMP is interesting in its own right, of course, because we can use it to implement many different key-exchange protocols. Nevertheless, we discuss ISAKMP only in the context of its use by IKE.

ISAKMP, like IKE, establishes SAs in two phases. In the first phase, the ISAKMP peers authenticate each other and establish a secure communication channel. In the second phase, ISAKMP negotiates VPN SAs. In IKE, for example, the AH and ESP SAs are negotiated in the second phase. The secure channel established in phase 1 can be used to negotiate several phase 2 SAs. We'll come back to the relationship between the two phases when we examine how they operate in IKE.

ISAKMP Cookies

One of IKE's goals is to guard against denial-of-service attacks. Because an attacker could merely flood an IKE node with random packets, it's not possible to provide absolute protection against DOS attacks, but we can protect against certain kinds of these attacks.

Recall that IKE uses a Diffie-Hellman exchange to derive a shared secret from which it generates other keying material. As we saw in Chapter 3, the Diffie-Hellman calculation involves exponentiation using big-number arithmetic and is therefore computationally expensive. One possible DOS attack is to flood an IKE node with IKE packets having random forged source addresses. The idea is to force the IKE node into making repeated, expensive, but useless, Diffie-Hellman calculations and thus make it unavailable for other work, including processing legitimate IKE messages.

ISAKMP prevents this attack by having the peers exchange cookies before making the expensive Diffie-Hellman calculations. When an ISAKMP node receives a message from its peer with the same cookie that it sent to that peer, it knows that the peer is at the specified source address; otherwise, it wouldn't have received the cookie that it is returning. After the first exchange, all further messages contain both cookies, which serve to identify that particular ISAKMP negotiation.

In order for this to work, the cookies must

• Be bound to the two peers using them. That is, the cookie must be specific to those two peers and them only. This prevents an attacker from obtaining a cookie from another negotiation and then flooding an ISAKMP node with packets having this cookie and forged source addresses.

• Not be forgeable by an attacker. That is, no one but the issuing ISAKMP node should be able to generate a cookie that the node will accept as legitimate.

• Be limited to a single negotiation so that old cookies can't be replayed. This criterion is met by having the cookie depend on the time it was generated.

One obvious way of meeting these criteria is to take a cryptographic hash of a concatenation of the peers' IP addresses and ports, a date/timestamp, and a secret known only to the cookie creator. That is,

Equation 1

where CKY is the cookie, src is the source IP address and port, dst is the destination IP address and port, ts is a timestamp, and secret is a random secret known only to the issuer of the cookie.

ISAKMP doesn't specify how the cookie should be generated, only that it should meet the above criteria and be relatively inexpensive to calculate. Most implementations calculate the cookie by using some variation of the method in (1).

The ISAKMP Header

Every ISAKMP and IKE message begins with an ISAKMP header. This header identifies the particular negotiation to which the message belongs, indicates the type of the first payload that the message contains, specifies the length of the message, and contains flags and other information. Figure 13.1 shows the format of this header.

Figure 13.1. The ISAKMP Header

[View full size image]

The initiator and responder cookies were discussed in the previous subsection. They are each 8 bytes long. The node that sends the first message in a negotiation is called the initiator, and its cookie comes first. The responder is the other node.

The next payload field indicates the type of the first payload in the message. Each payload also has a next payload field in a manner reminiscent of IPv6 extension headers. Figure 13.2 shows the payload types that can be in these fields.

Figure 13.2. Payload Types

Value	Payload Type
0	None
1	Security Association
2	Proposal
3	Transform
4	Key Exchange
5	Identification
6	Certificate
7	Certificate Request
8	HASH
9	Signature
10	Nonce
11	Notification
12	Delete
13	Vendor ID
14127	Reserved
128255	Private Use

The major and minor version fields indicate the ISAKMP version that generated this message. Currently, the major version is 1, and the minor version is 0.

As we'll see, ISAKMP uses several types of exchanges. The exchange type field carries the type of exchange that this message is for. Figure 13.3 shows the ISAKMP exchange types. The exchanges marked with a bullet in the IKE column are used in the IKE protocol. Quick Mode and New Group Mode are specific to IKE.

Figure 13.3. Exchange Types0

Value	Exchange Type	IKE
0	None
1	Base
2	Identity Protection	•
3	Authentication Only
4	Aggressive	•
5	Informational	•
631	ISAKMP Reserved
32	Quick Mode	•
33	New Group Mode	•
34239	DOI Reserved
240255	Private Use

The flags field is a single-byte bit mask for flags. Currently, three flags are defined:

Encryption	(bit 0) When this bit is set, the payloads following the ISAKMP header are encrypted as specified in the ISAKMP SA. The SA is identified by the two cookies. This flag cannot be set until after the peers have exchanged keys.
Commit	(bit 1) This flag is used to synchronize the key exchangethat is, to ensure that encrypted data is not sent before the SA is fully established. Either side can set the bit; the other side must wait for a CONNECTED notify message before using the SA.
Auth. Only	(bit 2) Normally, all phase 2 ISAKMP traffic is protected by the ISAKMP SA. In particular, this traffic will usually be encrypted. When this bit is set, it indicates that the payload is a Notify message that is protected with authentication but not encryption. This is the only exception to the rule that phase 2 traffic is encrypted as specified in the ISAKMP SA.

The message ID field is used to identify the protocol state in phase 2 negotiations. This identifier is necessary because several phase 2 SAs can be negotiated simultaneously, and the message ID ties the message to a particular negotiation. The message ID is a random 4-byte number that is generated by the initiator of the phase 2 negotiation. The message ID is set to 0 during phase 1 negotiations.

The length field is the total length of the ISAKMP message in bytes. The length includes both the header and payloads.

ISAKMP Payloads

ISAKMP messages consist of possibly multiple payloads that carry the details of the SA being negotiated. Each payload consists of a generic header (Figure 13.4) and a data stream that is opaque to ISAKMP: Their formats and interpretations are defined by a domain of interpretation (DOI) document. In the case of IPsec, the DOI is RFC 2407 [Piper 1998].

Figure 13.4. The ISAKMP Generic Header

[View full size image]

The DOI is more general than indicated here. In addition to defining the payload formats and their interpretation, it also defines naming conventions, security policies, additional exchange types and notification messages, and the syntax for IPsec SA attributes and payloads. It defines, in short, what ISAKMP should negotiate.

As we see in Figure 13.4, the generic header is a 4-byte structure that specifies the length of the payload and the type of the next payload, if any.

Some payloads have associated attributes. For example, IKE has such attributes as encryption method, key length, group type, and so on. We discuss individual attributes as we encounter them.

There are two types of attributes: basic and variable length. Basic attributes are encoded as type/value pairs, whereas variable-length attributes are encoded as type-length-value triplets. We show the encoding of attributes in Figure 13.5. The AF flag indicates whether the attribute is basic (AF=1) or variable length (AF=0). For variable-length attributes, the length field is the length of the value. The variable-length attribute value field is present only when the AF flag is 0.

Figure 13.5. ISAKMP Attribute

[View full size image]

Basic attributes are never encoded as variable length, but variable-length attributes may be encoded as basic attributes if their values fit in 2 bytes.

As we see from Figure 13.2, there are 13 ISAKMP payloads. For the rest of this section, we discuss these payloads and their formats but restrict the discussion to their use in IKE.

The Security Association, Proposal, and Transform Payloads

The first task in both the phase 1 and phase 2 negotiations is for the peers to agree on the parameters for the SA protecting the exchange. The peers do this by exchanging SA payloads. Each SA payload contains one or more Proposal payloads, which, in turn, contain one or more Transform payloads. These payloads can be combined to express complex policies.

Let's begin with the formats of the three payload formats involved. The SA payload indicates the DOI and the situation under which the negotiation is taking place. Figure 13.6 shows the SA payload.

Figure 13.6. The SA Payload

[View full size image]

The next payload field contains the type of the next payload. This will not be a Proposal or Transform payload, because they are considered part of SA payload. The payload length field contains the length of the entire payload, including the SA payload itself, all the associated Proposal payloads, and all the associated transform payloads.

The DOI field indicates the domain of interpretation. For IPsec, this is 1. The value 0 indicates a generic phase 1 ISAKMP SA that can be used for any phase 2 protocol. The only other legal value is 2, which indicates the group domain of interpretation (GDOI). See RFC 3547 [Baugher, Weis, Hardjono, and Harney 2003] for more on the GDOI.

The situation field provides context for the negotiation. The length and form of this field are specified by the DOI. For IPsec, the situation field is a 32-bit bit mask, having the possible values

SIT_IDENTITY_ONLY	(0x01) This indicates that the security association will be linked to the identity information provided in an Identification payload.
SIT_SECRECY	(0x02) This indicates that labeled secrecy is required for this SA. See RFC 2407 [Piper 1998] for more on this and the SIT_INTEGRITY bit. No labeled domains are currently defined, so SIT_SECRECY should not be specified.
SIT_INTEGRITY	(0x04) This is similar to the SIT_SECRECY situation, indicating that the SA requires labeled integrity. No labeled domains are currently defined, so SIT_INTEGRITY should not be specified.

As we see from Figure 13.6, the SA payload structure does not specify any SA state variables but merely sets the context in which the SA negotiation will take place. The actual parameters are negotiated in the Proposal and Transform payloads, which are associated with the SA payload. Figure 13.7 shows the first of these: the Proposal payload.

Figure 13.7. The Proposal Payload

[View full size image]

The next payload field is the next-payload type within this SA payload. The only legal values are Proposal and None (see Figure 13.2). The length field contains the length of the entire proposal, including the Proposal payload itself, and all transforms associated with the payload.

The proposal number field is used to logically combine proposals. Proposals with the same proposal number are ANDed together; those with different proposal numbers are ORed together. In the case of ORed proposals, the initiator will list them in preferred order, and the responder will choose one of the proposals and include only that proposal in its response.

The protocol ID field specifies the protocol being proposed. Figure 13.8 shows the valid IPsec protocol IDs.

Figure 13.8. IPsec Protocol IDs

Value	Protocol ID	Protocol
0	RESERVED
1	PROTO_ISAKMP	Phase 1 protection
2	PROTO_IPSEC_AH	Authentication Header
3	PROTO_IPSEC_ESP	Encapsulating Security Payload
4	PROTO_IPCOMP	IP Compression

For phase 2 proposals, the SPI size field is the size of the SPI in bytes. For IPsec, this is always 4. Phase 1 SAs are identified by the initiator and responder cookies from the ISAKMP header and don't have a separate SPI field. The SPI size for phase 1 SAs can be any number between 0 and 16. Even if the SPI size is nonzero for a phase 1 SA, the SPI field will be ignored.

Each proposal has one or more associated transforms: encryption and authentication algorithms, for example. The number of transforms field specifies how many transforms are included with this proposal.

The SPI field is the sender's security parameter index for this proposal: for IPsec phase 2 proposals, a 4-byte integer. This field has no meaning for phase 1 proposals and will not usually be presentthat is, the SPI size field will be 0.

The Transform payload carries information about the cryptographic primitives that a proposal will use. For example, if a proposal is for ESP, we might have transforms specifying that AES in CBC mode and SHA-1 will be the encryption and authentication methods. The Transform payload is shown in Figure 13.9.

Figure 13.9. The Transform Payload

[View full size image]

The next payload field specifies the next payload for this proposal. The only legal values are Transform and None. This is similar to the situation with the Proposal payload's next payload field.

The payload length field is the size in bytes of the Transform payload. Unlike the case with the SA and Proposal payloads, this length does not include any other payloads.

The transform number field is similar to the proposal number field in the Proposal payload but can indicate only an OR combination. The initiator will list the transforms in preferred order. The responder will choose one of the transforms and include that transform only in its reply.

The transform ID field is a code indicating which transform is being proposed. Each of the protocols from Figure 13.8 has its own namespace for transform IDs, shown in Figure 13.10.

Figure 13.10. IPsec Transform IDs

Protocol	Value	Transform ID	DOI
ISAKMP	0	RESERVED	•
ISAKMP	1	KEY_IKE	•
AH	01	RESERVED	•
AH	2	AH_MD5	•
AH	3	AH_SHA	•
AH	4	AH_DES	•
AH	5	AH_SHA2_256
AH	6	AH_SHA2_384
AH	7	AH_SHA2_512
AH	8	AH_RIPEMD
AH	9	AH_AES-XCBC-MAC
ESP	0	RESERVED	•
ESP	1	ESP_DES_IV64	•
ESP	2	ESP_DES	•
ESP	3	ESP_3DES	•
ESP	4	ESP_RC5	•
ESP	5	ESP_IDEA	•
ESP	6	ESP_CAST	•
ESP	7	ESP_BLOWFISH	•
ESP	8	ESP_3IDEA	•
ESP	9	ESP_DES_IV32	•
ESP	10	ESP_RC4	•
ESP	11	ESP_NULL	•
ESP	12	ESP_AES_CBC
ESP	13	ESP_AES_CTR
ESP	14	ESP_AES_CCM_8
ESP	15	ESP_AES_CCM_12
ESP	16	ESP_AES_CCM_16
IPCOMP	0	RESERVED	•
IPCOMP	1	IPCOMP_OUI	•
IPCOMP	2	IPCOMP_DEFLATE	•
IPCOMP	3	IPCOMP_LZS	•
IPCOMP	4	IPCOMP_LZJH

Transforms marked with a bullet in the DOI column are defined in RFC 2407, the IPsec DOI. The other transforms were added after the publication of the DOI. Most of the transforms in Figure 13.10 are self-explanatory. Full explanations of each transform and a pointer to the relevant RFC are in RFC 2407. For those transforms not in the DOI RFC, the IETF Assigned Numbers Web site has an IPsec page listing all the values at <http://www.iana.org/assignments/isakmp-registry>.

The SA attributes field contains additional information about the transform. The attributes are encoded as in Figure 13.5. The phase 1 and phase 2 attribute types differ. The phase 1 types are shown in Figure 13.11; the phase 2 types, in Figure 13.12.

Figure 13.11. Phase 1 Attributes

Value	Attribute	Type
1	Encryption Algorithm	B
2	Hash Algorithm	B
3	Authentication Method	B
4	Group Description	B
5	Group Type	B
6	Group Prime/Irreducible Polynomial	V
7	Group Generator One	V
8	Group Generator Two	V
9	Group Curve A	V
10	Group Curve B	V
11	Life Type	B
12	Life Duration	V
13	PRF	B
14	Key Length	B
15	Field Size	B
16	Group Order	V

Figure 13.12. Phase 2 IPsec Attributes

Value	Attribute	Type
1	SA Life Type	B
2	SA Life Duration	V
3	Group Description	B
4	Encapsulation Mode	B
5	Authentication Algorithm	B
6	Key Length	B
7	Key Rounds	B
8	Compress Dictionary Size	B
9	Compress Private Algorithm	V
10	ECN Tunnel	B
11	Extended Sequence Number	B

A full explanation of these attributes and their legal values are discussed in RFC 2409 (phase 1) and RFC 2407 (phase 2). The phase 2 ECN Tunnel and Extended Sequence Number attributes are new since RFC 2407 and are discussed on the IPsec Assigned Numbers Web page.

We mentioned above that Proposal payloads can be logically combined by using the proposal numbers. Adjacent proposals with the same proposal number are ANDed together to form a single compound proposal. In IPsec, this is useful for combining AH and ESP in a single proposal. In this case, there would be two Proposal payloadsone for AH and one for ESPbut they would have the same proposal number, indicating that an AH AND ESP is being proposed.

Another common example is for the user to provide a list of alternatives from which the responder makes a single choice. For example, the initiator might propose ESP with a choice of 3DES, Blowfish, or AES for encryption. Each of these transforms will have a different transform number, indicating that the proposal is ESP with 3DES OR Blowfish OR AES.

An example will help make this mechanism clearer. Suppose that we wish to propose ESP with either AES_CBC or 3DES for encryption and AH with MD5. The ISAKMP message would have the structure shown in Figure 13.13. The arrows show the payloads to which each of the next payload fields refers.

The Key Exchange Payload

The Key Exchange payload carries keying material used to generate a session key. This payload has the simple format shown in Figure 13.14.

Figure 13.14. The Key-Exchange Payload

[View full size image]

The next payload field contains the next payload type, as usual. The length field is the length of the entire Key Exchange payload, including the generic header.

The key-exchange data field contains the keying material used to generate a session key. This field's format is specified by the associated key-exchange algorithm.

The Identification Payload

One of the important goals of an ISAKMP negotiation is for the peers to identify themselves to each other and to authenticate that identification. As we'll see shortly, there are three methods of authenticating the identifications, but they all depend on the initial identification. That identification is carried in the Identification payload, shown in Figure 13.15. The figure shows the IPsec payload format as specified in the DOI (RFC 2407).

Figure 13.15. The IPsec Identification Payload

[View full size image]

The next payload and payload length fields are just as they were for the Key Exchange payload. As usual, the payload length includes the size of the header.

The ID type field indicates the type of data in the identification data field. Figure 13.16 lists the legal values for the ID type field.

Figure 13.16. ID Types

Value	ID Type
0	RESERVED
1	ID_IPV4_ADDR
2	ID_FQDN
3	ID_USER_FQDN
4	ID_IPV4_ADDR_SUBNET
5	ID_IPV6_ADDR
6	ID_IPV6_ADDR_SUBNET
7	ID_IPV4_ADDR_RANGE
8	ID_IPV6_ADDR_RANGE
9	ID_DER_ANSI_DN
10	ID_DER_ANSI_GN
11	ID_KEY_ID
12	ID_LIST

These types are mostly self-explanatory, but their meaning and formats are discussed fully in the IPsec DOI document.

The protocol ID field specifies an IP protocol type, such as UDP or TCP. A value of 0 means that the field should be ignored. The port field is the port associated with the protocol indicated in the protocol ID field. During phase 1 negotiations, these fields must either be 0 or have the values UPD/500.

Certificate Payloads

One of the methods of authenticating the identification of a peer is the exchange of certificates. Two types of payloads that address this: the Certificate Request payload (Figure 13.17) and the Certificate payload (Figure 13.18).

Figure 13.17. The Certificate Request Payload

[View full size image]

Figure 13.18. The Certificate Payload

[View full size image]

The next payload and payload length fields have the same meaning that we've seen in the last few payloads. As always, the length includes the header.

In the Certificate Request payload, the certificate authority field contains an encoding of a certificate authority acceptable to the requester. In the Certificate payload, the certificate data field contains an encoding of the certificate data. Both the cert. encoding and cert. type fields describe the type of certificate that is being requested or sent. Figure 13.19 shows the legal values for the certificate types.

Figure 13.19. Certificate Types

Value	Certificate Type
0	NONE
1	PKCS #7 wrapped X.509 certificate
2	PGP certificate
3	DNS signed key
4	X.509 certificate (signature)
5	X.509 certificate (key exchange)
6	Kerberos tokens
7	Certificate revocation list
8	Authority revocation list
9	SPKI certificate
10	X.509 certificate (attribute)

The Hash Payload

As we'll see shortly, ISAKMP and IKE exchange various hashes as a means of authenticating their messages. These hashes are carried in the Hash payload, shown in Figure 13.20.

Figure 13.20. The Hash Payload

[View full size image]

The fields in the generic header have the same meanings as they did for the payloads we've examined previously. The hash data field contains the results of the hash calculation. For example, if HMAC SHA-1 is used, this field will contain the 20 bytes of output from the SHA-1 calculation.

The Signature Payload

One of the ISAKMP identity authentication methods is for the peers to sign a hash of certain state known to both sides. The state is hashed and then encrypted, using the sending peer's private key. The receiving peer uses its peer's public key to decrypt the hash and verify it by calculating the same hash on its copy of the state. This is the usual digital signature procedure discussed in Chapter 3. Note that when a node verifies its peer's signature, it can be sure of the peer's identity because the peer will have the private key only if it is who it says it is.

The signature data is carried in a Signature payload, shown in Figure 13.21.

Figure 13.21. The Signature Payload

[View full size image]

The fields in the generic header have the same meaning that they do in the other payloads. The signature data field contains the signature itself.

The Nonce Payload

As noted earlier, a nonce is a (usually) random number meant to be used once and then discarded. ISAKMP and IKE make several uses of nonces and therefore need a way of exchanging them. Nonces are exchanged using the Nonce payload, shown in Figure 13.22.

Figure 13.22. The Nonce Payload

[View full size image]

The Nonce payload is virtually identical to several of the other payloads, such as the Key Exchange, Identification, Signature, and Hash payloads. The nonce is carried in the nonce data field.

The Notification Payload

The Notification payload plays a role within ISAKMP similar to that of ICMP within TCP/IP; it is used to carry information and error messages. Figure 13.23 shows the format of the Notification payload.

Figure 13.23. The Notification Payload

[View full size image]

The fields in the generic header have their usual meanings. The domain of interpretation field indicates which domain this notification is occurring under. For IPsec, this will be 1. The protocol ID field specifies the protocol identifier for this notification. For IPsec, these protocols are ISAKMP, ESP, and AH (Figure 13.8).

The SPI size field specifies the size of the following SPI field. For ISAKMP, the SA is identified by the initiator and responder cookies, so the SPI field is not used. In this case, the SPI size field may be any value from 0 to 16, but even if the size is nonzero, the SPI is ignored. For phase 2 IKE messages, the SPI size will be 4.

The notification message type field indicates the type of notification. Figure 13.24 shows the legal values for this field. The high numbers for the status messages are because of the partitioning of the message namespace. ISAKMP error messages are in the range 18,191, IPsec error messages in the range 8,19216,383, ISAKMP status messages in the range 16,38424,575, and IPsec status messages in the range 24,57632,767.

Figure 13.24. Notification Message Types

Value	Notification Type	Error/Status
1	INVALID-PAYLOAD-TYPE	E
2	DOI-NOT-SUPPORTED	E
3	SITUATION-NOT-SUPPORTED	E
4	INVALID-COOKIE	E
5	INVALID-MAJOR-VERSION	E
6	INVALID-MINOR-VERSION	E
7	INVALID-EXCHANGE-TYPE	E
8	INVALID-FLAGS	E
9	INVALID-MESSAGE-ID	E
10	INVALID-PROTOCOL-ID	E
11	INVALID-SPI	E
12	INVALID-TRANSFORM-ID	E
13	ATTRIBUTE-NOT-SUPPORTED	E
14	NO-PROPOSAL-CHOSEN	E
15	BAD-PROPOSAL-SYNTAX	E
16	PAYLOAD-MALFORMED	E
17	INVALID-KEY-INFORMATION	E
18	INVALID-ID-INFORMATION	E
19	INVALID-CERT-ENCODING	E
20	INVALID CERTIFICATE	E
21	CERT-TYPE-UNSUPPORTED	E
22	INVALID-CERT-AUTHORITY	E
23	INVALID-HASH-INFORMATION	E
24	AUTHENTICATION-FAILED	E
25	INVALID-SIGNATURE	E
26	ADDRESS-NOTIFICATION	E
27	NOTIFY-SA-LIFETIME	E
28	CERTIFICATE-UNAVAILABLE	E
29	UNSUPPORTED-EXCHANGE-TYPE	E
30	UNEQUAL-PAYLOAD-LENGTHS	E
16,384	CONNECTED	S
24,576	RESPONDER-LIFETIME	S
24,577	REPLAY-STATUS	S
24,578	INITIAL-CONTACT	S

The notification data field contains additional information about the error or status in the notify message type field. The IPsec DOI does not define any values for this field.

The Delete Payload

An IPsec endpoint can inform its peer that it is removing one or more SAs from its SAD by sending it a Delete payload. This message is informational only and does not request that the receiver remove the SA from its SAD. Of course, any further traffic on that SA will fail. Figure 13.25 shows the format of the Delete payload.

Figure 13.25. The Delete Payload

[View full size image]

The next payload and payload length fields have their usual meanings, as does the domain of interpretation field. The protocol ID field is the protocol that the SA or SAs are protecting. For ISAKMP SAs, the SPI size field will be 16the size of the two cookies; for IPsec SAs, it will be 4.

The number of SPIs field indicates how many SAs were deleted. Although several SAs can be specified in a single Delete payload, they must all be of the same protocol type because there is only one protocol ID field. The SPIs themselves are in the SPIs field. For ISAKMP SAs, this will be the 16 bytes of the initiator and responder cookies; for IPsec SAs, it will be the 4-byte integers identifying the SAs.

The Vendor ID Payload

The final payload is the Vendor ID payload, shown in Figure 13.26. Peers can, but need not, send this payload in order to determine that their peer is running the same ISAKMP implementation and that they can therefore exchange vendor-defined private-use payload types (Figure 13.2).

Figure 13.26. The Vendor ID Payload

[View full size image]

The next payload and payload length fields have their usual meanings. The vendor ID field is a hash of a vendor-chosen identification string. The choice of the string and hash function is left to the vendor. The vendor IDs are not registered with the IETF, so although RFC 2408 mandates that they must be unique, there does not appear to be a way of guaranteeing this.

ISAKMP Message Processing

By default, the ISAKMP messages are carried in UDP datagrams, using port 500 as the source and destination ports. Using UDP saves the connection setup and teardown of TCP but does not provide reliable delivery, so ISAKMP implements its own reliability layer.

Because message exchange in ISAKMP is very structuredas compared to TCP, say, where any data can be sent over a connectionthe reliability layer is quite simple. The messages are sent in lockstep: The initiator sends message X and waits for the responder to reply. When the responder does reply, the initiator sends the next message in the exchange type (Figure 13.3) currently under way. Because of this lockstep advancement of the state between the peers, no sequence numbers are necessary to ensure that packets aren't processed out of order. If the packet received does not have the correct payloads, it is rejected.

Thus, the reliability layer need be concerned only with ensuring that messages do not get lost. It does this in the usual way by implementing a retransmission timer. If the initiator does not receive the expected response to a message before the timer expires, the message is retransmitted unless the retry count is exceeded. RFC 2408 specifies that the retransmission timer must be adaptive. That is, it must adjust to changing conditions by using, for example, an exponential backoff like that of TCP.

ISAKMP defines five exchange types. Three of theseBase, Identity Protection, and Aggressiveare used for negotiating phase 1 SAs. The other twoAuthentication Only and Informationalcan be used in either phase 1 or 2. We won't discuss these exchanges heresee RFC 2408 for a complete descriptionbut IKE, as we'll see in the next section, makes use of the Identity Protection, Aggressive, and Informational exchanges.