![](bg3.png)
2.1 When the Initiator is Sending
iSCSI Date to the Target
• In the 'sending side' code of the IPsec layer on
the initiator, identify and isolate the user data in
the network traffic going to the target .
• Encrypt the rest of the traffic (i.e. All traffic
other than the user data) using the standard IPsec
mechanism, using keys generated and managed
by the IKE.
• Use a custom key, generated independently of
the IKE mechanism, to encrypt the user data. Do
not share this key with the target. Save this key
for future use to decrypt the same user-payload
when it is returned.
• At the target, decrypt the headers using standard
IPsec procedure, but do not attempt to decrypt
the user payload. Pass it in the encrypted form to
the upper layers so that the SCSI layer can write
it as is (in the encrypted form) to disk.
2.2 When the Initiator is Trying to
Read the iSCSI Data from the
Target
• On the target, encrypt the headers using standard
IPsec mechanism. Do not attempt to encrypt the
user payload.
• On the initiator, decrypt the headers using the
keys generated and managed by IKE. Use the
second, custom key originally used to encrypt the
user data, to decrypt the data.
• In order to come up with an implementation of
this scheme, the pattern of the flow of packets
between the initiator and the target, WITHOUT
IPsec was studied to understand the exact
sequence of packets – both when writing to the
target and when reading from the target. The
study threw a surprise. When the initiator is
writing, the user payload is carried as a part of
Data-out PDUs. When the initiator is reading, the
user-payload is carried in a plain-vanilla TCP
packet. A packet with a Data-in PDU precedes
this packet. Even more surprisingly, the
DataSegmentLength field of the Data-In PDU
reflects the length of the user payload, even
though the payload is actually carried by a
separate packet. The author could not find an
answer for this behavior nor a way to change it
so that a Data-in PDU contains the user payload.
Hence the solution implemented was designed
accordingly.
The proposed scheme entails changes to the
IPsec-specific code in the Linux 2.6 network stack.
To understand how the actual code-modification
scheme was arrived at, it helps to recap how data
would be handled by the IPsec code in its native
form.
2.3 The Native IPsec operation on
iSCSI
The IPsec scheme used in the current thesis is called
'transport' mode. This means an ESP header is
inserted between the IP header and the TCP header.
The 'protocol' field in the IP header is changed by
the IPsec layer to '50' to indicate the presence of an
ESP header following the IP header. Prior to the
'encryption' part of the IPsec code, this 'protocol'
field of the ip header was populated with ‘6’, which
is 'TCP'. This information is saved in the IPsec layer,
before the 'protocol' field is overwritten with '50'.
The saved value will be entered later in the last byte
of the padding that is going to be added at the end of
the payload. The iSCSI header together with the user
data forms the payload for the TCP layer. The TCP
header plus the iSCSI payload, in turn forms the
payload for the IPsec protocol. This IPsec payload is
padded so that the total length (tcp header + IPsec
payload + padding) is an exact multiple of the block
size of the encryption algorithm being used. Care is
taken to make sure that the padding is at least 2
bytes long. The last byte of the padding, is set to the
protocol ID saved earlier. The last-but-one byte is
set to the total number of padding bytes (Hence the
need to make sure the padding is at least 2 bytes
long). The TCP header, iSCSI header, iSCSI
payload and the ESP trailer are together encrypted as
one unit. The padding forms the ESP trailer. An ESP
authentication trailer is inserted after the ESP-trailer.
This trailer contains the cryptographic checksum of
Ipheader + esp header + tcp header + iSCSI
header + iSCSI data + esp trailer.
The authentication trailer is NOT encrypted.
On the receiving end, the cryptographic
checksum is recomputed on the same components as
mentioned earlier. This is compared to the value
stored in the ESP authentication trailer. The packet
is rejected if they do not match. If they are found to
be matching, the code proceeds to decrypt the tcp
header + iscsi header + iscsi data + esp trailer. After
decryption, the esp header placed between the IP
header and the tcp header is removed. The '50' in the
'protocol' field of the IP header is replaced by the
value in the last byte of the padding. The last-but-
one byte of the total payload (which is the length of
the padding) gives the number of padding bytes to
be stripped.
SECRYPT 2010 - International Conference on Security and Cryptography
316