UNIT I NETWORK LAYER SECURITY &TRANSPORT LAYER

SECURITY
IPSec Protocol - IP Authentication Header - IP ESP - Key Management Protocol for IPSec. Transport
layer Security: SSL protocol, Cryptographic Computations – TLS Protocol.

Various algorithms used in the process of security in Network Layer

Encryption
ESP is designed for use with symmetric algorithms like a triple DES in CBC mode. For
encryption to be applied, the sender encapsulates the ESP payload field, adds any necessary
padding, and encrypts the result (i.e. payload data, padding, pad length and next header). The
sender encrypts the fields (payload data, padding, pad length and next header) using the key,
encryption algorithm, algorithm mode indicated by the SA and an IV (cryptographic synchronisation
data). If the algorithm to be encrypted requires an IV, then this data is carried explicitly in the

payload field. The payload data field is an integral number of bytes in length. Since ESP provides
padding for the plaintext, encryption algorithms employed by ESP exhibit either block or stream
mode characteristics.The 3DES–CBC mode requires an IV that is the same size as the block size. The
IV is XORed with the first plaintext block before it is encrypted. For successive blocks, the previous
ciphertext block is XORed with the current plaintext before it is encrypted. Triple DES, known as
DES–EDE3, processes each block three times, each time with a different key. Therefore, the triple
DES algorithm has 48 rounds. In DES–EDE3-CBC, an IV is XORed with the first 64-bit plaintext
block (P1). Some cipher algorithms allow for a variable-sized key (RC5), while others only allow a
specific key size (DES, IDEA).

Decryption
The receiver decrypts the ESP payload data, padding, pad length and next header using the
key, encryption algorithm, algorithm mode and IV data. If explicit IV data is indicated, it is taken from
the payload field and input to the decryption algorithm. If implicit IV data is indicated, a local version
of the IV is constructed and input to the decryption algorithm.
The exact steps for reconstructing the original datagram depend on the mode (transport or
tunnel) and are described in the Security Architecture document. The receiver processes any
padding as given in the encryption algorithm specification. For transport mode, the receiver
reconstructs the original IP datagram from the original IP header plus the original upper-layer
protocol information in the ESP payload field. For tunnel mode, the receiver reconstructs the tunnel
IP header plus the entire IP datagram in the ESP payload field.
Authentication
The authentication algorithm employed for the ICV computation is specified by the SA. For
communication between two points, suitable authentication algorithms include Keyed Message
Authentication Codes (MACs) based on symmetric encryption algorithms (i.e. DES) or on one-way
hash function (i.e. MD5 or SHA-1). For multicast communication, one-way hash algorithms combined
with asymmetric signature algorithms are appropriate.
Integrity Check Vector
Once the SA selects the authentication algorithm, the sender computes the ICV over the ESP
packet minus the authentication data. The ICV is an MAC or a truncated value of a code produced by
an MAC algorithm. As with AH, ESP supports the use of an MAC with a default length of 96 bits. The
current specification for use of the HMAC computation must support:
HMAC–MD5–96
HMAC–SHA-1–96

Discuss in detail about OAKLEY Key Determination Protocol.

The Diffie–Hellman key exchange algorithm provides a mechanism that allows two users to
agree on a shared secret key without requiring encryption. This shared key is immediately available
for use in encrypting subsequent data transmission. Oakley is not only a refinement of the Diffie–
Hellman key exchange algorithm, but a method to establish an authentication key exchange. The
Oakley protocol is truly used to establish a shared key with an assigned identifier and associated
authenticated identities for the two parties. Oakley can be used directly over the IP protocol or over
UDP protocol using a well-known port number assignment available.

It is worth to note that Oakley uses the cookies for two purposes: anti-clogging (denial of
service) and key naming. The anti-clogging tokens provide a form of source address identification for
both parties. The construction of the cookies prevents an attacker from obtain a cookie using a real
IP address and UDP port.

Creating the cookie is to produce the result of a one-way function applied to a secret value,
the IP source and destination addresses, and the UDP source and destination ports. Protection
against the anti-clogging always seems to be one of the most difficult to address. A cookie or anti-
clogging token is aimed for protecting the computing resources from attack without spending
excessive CPU resources to determine its authenticity. Absolute protection against anti-clogging is
impossible, but this anti-clogging token provides a technique for making it easier to handle.

