Brocade Fabric OS Encryption Administrator's Guide Supporting Fabric OS v6.2.0 (53-1001201-04, May 2009)

Encryption Administrator’s Guide 161
53-1001201-04
Data re-keying
3
Migrating an existing Tape Pool
If you have a configured tape backup application and a pre-existing tape pool before you deploy the
Brocade encryption platform, you can integrate the pre-existing tape pool into the encryption
platform with the following procedure.
1. On the encryption group leader configure the tape pool with the --create -tapepool command.
Refer to the section “Creating a tape pool” on page 158 for detailed instructions.
a. Specify a tape pool label (maximum of 64 bytes) or numeric ID depending on your tape
backup application. Refer to the sections “Tape pool labeling” on page 156 for information
on labeling tape pools. The tape pool label should match the tape pool label that was
configured for your tape backup application.
b. Set the tape pool policy to encrypt or cleartext.
c. Set the encryption format to Brocade native or DF-compatible.
2. Re-label the tape media to assign the media to the tape pool created in step 1. If you fail to
perform this step, the policies configured at the tape pool level will not take effect when writing
to the tape media.
Data re-keying
In a re-keying operation, encrypted data on a LUN is decrypted with the current key, re-encrypted
with a new key and written back to the same LUN at the same logical block address (LBA) location.
This process effectively re-encrypts the LUN and is referred to as “in-place re-keying.”
It is recommended you limit the practice of re-keying to the following situations:
• Key compromise as a result of a security breach.
• As a general security policy to be implemented as infrequently as every 6 months or once per
year.
Re-keying is only applicable to disk array LUNs or fixed block devices. There is no re-keying support
for tape media. If there is a need to re-encrypt encrypted tape contents with a new key, the process
is equivalent to restoring the data from tape backup. You decrypt the data with the old DEK and
subsequently back up the tape contents to tape storage, which will have the effect of encrypting
the data with the new DEK.
Resource Allocation
Fabric OS 6.2.0 supports a maximum of 12 outstanding sessions per encryption switch or blade
with a maximum of two concurrent sessions per OB1 FPGA. This includes both re-key (auto and
manual) and first time encryption sessions. Since the virtual targets and virtual initiators are
assigned to an OB1, there is an effective limit of two concurrent re-key/encryption sessions per
target container and of two concurrent sessions per physical initiator. If your configuration has two
containers that are accessed by the same physical initiator, you cannot have more than two
concurrent re-key or encryption sessions.
When scheduled re-key or first time encryption sessions exceed the maximum allowable limit,
these sessions will be pending and a "Temporarily out of resources" message is logged. Whenever
an active re-key of first time encryption session completes, the next pending session is scheduled.