As I mentioned in an earlier article, Data Domain OS 5.5 introduced a new feature, in-flight encryption. This applies to Data Domain Boost connections, and requires v3 of the DDBoost Libraries, which are thankfully found in NetWorker 8.2.
Currently you won’t find the controls for in-flight encryption within NetWorker – it’s something that needs to be enabled or disabled from the Data Domain itself. Thankfully, it’s relatively trivial to do:
There’s two different commands that have been used here:
# ddboost clients show config
That command lists the current configuration setting for in-flight encryption. The second command I used was to enable in-flight encryption for a host, viz.:
# ddboost clients add centaur encryption-strength high
As is the case with any Data Domain command, you can get a full list of the options for a command by typing help command – in this case, help ddboost clients. A basic dump of the options can be triggered by an incomplete command, too:
Once in-flight encryption has been enabled, all you have to do is ensure the client direct option is enabled for the client. So long as the client can reach the Data Domain directly via the Boost device names in NetWorker (and the client is running NetWorker 8.2), you’ll get encryption of data during transit.
Those who have been using NetWorker for a while will know that there are other options for triggering encrypted backups, but of course such options are incompatible with successful deduplicated storage on a Data Domain – this method still allows for distributed stream processing and effective deduplication, but keeps the data secure during transit.
As you’d expect, the in-flight encryption works for recoveries as well as backup. Using tcpdump on the Data Domain I captured a couple of recoveries, one with encryption disabled, and one with encryption enabled. The files I recovered were those you’ll typically find in /usr/share/doc on a Linux system, and the results look quite different when viewed in Wireshark.
First, the unencrypted data:
With in-flight encryption, the traffic looks considerably different:
That’s all there is to it – it’s simple and straight forward to enable (and yes, as you may have guessed from the very first screen-capture, you can indeed use wild-cards in client definitions).
Thanks Preston,
this is really beautiful and considerably useful in todays “think service” deployments.
//JR
Does this require the global encryption for Data Domain to be licensed/turned on?
No – in-flight encryption is different from encryption at rest. It only requires the DDBoost license.
Presumably then ddboost clients add * encryption-strength high will enable for all clients existing and future
This is correct, yes.
How does this work today? In NW Dboost integration guide only reference when creating devices states you should use None (actually, there is one KB article which speaks of devices no longer mounting which says the same as makes reference to guide). On top, there is authentication-mode which also needs to be set and documentation usually talks about this in respect to WAN clients only. So, I guess key question is really how would you use this today and what are supported models of implementation (along with parameters which are supported)?
A reference to ‘none’ in the integration guide might be referring to making sure any NetWorker initiated encryption (e.g., encryption via directive) is disabled.
DDBoost in-flight encryption is controlled as an interface group setting on the Data Domain. Add the client list into the interface group, enable in-flight encryption for the interface group, and it’ll run with in-flight encryption.