Oakley employs nonces to ensure against replay attacks. Each nonce is a pseudorandom
number which is generated by the transmitting entity. The nonce payload contains this random data
used to guarantee liveness during a key exchange and protect against replay attacks. If nonces are
used by a particular key exchange, the use of the nonce payload will be dictated by the key
exchange. The nonces may be transmitted a part of the key exchange data.

All the Oakley message fields correspond to ISAKMP message payloads. The relevant payload
fields are the SA payload, the authentication payload, the certification payload, and the exchange
payload. Oakley is the actual instantiation of ISAKMP framework for IPsec key and SA generation.
The exact mapping of Oakley message fields to ISAKMP payloads is in progress at this time.
Draw the header format for ISAKMP protocol and explain the various fields present in it.

ISAKMP defines a framework for SA management and cryptographic key establishment for
the Internet. This framework consists of defined exchange, payloads and processing guidelines that
occur within a given DOI. ISAKMP defines procedures and packet formats to establish, negotiate,
modify and delete SAs. It also defines payloads for exchanging key generation and authentication
data. ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the
network stack. By centralising the management of the SAs, ISAKMP reduces the amount of
duplicated functionality within each security protocol.

ISAKMP Payloads
ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The
presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type
Field located in the ISAKMP header.
ISAKMP Header
The various fields present are:
Initiator Cookie (64 bits)
This field is the cookie of entity that initiated SA establishment, SA notification, or SA
deletion.
Responder Cookie (64 bits)
This field is the cookie of entity that is corresponded to an SA establishment request, SA
notification, or SA deletion.
Next Payload (8 bits)
This field indicates the type of the first payload in the message.
Major Version (4 bits)
This field indicates the Major version of the ISAKMP protocol in use. Set the Major version to
1 according to ISAKMP Internet-Draft.
Minor Version (4 bits)
This field indicates the Minor version of ISAKMP protocol in use. Set the Minor version to 0
according to implementations based on the ISAKMP Internet-Draft.
Exchange Type (8 bits)
This field indicates the type of exchange being used. This dictates the message and payload
orderings in the ISAKMP exchanges.
Flags (8 bits)
This field indicates specific options that are set for the ISAKMP exchange. The Flags are
specified in the Flags field beginning with the least significant bit: the encryption bit is bit 0 of the
Flags field, the commit bit is bit 1, and authentication only bit is bit 2 of the Flags field. The
remaining bits of the Flags field must be set to 0 prior to transmission.
Message ID (32 bits)
Message ID is used to identify protocol state during Phase 2 negotiations. This value is
randomly generated by the initiator of the phase 2 negotiation. During Phase 1 negotiation, this
value must be set to 0.
Length (32 bits)
Length of total message (header || payload) is 32 bits. Encryption can expand the size of an
ISAKMP message.
List and explain the various payloads present in ISAKMP Protocol and the steps in processing each
payloads.

General Message Processing

Every ISAKMP message has basic processing applied to insure protocol reliability and to
minimize threats such as denial of services and replay attacks. All processing should include packet
length checks to insure the packet received is at least as long as the length given in the ISAKMP
Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP
Header are not the same, then ISAKMP message must be rejected.

ISAKMP Header Processing

When an ISAKMP message is created at the transmitting entity, the initiator (transmitter)
must create the respective cookie, determine the relevant security characteristics of the session,
construct an ISAKMP Header with fields, and transmit the message to the destination host
(responder).
When an ISAKMP is received at the receiving entity, the responder (receiver) must verify the
Initiator and Responder cookies, check the Next Payload field to confirm it is valid, check the Major
and Minor Version fields to confirm they are correct, check the Exchange Type field to confirm it is
valid, check the Flags field to ensure it contains correct values, and check the Message ID field to
ensure it contains correct values.

Generic Payload Header

