2.2.3.2.1 Crypto Payload 0x85 Encryption Flag Set
The Crypto payload is constructed in a similar manner as ESP (see [RFC4303] section 2) minus the SPI field.
The Crypto payload type 0x85 with the encryption flag set format is structured as follows.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
seqNUM |
|||||||||||||||||||||||||||||||
|
Initialization_Vector (variable) |
|||||||||||||||||||||||||||||||
|
... |
|||||||||||||||||||||||||||||||
|
Encrypted_Payloads (variable) |
|||||||||||||||||||||||||||||||
|
... |
|||||||||||||||||||||||||||||||
|
Padding (variable) |
|||||||||||||||||||||||||||||||
|
... |
|||||||||||||||||||||||||||||||
|
Pad_Length |
Next_Payload |
Integrity_Checksum_Data (variable) |
|||||||||||||||||||||||||||||
|
... |
|||||||||||||||||||||||||||||||
seqNUM (4 bytes): The seqNUM field is a sequence number for the next expected packet number. Sequence number generation is described in section 3.1.1.
Initialization_Vector (variable): The length of the Initialization_Vector (IV) field MUST equal the block size that is used by the encryption algorithm as specified in [RFC3602] section 2.4 and [RFC2451] section 2.4. The presence and content of the Initialization_Vector depends on the encryption and authentication algorithms used, as specified in [RFC4303] section 2.2. Encryption begins immediately after the Initialization_Vector and encrypts up to the beginning of the integrity checksum data.
Encrypted_Payloads (variable): A variable-length sequence of encrypted Authenticated Internet Protocol payloads, each payload starting with the generic payload header. The entire payload sequence, including the generic payload headers, MUST be encrypted. This is identical to [RFC4303] section 2.3. The Padding, Pad_Length, and Next_Payload are also encrypted, and are therefore conceptually included in the Encrypted_Payloads.
Padding (variable): 0 to 255 bytes of padding as required by the encryption algorithm.
Pad_Length (1 byte): The length of the preceding padding. The Pad_Length field is located after the variable-length padding; hence, the payload MUST be decoded starting from the end. ESP uses an identical technique for encoding the pad length, as specified in [RFC4303] sections 2.4 and 2.5.
Next_Payload (1 byte): The payload type of the first payload in the Encrypted payload sequence that is carried by this Crypto payload.
Integrity_Checksum_Data (variable): As required by the negotiated integrity algorithm (see [RFC4303] section 2.8). The integrity checksum data covers the ISAKMP header to the beginning of the integrity checksum data. To compute the checksum successfully, the ISAKMP header length MUST be set to zero.
-
If one of the following vendor IDs is received, the integrity checksum data size of 12 bytes MUST be used for all algorithms.
-
Vendor IDs that require 12-byte integrity checksum data:
-
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 05
-
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 06
-
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 07
-
Otherwise, the size of the integrity checksum data depends on the negotiated integrity algorithm. The algorithm itself is denoted "hash" in section 3.1 and is stored in the security association database (SAD), as described in [RFC4301] section 4.4.2. For the negotiated integrity algorithms HMAC-MD5 and HMAC-SHA-1, the integrity checksum data size is 12 bytes. For all other integrity algorithms, the integrity checksum data size is specified in [RFC4868] section 2.3.