6.5 Security for IP SANs

Security for storage data has trailed behind the deployment of shared storage technologies. In part, this lag has resulted from the physical isolation of SANs from the rest of the data communications network. In part, security and management issues could not be addressed until SAN technology itself achieved stability and an installed base. In contrast, storage data over IP networks has focused more attention on security because that data is now potentially exposed to untrusted network segments. This sensitivity in turn has exposed the security weakness of Fibre Channel SANs, and a new industry has developed specifically to address SAN security. NeoScale, for example, has developed products that enable Fibre Channel-originated storage data to be encrypted to disk, providing a secure solution for highly sensitive information stores.

SAN security involves access, authentication, and data encryption. Rudimentary access security can be provided by zoning, LUN masking, or access control lists (ACLs). As with quality of service, IP networking brings additional tools for securing storage data. At the link layer, VLAN tagging can be used to enforce the equivalent of Fibre Channel zone segregation. The iSNS protocol discussed earlier can be used to enforce zoning through discovery domains.

Authentication and data encryption are well-defined facilities in IP networking, with specifications provided under the banner of IP Security, or IPSec. The IPSec architecture is defined in the IETF RFC 2401 standards track document, "Security Architecture for the Internet Protocol." IPSec has two main components: authentication of the identity of communicating peers in the network and data encryption. Authentication is defined in RFC 2402, "IP Authentication Header," and payload encryption is defined in RFC 2406, "IP Encapsulating Security Payload (ESP)." Because various authentication and encryption methods have evolved over time, IPSec does not specify an individual solution. The specific type of authentication or encryption to be used is negotiated by the end devices or is established by IPSec products such as firewalls or IP routers with IPSec engines.

Authentication and encryption methods are dependent on encryption keys. A key is a value that is applied in an encryption algorithm against standard data. The longer the key, the more difficult it is to decipher the newly encrypted data. The Data Encryption Standard (DES), for example, uses a 56-bit key, allowing for as many as 72 quadrillion possible keys that can be applied to a datagram. In a well-publicized challenge, however, a DES-encrypted message was cracked, resulting in a more rigorous triple DES implementation. In triple DES, data blocks are passed through three different keys to thoroughly encrypt them.

Although secret keys such as DES can be used at both source and destination to encrypt and decrypt user data, both sides must have the same list of keys to properly decipher arriving datagrams. Securely exchanging secret key lists is therefore an issue. Another approach, provided by Public Key Infrastructure (PKI) services, employs public and private key pairs for data encryption and decryption. Based on the International Telecommunications Union (ITU) X.509 standard, PKI enables the distribution of public keys over untrusted networks while relying on the security of individual hosts to maintain control over their private keys. A message that is encrypted by a remote host using your public key can be decoded locally using your private key.

The role of IPSec for storage has been a contentious issue in the standardization of iSCSI and IP storage protocols. Ideally, IPSec should be embedded in every networked device so that complete authentication and encryption would be available for every IP-based transaction. The IETF has therefore encouraged incorporation of IPSec in every IP transport protocol, including iSCSI. The reality, however, is that embedding IPSec ASICs on every adapter card would drive the cost of iSCSI NICs much higher and beyond the reach of the broad market. In addition, customers may already have firewalls or IPSec options installed in their IP routers and thus see less value in driving security down to the end device.

In the end, customers must decide which parts of their networks are untrusted and where IPSec should be applied. For storage networking applications, third-party IPSec products are now capable of wire-speed data encryption and unobtrusively appear as "bumps in the wire" when deployed. As shown in Figure 6-17, IPSec hardware can be installed on the boundary of an untrusted network segment. IPSec products see iSCSI or iFCP traffic as simply additional IP datagrams, so even though these security products are not storage-aware, they can provide a valuable service for storage data. When IP security chip sets become more commoditized, it will be possible to justify the cost of implementing security for every networked device.

Figure 6-17. IPSec for Fibre Channel-originated storage data