Each ISAKMP payload begins with a generic header which provides a payload chaining
capability and clearly defines the boundaries of a payload.
The generic payload header fields in 32 bits are defined as follows:
Next Payload (8 bits)
This field is identifier for the payload type of the next payload in the message. If the current
payload is the last in the message, then this field will be 0. This field provides the chaining capability.
Reserved (8 bits)
This field is not used and set to 0.
Payload Length (16 bits)
This field indicates the length in bytes of the current payload, including the generic payload
header.
Generic Payload Header Processing:
When any of the ISAKMP Payloads are created, a Generic Payload Header is placed at the
beginning of these payloads. When creating the Generic Payload Header, the transmitting entity
(initiator) must place the value of the Next Payload in the Next Payload field, place the value zero (0)
in the Reserved field, place the length (in octets) of the payload in the Payload Length field, and
construct the payloads.
When any of the ISAKMP Payloads are received, the receiving entity (responder) must check
the Next Payload field to confirm it is valid, verify the Reserved field contains the value zero (0), and
process the remaining payloads as defined by the Next Payload field.

Security Association Payload

The Security Association Payload is used to negotiate security attirutes and to identify the
Domain of Interpretation (DOI, 32 bits) under which negotiation is taking place. A DOI value of 0
during a Phase 1 exchange specifies a Generic ISAKMP which can be used for any protocol during the
Phase 2 exchange. A DOI value of 1 is assigned to the IPsec DOI.
The Security Association Payloads are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. This field has a value of 0 if this is the last payload in the message.
 The Reserved field (8 bits) is unused, set to 0.
The Payload Length field (16 bits) indicates the length in octets of the entire Security
Association payload, including the SA payload, all Proposal payloads, and all Transform payloads
associated with the proposed SA.
The Situation field (variable length) is a DOI-specific field that identifies the situation under
which negotiation is taking a place. The Situation field defines policy decisions regarding the security
attributes being negotiated.
Security Association Payload Processing:
When a Security Association Payload is created, the transmitting entity (initiator) must
determine the Domain of Interpretation (DOI) for which this negotiation is being preformed. When a
Security Association payload is received, the receiving entity (responder) must determine if the DOI
is supported, determine if the given situation can be protected, and process the remaining payloads
(Proposal, Transform) of the SA payload. If the SA Proposal is not accepted, then the Invalid Proposal
event may be logged in the appropriate system audit file. An Information Exchange with a
Notification payload containing the No-Proposal-Chosen message type may be sent to the
transmitting entity (initiator). This action is dictated by a system security policy.

Proposal Payload
The Proposal Payload is used to build ISAKMP message for the negotiation and
establishment of SAs. The Proposal Payload field contains information used during SA negotiation for
securing the communications channel. The payload type for the Proposal Payload is two (2).
The Proposal Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. This field must only contain the value 2 or 0. This field will be 2 for additional Proposal
Payloads in the message and 0 when the current Proposal Payload is the last within the SA proposal.
The Reserved field (8 bits) is set to 0 and is reserved it for the future use.
The Payload Length field (16 bits) is the length in octets of the entire Proposal payload,
including generic payload header, the Proposal Payload, and all Transform payloads associated with
this proposal.
The Proposal # field (8 bits) identifies the proposal number for the current payload.
The Protocol-id field (8 bits) specifies the protocol identifier for the current negotiation.
The SPI Size (8 bits) denotes the length in octets of the SPI. In the case of ISAKMP, the
Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI. The
SPI size may be from zero(0) to sixteen (16). If the SPI size is non-zero, the content of the SPI
field must be ignored. The DOI will dictate the SPI Size for other protocols.
# of Transform (8 bits) specifies the number of transforms for the proposal.
SPI field (variable) is the sending entity‘s SPI. In the event of the SPI size is not a multiple of 4
octets, there is no padding applied to the payload.

Proposal Payload Processing:

