Brocade Fabric OS Encryption Administrator's Guide v6.3.0 (53-1001341-02, July 2009)

Encryption Administrator’s Guide 125
53-1001341-02
Data re-keying
3
Impact of tape pool configuration changes
Tape pool-level policies overrule policy configurations at the LUN level, when no policies are
configured at the tape pool level. The following restrictions apply when modifying tape pool-level
configuration parameters:
• If you change the tape pool policy from encrypt to cleartext or from cleartext to encrypt or if you
change the encryption format from Brocade native to DF-compatible while data is written to or
read from a tape backup device, the policy change is not enforced until the current process
completes and the tape is unmounted, rewound, or overwritten. This mechanism prevents the
mixing of cleartext data to cipher-text data on the tape.
• You cannot modify the tape pool label or the key lifespan value. If you wish to modify these
tape pool attributes, delete the tape pool and create a new tape pool with a different label and
key lifespan.
Key lifespan values only apply to native-mode pools. When in DF-compatible
mode, every new media receives a unique key, matching DataFort behavior.
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.
The system checks once every hour to determine, if there are any re-key or first time encryption
sessions pending. If resources are available, the next session in the queue is processed. There
may be up to an hour lag before the next session in the queue is processed. It is therefore
recommended that you do not schedule more than 12 re-key or first time encryption sessions.