Securing Block Storage Protocols over IP
updated by
- rfc-7146 — Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
Extracted elements (29)
IPsec is preferred over the SLPv2 security model (RFC 2608) for protecting SLPv2 in IP storage environments because native SLPv2 security cannot authenticate 'zero result responses', enabling DoS attacks, and does not support confidentiality. IPsec ESP with a non-null transform addresses both limitations.
iSCSI Login authentication is explicitly characterized as a weak security solution: it provides mutual authentication at connection setup but does not protect control and data traffic on a per-packet basis, and does not provide a protected ciphersuite negotiation. IPsec is therefore required to supply per-packet authentication, integrity, confidentiality, and replay protection.
Separate IPsec SAs are advisable when different QoS treatment is required for different IP block storage connections; attempting to apply different QoS to connections under the same SA can cause reordering and replay window violations.
iFCP and FCIP do not have native in-band security mechanisms and rely entirely on the IPsec protocol suite for data confidentiality and authentication, with IKE as the key management protocol. Because iFCP and FCIP devices are the last line of defense for an entire Fibre Channel island, successful attacks could compromise all Fibre Channel hosts behind the devices.
IKE Main Mode with pre-shared key SHOULD NOT be used when peers have dynamically assigned IP addresses, because this forces use of a group pre-shared key that is vulnerable to man-in-the-middle attack. In such cases, FQDN or USER_FQDN identity payloads SHOULD be used instead.
When IPsec integrity protection is known to be in place end-to-end between iSCSI endpoints, portions of iSCSI can be simplified: CRC check failure recovery is not necessary, and in certain NIC offload scenarios the iSCSI 32-bit CRC can be omitted entirely as it provides no additional protection.
All IP block storage security compliant implementations MUST support IPsec ESP to provide security for both control and data packets, including replay protection mechanisms. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
All iSNS implementations MUST support the replay protection mechanisms of IPsec. ESP in tunnel mode MUST be implemented. To provide data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported. If iSNS distributes security policy, authentication, data integrity, and confidentiality MUST be supported and used.
Any CHAP secret used for initiator authentication MUST NOT be configured for target authentication, and vice versa. If an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles.
Compliant iSCSI implementations MUST implement the CHAP authentication method (RFC 1994) including support for bi-directional authentication. Implementations MUST support random CHAP secrets of up to 128 bits and MUST NOT provide secret generation means other than random generation.
Conformant implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key SHOULD NOT be used when either peer uses a dynamically assigned IP address, as it forces use of a group pre-shared key vulnerable to man-in-the-middle attack.
Conformant IP block storage implementations MUST support ESP in tunnel mode and MAY implement ESP in transport mode.
Conformant IP block storage security implementations MUST support peer authentication using a pre-shared key and MAY support certificate-based peer authentication using digital signatures. Peer authentication using IKE public key encryption methods (sections 5.2 and 5.3 of RFC 2409) SHOULD NOT be used.
If an entity has already obtained its security configuration via other mechanisms (manual or automatic), then it MUST NOT request security policy via iSNS or SLPv2.
If CHAP is used with a secret smaller than 96 bits, IPsec encryption MUST be used to protect the connection and a compliant implementation MUST NOT continue with the iSCSI login unless it can verify that IPsec encryption is being used.
IKE Phase 2 Quick Mode exchanges used by IP block storage implementations MUST explicitly carry the Identity Payload fields (IDci and IDcr). Each Phase 2 IDci and IDcr SHOULD carry a single IP address and SHOULD NOT use IP Subnet or IP Address Range formats.
iSCSI implementations using SRP MUST use one of the well-known groups defined in Appendix A. All groups up to 1536 bits (SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST be supported by initiators and targets; targets MUST always offer 'SRP-1536' as one of the proposed groups.
Receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down an IP block storage connection. It is preferable to leave the connection up and bring up another IKE Phase 2 SA if additional traffic is sent.
To provide confidentiality with ESP, 3DES in CBC mode MUST be supported and AES in Counter mode (RFC 3686) SHOULD be supported. DES in CBC mode SHOULD NOT be used due to inherent weakness.
To provide data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported and AES in CBC MAC mode with XCBC extensions (RFC 3566) SHOULD be supported. ESP with NULL encryption MUST be supported for authentication-only use.
Where iSNS or SLPv2 is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures to avoid continually contacting discovered endpoints that fail authentication.
Where SLPv2 is used to distribute security policy or configuration information, per-packet data origin authentication, integrity, and replay protection MUST be used to protect the discovery protocol, as it would constitute a weak link for the protocols whose security it configures.
Within IKE Phase 1, conformant IP block storage implementations MUST support ID_IPV4_ADDR, ID_IPV6_ADDR (if IPv6 is supported), and ID_FQDN Identity Payloads. The ID_KEY_ID Identity Payload MUST NOT be used. The ID port and protocol fields MUST be set to zero or UDP port 500.
An iSCSI session is identified by the 2-tuple <ISID, TSIH>; each connection within a session is assigned a unique Connection ID (CID) and identified by a TCP 5-tuple. An IPsec Phase 2 SA is identified by the 3-tuple <Protocol (ESP), destination address, SPI>. Each TCP connection is protected by exactly one IKE Phase 2 SA, though one SA may cover multiple TCP connections.
iSNS clients that are registered in the iSNS database MUST maintain at least one Phase 1 and one Phase 2 IPsec security association with the iSNS server. All iSNS protocol messages between clients and server are protected by a Phase 2 SA. The iSNS authentication block (identical in format to the SLP authentication block) MAY be used for broadcast/multicast messages.
SLPv2 security for iSCSI and FCIP uses IPsec ESP with a non-null transform to protect unicast SLPv2 messages. SLPv2 authentication blocks (digital signatures per RFC 2608) MAY also be used to authenticate unicast and multicast messages, but IPsec is preferred as certificate deployment for IPsec is more likely than for SLPv2 alone.
NAT traversal with IPsec is problematic for IP block storage protocols: AH is incompatible with NAT since it authenticates IP addresses, and ESP transport mode is similarly incompatible with NAT. IPsec ESP tunnel mode with IKE NAT traversal (UDP encapsulation) is the only viable option where NAT is present.
Rekeying of IPsec SAs must be handled carefully to avoid gaps in protection; implementations should rekey before SA expiration. Inappropriate handling of the overlap period between old and new SAs can create replay window vulnerabilities or cause connection disruption. IKE Phase 2 delete for idle SAs must not be misinterpreted as a reason to tear down active storage connections.
Transport mode IPsec exposes TCP port information to network middleboxes (enabling firewall filtering) but also to attackers who can use port information to mount targeted attacks. Tunnel mode hides port information but prevents per-connection firewall filtering. The document analyzes trade-offs and notes that transport mode is appropriate within a trusted administrative domain while tunnel mode is preferred across untrusted networks.