When a Proposal Payload is created, the transmitting entity (initiator) must determine the
Protocol for this proposal, determine the number of proposals to be offered for this proposal and
the number of transform for each proposal, generate a unique pseudo-random SPI, and construct a
Proposal payload.
When a Proposal payload is received, the receiving entity (responder) must determine if the
proposal is supported and if the Protocol-ID field is invalid, determine whether the SPI is valid or not,
ensure whether or not proposals are formed correctly, and then process the Proposal and Transform
payloads as defined by the Next Payload field.
Transform Payload
The Transform Payload contains information used during Security Association negotiation.
The Transform Payload consists of a specific security mechanism to be used to secure the
communications channel. The Transform Payload also contains the security association attributes
associated with the specific transform.
The Transform Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. This field must only contain the value 3 or 0. This field is 3 when there are additional
Transform payloads in the proposal. This field is 0 when the current Transform Payload is the last
within the proposal.
The Reserved field (8 bits) is for unused, set to 0.
The Transform # field (8 bits) identifies the Transform number for the current payload. If there is
more than one transform within the Proposal Payload, then each Transform Payload has a unique
Transform number.
The Transform-id field (8 bits) specifies the Transform identifier for the protocol within the current
proposal.
The Reserved 2 field (16 bits) is for unused, set to 0. The payload type for the Transform Payload is
three (3).

Transform Payload Processing:

When creating a Transform Payload, the transmitting entity (initiator) must determine the
Transform # for this transform, determine the number of transforms to be offered for this proposal,
and construct a Transform payload.
When a Transform payload is received, the receiving entity (responder) must do as follows:
Determine if the Transform is supported. If the Transform-ID field contains an unknown or
unsupported value, then that Transform payload must be ignored. Finally, process the subsequent
Transform and Proposal payloads as defined by the Next Payload field.

Key Exchange Payload

The Key Exchange Payload supports a variety of key exchange techniques. Example key
exchanges are Oakley, Diffie-Hellman, the enhanced D-H key exchange, and the RSA-based key
exchange used by PGP.
The Key Exchange Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is unused for the future use, set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Key Exchange Data field (variable length) is the data required to generate a session key.

Key Exchange Payload Processing:

When creating a Key Exchange payload, the transmitting entity (initiator) must determine
the Key Exchange to be used as defined by the DOI, determine the usage of Key Exchange Data field
as defined by the DOI, and construct a Key Exchange payload. When a Key Exchange payload is
received, the receiving entity (responder) must determine if the Key Exchange is supported.
If the Key Exchange determination fails, the message is discarded and the following actions
are taken:
The event of Invalid Key Information may be logged in the appropriate system audit file. An
Informational Exchange with a Notification payload containing the Invalid-Key- Information message
type may be sent to the transmitting entity. This action is dictated by a system security policy.
Identification Payload
The Identification Payload contains DOI-specific data used to exchange identification
information. This information is used for determining the identities of communication partners and
may be used for determining authenticity of information.
The Identification Payload fields are described as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the Next Payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is not used, but set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The ID type field (8 bits) specifies the type of identification being used. This field is DOI-dependent.
The DOI specific ID Data field (24 bits) contains DOI specific identification data. If unused, then this
field must be set to 0.
The Identification Data field (variable length) contains identity information.
The payload type for the Identification Payload is five (5).

Identification Payload Processing:

When an Identification Payload is created, the transmitting entity (initiator) must determine
the Identification information to be used as defined by the DOI, determine the usage of the
Identification Data field as defined by the DOI, construct an Identification payload, and finally
transmit the message to the receiving entity.
When an Identification payload is received, the receiving entity (responder) must determine
if the Identification Type is supported. This may be based on the DOI and Situation. If the
Identification determination fails, the message is discarded. An Informational Exchange with a
Notification payload containing the Invalid-ID-Information message type is sent to the transmitting
entity (initiator).

Certificate Payload
The Certificate Payload provides a mean to transport certificates via ISAKMP and can appear in any
ISAKMP message. Certificate payloads should be included in an exchange whenever an appropriate
directory service is not available to distribute certificates.
The Certificate Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the Payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is unused, set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Certificate Encoding field (8 bits) indicates the type of certificate or certificate-related
information contained in the Certificate Data field.
The Certificate Data field (variable length) denotes actual encoding of certificate data.
The type of certificate is indicated by the Certificate Encoding field.
The Payload type for the Certificate payload is six (6).

Certificate Payload Processing:

