TLS (“Transport Layer Security”) is the modern version of SSL and is used to secure TCP sockets. TLS is specified in RFC 2246 (version 1.0), RFC 4346 (version 1.1) and RFC 5246 (version 1.2). When people talk about connections “secured with SSL”, today TLS is the technology that’s really used instead of older editions of SSL.
See “SSL” for more discussion about how SSL/TLS is used in practice.
See the Wikipedia entry for TLS if you are interested in the technical mechanics behind TLS.
BEST PRACTICE: All modern file transfer clients and file transfer servers should support TLS 1.0 today. Most clients and servers support TLS 1.1 today, but TLS 1.1 support will probably not be required unless major issues appear in TLS 1.0. Some clients and servers support TLS 1.2 today but it’s a trivial concern at this point. All file transfer software should use FIPS validated cryptography to provide TLS services across file transfer protocols such as HTTPS, FTPS, AS1, AS2, AS3 or email protocols secured with TLS.
A translation engine is software that performs the work defined in individual transformation maps.
The transformation engines that power transformation maps are typically defined as “single-pass” or “multiple-pass” engines. Single-pass engines are faster than multiple-pass engines because documents are directly translated from source formats to destination formats, but single-pass engines often require more manual setup and are harder to integrate and extend than multiple-pass engines. Multiple-pass engines use an intermediate format (usually XML) between the source and destination formats; this makes them slower than single-pass engines but often eases interoperability between systems.
BEST PRACTICE: Your decision to use a single- or multiple-pass map transformation engine should be predicated first on performance, then on interoperability. (It won’t matter how interoperable your deployment is if it can’t keep up with your traffic.) However, the ever-increasing speed of computers and more common use of parallel, coordinated systems is gradually tilting the file transfer industry in favor of multiple-pass transformation engines.
A transformation map (or just “map”) provides a standardized way to transform one document format into another through the use of pre-defined document definitions.
A single transformation map typically encompasses separate source and destination document definitions, a field-by-field “mapping” from the source document to the destination, and metadata such as the name of the map, what collection it belongs to and which people and workflows can access it.
It is common to “develop” new maps and document formats to cope with document formats unique to a specific organization, trading arrangement or industry. (The term “development” is still typically used with maps in the file transfer industry, even though most mapping interfaces are now 99%+ drag-and-drop.)
BEST PRACTICE: Most transformation engines (especially those tuned for a particular industry) now come with extensive pre-defined libraries of common document formats and maps to translate between them. Before investing in custom map development, research available off-the-shelf options thoroughly.
In file transfer, a “translation engine” is a common name for a “transformation engine” that converts documents from one document definition to another through “transformation maps“.
See “transformation engine” for more information.
A transmission window is a window of time in which certain file transfers are expected or allowed to occur.
Transmission windows typically reoccur on a regular basis, such as every day, on all weekdays, on a particular day of the week, or on the first or last day of the month or quarter.
Most transmission windows are contiguous and set on hourly boundaries (e.g., from 3:00pm to 11:00pm) but can also contain breaks (e.g., 3-6pm and 7-9pm) and start/end on minute/second boundaries (e.g., from 3:05:30pm to 7:54:29).
Files received outside of transmission windows are not immediately processed or forwarded by file transfer systems. Instead, they are typically stored or queued, and are usually processed when the transmission window opens back up. (e.g., a file received at 7:58am for an 8am-2pm transmission window would be processed today at 8:00am, however a file received at 2:02pm would be processed tomorrow at 8:00am.)
When transmission windows are coupled with specific types of file transfers, service level agreements (SLAs) can be written to lock down expectations and reduce variability.
See also: cut-off time.
BEST PRACTICE: When possible, select file transfer scheduling technology that allows you to maintain transmission windows separate from your defined workflows. For example, if you want to change the transmission window for a particular type of file across 50 customer workflows, make sure you can do so by only changing one window definition, not 50 workflow definitions. Also look for technology that allows you to see and control the contents of queued files received outside of transmission windows. Your operators may want to allow, roll over or simply delete some of the files received outside any particular transmission window.
A “trigger file” is a common type of control file used to initiate further processing or retransmission. Trigger files are typically created by the same application that original sends files into a file transfer system.
The two most common types of trigger files are files with similar names to the files that need to be sent and files that contain the names of files that need to be sent. Examples of two of the most common types of trigger files are shown below.
Similar Name Trigger File Example: Two files named “textrequest_20110608.xml” and “textrequest_20110608.tiff” are sent into a file transfer system. A third trigger file called “textrequest_20110608.trg” is then uploaded to tell the system to process or send the two “xml” and “tiff” files bearing similar names.
List of Files Trigger File Example: Two files named “textrequest_20110608.xml” and “textrequest_20110608.tiff” are sent into a file transfer system. A third trigger file called “trigger24235.txt” containing the names of the “xml” and “tiff” files is then uploaded to tell the system to process those specific files.
See “control file” for more information.
3DES (also “Triple DES”) is an open encryption standard that offers strong encryption at 112-bit and 168-bit strengths.
3DES is a symmetric encryption algorithm often used today to secure data in motion in both SSH and SSL/TLS. (After asymmetric key exchange is used perform the handshake in a SSH or SSL/TLS sessions, data is actually transmitted using a symmetric algorithm such as 3DES.)
3DES is also often used today to secure data at rest in SMIME, PGP, AS2, strong Zip encryption and many vendor-specific implementations. (After asymmetric key exchange is used to unlock a key on data at rest, data is actually read or written using a symmetric algorithm such as 3DES.)
NIST‘s AES competition was held to find a faster and stronger replacement for 3DES. However, 3DES has not yet been phased out and is expected to remain approved through 2030 for sensitive government information. (Only the 168-bit version is currently allowed; permitted use of the 112-bit version ceased January 1, 2011.) NIST validates specific implementations of 3DES under FIPS 140-2, and several hundred unique implementations have now been validated under that program. The 3DES algorithm itself is specified in FIPS 46-3.
See the Wikipedia entry for 3DES if you are interested in the technical mechanics behind 3DES.
BEST PRACTICE: All modern file transfer clients and file transfer servers should support FIPS-valided AES, FIPS-validated 3DES or both. (AES is faster, may have more longevity and offers higher bit rates; 3DES offers better backwards compatibility.)