Blockbridge is excited to announce the first generally available implementation of iSCSI over TLSv1.2. iSCSI-TLSv1.2 delivers a 290% increase in maximum throughput, 18% reduction in minimum latency, and drastically simplified management when compared to IPsec. There’s no longer an excuse for an insecure storage network!
iSCSI
The iSCSI protocol defines a method for transporting SCSI packets over one or more TCP/IP connections (see RFC3720). 15 years ago, when the protocol was designed, secure transport options were limited. IPsec emerged as the recommended standard. Fast forward a decade and a half, we have new cipher suites, crypto primitives built into commodity hardware and storage devices that operate well in excess of 1GB/s. The time has come to consider modern alternatives to IPsec for securing high-performance storage.
IPsec Primer
IPsec is an IP/Layer 3 protocol that cryptographically protects packets of any kind (i.e. TCP, UDP, ICMP, etc). In the most common mode of operation, each transmitted IP packet requires encryption, encapsulation and generation of a MAC (message authentication code). The keying materials used to perform encryption and hashing are most often established by out of band protocols such as IKEv2/ISAKMP.
Why Performance is Poor
In almost all network stacks, per-flow IPsec processing is serialized due to implementation specific constraints of upper level protocols that require in-order packet processing and lower level hardware interfaces that are optimized for latency. The lack of concurrency, combined with memory copy requirements, inline cryptographic operations and multiple traversals of the network layer are to blame for poor performance. That said, it is worth noting that the cryptography itself is NOT the bottleneck (with modern ciphers). The real issue is latency introduced by additional random memory accesses inline of each packet processed.
Origin of Complexity
The complexity of IPsec originates in how keying materials are established and subsequently configured to protect a flow (i.e. Security Association). The process involves sophisticated protocols that rely on well-defined ports, firewall detection, dynamic instantiation of routes, and programatic administration of databases that hold keying materials. There are a lot of moving parts in a working implementation. Consequently, debug requires patience and expertise.
Simplicity Through Orchestration
Where there is complexity, there is also an opportunity for simplification. To ease the process of securing storage, Blockbridge introduced “single command IPsec configuration” last fall. Our tools orchestrate creation and secure distribution of randomized access credentials, as well as configuration of the client. Yes, IPsec is still complicated. However, we’ve made it turnkey. Here’s the workflow:
# bb host attach --ipsec =============================================================================== vss-1/disk-1 attached with IPsec (read-write) to client-37 as /dev/sdb =============================================================================== # bb host info == Localhost: client-37 Hostname client-37 Initiator Name iqn.1994-05.com.redhat:d45acefe3a13 == Disks attached to client-37 disk [1] capacity size paths transport mode device ---------------------------- -------- -------- ----- --------- ---------- -------- disk-1 (DSK1962D94C406264C0) 1.0TiB 288.0KiB 1 IPsec read-write /dev/sdb
TLSv1.2: Easier, Faster, More Efficient
Transport Layer Security (TLS) is a record-oriented application protocol that provides privacy and data integrity. Unlike IPsec, it defines a method for securing a transport and exchanging keys within a single protocol (see RFC5246).
Complexity
TLS reduces complexity across the board. Because it is layered on top of TCP/IP, it is firewall friendly and issues can be diagnosed with familiar tools. Additionally, the singular specification and open nature of implementations have led to far fewer interoperability problems in the field. Using TLS with iSCSI requires the client to run an SSL proxy. The configuration and management of the proxy is simple compared to IPsec. Using the Blockbridge tools, it’s just a command line option. Here’s the workflow:
# bb host attach --tls =============================================================================== vss-1/disk-1 attached with TLSv1.2 (read-write) to client-37 as /dev/sdb =============================================================================== # bb host info == Localhost: client-37 Hostname client-37 Initiator Name iqn.1994-05.com.redhat:d45acefe3a13 == Disks attached to client-37 disk [1] capacity size paths transport mode device ---------------------------- -------- -------- ----- --------- ---------- -------- disk-1 (DSK1962D94C406264C0) 1.0TiB 288.0KiB 1 TLSv1.2 read-write /dev/sdb
Performance
TLS has a distinct performance advantage over IPsec because it is layered on top of TCP/IP. This layering allows a TLS flow to traverse the network stack while taking full advantage of hardware and kernel-level optimizations. Additionally, TLS record sizes are often larger than MTU (16KB vs 1500/9000B), resulting in lower setup costs for encapsulation. We believe the results speak for the themselves.
Conclusion
TLS is a clear winner when it comes to securing the storage fabric and we’re pleased to be the first to bring it to market. Simply put, it’s faster and more efficient. From a user perspective, it’s also more versatile because it’s firewall friendly. In fact, you can now access storage over WAN just as easily as you can on a LAN. Lastly, it’s also worth pointing out that it’s easy to scale performance. So, if you’re looking for high throughput (i.e. multiple GB/s), feel free to reach out.
Test System Specification
# cat /etc/issue CentOS release 6.7 (Final) # uname -a Linux client-37 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 21:19:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cpuinfo | egrep "name|MHz" model name : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz cpu MHz : 3400.179 model name : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz cpu MHz : 3400.179 model name : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz cpu MHz : 3400.179 model name : Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz cpu MHz : 3400.179 # bb version == blockbridge-cli version 1.3.0-498 build time 2016-03-04 21:30:16 +0000 api library 1.1.0 ruby version 2.1.5 (x86_64-linux)