When a Certificate Payload is created, the transmitting entity (initiator) must determine the
Certificate Encoding which is specified by the DOI, ensure the existence of a certificate formatted as
defined by the Certificate Encoding, construct a Certificate payload, and then transmit the message
to the receiving entity (responder).
When a Certificate payload is received, the receiving entity (responder) must determine if
the Certificate Encoding is supported. If the Certificate Encoding is not supported, the payload is
discarded. The responder then processes the Certificate Data field. If the Certificate Data is
improperly formatted, the payload is discarded.

Certificate Request Payload

The Certificate Request Payload provides a mean to request certificate via ISAKMP and can
appear in any message. Certificate Request Payloads should be included in an exchange whenever
an appropriate directory service is not available to distribute certificates.
The Certificate Request Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is not used, set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Certificate Type field (8 bits) contains an encoding of the type of certificate requested.
Acceptable values are listed in the Certificate Payload fields.
The Certificate Authority field (variable length) contains an encoding of an acceptable certificate
authority for the type of certificate requested.
The payload type for the Certificate Request Payload is seven (7).
Certificate Request Payload Processing:
When creating a Certificate Request Payload, the transmitting entity (initiator) must
determine the type of Certificate Encoding to be requested, determine the name of an acceptable
Certificate Authority, construct a Certificate Request payload, and then transmit the message to the
receiving entity (responder).
When a Certificate Request payload is received, the receiving entity (responder) must
determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, the payload
is discarded. If the Certificate Authority is improperly formatted, the payload is discarded. Finally,
the responder must process the Certificate Request. If a requested Certificate Type with the
specified Certificate Authority is not available, then the payload is discarded.

Hash Payload
The Hash Payload contains data generated by the hash function over some part of the
message and/or ISAKMP state. This payload possibly be used to verify the integrity of the data in an
ISAKMP message or for authentication of the negotiating entities.
The Hash Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is not used, set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Hash Data field (variable length) is the data that results from applying the hash routine to the
ISAKMP message and/or state.
The payload type for the Hash Payload is eight (8).
Hash Payload Processing:
When creating a Hash Payload, the transmitting entity (initiator) must determine the Hash
function to be used as defined by the SA negotiation, determine the usage of the Hash Data field as
defined by the DOI, construct a Hash payload, and then transmit the message to the receiving entity
(responder).
When a Hash Payload is received, the receiving entity (responder) must determine if the
Hash is supported. If the Hash determination fails, the message is discarded. The responder also
performs the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the
Hash function fails,the message is discarded.
Signature Payload
The Signature Payload contains data generated by the digital signature function, over some
part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in
the ISAKMP message, and may be of use for non-repudiation services.
The Signature Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is not used, but set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Signature Data field (variable length) is the data that results from applying the digital signature
function to the ISAKMP message and/or state.
The payload type for the Signature Payload is nine (9).
Signature Payload Processing:
When a Signature Payload is created, the transmitting entity(initiator) must determine the
Signature function to be used as defined by the SA negotiation, determine the usage of the
Signature Data filed as defined by the DOI, construct a Signature payload, and finally transmit the
message to the receiving entity (responder).
When a Signature payload is received, the receiving entity must determine if the Signature is
supported. If the Signature determination fails, the message is discarded. The responder must
perform the Signature function as outlined in the DOI and/or Key Exchange protocol documents. If
the Signature function fails, the message is discarded.

Nonce Payload
The Nonce Payload contains random data used to guarantee liveness during an exchange
and protect against replay attacks. If nonce are used by a particular key exchange, the use of the
Nonce Payload will be dictated by the key exchange.
The Nonce Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is unused, but set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Nonce Data field (variable length) contains the random data generated by the transmitting
entity.
The Payload type for the Nonce Payload is ten (10).
Nonce Payload Processing:
When creating a Nonce Payload, the transmitting entity (initiator) must create an unique
random values to be used as a nonce, construct a Nonce payload, and transmit the message to the
receiving entity.
When a Nonce Payload is received, the receiving entity (responder) must do as follows:
There are no specific procedures for handling Nonce payloads. The procedures are defined
by the exchange types and possibly the DOI and Key Exchange descriptions.

