Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
updates
- rfc-3720 — Internet Small Computer Systems Interface (iSCSI)
- rfc-3723 — Securing Block Storage Protocols over IP
- rfc-3821 — Fibre Channel Over TCP/IP (FCIP)
- rfc-3822 — Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)
- rfc-4018 — Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
- rfc-4172 — iFCP - A Protocol for Internet Fibre Channel Storage Networking
- rfc-4173 — Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
- rfc-4174 — The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
- rfc-5040 — A Remote Direct Memory Access Protocol Specification
- rfc-5041 — Direct Data Placement over Reliable Transports
- rfc-5042 — Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security
- rfc-5043 — Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
- rfc-5044 — Marker PDU Aligned Framing for TCP Specification
- rfc-5045 — Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)
- rfc-5046 — Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)
- rfc-5047 — DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)
- rfc-5048 — Internet Small Computer System Interface (iSCSI) Corrections and Clarifications
Extracted elements (28)
3DES CBC was downgraded from MUST to MAY because its 64-bit block size creates a birthday bound of 32 GiB, requiring frequent rekeying (e.g., every 3 GiB for a 10x safety margin) at multi-gigabit/second block storage rates. AES CBC with its 128-bit block size has a birthday bound of 2^68 bytes, making it the appropriate mandatory-to-implement replacement.
AES GCM was added as a SHOULD requirement (conditional on IKEv2 support) because it is now the encryption transform most amenable to hardware implementation at high data rates, providing both encryption and integrity in a single mechanism. AES GCM is not compatible with IKEv1's key exchange protocol.
AES GMAC was added as a SHOULD requirement because it is more amenable to hardware implementations, which may be preferable for the high data rates at which block storage protocols are expected to operate.
ID_KEY_ID is prohibited because it is an opaque identifier not interoperable among different IPsec implementations; heterogeneity among iSCSI initiator and target implementations makes interoperability of the IPsec layer critical.
IPsec v2 remains mandatory (not replaced by v3) to preserve interoperability with existing implementations; IPsec v3 is strongly recommended (SHOULD) to encourage implementers to adopt the newer version.
The requirement that IKEv1 use UDP port 500 was removed to allow NAT traversal (RFC 3947), which requires the ability to use other ports.
The method used by implementations supporting both IPsec v2 and v3 to determine which version a peer supports is regarded as an issue of IPsec policy administration and is not defined in this document.
This document's updated IPsec requirements apply not only to RFC 3723 but also to RFC 7143 (iSCSI consolidated) and RFC 7145 (iSER), and update the IPsec requirements in 17 other RFCs including iSCSI, FCIP, iFCP, RDMAP, DDP, and related protocols.
3DES CBC and AES CTR MAY be implemented (downgraded from RFC 3723's MUST and SHOULD, respectively); NULL encryption MUST be supported to enable authentication-only SAs.
AES CBC MAC with XCBC extensions (AES-XCBC-MAC-96) SHOULD be implemented; 128-bit keys MUST be supported, and other key sizes MAY also be supported.
AES in CBC mode MUST be implemented as a confidentiality transform; implementations MUST support 128-bit keys and MAY support other key sizes. This replaces the former mandatory requirement for 3DES CBC.
For IKEv1, ID_IPV4_ADDR, ID_IPV6_ADDR (if IPv6 supported), and ID_FQDN identification types MUST be supported; ID_KEY_ID MUST NOT be used. For IKEv2, the same address/FQDN types MUST be supported; ID_RFC822_ADDR SHOULD be supported; ID_KEY_ID MUST NOT be used.
HMAC-SHA-1-96 MUST be implemented as a data origin authentication and integrity transform for ESP.
If both IPsec v2 and v3 are supported by both endpoints of a block storage protocol connection, the use of IPsec v3 is RECOMMENDED.
IKEv1 implementations MUST support Main Mode; Aggressive Mode SHOULD be supported. Main Mode with pre-shared key authentication SHOULD NOT be used when either initiator or target uses dynamically assigned IP addresses, due to man-in-the-middle vulnerability from group pre-shared keys.
IKEv2 SHOULD be supported for peer authentication, negotiation of security associations, and key management. Manual keying MUST NOT be used with any version of IPsec for block storage protocols.
Implementations capable of operating at 1 gigabit/second or higher MUST implement extended (64-bit) sequence numbers for ESPv2 and ESPv3 (if supported), and SHOULD use extended sequence numbers for all block storage protocol traffic, to avoid frequent SA rekeying from 32-bit sequence number exhaustion.
Implementations MUST support ESPv2 in tunnel mode (IPsec v2) and SHOULD also support ESPv3 in tunnel mode (IPsec v3) to provide security for both control and data packets. Per-packet data origin authentication, integrity, and replay protection MUST be provided when either ESP version is utilized.
Implementations that support IKEv2 SHOULD also implement AES GCM; AES GCM implementations MUST support 128-bit keys and MAY support other key sizes.
In IKEv1 Phase 2 Quick Mode, the Identification Payload MUST be present in exchanges creating the Phase 2 SA.
Peer authentication using a pre-shared cryptographic key MUST be supported; certificate-based authentication using digital signatures MAY be supported. For IKEv1, public key encryption authentication methods SHOULD NOT be used.
Receipt of an IKEv1 Phase 2 delete message or an IKEv2 INFORMATIONAL exchange deleting an SA SHOULD NOT be interpreted as a reason to tear down the block storage protocol connection; if additional traffic is sent, a new SA will be created.
Support for perfect forward secrecy in IKEv1 Quick Mode key exchange MUST be implemented, and this requirement is extended to IKEv2: support for perfect forward secrecy in the CREATE_CHILD_SA key exchange MUST be implemented.
When DH groups are used, a DH group of at least 2048 bits SHOULD be offered in all proposals to create IPsec SAs for both IKEv1 and IKEv2; use of 1024-bit DH groups is NOT RECOMMENDED.
When digital signatures are used, all IKEv1 and IKEv2 negotiators SHOULD use Certificate Request Payloads and SHOULD check certificate validity via CRL or OCSP before accepting a PKI certificate for authentication.
3DES CBC remains optional and may be suitable for lower-speed implementations where its required rekeying frequency (at the 32 GiB birthday bound) is acceptable, but is no longer recommended for high-speed block storage use.
AES GCM and AES GMAC are both vulnerable to catastrophic forgery attacks if a nonce is ever repeated with a given key. Implementers must ensure nonce uniqueness per key for these modes.
Key sizes with comparable strength SHOULD be used for all cryptographic algorithms and transforms within any individual IPsec security association, per NIST SP 800-57 guidance.