Notification Payload
The Notification Payload can contain both ISAKMP and DOI-specific data and is used to
transmit information data, such as error conditions to an ISAKMP peer. It is possible to send multiple
Notification Payloads in a single ISAKMP message.
The Notification Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is unused, but set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Domain of Interpretation field (32 bits) identifies the DOI under which this notification is taking
place. For ISAKMP this value is zero (0) and for the IPsec DOI it is one (1).
The Protocol-id field (8 bits) specifies the protocol identifier for the current notification.
The SPI Size field (8 bits) is the length in octets of the SPI as defined by the protocol id.
The Notify Message Type field (16 bits) specifies the type of notification message. Additional text, if
specified by the DOI, is placed in the Notification Data field.
The Security Parameter Index (SPI) field has the variable length.
The Notification Data field (variable length) is informational or error data transmitted in addition to
the Notify Message Type. Values for this field are DOI-specific.
The payload type for the Notification Payload is eleven (11).
Notification Payload Processing:
When a Notification Payload is created, the transmitting entity (initiator) must determine
the DOI for this Notification, determine the Protocol-ID for this Notification, determine the SPI size
based on the Protocol-ID field, determine the Notify Message Type based on the error or status
message desired, determine the SPI which is associated with this notification, determine if additional
Notification Data is to be included, construct a Notification Payload, and finally transmit the
messages to the receiving entity.
When a Notification payload is received, the receiving entity (responder) must determine if
the Informational Exchange has any protection applied to it by checking the Encryption Bit and
Authentication Only Bit in the ISAKMP Header, determine if the Domain of Interpretation (DOI) is
supported, determine if the protocol-ID is supported, determine if the SPI is valid, determine if the
Notify Message Type is valid, and then process the Notification payload, including additional
Notification Data, and take appropriate action according to local security policy.

Delete Payload
The Delete Payload contains a protocol-specific security association identifier that the
sender has removed from its SA database. Therefore, the sender is no longer valid. It is possible to
send multiple SPIs in a Delete Payload. But each SPI must be for the same protocol.
The Delete Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is unused, but set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Domain of Interpretation field (32 bits) identifies the DOI under which this deletion is taking
place. For ISAKMP this value is zero(0) and for the IPsec DOI it is one (1).
The Protocol-id field (8 bits) specifies that ISAKMP can establish SAs for various protocols, including
ISAKMP and IPsec.
The SPI Size field (8 bits) is the length in octets of the SPI as defined by the Protocol-id.
The # of SPIs field (16 bits) is the number of SPIs contained in the Delete Payload. The size of each
SPI is defined by the SPI Size field.
The Security Parameter Indexes field (variable length) identifies the specific security associations to
delete.
The Payload type for the Delete Payload is twelve (12).
Delete Payload Processing:
When a Delete Payload is created, the transmitting entity (initiator) must determine the DOI
for this Deletion, determine the Protocol-ID for this Deletion, determine the SPI size based on the
Protocol-id field, determine the # of SPIs to be deleted for this protocol, determine the SPI(s) which
is (are) associated with this deletion, construct a Delete payload, and then transmit the message to
the receiving entity.
When a Delete payload is received, the receiving entity (responder) must do as follows:
∑ Since the Information Exchange is protected by authentication for an Auth-Only SA and
encryption for other exchange, the message must have these security services applied using
the ISAKMP SA. Any errors that occur during the Security Service processing will be evident
when checking information in the Delete payload.
∑ Determine if the Domain of Interpretation (DOI) is supported.
∑ Delete if the Protocol-ID is supported.
∑ Determine if the SPI is valid for each SPI included in the Delete payload.
∑ Process the Delete payload and take appropriate action, according to local security policy.

Vendor ID Payload
The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to
identify and recognize remote instances of their implementations.
The Vendor ID Payload fields are defined as follows:
The Next Payload field (8 bits) is the identifier for the payload type of the next payload in the
message. If the current payload is the last in the message, then this field will be 0.
The Reserved field (8 bits) is unused, but set to 0.
The Payload Length field (16 bits) is the length in octets of the current payload, including the generic
payload header.
The Vendor ID field (variable length) contains the choice of hash and text to hash. Vendors could
generate their vendor-id by taking a keyless hash of a string containing the product name, and the
version of the product.
The Payload type for the Vendor ID Payload is thirteen (13).