RFC 3723
Securing Block Storage Protocols over IP
Securing Block Storage Protocols over IP 🎀
RFC 3723, from the Network Working Group, is a Standards Track doc, dated April 2004. It was written by B. Aboba (Microsoft), J. Tseng (McDATA Corporation), J. Walker (Intel), V. Rangan (Brocade Communications Systems Inc.), and F. Travostino (Nortel Networks). The title block doesn't list anything it obsoletes or updates. 💖
Status of This Memo 📜
Okay bestie, this part is the legal-ish stuff, but it matters. This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice 💜
Copyright (C) The Internet Society (2004). All Rights Reserved. 🌸
Abstract 🦋
So this doc is all about locking down block storage and storage discovery protocols that run over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange) 🔐 It builds threat models and security protocols for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking), and FCIP (Fibre Channel over TCP/IP). It also covers the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. And yes, it digs into performance issues and resource constraints too 💅
Table of Contents 🗂️
1. Introduction ................................................. 3
1.1. iSCSI Overview ......................................... 3
1.2. iFCP Overview .......................................... 4
1.3. FCIP Overview .......................................... 4
1.4. IPsec Overview ......................................... 4
1.5. Terminology ............................................ 6
1.6. Requirements Language .................................. 7
2. Block Storage Protocol Security .............................. 7
2.1. Security Requirements ................................. 7
2.2. Resource Constraints ................................... 10
2.3. Security Protocol ...................................... 12
2.4. iSCSI Authentication ................................... 16
2.5. SLPv2 Security ......................................... 18
2.6. iSNS Security .......................................... 24
3. iSCSI security Inter-Operability Guidelines .................. 28
3.1. iSCSI Security Issues .................................. 28
3.2. iSCSI and IPsec Interaction ............................ 29
3.3. Initiating a New iSCSI Session ......................... 30
3.4. Graceful iSCSI Teardown ................................ 31
3.5. Non-graceful iSCSI Teardown ............................ 31
3.6. Application Layer CRC .................................. 32
4. iFCP and FCIP Security Issues ................................ 34
4.1. iFCP and FCIP Authentication Requirements .............. 34
4.2. iFCP Interaction with IPsec and IKE .................... 34
4.3. FCIP Interaction with IPsec and IKE .................... 35
5. Security Considerations ...................................... 36
5.1. Transport Mode Versus Tunnel Mode ...................... 36
5.2. NAT Traversal .......................................... 39
5.3. IKE Issues ............................................. 40
5.4. Rekeying Issues ........................................ 40
5.5. Transform Issues ....................................... 43
5.6. Fragmentation Issues ................................... 45
5.7. Security Checks ........................................ 46
5.8. Authentication Issues .................................. 47
5.9. Use of AES in Counter Mode ............................. 51
6. IANA Considerations .......................................... 51
6.1. Definition of Terms .................................... 52
6.2. Recommended Registration Policies ...................... 52
7. Normative References ......................................... 52
8. Informative References ....................................... 54
9. Acknowledgments .............................................. 58
Appendix A - Well Known Groups for Use with SRP ................. 59
Appendix B - Software Performance of IPsec Transforms ........... 61
B.1. Authentication Transforms .............................. 61
B.2. Encryption and Authentication Transforms ............... 64
Authors' Addresses ............................................... 69
Full Copyright Statement ......................................... 701. Introduction 🧚
This spec is all about using the IPsec protocol suite to protect block storage protocols over IP networks (that's iSCSI, iFCP, and FCIP), plus the storage discovery protocols (iSNS and SLPv2) ✨
1.1. iSCSI Overview 💾
iSCSI, described in [RFC3720], is a connection-oriented command/response protocol. It runs over TCP and is used to access disk, tape, and other devices 🍓 It's a client-server protocol, where clients (initiators) open connections to servers (targets) and then do an iSCSI login.
This doc uses the SCSI terms initiator and target for clarity. It also helps avoid the common assumption that clients have way less computing and memory power than servers. For SCSI it's often the opposite, since targets are usually dedicated devices of some form 🙈
iSCSI has a text-based negotiation mechanism as part of its initial (login) procedure. It's extensible in two ways: you can define new text keys and values for what gets negotiated, and the number of negotiation rounds can grow too. That's how stuff like challenge-response authentication fits in 🔥
Once the login succeeds, the iSCSI initiator can send SCSI commands for the iSCSI target to run. The target sends back a status response for each command, all over the same connection. That one connection carries both the command/status messages and the data transfer and/or optional command parameters 💅 An iSCSI session can have multiple connections, but a separate login happens on each one. The session ends when its last connection closes.
iSCSI initiators and targets are application layer entities, so they don't depend on TCP ports or IP addresses. They have names whose syntax is defined in [RFC3721]. An iSCSI session between a given initiator and target runs over one or more TCP connections between those two. The login process is what links an iSCSI Session to the TCP connection(s) that carry the iSCSI PDUs 🔗
Here's the twist: the iSCSI login can include mutual authentication of the iSCSI endpoints and negotiation of session parameters. But iSCSI doesn't define its own per-packet authentication, integrity, confidentiality, or replay protection. Instead it leans on the IPsec protocol suite for per-packet data confidentiality, integrity, and authentication services, with IKE as the key management protocol 🛡️ And iSCSI uses TCP for congestion control, error detection, and error recovery 🫶
1.2. iFCP Overview 🌈
iFCP, defined in [iFCP], is a gateway-to-gateway protocol. It provides transport services to Fibre Channel devices over a TCP/IP network 🌸 It lets existing Fibre Channel devices interconnect and network at wire speeds over an IP network. iFCP implementations emulate fabric services to boost fault tolerance and scalability by really leveraging IP technology. Each TCP connection supports storage traffic between one unique pair of Fibre Channel N_PORTs 👑
iFCP has no native, in-band security mechanism 😭 So it relies on the IPsec protocol suite for data confidentiality and authentication services, with IKE as the key management protocol. iFCP uses TCP for congestion control, error detection, and error recovery.
1.3. FCIP Overview 🦋
FCIP, defined in [FCIP], is a pure FC encapsulation protocol that transports FC frames. The current spec work is aimed at interconnecting Fibre Channel switches over TCP/IP networks, but the protocol isn't inherently limited to connecting FC switches 💖 FCIP is different from iFCP because no interception or emulation of fabric services is involved. One or more TCP connections get bound to an FCIP Link, which realizes Inter-Switch Links (ISLs) between pairs of Fibre Channel entities. FCIP Frame Encapsulation is described in [RFC3643] ✨
FCIP also has no native, in-band security mechanism. Same story as iFCP: it relies on the IPsec protocol suite for data confidentiality and authentication services, with IKE as the key management protocol. FCIP uses TCP for congestion control, error detection, and error recovery.
(Part 1 of 17 is done, bestie 🎀 Part 2 picks up with the IPsec overview next! 💅)
1.4. IPsec Overview 🔐
okay bestie, IPsec is a whole protocol suite that locks down communication at the network layer between two peers 🔒✨ It's specified across the IP Security Architecture [RFC2401], IKE [RFC2409][RFC2412], the IPsec Authentication Header (AH) [RFC2402], and the IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE is the key management protocol 🔑 while AH and ESP are the ones actually protecting the IP traffic 🛡️
An IPsec SA is a one-way security association 💌 and it's uniquely identified by a 3-tuple: Security Parameter Index (SPI), protocol (ESP) and destination IP. Usually a key management protocol sets up its parameters, like the encapsulation mode, encapsulation type, session keys and SPI values 🧚
IKE is a two phase negotiation protocol built on the modular exchange of messages defined by ISAKMP [RFC2408], and the IP Security Domain of Interpretation (DOI) [RFC2407]. IKE has two phases and handles four jobs:
- Protected cipher suite and options negotiation, using keyed MACs and encryption and anti-replay mechanisms
- Master key generation, such as via MODP Diffie-Hellman calculations
- Authentication of end-points
- IPsec SA management (selector negotiation, options negotiation, create, delete, and rekeying)
Items 1 through 3 happen in IKE Phase 1, and item 4 is handled in IKE Phase 2 💅
An IKE Phase 2 negotiation sets up both an inbound and an outbound IPsec SA. The traffic that gets protected is decided by a selector, proposed by the IKE initiator and accepted by the IKE Responder. In IPsec transport mode, the selector can be a "filter" or traffic classifier, defined as the 5-tuple: <Source IP address, Destination IP address, transport protocol (UDP/SCTP/TCP), Source port, Destination port>. Once an IKE Phase-2 SA is successfully established, you get two uni-directional IPsec SAs, each fully qualified by the tuple <Protocol (ESP/AH), destination address, SPI> 👯
The session keys for each IPsec SA come from a master key, usually via a MODP Diffie-Hellman computation. Rekeying an existing IPsec SA pair means creating two new IPsec SAs, making them active, and then optionally deleting the older pair. Typically the new outbound SA gets used immediately, while the old inbound SA stays active to receive packets for some locally defined time, perhaps 30 seconds or 1 minute ⏰
1.5. Terminology 📖
Fibre Channel: Fibre Channel (FC) is a gigabit speed networking technology mainly used to build Storage Area Networks (SANs), although it may also carry other frame types, including IP. FC is standardized under American National Standard for Information Systems of the InterNational Committee for Informational Technology Standards (ANSI-INCITS) in its T11 technical committee. 🌐
FCIP: Fibre Channel over IP (FCIP) is a protocol for connecting Fibre Channel islands over IP networks so they form a unified SAN in a single Fibre Channel fabric. The principal FCIP interface point to the IP network is the FCIP Entity. The FCIP Link represents one or more TCP connections that exist between a pair of FCIP Entities. 🦋
HBA: Host Bus Adapter (HBA) is a generic term for a SCSI interface to other device(s). It's roughly analogous to the term Network Interface Card (NIC) for a TCP/IP network interface, except that HBAs generally have on-board SCSI implementations, whereas most NICs do not implement TCP, UDP, or IP. it's the NIC's cooler storage cousin 💜
iFCP: iFCP is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to Fibre Channel devices over a TCP/IP network. 🌸
IP block storage protocol: Where this document uses the term "IP block storage protocol", it covers all block storage protocols running over IP, including iSCSI, iFCP and FCIP. 🧩
iSCSI: iSCSI is a client-server protocol in which clients (initiators) open connections to servers (targets). 🎀
iSNS: The Internet Storage Name Server (iSNS) protocol provides for discovery and management of iSCSI and Fibre Channel (FCP) storage devices. iSNS applications store iSCSI and FC device attributes and monitor their availability and reachability, giving you one consolidated information repository for an integrated IP block storage network. iFCP requires iSNS for discovery and management, iSCSI may use iSNS for discovery, and FCIP does not use iSNS. ✨
initiator: The iSCSI initiator connects to the target on well-known TCP port 3260. It then issues SCSI commands for execution by the iSCSI target. 🚀
target: The iSCSI target listens on a well-known TCP port for incoming connections, and returns a status response for each command issued by the iSCSI initiator, over the same connection. 🍓
1.6. Requirements Language 📝
In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [RFC2119]. the capital letters are doing the heavy lifting here, bestie 💅
Note that requirements specified in this document apply only to use of IPsec and IKE with IP block storage protocols. So these requirements do not apply to IPsec implementations in general. Implementation requirements language should therefore be assumed to relate to the availability of features for use with IP block storage security only. 🫶
Although the security requirements in this document are already incorporated into the iSCSI [RFC3720], iFCP [iFCP] and FCIP [FCIP] standards track documents, they are reproduced here for convenience. If there's ever a discrepancy, the individual protocol standards track documents take precedence. 👑
2. Block Storage Protocol Security ✨
2.1. Security Requirements ✨
okay so IP block storage protocols like iSCSI, iFCP and FCIP are literally how SCSI commands travel over IP networks 🌐 which means both the control packets AND the data packets are vulnerable to attack 💀 here's the list of ways an adversary could try to mess with things:
- An adversary may attempt to acquire confidential data and identities by snooping data packets.
- An adversary may attempt to modify packets containing data and control messages.
- An adversary may attempt to inject packets into an IP block storage connection.
- An adversary may attempt to hijack TCP connection(s) corresponding to an IP block storage session.
- An adversary may launch denial of service attacks against IP block storage devices such as by sending a TCP reset.
- An adversary may attempt to disrupt security negotiation process, in order to weaken the authentication, or gain access to user passwords. This includes disruption of application-layer authentication negotiations such as iSCSI Login.
- An adversary may attempt to impersonate a legitimate IP block storage entity.
- An adversary may launch a variety of attacks (packet modification or injection, denial of service) against the discovery (SLPv2 [RFC2608]) or discovery and management (iSNS [iSNS]) process. iSCSI can use SLPv2 or iSNS. FCIP only uses SLPv2, and iFCP only uses iSNS.
Ngl this is scary 😭 since iFCP and FCIP devices are the last line of defense for a whole Fibre Channel island, if any of the above attacks actually work, they could compromise every Fibre Channel host behind those devices. 🫠
To deal with these threats, IP block storage security protocols MUST NOT be the weak link, so they need to support confidentiality, data origin authentication, integrity, and replay protection on a per-packet basis. 🔐 Confidentiality matters a lot because IP block storage traffic may travel over insecure public networks. The IP block storage security protocols must support perfect forward secrecy in the rekeying process. 🦋
Bi-directional authentication of the communication endpoints MUST be provided. There's no requirement that the identities used in authentication stay confidential (for example, from a passive eavesdropper), so that part is chill. 🙈
For a security protocol to be useful, the CPU overhead and hardware availability must not block implementation at 1 Gbps today. Implementation at 10 Gbps is highly desirable, but it may not be demonstrable yet. These performance levels apply to aggregate throughput and include all TCP connections used between IP block storage endpoints, and IP block storage communications typically involve multiple TCP connections. Performance issues are discussed further in Appendix B. 🚀
Enterprise data center networks are treated as mission-critical facilities that must be isolated and protected from possible security threats. These networks are often protected by security gateways, which at a minimum provide a shield against denial of service attacks. 🛡️ The IP block storage security architecture should be able to leverage the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and VPN services available on existing security gateways. ✨
When iFCP or FCIP devices are deployed within enterprise networks, IP addresses will typically be statically assigned, just like with most routers and switches. So support for dynamic IP address assignment, as described in [RFC3456], will typically not be required, although it can't be ruled out. This also matters for iSCSI hosts whose addresses are dynamically assigned. As a result, the IP block storage security protocols must not introduce additional security vulnerabilities where dynamic address assignment is supported. 💅
While IP block storage security is mandatory to implement, it is not mandatory to use. 🎀 The security services that get used depend on the configuration and security policies put in place. For example, configuration influences the authentication algorithm negotiated within iSCSI Login, as well as the security services (confidentiality, data origin authentication, integrity, replay protection) and transforms negotiated when IPsec is used to protect IP block storage protocols such as iSCSI, iFCP and FCIP. 🧚
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. For iFCP, the granularity corresponds to an iFCP Portal. For iSCSI, the granularity of control is typically that of an iSCSI session, although it's possible to control things all the way down to the destination IP address and TCP port. 🍓
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA. So IP block storage connections that need a different set of security services than the ones negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. 👑
Separate IPsec SAs are also advisable where quality of service considerations dictate different handling of IP block storage connections. Applying different quality of service to connections handled by the same IPsec SA can result in reordering, and packets falling outside the replay window. For a discussion of the issues, see [RFC2983]. 🌸
IP block storage protocols can be expected to carry sensitive data and provide access to systems and data that need protection against security threats. SCSI and Fibre Channel currently contain little in the way of security mechanisms, and they rely on physical security, administrative security, and correct configuration of the communication medium and the systems/devices attached to it for their security properties. 🥺
For most IP networks, it's inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used by IP block storage protocols (e.g., iSCSI SHOULD use one of its in-band authentication mechanisms or the authentication provided by IKE) in order to provide a minimal assurance that connections have initially been opened with the intended counterpart. 🫶
iSNS, described in [iSNS], is required in all iFCP deployments. iSCSI may use iSNS for discovery, and FCIP does not use iSNS. iSNS applications store iSCSI and FC device attributes and monitor their availability and reachability, providing a consolidated information repository for an integrated IP block storage network. The iSNS specification defines mechanisms to secure communication between an iSNS server and its clients. 🔥
2.2. Resource Constraints 💜
Resource constraints and performance requirements for iSCSI are discussed in [RFC3347] Section 3.2. iFCP and FCIP devices will typically be embedded systems racked up in air-conditioned data center facilities. Embedded systems like these may include hardware chipsets that handle data encryption, authentication, and integrity processing. So memory and CPU resources are generally not a constraining factor. 🧠✨
iSCSI will run on all kinds of systems, from big servers running general purpose operating systems to embedded host bus adapters (HBAs). In general, a host bus adapter is the most constrained iSCSI implementation environment, although an HBA may draw upon the resources of the system it's attached to in some cases (for example, authentication computations required for connection setup). More resources should be available to iSCSI implementations for embedded and general purpose operating systems. The following guidelines show roughly how many resources authentication, keying, and rekeying functionality can reasonably expect to draw upon:
- Low power processors with small word size are generally not used, as power is usually not a constraining factor, with the possible exception of HBAs, which can draw upon the computational resources of the system into which they are inserted. Computational horsepower should be available to perform a reasonable amount of exponentiation as part of authentication and key derivation for connection setup. The same is true of rekeying, although the ability to avoid exponentiation for rekeying may be desirable (but is not an absolute requirement).
- RAM and/or flash resources tend to be constrained in embedded implementations. 8-10 MB of code and data for authentication, keying, and rekeying is clearly excessive, 800-1000 KB is clearly larger than desirable, but tolerable if there is no other alternative, and 80-100 KB should be acceptable. These sizes are intended as rough order of magnitude guidance, and should not be taken as hard targets or limits (e.g., smaller code sizes are always better). Software implementations for general purpose operating systems may have more leeway.
The primary resource concern for implementing authentication and keying mechanisms is code size, since iSCSI assumes the computational horsepower to do exponentiations will be available. 📏
There's no dominant iSCSI usage scenario. The scenarios range from a single connection constrained only by media bandwidth to hundreds of initiator connections to a single target or communication endpoint. SCSI sessions, and hence the connections they use, tend to be relatively long lived. For disk storage, a host typically opens a SCSI connection on boot and closes it on shutdown. 💾 Tape session length tends to be measured in hours or fractions thereof (rapid fire sharing of the same tape device among different initiators is unusual), although tape robot control sessions can be short when the robot is shared among tape drives. On the other hand, tape won't see a large number of initiator connections to a single target or communication endpoint, since each tape drive is dedicated to a single use at a single time, and a dozen tape drives is already a large tape device. 📼
2.3. Security Protocol 🔐
2.3.1. Transforms
All IP block storage security compliant implementations MUST support IPsec ESP [RFC2406] to provide security for both control packets and data packets, as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity and replay protection MUST be used. 🙌
To provide confidentiality with ESP, ESP with 3DES in CBC mode [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. ESP with NULL encryption MUST be supported for authentication. 🍰
2.3.2. IPsec Modes
Conformant IP block storage protocol implementations MUST support ESP [RFC2406] in tunnel mode and MAY implement IPsec with ESP in transport mode. 🦋
2.3.3. IKE 🎀
okay bestie, so every conformant IP block storage security implementation MUST support IKE [RFC2409] for peer authentication, negotiating security associations, and key management, all using the IPsec DOI [RFC2407]. Manual keying MUST NOT be used, because it doesn't give you the rekeying support you actually need 🙅♀️ Conformant implementations MUST support peer authentication with a pre-shared key, and MAY also support certificate-based peer authentication using digital signatures ✨ Peer authentication using the public key encryption methods in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used 💅
Okay, next part! Conformant IP block storage security implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode 🌸 IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either peer uses a dynamically assigned IP address 🙈 Main Mode with pre-shared keys is pretty secure in lots of cases, but when addresses are dynamic you're forced into a group pre-shared key, and that's vulnerable to man-in-the-middle attacks. not iconic 💀
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used 🦋 In every case, locally stored secret information (the pre-shared key, or the private key used for digital signing) must be suitably restricted. If the secret gets compromised, the security properties of the IKE/IPsec protocols are gone, so guard it like your diary 🔒🫶
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) it trusts, according to its local policy 👑 IKE negotiators SHOULD also check the relevant Certificate Revocation List (CRL) before accepting a PKI certificate for IKE's authentication procedures ✨
The IPsec DOI [RFC2407] has several kinds of identification data. In IKE Phase 1, for the IDii and IDir payloads, conformant IP block storage security implementations MUST support the ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN Identity Payloads 🧚 iSCSI security implementations SHOULD support the ID_USER_FQDN Identity Payload, but the other IP block storage protocols (iFCP, FCIP) SHOULD NOT use ID_USER_FQDN 🍓 Identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (like ID_FQDN or ID_USER_FQDN) SHOULD be used when Aggressive mode is combined with pre-shared keys and IP addresses are dynamically assigned. The IP Subnet, IP Address Range, ID_DER_ASN1_DN and ID_DER_ASN1_GN formats SHOULD NOT be used for IP block storage protocol security. The ID_KEY_ID Identity Payload MUST NOT be used 🙅♀️ As described in [RFC2407], within Phase 1 the ID port and protocol fields MUST be set to zero or to UDP port 500. And as [RFC2407] also notes:
When an IKE exchange is authenticated using certificates (of any format), any ID's used for input to local policy decisions SHOULD be contained in the certificate used in the authentication of the exchange.
The Phase 2 Quick Mode exchanges used by IP block storage protocol implementations MUST explicitly carry the Identity Payload fields (IDci and IDcr) 🌈 Each Phase 2 IDci and IDcr Payload SHOULD carry a single IP address (ID_IPV4_ADDR, ID_IPV6_ADDR) and SHOULD NOT use the IP Subnet or IP Address Range formats. Other ID payload formats MUST NOT be used 💜
Here's the tea ☕ IPsec acceleration hardware might only handle a limited number of active IKE Phase 2 SAs, so Phase 2 delete messages may be sent for idle SAs, to keep the number of active Phase 2 SAs as low as possible. Receiving an IKE Phase 2 delete message MUST NOT be treated as a reason to tear down an IP block storage connection 😭 It's actually better to leave the connection up, and if more traffic gets sent on it, bring up another IKE Phase 2 SA to protect it. That way you avoid constantly bringing connections up and down, which is so not it 🦋
2.3.4. Security Policy Configuration 🌷
One of the goals of this spec is a high level of interoperability without needing a ton of configuration. This section gives guidelines for setting IKE parameters so the negotiation is more likely to succeed. It also describes how security policy configuration info can be provided to help even more ✨
To boost interoperability, here are some actions to think about 💖
- Transform restriction. Since support for 3DES-CBC and HMAC-SHA1 is required of all implementations, offering these transforms makes a successful negotiation more likely 🙌 If AES-CTR [RFC3686] with XCBC-MAC [RFC3566] is supported, that transform combination will typically be preferred, with 3DES-CBC/HMAC-SHA1 as a secondary offer 💅
- Group Restriction. If 3DES-CBC/HMAC-SHA1 is offered and DH groups are offered, it is recommended that a DH group of at least 1024 bits be offered along with it. If AES-CTR/XCBC-MAC is the preferred offer and DH groups are offered, it is recommended that a DH group of at least 2048 bits be offered along with it, as noted in [KeyLen] 🔥 If perfect forward secrecy is required in Quick Mode, it is recommended that the QM PFS DH group be the same as the IKE Phase 1 DH group. That cuts down the total number of combinations, which means more chances to interoperate 🫶
- Key lifetimes. If a key lifetime is offered that is longer than desired, then instead of making the IKE negotiation fail, it is recommended that the Responder treat the offered lifetime as a maximum and accept it. The key can then use a shorter lifetime and send a Lifetime Notify to tell the other peer when it expires ⏳
Even when you follow all that, it can still be useful to provide extra configuration info to boost your chances, and it's handy to be able to manage security configuration no matter how big the deployment is 🌈
For example, you might want to configure the security policy of an IP block storage device. That can be done manually or automatically through a security policy distribution mechanism. Alternatively, it can be supplied via iSNS or SLPv2 🧚 If an IP block storage endpoint can get the security policy it needs by other means (manually, or automatically through a security policy distribution mechanism), then it doesn't need to request that info via iSNS or SLPv2. But if the needed configuration isn't available through other mechanisms, iSNS or SLPv2 can be used to get it 💜
It can also help to learn a peer's preferences before starting IKE. Negotiating security parameters within IKE is usually possible, but sometimes incompatible parameters make the IKE negotiation fail. The following info can be provided via SLPv2 or iSNS:
- IPsec or cleartext support. The minimum peer configuration needed is whether an IP block storage endpoint requires IPsec or cleartext. You can't figure this out from the IKE negotiation alone without risking a long timeout, which is seriously not ideal for a disk access protocol 💀
- Perfect Forward Secrecy (PFS) support. It helps to know whether a peer allows PFS, because an IKE Phase 2 Quick Mode can fail if an initiator proposes PFS to a Responder that doesn't allow it 🙈
- Preference for tunnel mode. It's legal to propose both transport and tunnel mode in the same offer, but not every IKE implementation supports that. So it's useful to know whether a peer prefers tunnel mode or transport mode, so you can negotiate the preferred mode on the first try 🦋
- Main Mode and Aggressive Mode support. IKE negotiation can fail if a mode is proposed to a peer that doesn't allow it, so it's helpful to know which modes a peer allows, letting you negotiate an allowed mode on the first try 👑
Here's the important bit 🚨 iSNS or SLPv2 can be used to distribute IPsec security policy and configuration info for IP block storage protocols, so these discovery protocols would be a 'weak link' if they weren't secured at least as well as the protocols whose security they configure. The major vulnerability is packet modification and replay, so when iSNS or SLPv2 are used to distribute security policy or configuration information, per-packet data origin authentication, integrity and replay protection MUST, at a minimum, be used to protect the discovery protocol 🛡️💖
2.4. iSCSI Authentication ✨
2.4.1. CHAP ✨
Okay bestie, CHAP is the main character of this section 💅 Compliant iSCSI implementations MUST implement the CHAP authentication method [RFC1994] (according to [RFC3720], section 11.1.4), which includes support for bi-directional authentication, and the target authentication option. Iconic requirement, no notes 💖
When CHAP runs over a non-encrypted channel, it is vulnerable to an off-line dictionary attack 😭 So implementations MUST support random CHAP secrets of up to 128 bits, including the means to generate such secrets and to accept them from an external generation source. And they MUST NOT provide secret generation (or expansion) means other than random generation. Random only, periodt 🎲
If CHAP is used with a secret smaller than 96 bits, then IPsec encryption (according to the implementation requirements in [RFC3720] section 8.3.2) MUST be used to protect the connection 🔒 Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used. And when CHAP is used with a secret smaller than 96 bits, a compliant implementation MUST NOT continue with the iSCSI login unless it can verify that IPsec encryption is being used to protect the connection. No IPsec, no login, it's giving strict parent energy 🙈
Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication 🦋 Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. Caught in 4K.
The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets 🥺 Why? Because it lets any of them impersonate any other one of them, and if you compromise one, the attacker can impersonate any of them. It is recommended that iSCSI implementations check for use of identical CHAP secrets by different peers when this check is feasible, and take appropriate measures to warn users and/or administrators when this is detected. A single CHAP secret MAY be used for authentication of an individual initiator to multiple targets. Likewise, a single CHAP secret MAY be used for authentication of an individual target to multiple initiators. So sharing is allowed, but not in a sus way 🌸
A Responder MUST NOT send its CHAP response if the initiator has not successfully authenticated. Here's the exchange:
I->R CHAP_A=<A1,A2,...>
R->I CHAP_A=<A1> CHAP_C=<C> CHAP_I=<I>
I->R CHAP_N=<N> CHAP_C=<C> CHAP_I=<I>(Where N, (A1,A2), I, C, and R are correspondingly the Name, Algorithms, Identifier, Challenge, and Response as defined in [RFC1994])
This exchange MUST result in the Responder (target) closing the iSCSI TCP connection, because the initiator has failed to authenticate (there is no CHAP_R in the third message). Bye bye, no vibes 👋
Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator 🚫 If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close. This makes sure the same CHAP secret isn't used for authentication in both directions. Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles. Two hats, two passwords, the end 👑
Here's the attack these rules are stopping, so you can see why it matters 💀
Rogue wants to impersonate Storage to Alice, and knows that a
single secret is used for both directions of Storage-Alice
authentication.
Rogue convinces Alice to open two connections to Rogue, and
Rogue identifies itself as Storage on both connections.
Rogue issues a CHAP challenge on connection 1, waits for Alice
to respond, and then reflects Alice's challenge as the initial
challenge to Alice on connection 2.
If Alice doesn't check for the reflection across connections,
Alice's response on connection 2 enables Rogue to impersonate
Storage on connection 1, even though Rogue does not know the
Alice-Storage CHAP secret.Rogue really thought it could just reflect Alice's own answer back at her, but nah 🙅♀️
Note that RADIUS [RFC2865] does not support bi-directional CHAP authentication 🫠 So while a target acting as a RADIUS client will be able to verify the initiator Response, it will not be able to respond to an initiator challenge unless it has access to an appropriate shared secret by some other means. RADIUS said "one direction only, bestie" 💜
2.4.2. SRP
iSCSI implementations MAY implement the SRP authentication method [RFC2945] (see [RFC3720], Section 11.1.3) 🧚 The strength of SRP security depends on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie-German prime (of the form N = 2q + 1, where q is also prime) and the generator g is a primitive root of GF(n) [SRPNDSS]. Math is literally giving main character energy 🤓
SRP well-known groups are included in Appendix A, and additional groups may be registered with IANA 🌈 iSCSI implementations MUST use one of these well-known groups. All the groups specified in Appendix A up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups. Interop is the vibe, so SRP-1536 is always on the menu ✨
2.5. SLPv2 Security
Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer entities and management servers 🔍 SLPv2 may also be used to provide information on peer security configuration. When SLPv2 is deployed, the SA advertisements, as well as UA requests and/or responses, are subject to the following security threats 😬
- [1] An attacker could insert or alter SA advertisements or a response to a UA request in order to masquerade as the real peer or launch a denial of service attack.
- [2] An attacker could gain knowledge about an SA or a UA through snooping, and launch an attack against the peer. Given the potential value of iSCSI targets and FCIP entities, leaking such information not only increases the possibility of an attack over the network; there is also the risk of physical theft. Yikes, that's a whole vibe shift 🚨
- [3] An attacker could spoof a DAAdvert. This could cause UAs and SAs to use a rogue DAs.
To address these threats, the following capabilities are required:
- [a] Service information, as included in
SrvRply,AttrRply,SrvRegandSrvDeregmessages, needs to be kept confidential 🤫 - [b] The UA has to be able to distinguish between legitimate and illegitimate service information from
SrvRplyandAttrRplymessages. In the SLPv2 security model, SAs are trusted to sign data. - [c] The DA has to be able to distinguish between legitimate and illegitimate
SrvRegandSrvDeregmessages. - [d] The UA has to be able to distinguish between legitimate and illegitimate DA Advertisements. This lets the UA avoid rogue DAs that will return incorrect data or no data at all 🙃 In the SLPv2 security model, UAs trust DAs to store, answer queries on, and forward data on services, but not necessarily to originate it.
- [e] SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2 is used. In this case, SAs register with only one DA and trust that this DA will forward the registration to others. Trust falls, but make it a chain 🔗
By itself, SLPv2 security, defined in [RFC2608], does not satisfy these security requirements 💔 SLPv2 only provides end-to-end authentication, but does not support confidentiality. In SLPv2 authentication, there is no way to authenticate "zero result responses". This enables an attacker to mount a denial of service attack by sending UAs a "zero results" SrvRply or AttrRply as if from a DA whose source address corresponds to a legitimate DAAdvert. Unhinged behaviour, honestly 😭
In all cases, there is a potential for denial of service attack against protocol service providers, but such an attack is possible even in the absence of SLPv2-based discovery mechanisms 🛡️
2.5.1. SLPv2 Security Protocol ✨
okay bestie, so the SLPv2 message types are SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, and SAAdvert 💅 SLPv2 says User Agents (UAs) and Service Agents (SAs) have to support SrvRqst, SrvRply, and DAAdvert. SAs must also support SrvReg, SrvAck, and SAAdvert 🫶
When there's no Directory Agent (DA), the SrvRqst gets multicast but the SrvRply comes back via unicast UDP 🦋 DAAdverts are multicast too. Everything else in SLPv2 goes over UDP unicast, so it's giving very organized 💜
To get the security stuff going, iSCSI and FCIP implementations that support SLPv2 security SHOULD protect SLPv2 messages sent via unicast with IPsec ESP using a non-null transform 🔒 SLPv2 authentication blocks (the ones carrying digital signatures, from [RFC2608]) MAY also be used to authenticate both unicast and multicast messages ✨
The iSCSI side of SLPv2 is described in [iSCSISLP]. iSCSI initiators and targets can turn on IKE mechanisms to establish identity 🎀 Then a later user-level iSCSI session login can protect the initiator-target nexus, so even if the SLPv2 discovery process gets compromised, they're still protected 🛡️
The FCIP side is described in [FCIPSLP]. FCIP Entities assume that once a peer's IKE identity is established, the FCIP Entity Name in the FCIP Short Frame is implicitly accepted as that authenticated peer too 🌸 Any link between the IKE identity and the FCIP Entity Name is set up administratively 🍓
Now, when digital signatures are used for authentication in IKE, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to name the certificate authority (or authorities) it trusts, based on its local policy 👑 IKE negotiators SHOULD also check the relevant Certificate Revocation List (CRL) before accepting a PKI certificate for IKE's authentication procedures 🧚 And if key management for SLPv2 DAs has to line up with the SAs, the UAs, and the protocol service implementations, you can use certificate-based key management with a shared root Certificate Authority (CA) 🌈
Why use IPsec to secure SLPv2 at all? Because certificates are more likely to get deployed for IPsec than for SLPv2 😭 That simplifies SLPv2 security, makes interoperable implementations more likely, and, most importantly, makes it more likely that it actually gets used 💖 So it's desirable that very little extra effort is needed to turn on IPsec protection for SLPv2 ✨
BUT (and this is a big but 🙈) a certificate being trusted for IPsec doesn't automatically mean the host is allowed to do SLPv2 operations. When you use IPsec for SLPv2, it can be useful to tell apart the certificates meant for UAs, SAs, and DAs 💅 For example, a UA might be allowed to use any certificate that fits the IKE certificate policy, but an SA's certificate should show it's a legit source of service advertisements, and a DA's certificate should show it's a valid DA 🦋 You can do this with special CAs that only issue certificates for SAs and DAs, or you can use SA and DA authorizations instead 🔥
Say the policy for issuing and handing out SLPv2 authorized certificates to SAs and DAs only covers legit SAs and DAs. Then IPsec does the SLPv2 security like this:
[a] SLPv2 messages sent via unicast are IPsec protected, using ESP with a non-null transform 🔐
[b] SrvRply and AttrRply messages from either a DA or an SA are unicast to UAs. If the SA used a certificate authorized for SLPv2 service advertisement when it set up the IKE Phase 1 SA, or the DA used a certificate authorized for DA usage, the UA can accept the info even if there's no SLPv2 authentication block 🎀
Heads up, though: where SrvRqst messages are multicast, they're not protected 🙀 An attacker could try to spoof a multicast SrvRqst from the UA and get an SA of their choosing to send a SrvRply. Even though that SrvRply is secured, it doesn't match a legit SrvRqst the UA actually sent 💀 To dodge this attack, wherever SrvRqst messages are multicast, the UA MUST check that each SrvRply is a legitimate reply to the SrvRqst that was sent 🚨
[c] SrvReg and SrvDereg messages from an SA are unicast to DAs. If the SA used a certificate authorized for SLPv2 service advertisement when it set up the IKE Phase 1 SA, the DA can accept the de/registration even without an SLPv2 authentication block. Usually the SA checks DA authorization before sending the service advertisement 🌸
[d] Multicast DAAdverts can be treated as advisory 💜 The UA will try to contact DAs via unicast. If the DA used a certificate authorized for SLPv2 DAAdverts when it set up the IKE Phase 1 SA, the UA can accept the DAAdvert even without an SLPv2 authentication block ✨
[e] SAs can accept DAAdverts as described in [d] 🧚
2.5.2. Confidentiality of Service Information 🔐
okay so SLPv2 messages can contain info that reveals the vendor of a device or other stuff about it, which makes revealing service info a real security risk 🙈 For example, the FCIP Entity Name might reveal a WWN, and an attacker could learn useful stuff about the Entity's characteristics from that 👀
The SLPv2 security model assumes service info is public, so it doesn't provide confidentiality. BUT storage devices are mission critical infrastructure with serious value, so iSCSI and FCIP security implementations that support SLPv2 security SHOULD encrypt as well as authenticate and integrity-protect unicast SLPv2 messages 🛡️💜
If every unicast SLPv2 message is IPsec protected with confidentiality, the disclosure risk is basically limited to the multicast SLPv2 messages, which are SrvRqst and DAAdvert 🦋
How much a multicast SrvRqst leaks depends on how detailed the query is 🌈 If leakage worries you, a DA can be provided. If that's not doable, you can send a general query via multicast and then get more detail from the replying entities with extra unicast queries, which are protected by IPsec 💅
Leakage from a multicast DAAdvert matters less than its authenticity 🙌 Knowing a DA is on the network only tells an attacker that SLPv2 is in use, and maybe that a directory service is around too. That info isn't considered very valuable, so it's a lower-stakes vibe 🌸
2.5.3. SLPv2 Security Implications ✨
okay so SLPv2 can totally be used to hand out security settings for IP block storage entities, through the security attributes we defined 🎀. BUT it's not required if the settings can already be figured out another way, like manual config or IPsec security policy distribution 💅. If an entity already got its security config from other mechanisms, then it MUST NOT request security policy via SLPv2. no cap, don't double dip 💀
Where SLPv2 is used to provide security policy info for IP block storage protocols, SLPv2 MUST be protected by IPsec, as described in this document 🔐. Where SLPv2 is not used to distribute security policy info, implementations MAY implement SLPv2 security as described in this document 🌸.
Where SLPv2 is used but security isn't implemented, IP block storage protocol implementations MUST support a negative cache for authentication failures 🙈. This is lowkey essential because it stops implementations from constantly knocking on discovered endpoints that keep failing auth, whether that's inside IPsec or at the application layer (the iSCSI Login case) 🫶. The negative cache doesn't have to live inside the IPsec implementation. It can live in the IP block storage protocol implementation instead 🧚.
Okay, now the messy part 😭. Since this document proposes hop-by-hop security as the primary way to protect SLPv2, UAs have to trust DAs to accurately relay data from SAs. That's a change from the SLPv2 security model in [RFC2608] 👀. And SLPv2 auth as defined in [RFC2608] doesn't give a way to authenticate "zero result responses", so SLPv2 is vulnerable to a denial of service attack. It can be pulled off on a UA by sending it a "zero results" SrvRply or AttrRply from a source address matching a DA that's issuing a legit DAAdvert 💀.
Also, SLPv2 security as defined in [RFC2608] doesn't support confidentiality 🥺. When IPsec with ESP and a non-null transform protects SLPv2, unicast requests and replies can be authenticated AND confidentiality can be provided. That covers unicast requests to DAs and SAs, plus the replies. You can also actively discover SAs using multicast SA discovery, then send unicast requests to the SAs you found ✨.
So for IP block storage protocols, it's believed that IPsec is more appropriate for security than the SLPv2 security model defined in [RFC2608] 🦋.
Using IPsec to secure SLPv2 has performance implications 📊. Security associations between:
- UAs and SAs may be reused (the client on the UA host will use the service on the SA host).
- SAs and DAs may be reused (the SAs will reregister services).
- UAs and DAs will probably not be reused (many idle security associations are likely to result, and build up on the DA).
When IPsec protects SLPv2, it's not necessarily appropriate for every host you can set up an IPsec SA with to be trusted to originate SLPv2 service advertisements 🚫. This is especially true where it's easy to get certificates valid for IPsec (for example, where anyone with network access can get a machine certificate valid for IPsec) 👀. If not all hosts are authorized to originate service advertisements, then you need to tell authorized and unauthorized hosts apart 🎀.
You can do that with the following mechanisms:
[1] Configure SAs with the identities or certificate characteristics of valid DAs, and configure DAs with the identities of SAs allowed to advertise IP block storage services. The DAs are then trusted to enforce policies on service registration. This takes manual configuration, but it avoids certificate customization for SLPv2 🛠️.
[2] Restrict the issuance of certificates valid for SLPv2 service advertisement. While all certificates allowed for IPsec will chain to a trusted root, certificates for hosts authorized to originate service advertisements could be signed by an SLPv2-authorized CA, or could contain explicit SLPv2 authorizations within the certificate. After the IPsec SA is set up between the SLPv2 entities, the SLPv2 implementations can then retrieve the certificates used in the negotiation to figure out whether the entities are authorized for the operations being performed 🔍. This needs less configuration, but it does need some certificate customization for use with SLPv2 💅.
2.6. iSNS Security 🌈
The iSCSI protocol may use iSNS for discovery and management services, while the iFCP protocol is required to use iSNS for those services 🧚. iSNS can also store and distribute security policy and authorization info to iSCSI and iFCP devices 🔐. When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients is subject to these additional security threats 😬:
[1] An attacker can alter iSNS protocol messages, directing iSCSI and iFCP devices to set up connections with rogue devices, or weakening IPsec protection for iSCSI or iFCP traffic 💀.
[2] An attacker can pretend to be the real iSNS server by sending false iSNS heartbeat messages. That could trick iSCSI and iFCP devices into using rogue iSNS servers 🙈.
[3] An attacker can learn about iSCSI and iFCP devices by snooping iSNS protocol messages. That info could help them mount a direct attack on iSCSI and iFCP devices, like a denial-of-service attack or outright physical theft 😱.
To handle these threats, the following capabilities are needed 🛡️:
[a] Unicast iSNS protocol messages may need to be authenticated. And to protect against threat [3] above, confidentiality support is desirable, and REQUIRED when certain iSNS functions are used 🔒.
[b] Multicast iSNS protocol messages, like the iSNS heartbeat message, need to be authenticated. These messages don't need to be confidential, since they don't leak critical info 🫶.
There's no requirement that the identities of iSNS entities be kept confidential. Specifically, the identity and location of the iSNS server don't need to be kept confidential 👑.
To protect against an attacker pretending to be an iSNS server, client devices MUST support authentication of broadcast or multicast messages, like the iSNS heartbeat 🚨. The iSNS authentication block (which is identical in format to the SLP authentication block) MAY be used for this purpose. Note that the authentication block is only used for iSNS broadcast or multicast messages, and SHOULD NOT be used in unicast iSNS messages 🎀.
Since iSNS distributes the authorizations that decide which client devices can communicate, IPsec authentication and data integrity MUST be supported 💜. And if iSNS is used to distribute security policy for iFCP and iSCSI devices, then authentication, data integrity, and confidentiality MUST be supported and used 🔥.
Where iSNS is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures 🙈. This lets implementations avoid constantly contacting discovered endpoints that fail authentication within IPsec or at the application layer (the iSCSI Login case) 🫶. The negative cache doesn't have to live inside the IPsec implementation. It can live in the IP block storage protocol implementation instead 🧚.
2.6.1. Use of iSNS to Discover Security Configuration of Peer Devices 🕵️♀️
In practice, within a single installation, iSCSI and/or iFCP devices may have different security settings 🎭. For example, some devices may be set to initiate secure communication, while others may respond to a request for secure communication without requiring security. Still other devices, while security capable, may neither initiate nor respond securely 😅.
Those config variations can leave devices unable to talk to each other 💔. For example, a device that's configured to always initiate secure communication will have trouble communicating with a device that neither initiates nor responds securely 😬.
The iSNS protocol transfers naming, discovery, and management info between iSCSI devices, iFCP gateways, management stations, and the iSNS server 📡. That includes the ability to discover the security settings used for communication via the iSCSI and/or iFCP protocols ✨.
The iSNS server stores security settings for each iSCSI and iFCP device interface. Authorized hosts can retrieve these settings, which include use or non-use of IPsec, IKE, Main Mode, Aggressive Mode, PFS, Pre-shared Key, and certificates 🗝️.
For example, IKE may not be enabled for a particular device interface. If a peer device can learn this in advance by checking the iSNS server, it won't waste time and resources trying to initiate an IKE Phase 1 SA with that device interface 🙌.
If iSNS is used to distribute security policy, then the minimum info that should be learned from the iSNS server is the use or non-use of IKE and IPsec by each iFCP or iSCSI peer device interface 🔍. This info is encoded in the Security Bitmap field of each Portal of the peer device, and it applies on a per-interface basis for that peer device 🧩. iSNS queries to acquire security configuration data about peer devices MUST be protected by IPsec/ESP authentication 🔐.
2.6.2. Use of iSNS to Distribute iSCSI and iFCP Security Policies 💌
Once communication between iSNS clients and the iSNS server is secured through IPsec, iSNS clients can discover the security settings required for communication via the iSCSI and/or iFCP protocols 🎉. Using iSNS to distribute security policies can cut down on manual device config and lower the chance of communication failures from incompatible security policies 📉. If iSNS is used to distribute security policies, then IPsec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages 🔒.
The complete IKE/IPsec config of each iFCP and/or iSCSI device can be stored in the iSNS server, including the policies used for IKE Phase 1 and Phase 2 negotiations between client devices 🗂️. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the IPsec policy that protects iSCSI or iFCP traffic 🧠.
Note that iSNS distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution 💅. If an entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via iSNS 🚫.
For further details on how to store and retrieve IKE policy proposals in the iSNS server, see [iSNS] 📚✨.
2.6.3. iSNS Interaction with IKE and IPsec
Okay so when IPsec security is turned on, every iSNS client registered in the iSNS database keeps at least one Phase 1 and one Phase 2 security association with the iSNS server 🔐✨. All the iSNS protocol messages between clients and the server are to be protected by a phase-2 security association 💖.
2.6.4. iSNS Server Implementation Requirements
Bestie, this is the checklist for iSNS servers 📋💅. Every iSNS implementation MUST support the replay protection mechanisms of IPsec 🛡️. ESP in tunnel mode MUST be implemented 🎀, and IPsec with ESP in transport mode MAY be implemented 🦋.
To get data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported 🔥. When confidentiality is implemented, 3DES in CBC mode MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported 🌈. DES in CBC mode SHOULD NOT be used due to its inherent weakness 💀. If confidentiality is not required but data origin authentication and integrity is enabled, ESP with NULL Encryption MUST be used 🫶.
Conformant iSNS implementations MUST support IKE for authentication, negotiation of security associations, and key management, using the IPsec DOI, described in [RFC2407] 👑. IP block storage protocols can be expected to send data in high volumes, which means they need rekey ✨. Since manual keying does not provide rekeying support, its use is prohibited with IP block storage protocols 🚫. Although iSNS doesn't send a high volume of data, so rekey isn't a major concern, manual keying SHOULD NOT be used 🙈. This is for consistency, since dynamic keying support is already required in IP storage security implementations 🧚.
Conformant iSNS security implementations MUST support authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures 🎀. Peer authentication using the public key encryption methods outlined in [RFC2409] sections 5.2 and 5.3 SHOULD NOT be used 💅.
Conformant iSNS implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode 🌸. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers uses dynamically assigned IP addresses 🙅. Main Mode with pre-shared key authentication offers good security in many cases, but situations where dynamically assigned addresses are used force a group pre-shared key, which is vulnerable to man-in-the-middle attack 😭.
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used 🦋. In all cases, access to locally stored secret information (pre-shared key or private key for digital signing) MUST be suitably restricted 🔒. Compromise of the secret information nullifies the security properties of the IKE/IPsec protocols, so this part is seriously important 🚨.
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy 📜. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures 🔍✨.
3. iSCSI Security Interoperability Guidelines
These guidelines are set up to meet iSCSI security requirements using IPsec in practical situations 🎀✨.
3.1. iSCSI Security Issues
iSCSI provides iSCSI Login, outlined in [RFC3720], which includes support for application-layer authentication 🔐. This authentication happens logically between the iSCSI initiator and the iSCSI target, not between the TCP/IP communication endpoints 🧚. The whole point of the iSCSI design is that the initiator and target represent the systems (like a host and a disk array or tape system) taking part in the communication, rather than network interfaces or endpoints 💖.
The iSCSI protocol and iSCSI Login authentication do not meet the security requirements for iSCSI 😬. iSCSI Login authentication gives mutual authentication between the iSCSI initiator and target when the connection starts, but it doesn't protect control and data traffic on a per-packet basis, so the iSCSI connection stays open to attack 💀. iSCSI Login authentication can mutually authenticate the initiator to the target, but it doesn't by itself provide per-packet authentication, integrity, confidentiality, or replay protection 🙃. It also doesn't provide for a protected ciphersuite negotiation 🥲. So iSCSI Login is a weak security solution, and we need to be real about that 🫠.
3.2. iSCSI and IPsec Interaction
An iSCSI session [RFC3720], made up of one or more TCP connections, is identified by the 2-tuple of the initiator-defined identifier and the target-defined identifier, <ISID, TSIH> 🌸. Each connection within a given session gets its own unique Connection Identification, CID ✨. The TCP connection is identified by the 5-tuple <Source IP address, Destination IP address, Protocol (TCP), Source Port, Destination Port> 🧩. An IPsec Phase 2 SA is identified by the 3-tuple <Protocol (ESP),destination address, SPI> 🔑.
The iSCSI session and connection info rides inside the iSCSI Login Commands, which go over TCP 📦. Since an iSCSI initiator can have multiple interfaces, iSCSI connections in one session can start from different IP addresses 🌍. Multiple iSCSI targets can also live behind a single IP address, so there can be multiple iSCSI sessions between a given <source IP address, destination IP address> pair 👯.
When multiple iSCSI sessions are active between a given <initiator, target> pair, the set of TCP connections used by one iSCSI session must be disjoint from the ones used by every other iSCSI session between that same pair 🚧. So a TCP connection can be associated with one and only one iSCSI session 💅.
The relationship between iSCSI sessions, TCP connections, and IKE Phase 1 and Phase 2 SAs goes like this 🧠:
[1] An iSCSI initiator or target may have more than one interface, and therefore may have multiple IP addresses. Also, multiple iSCSI initiators and targets may exist behind a single IP address. As a result, an iSCSI Session may correspond to multiple IKE Phase 1 Security Associations, though typically a single IKE Phase 1 security association will exist for an <initiator IP address, target IP address> tuple 🎀.
[2] Each TCP connection within an iSCSI Session is protected by an IKE Phase 2 SA. The selectors may be specific to that TCP connection or may cover multiple connections. While each IKE Phase 2 SA may protect multiple TCP connections, each TCP connection is transported under only one IKE Phase 2 SA 🦋.
Given all this, all the info needed for the iSCSI/IPsec binding lives inside the iSCSI Login messages from the iSCSI initiator and target 📬. That includes the binding between an IKE Phase 1 SA and the matching iSCSI sessions, as well as the binding between a TCP connection, an IKE Phase 2 SA, and the iSCSI connection ID 💖✨.
3.3. Initiating a New iSCSI Session
To create a new iSCSI Session, if an IKE Phase 1 SA doesn't already exist, the initiator implementing iSCSI security sets one up 🚀. Later iSCSI connections in the session will typically be protected by IKE Phase 2 SAs derived from that IKE Phase 1 SA, though additional IKE Phase 1 SAs can also be brought up 🌈.
The initiator and target implementations successfully finish the IKE Phase 1 and Phase 2 negotiations before the iSCSI initiator contacts the target on well-known TCP port 3260 and sends the iSCSI Login command over the TCP connection 🙌. IPsec implementations configured with the correct policies (for example, using ESP with a non-null transform for all traffic going to the iSCSI well-known TCP port 3260) will handle this automatically 🤖✨.
The initiator fills in the ISID field and leaves the TSIH field set to zero, which tells everyone this is the first message of a new session establishment exchange 🌱. The initiator also fills in a CID value, which identifies the TCP connection the Login command is being exchanged over 🔗. When the iSCSI target replies with its Login Command, both iSCSI devices will know the TSIH, and so they'll both know the iSCSI session identifier <ISID, TSIH> 🥳.
A single iSCSI session identifier may have multiple associated IKE Phase 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI session identifiers 🌸. Each iSCSI connection (identified by the connection identifier) corresponds to a single TCP connection (identified by the 5-tuple) 🧩. Each IKE Phase 2 SA is identified by the <Protocol (ESP), destination address, SPI> combination 🔑. A Phase 2 SA may protect multiple TCP connections, and it corresponds to a single IKE Phase 1 SA 💜.
Inside IKE, each key refresh means a new security association has to be established ♻️. In practice there's a time window where both the old, about-to-expire SA and the newly established SA are valid at the same time ⏳. The IPsec implementation chooses which security association to use based on local policy, and iSCSI concerns play no role in that selection 🙅♀️💅.
3.4. Graceful iSCSI Teardown
Mechanisms within iSCSI give both graceful and non-graceful teardown of iSCSI Sessions, or of individual TCP connections within a session 👋. The iSCSI Logout command is used for graceful teardown 🌷. This command lets the iSCSI initiator request that:
[a] the session be closed 🚪
[b] a specific connection within the session be closed 🔌
[c] a specific connection be marked for recovery 🩹
When the iSCSI implementation wants to close a session, it uses the appropriate iSCSI commands to do that 🎬. After exchanging the right iSCSI control messages for session closure, the iSCSI security implementation will typically start a half-close of each TCP connection within the iSCSI session 🫶.
When the iSCSI security implementation wants to close an individual TCP connection while leaving the parent iSCSI session active, it should half-close the TCP connection 🦋. After the TIME_WAIT timeout expires, TIME_WAIT runs out and the TCP connection is closed 🌙✨.
3.5. Non-graceful iSCSI Teardown 💔
Okay so if a TCP connection unexpectedly dies 💀, the iSCSI connection riding on it gets torn down too. There's no rule that an IKE Phase 2 delete has to happen right after the iSCSI connection goes down or right after Phase 1 deletion. An IKE Phase 2 SA can cover multiple TCP connections, so deleting it at that moment might be totally inappropriate 🙅♀️. Same energy here: if IKE gets a Phase 2 Delete for an SA tied to a TCP connection, that does NOT automatically mean the TCP or iSCSI connection is getting torn down 😭.
If a Logout Command/Logout Response sequence marks a connection for removal from the iSCSI session, then once the iSCSI peer has run its teardown process for that connection, the TCP connection gets closed. After that, the iSCSI connection state can be safely removed ✨.
Since one IKE Phase 2 SA can be used by multiple TCP connections, an iSCSI implementation should not depend on receiving the IPsec Phase 2 delete as confirmation that the iSCSI peer finished its teardown process for the connection 🫠.
IPsec acceleration hardware might only be able to handle a limited number of active IKE Phase 2 SAs 🏎️. So Phase 2 delete messages may be sent for idle SAs, as a way to keep the number of active Phase 2 SAs to a minimum.
The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down the corresponding iSCSI connection if no Logout Command/Logout Receive has been executed on the connection. Instead, it's way better to leave the iSCSI connection up, and if more traffic gets sent on it, bring up another IKE Phase 2 SA to protect it 🦋. This avoids the potential for continually bringing iSCSI connections up and down, which is giving chaos 🌀.
3.6. Application-Layer CRC 🧮
iSCSI's error detection and recovery assumes that the TCP and IP checksums give inadequate integrity protection for high-speed communications. As described in [CRCTCP], when operating at high speeds, the 16-bit TCP checksum [RFC793] won't necessarily detect every error, so data corruption is possible. iSCSI [RFC3720] therefore includes a 32-bit CRC to protect its headers and data 💖.
When a CRC check fails (meaning the CRC computed at the receiver doesn't match the received CRC), the iSCSI PDU covered by that CRC gets discarded 🗑️. Since the error presumably wasn't caught by the TCP checksum, TCP retransmission won't happen, so it can't help recover. iSCSI has data and command retry mechanisms for these situations, including SNACK, the ability to reissue R2T commands, and the retry (X) bit for commands 🔁.
IPsec protects against an attacker trying to modify packets in transit, and also against unintentional packet modifications caused by network malfunctions or other errors 🛡️. In general, IPsec authentication transforms give stronger integrity protection than both the 16-bit TCP checksum and the 32-bit application-layer CRC used with iSCSI 💪. Since IPsec integrity protection happens below TCP, if an error is found, the packet is discarded and TCP retransmission happens, so no recovery action is needed at the iSCSI layer 🎀.
3.6.1. Simplification of Recovery Logic 🪄
Where IPsec integrity protection is known to be in place end-to-end between iSCSI endpoints (or the portion that needs extra integrity protection), parts of iSCSI can be simplified 🧹. For example, mechanisms to recover from CRC check failures aren't necessary.
If the iSCSI CRC is negotiated, the recovery logic can be simplified to treat any CRC check failure as fatal. For example, it can generate a CHECK CONDITION on a data error, or close the corresponding TCP connection on a header error. This works because it'll be very rare for errors that IPsec integrity protection missed to get caught by the iSCSI CRC 🙌.
3.6.2. Omission of iSCSI CRC 🙈
In some situations where IPsec is employed, the iSCSI CRC won't add any extra protection and can be left out 🫧.
For example, where IPsec processing, TCP checksum, and iSCSI CRC verification are all offloaded within the NIC, each of these checks gets verified before data crosses the bus. So later errors won't be detected by these mechanisms. As a result, where IPsec processing is offloaded to the NIC, the iSCSI CRC isn't necessary, and implementations may wish not to negotiate it 💅.
However, in other circumstances, the TCP checksum and iSCSI CRC provide additional error coverage, because they're computed and checked at a different point in the protocol stack or in devices different from those that implement the IPsec integrity checks 🧐. That extra coverage of possible errors may make it desirable to negotiate use of the iSCSI CRC even when IPsec integrity protection is in use. Examples of these situations include where:
- [1] IPsec, TCP and iSCSI are implemented purely in software. Here, additional failure modes may be detected by the TCP checksum and/or iSCSI CRC. For example, after the IPsec message integrity check is successfully verified, the segment is copied as part of TCP processing, and a memory error during this process might cause the TCP checksum or iSCSI CRC verification to fail 💻.
- [2] The implementation is an iSCSI-iSCSI proxy or gateway. Here the iSCSI CRC can be propagated from one iSCSI connection to another. In this case, the iSCSI CRC is useful to protect iSCSI data against memory, bus, or software errors within the proxy or gateway, and requesting it is desirable 🌉.
- [3] IPsec is provided by a device external to the actual iSCSI device. Here the iSCSI header and data CRCs can be kept across the part of the connection that isn't protected by IPsec. For instance, the iSCSI connection could traverse an extra bus, interface card, network, interface card, and bus between the iSCSI device and the device providing IPsec. In this case the iSCSI CRC is desirable, and the iSCSI implementation behind the IPsec device may request it 🧚.
Note that if both ends of the connection are on the same segment, traffic is effectively protected by the layer 2 CRC. So negotiating the iSCSI CRC isn't necessary to protect against NIC and network errors, although it may be desirable for other reasons (e.g., [1] and [2] above) ✨.
4. iFCP and FCIP Security Issues 🌈
4.1. iFCP and FCIP Authentication Requirements 🔐
iFCP and FCIP are peer-to-peer protocols. iFCP and FCIP sessions may be initiated by either or both peer gateways. Consequently, bi-directional authentication of peer gateways MUST be provided 🤝.
iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre Channel frames over IP. Therefore, Fibre Channel, operating system, and user identities are transparent to the iFCP and FCIP protocols, meaning those protocols just don't see them 👀.
iFCP gateways use Discovery Domain information obtained from the iSNS server to determine whether the initiating Fibre Channel N_PORT should be allowed access to the target N_PORT 🚪. N_PORT identities used in the Port Login (PLOGI) process will be considered authenticated, provided they're received over a connection whose security complies with the local security policy 🛂.
There is no requirement that the identities used in authentication be kept confidential 🫶.
4.2. iFCP Interaction with IPsec and IKE 🧩
A conformant iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) with a peer iFCP Portal 🤙. A Phase-1 SA may be established when an iFCP Portal is initialized, or it may be deferred until the first TCP connection with security requirements is established ⏳.
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal 🛡️. More specifically, successfully establishing an IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs, fully qualified by the tuple <SPI, destination IP address, ESP>. These SAs protect the setup process of the underlying TCP connections and all their subsequent TCP traffic. Each of the TCP connections protected by an SA is either in the unbound state, or bound to a specific iFCP session 🎯.
In summary, at any point in time:
- [1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals
- [2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs
- [3] Each IKE Phase-2 SA protects 0..Z TCP connections
The creation of an IKE Phase-2 SA may be triggered by security policy rules retrieved from an iSNS server 📥. Alternatively, it may be triggered by policy rules configured through a management interface that reflect iSNS-resident policy rules 🎛️. Likewise, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be driven by security policy rules retrieved from the iSNS server, or set through a management interface 🔑.
If an iFCP implementation makes use of unbound TCP connections, and those connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times, just like bound connections 🔒.
Bestie, on receiving an IKE Phase-2 delete message there's no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. Don't panic-close everything 🙅♀️.
Since an IKE Phase-2 SA may be associated with multiple TCP connections, terminating such connections might in fact be inappropriate and untimely ⏰.
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while 🧹. To minimize the use of SA resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections 💤.
4.3. FCIP Interaction with IPsec and IKE 🦋
FCIP Entities establish tunnels with other FCIP Entities in order to transfer IP-encapsulated FC frames 🚇. Each tunnel is a separate FCIP Link, and it can encapsulate multiple TCP connections. The binding of TCP connections to an FCIP Link is performed using the Fibre Channel World Wide Names (WWNs) of the two FCIP Entities 🏷️.
FCIP Entities may have more than one interface and IP address, and it's possible for an FCIP Link to contain multiple TCP connections whose FCIP endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is typically established for each FCIP endpoint IP Address pair. For the purposes of establishing an IKE Phase 1 SA, static IP addresses are typically used for identification 📍.
Each TCP connection within an FCIP Link corresponds to an IKE Phase 2 (Quick Mode) SA 🎟️. This is established prior to sending the initial TCP SYN packet and applies to the life of the connection. Phase 2 negotiation is also required for rekeying, in order to protect against replay attacks 🔄.
FCIP implementations MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface 🧱.
FCIP Entities do not require any user-level authentication, since all FCIP Entities participate in a machine-level tunnel function 🤖. FCIP uses SLP for discovery, but not to distribute security policies 🙅♀️.
5. Security Considerations 🛡️
5.1. Transport Mode Versus Tunnel Mode ✨
okay so when we're talking block storage protocols, the big differences between IPsec tunnel mode and transport mode are these 💅
- MTU considerations. Tunnel mode adds an extra IP header to every datagram, and that shrinks the path MTU that packets crossing the tunnel get to see 📉 This may lower the maximum segment size of TCP connections running over the tunnel 🫶
- Address assignment and configuration. In tunnel mode you have to configure inner and outer source addresses, and you have to discover inner and outer destination addresses. In transport mode it's way simpler: you only discover one destination address and configure one source address 🌸 Tunnel mode address usage gets more detail below, so stay tuned 🧚
- NAT traversal. As noted in [RFC3715], IPsec tunnel mode ESP can traverse NAT in limited circumstances, but transport mode ESP can't traverse NAT at all 😭 To get NAT traversal working in the general case, you can implement the IPsec NAT traversal functionality described in [RFC3715], [UDPIPsec] and [NATIKE]. The next section has more details 🦋
- Firewall traversal. When a block storage protocol has to cross administrative domains, the firewall admin might want to verify the integrity and authenticity of each packet that transits, instead of poking a hole in the firewall for the block storage protocol 👀 Tunnel mode is perfect for this, since the firewall can terminate the tunnel mode connection while still letting the endpoints talk end-to-end 🔥 If the endpoints want, they can also use IPsec transport mode for end-to-end security, so they can verify the authenticity and integrity of each packet themselves too 💜
Verifying this with IPsec transport mode is way more complicated, though 💀 The firewall would need to terminate the IPsec transport mode connection and act as an iSCSI, iFCP or FCIP gateway or TCP proxy, then originate a brand new IPsec transport mode connection from the firewall to the internal endpoint. That kind of setup can't provide end-to-end authenticity or integrity protection, so an application-layer CRC (for iSCSI) or forwarding of the Fibre Channel frame CRC (for iFCP and FCIP) is necessary to protect against errors introduced by the firewall 🛡️
- IPsec-application integration. When IPsec and the application layer protocol live on the same device or host, you can get really tight integration between them 🤝 The application layer can request and verify that connections are protected by IPsec, and it can grab attributes of the IPsec security association 🎀 In transport mode implementations, IPsec and the application protocol usually sit on the same host, but with tunnel mode they may end up on different hosts. If IPsec is implemented on an external gateway, integration between the application and IPsec is typically not possible, which means the application has less control over and ability to verify IPsec behavior 🙈
5.1.1. IPsec Tunnel Mode Addressing Considerations ✨
ok this part is all about addresses 🧚 IPsec tunnels include both inner and outer source and destination addresses, so there's a lot going on 🫧
When you're using IP block storage protocols, the inner destination address is the address of the IP block storage protocol peer (basically the ultimate destination for the packet) 💖 You can find this inner destination address with SLPv2 or iSNS, or resolve it from an FQDN via DNS, so getting it is typically not a big deal 🌈
The outer destination address is the address of the IPsec security gateway used to reach the peer 🚪 Several mechanisms have been proposed for discovering the IPsec security gateway used to reach a particular peer. [RFC2230] talks about using KX Resource Records (RRs) for IPsec gateway discovery. Here's the tea though: KX RRs are supported by lots of DNS server implementations, but they haven't been widely deployed yet 😬 Another option is DNS SRV [RFC2782], which can be used for this purpose ✨ Wherever DNS is used for gateway location, DNS security mechanisms like DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple Secure Dynamic Update [RFC3007] are advisable 🔐
When you're using IP block storage protocols, the outer source address is configured either statically or dynamically, using mechanisms such as DHCPv4 [RFC2131], DHCPV6 [RFC3315], or stateless address autoconfiguration [RFC2373] 🦋
The inner source address SHOULD be included in the Quick Mode ID payload when the peer establishes a tunnel mode SA with the IPsec security gateway 💜 That's what lets the IPsec security gateway route packets back to the remote peer properly 🪄 The inner source address can be configured through a bunch of different mechanisms, depending on the scenario. If the IP block storage peers are in the same administrative domain, it's typically possible for the inner and outer source addresses to be the same 🥰 This works because the outer source address is presumably assigned from a prefix that belongs to the administrative domain, so it's routable within the domain. As long as the IPsec security gateway knows the inner source address the connecting peer is using and plumbs a host route for it, packets arriving at the gateway destined for that address can be correctly encapsulated and sent down the correct tunnel 🎀
When IP block storage peers are in different administrative domains, the inner source address may need to be assigned by the IPsec security gateway, which effectively "joins" the remote host to the LAN attached to the gateway 🏠 For example, if the remote peer used its assigned (outer) source address as the inner source address, a few problems could pop up:
- Intrusion detection systems sniffing the LAN behind the IPsec security gateway would notice source addresses coming from outside the administrative domain 🚨
- Reply packets might not reach their destination 😱 The IPsec security gateway typically doesn't advertise the default route, only the prefix it allocates addresses from. The remote peer's address doesn't come from a prefix native to the administrative domain, so routers inside the domain probably wouldn't have a route for it. They'd send the packet off to the router advertising the default route (maybe a border router) instead of to the IPsec security gateway 🙃
So for inter-domain use, assigning inner source addresses may be needed 🫶 At the moment this isn't a very common scenario, but if address assignment is provided, then DHCP-based address assignment within IPsec tunnel mode [RFC3456] MUST be supported 📣 Heads up that this mechanism isn't widely deployed within IPsec security gateways yet 😅 Existing IPsec tunnel mode servers typically do this through proprietary extensions to IKE 🧩
5.2. NAT Traversal 🦋
As noted in [RFC3715], tunnel mode ESP can traverse NAT in a limited set of circumstances 🌸 For example, tunnel mode ESP may successfully traverse NATs if there's only one protocol endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the receiver doesn't do source address validation 👀 But ignoring source address validation opens up new security vulnerabilities, and negotiating specific selectors is desirable so you limit the traffic that can be sent down the tunnel 🔒 So these conditions may not necessarily apply, which means tunnel mode NAT traversal won't always be possible 😔
TCP carried within transport mode ESP can't traverse NAT, even though ESP itself doesn't include IP header fields in its message integrity check 💀 Why? The 16-bit TCP checksum is calculated over a "pseudo-header" that includes IP header fields, and the checksum is protected by the IPsec ESP message integrity check 🧐 So a NAT sitting between the two endpoints will invalidate the TCP checksum 💥
TCP checksum calculation and verification is mandatory in both IPv4 and IPv6, so you can't skip checksum verification and still be standards compliant 🙅♀️ To enable traversal of NATs while staying in compliance, iSCSI, iFCP or FCIP security implementations can implement IPsec/IKE NAT traversal, as described in [RFC3715], [UDPIPsec], and [NATIKE] 🌈
The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications let UDP encapsulation of IPsec get negotiated if a NAT is detected in the path 🦋 Once you determine the IP address of the NAT, the TCP checksum can be calculated based on a pseudo-header that includes the NAT-adjusted address and ports 🎀 If you do this before calculating the IPsec message integrity check, TCP checksum verification won't fail 🥳
5.3. IKE Issues 🧩
Sometimes IKE has to be implemented in firmware 🔧 In those situations it's really important to keep the size of the IKE implementation within strict limits 📏 An upper bound on the size of an IKE implementation might be considered to be 800 KB, with 80 KB enabling implementation in a wide range of situations 🌟
As noted in Table 5.3-1 on the next page, IKE implementations that already exist do meet the requirements ✅ So removing seldom used IKE functionality (like the nonce authentication methods) would cut complexity, but implementations typically won't need to do that to fit within the code size budget 💅
5.4. Rekeying Issues 🔄✨
Okay so IP block storage implementations are expected to need to operate at high speed, bestie 🏎️. Implementations running at 1 Gbps are currently in design, and 10 Gbps ones are following shortly after 💨. At those speeds, a single IPsec SA could literally zoom through the whole 32-bit IPsec sequence number space in no time 😭.
Let's do the math, because it's wild 🧮. A single SA running at 1 Gbps line rate and sending 64 octet packets would exhaust the 32-bit sequence number space in 2200 seconds, or 37 minutes. With 1518 octet packets, exhaustion would happen in 14.5 hours. At 10 Gbps, exhaustion would happen in 220 seconds, or 3.67 minutes. With 1518 octet packets, it would happen within 1.45 hours.
In the future, it may be desirable for implementations running at 1 Gbps or greater to implement the IPsec sequence number extension, described in [Seq] 🌸. Note that depending on the transform in use, rekeying might be required before the sequence number space runs out, so keep that in mind 👀.
Now for the CBC drama 🎭. In CBC-mode ciphers, the ciphertext of one block depends on the plaintext of that block and the ciphertext of the previous block. So if two ciphertext blocks are identical, and the plaintext of the next block is also identical, then the ciphertext of that next block will be identical too. Thus, if identical ciphertext blocks can be found with matching subsequent blocks, an attacker can work out whether matching plaintext exists. Honestly, that's so sneaky 🙈.
These "Birthday attacks" were examined by Bellare et. al. in [DESANALY]. On average, a ciphertext block of size n bits is expected to repeat every 2^[n/2] blocks. A single "birthday attack" doesn't give an attacker much info, but multiple such attacks might give them something useful 🕵️♀️. To make that unlikely, it is recommended that a rekey happen before 2^[n/2] blocks have been sent on a given SA 🔑. Bellare et. al. formalized this in [DESANALY], showing that the insecurity of CBC mode increases as O(s^2/2^n), where n is the block size in bits and s is the total number of blocks encrypted. These conclusions do not apply to counter mode 💜.
Here's the IKE code size table, bestie. Look at how tiny some of these are 🥹:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Code size | |
|Implementation | (octets) | Release |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Linux |
| Pluto | 258KB | FreeSWAN |
|(FreeSWAN) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Racoon | 400KB | NetBSD 1.5 |
| (KAME) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Isakmpd | 283KB | NetBSD 1.5 |
| (Erickson) | | x86 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| WindRiver | 142KB | PowerPC |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 222KB | PowerPC |
| VPN1700 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 350K | PowerPC |
| VPN3000 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Cisco | 228KB | MIPS |
| VPN7200 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table 5.3-1 - Code Size for IKE implementations 📋
The formula below sets a limit on how many bytes can be sent on a CBC SA before a rekey is required 🧠:
B = (n/8) * 2^[n/2]
Where:
B = maximum bytes sent on the SA
n = block size in bitsSo this means both the cipher block size and the key length need to be considered in the rekey decision 💅. 3DES uses a block size of n = 64 bits (2^3 bytes), which implies that the SA must be rekeyed before B = (64/8) * (2^32) = 2^35 bytes are sent. At 1 Gbps, that means a rekey will be required every 274.9 seconds (4.6 minutes). At 10 Gbps, a rekey is required every 27.5 seconds 😱.
In terms of the sequence number space, for a 3DES encrypted message of 512 = 2^9 bytes (2^6 blocks), this implies the key has become insecure after about 2^26 messages 💀.
5.5. Transform Issues 💎
Since IP block storage implementations may operate at speeds of 1 Gbps or greater, offering IPsec security services at high speeds is a super big deal 🚀. Supporting multiple algorithms multiplies the complexity and expense of hardware design, so one of the goals of the transform selection effort is to find a minimal set of confidentiality and authentication algorithms that can be implemented in hardware at speeds of up to 10 Gbps, while also being efficient to implement in software at speeds of 100 Mbps or slower 🧩.
In this specification, we mainly focus on IPsec transforms that have already been specified and for which parts are available that can run at 1 Gbps line rate 🎯. Where existing algorithms don't scale gracefully to 10 Gbps, we also consider algorithms whose transform specifications aren't complete yet, but whose parts are expected to be available for products shipping within the next 12 months ⏳. As the state of the art advances, the range of feasible algorithms will broaden, and additional mandatory-to-implement algorithms may be considered 🌈.
Section 5 of [RFC2406] states:
"A compliant ESP implementation MUST support the following
mandatory-to-implement algorithms:
- DES in CBC mode
- HMAC with MD5
- HMAC with SHA-1
- NULL Authentication algorithm
- NULL Encryption algorithm"The DES algorithm is specified in [FIPS46-3]; implementation guidelines are found in [FIPS74], and security issues are discussed in [DESDIFF],[DESINT], [DESCRACK]. The DES IPsec transform is defined in [RFC2405], and the 3DES in CBC mode IPsec transform is specified in [RFC2451] 📚.
The MD5 algorithm is specified in [RFC1321]; HMAC is defined in [RFC2104], and security issues with MD5 are discussed in [MD5Attack]. The HMAC-MD5 IPsec transform is specified in [RFC2403]. The HMAC-SHA1 IPsec transform is specified in [RFC2404] 🔐.
In addition to these existing algorithms, NIST is currently evaluating the following modes [NSPUE2] of AES, defined in [FIPS197] 🧪:
- AES in Electronic Codebook (ECB) confidentiality mode
- AES in Cipher Block Chaining (CBC) confidentiality mode
- AES in Cipher Feedback (CFB) confidentiality mode
- AES in Output Feedback (OFB) confidentiality mode
- AES in Counter (CTR) confidentiality mode
- AES CBC-MAC authentication mode
When utilizing AES modes, it may be necessary to use larger public keys; the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman groups for use with IKE are described in [RFC3526] 🔑.
The Modes [NSPUE2] effort is also considering a number of additional algorithms, including the following:
- PMAC
To provide authentication, integrity, and replay protection, IP block storage security implementations MUST support HMAC-SHA1 [RFC2404] for authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be supported [RFC3566] 🛡️.
HMAC-SHA1 [RFC2404] is to be preferred over HMAC-MD5, due to concerns that have been raised about the security of MD5 [MD5Attack] 🙅♀️. HMAC-SHA1 parts are currently available that run at 1 Gbps, the algorithm is implementable in hardware at speeds up to 10 Gbps, and an IPsec transform specification [RFC2404] exists. As a result, it is most practical to use HMAC-SHA1 as the authentication algorithm for products shipping in the near future 💖. AES in CBC-MAC authentication mode with XCBC extensions was selected because it avoids adding substantial extra code if AES is already being implemented for encryption, and an IPsec transform document is available [RFC3566] ✨.
Some authentication transforms are considerably more efficient to implement than HMAC-SHA1 or AES in CBC-MAC authentication mode. UMAC [UMAC],[UMACKR] is more efficient to implement in software, and PMAC [PMAC] is more efficient to implement in hardware 🏃♀️. PMAC is currently being evaluated as part of the NIST modes effort [NSPUE2], but an IPsec transform doesn't exist yet, and neither does a UMAC transform 🥺.
For confidentiality, the ESP mandatory-to-implement algorithm (DES) is unacceptable 🚫. As noted in [DESCRACK], DES is crackable with modest computation resources, so it's inappropriate for situations that require high levels of security 💀.
To provide confidentiality for iSCSI, iFCP, and FCIP, 3DES in CBC mode [RFC2451] MUST be supported, and AES in Counter Mode [RFC3686] SHOULD be supported 🎀. For use in high-speed implementations, 3DES has significant disadvantages. However, a 3DES IPsec transform has been specified and parts are available that can run at 1 Gbps, so implementing 3DES in products is practical for the short term 🧁.
As described in Appendix B, 3DES software implementations make excessive computational demands at speeds of 100 Mbps or greater, effectively ruling out software-only implementations 🐢. In addition, 3DES implementations require rekeying before the current 32-bit IPsec sequence number space is exhausted, so they wouldn't be able to use sequence space extensions even if those were available 😩. This means 3DES will require very frequent rekeying at speeds of 10 Gbps or faster. Thus, 3DES is inconvenient for very high speeds, as well as being impractical for software implementation at slower speeds (100+ Mbps) 🙄.
5.6. Fragmentation Issues 🧩
Okay so, when certificate authentication is in play, IKE fragmentation can totally happen 😭. That's when you're using certificate chains, or even just one certificate if the key size or other certificate fields (like the distinguished name and other OIDs) are chunky enough 🎀. Lots of NATs and firewalls don't handle fragments properly, so they just drop them on the way in and/or out 💀.
Routers along the path will also often toss fragments after the first one, since those usually don't contain full IP headers they can compare against an Access List 🙈.
So when IKE fragments, the endpoints are often unable to set up an IPsec security association 😭. The fix is to install NAT, firewall or router code that can properly support fragments 💅. If that can't happen, these alternatives can be considered:
- [1] Obtaining certificates by other means.
- [2] Reducing the size of the certificate chain.
- [3] Reducing the size of fields within the certificates. This includes reduction in the key size, the distinguished name or other fields. This should be considered only as a last resort 🫠.
Fragmentation can become a concern when you're prepending IPsec headers to a frame 🥺. One thing that helps is using path MTU discovery 🧚. For example, when TCP is the transport for iSCSI, iFCP or FCIP, path MTU discovery (described in [RFC1191], [RFC1435], [RFC1981]) can help the TCP endpoints figure out the right MTU, including the effects of IPsec encapsulation ✨.
BUT path MTU discovery fails when the right ICMP messages never reach the host 😩. That happens with IPsec implementations that drop unauthenticated ICMP packets, and it can cause blackholing in naive TCP implementations, as described in [RFC2923]. The proper TCP behavior is described in Section 2.1 of [RFC2923]:
"TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet. If this succeeds, it should continue to turn off PMTUD for the connection for some reasonable period of time, after which it should probe again to try to determine if the path has changed."
If an IPsec implementation that processes unauthenticated ICMP packets receives an ICMP PMTU, this value should be stored in the SA as proposed in [RFC2401]. IPsec should also notify TCP of this event so the new MTU value gets reflected correctly 🦋.
5.7. Security Checks 🔐
When a connection is opened that requires security, IP block storage security implementations may want to check that the connection is protected by IPsec 👀. If security is desired and IPsec protection gets removed from a connection, it is reinstated before unprotected IP block storage packets are sent 🛡️. Since IPsec verifies that each packet arrives on the correct SA, as long as IPsec protection is in place, IP block storage implementations can be assured that each received packet was sent by a trusted peer 💜.
When used with IP block storage protocols, each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA 🌊. IP block storage security implementations do not need to verify that the IP addresses and TCP port values in the packet match the socket information used to set up the connection. IPsec does this check, which stops malicious peers from sending commands on inappropriate Quick Mode SAs 🙅♀️.
5.8. Authentication Issues 🎀
5.8.1. Machine Versus User Certificates 🖥️
The certificate credentials the iSCSI initiator provides during IKE negotiation may belong to the machine or to the iSCSI entity 🤓. With machine authentication, the machine certificate is usually stored on the iSCSI initiator and target during an enrollment process. With user certificates, the user certificate can live on the machine or on a smartcard 💳. For iFCP and FCIP, the certificate credentials provided will almost always belong to the device and be stored on the device 🧃.
Since the value of a machine certificate is inversely proportional to how easily an attacker can get one under false pretenses, the machine certificate enrollment process should be strictly controlled 🚨. For example, only administrators may have the ability to enroll a machine with a machine certificate 👑.
Smartcard storage lowers the chance of the private key getting compromised, but smartcards aren't necessarily the move in every situation 🙃. For example, some organizations deploying machine certificates use them to restrict use of non-approved hardware. User authentication can be provided within iSCSI login (keeping in mind the weaknesses described earlier), and support for machine authentication in IPsec makes it possible to authenticate both the machine and the user 🫶. Since iFCP and FCIP have no equivalent of iSCSI Login, only the machine is authenticated for these protocols 🤷♀️.
When this dual assurance is considered valuable, moving the machine certificate from one machine to another may be undesirable. That's the case even though it would be possible if the machine certificate were stored on a smart card 🙅♀️.
Similarly, when user certificates are deployed, the user enrollment process should be strictly controlled 🔒. If, for example, a user password can readily be used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password 😭. To limit an attacker's ability to get a user certificate from a stolen password, the enrollment period can be limited, after which password access gets turned off ⏰. That policy keeps an attacker who gets the password of an unused account from obtaining a user certificate once the enrollment period has expired 💅.
5.8.2. Pre-Shared Keys 🗝️
Okay this one is a big deal, bestie 😭. Using pre-shared keys in IKE Main Mode is vulnerable to man-in-the-middle attacks when used with dynamically addressed hosts (like iSCSI initiators) 👀. In Main Mode, SKEYID_e has to be used before the identification payload is received. So the pre-shared key can only be selected based on information in the IP header. But when dynamic IP address assignment is typical, it's often not possible to identify the required pre-shared key from the IP address 🥴.
So when pre-shared key authentication is used in Main Mode with entities whose addresses are dynamically assigned, the same pre-shared key gets shared by a group and can no longer work as an effective shared secret 💔. In this case, neither the initiator nor the Responder identifies itself during IKE Phase 1. It's only known that both parties are members of the group that knows the pre-shared key 🫥. That means anyone with access to the group pre-shared key can act as a man-in-the-middle 🕵️♀️.
This isn't typically a concern where IP addresses are usually statically assigned (like with iFCP and FCIP), since individual pre-shared keys are possible within IKE Main Mode in that setup 🧘♀️.
However, when IP addresses are dynamically assigned and Main Mode is used with pre-shared keys, the Responder isn't authenticated unless application-layer mutual authentication is performed (for example, iSCSI login authentication) 😱. That lets an attacker holding the group pre-shared key pretend to be the Responder. Besides feeding the target false data, the attacker could also run a dictionary attack on legacy authentication methods like CHAP [RFC1994], potentially compromising lots of passwords at once 💀. This vulnerability is widely present in existing IPsec implementations 🚩.
Group pre-shared keys are not required in Aggressive Mode, since the identity payload is sent earlier in the exchange. That means the pre-shared key can be selected based on the identity 🧠. However, when Aggressive Mode is used, the user identity is exposed, and that's often considered undesirable 🙈.
Care needs to be taken with IKE Phase 1 Identity Payload selection so identities can be mapped to pre-shared keys even with Aggressive Mode 🧩. When the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, identities can't be mapped to keys. So group pre-shared keys are still a practical necessity 😩. As a result, identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or ID_USER_FQDN) SHOULD be employed when Aggressive Mode is used with pre-shared keys and IP addresses are dynamically assigned ✨🫶.
5.8.3. IKE and Application-Layer Authentication ✨
okay so iSCSI has its own authentication methods on top of IKE 💅 Fibre Channel security is being worked on right now, so a similar authentication process may eventually apply to iFCP and FCIP too 🦋
ngl iSCSI does provide initial authentication, but it does NOT do per-packet authentication, integrity or replay protection 💀 which means the identity verified in the iSCSI Login isn't checked again on each packet 🙈
with IPsec, once the identity asserted in IKE is authenticated, the resulting derived keys give you per-packet authentication, integrity and replay protection ✨ so the IKE identity actually gets verified on every packet. iconic 👑
now the drama 😭 let's say the identity claimed in iSCSI Login is a user identity, but the identity claimed within IKE is a machine identity. only the machine identity gets verified per packet, so the recipient has no way to confirm that only the user who logged in through iSCSI is using the IPsec SA 🫣
also, IPsec implementations that only support machine authentication usually have no way to tell apart user traffic inside the kernel 💀 so where machine authentication is used, once an IPsec SA is open, another user on a multi-user machine may be able to send traffic down that SA. this is true for both transport mode and tunnel mode SAs 🙈
bestie, to limit this vulnerability, IP block storage implementations MUST do the following:
- Ensure that socket access is appropriately controlled. on a multi-user operating system, sockets opened for use by IP block storage protocols MUST be exclusive 🔒
- in the case of iSCSI, implementations MUST also ensure that application layer login credentials (such as iSCSI login credentials) are protected from unauthorized access 🗝️
if these directives are followed, then a rogue process will not be able to access an IP block storage volume 🛡️✨
while the identity asserted within IKE is verified on a per-packet basis, operating system support is required to avoid interference between users on a given machine 🌸 to segregate traffic between users when user authentication is supported, the IPsec endpoints must ensure that only traffic from that particular user is sent or received within the IPsec SA. enforcement of this restriction is the responsibility of the operating system 💅
in kernel mode iSCSI drivers there typically is no user context to do user authentication, so the authentication is closer to machine authentication 🧚 on most operating systems, device permissions control who can read and write the device before mounting. once the device is mounted, ACLs set by the filesystem control access to it. an administrator can access the blocks on the device directly (for instance, by sending pass through requests straight to the port driver, like in Windows NT) 👀 and in the same way, an administrator can open a raw socket and send IPsec protected packets to an iSCSI target. the situation is analogous, so no new vulnerability is created that didn't already exist 🙌 the operating system's ACLs need to be effective to protect a device, whether it's a SCSI device or an iSCSI device 🔥
5.8.4. IP Block Storage Authorization 💜
IP block storage protocols can use a variety of mechanisms for authorization 🎀 where ID_FQDN is used as the Identity Payload, IP block storage endpoints can be configured with a list of authorized FQDNs. that config can happen manually, or automatically via iSNS or the iSCSI MIB, defined in [AuthMIB] ✨
assuming IPsec authentication is successful, this list of FQDNs can be examined to determine authorization levels 👑 where certificate authentication is used, it's possible to configure IP block storage protocol endpoints with trusted roots. the trusted roots used with IP block storage protocols might be different from the trusted roots used for other purposes. if that's the case, then the burden of negotiating use of the proper certificates lies with the IPsec initiator 🫶
note that because IKE does not deal well with certificate chains, and is typically configured with a limited set of trusted roots, it is most appropriate for intra-domain usage 🏠
since iSCSI supports Login authentication, it's also possible to use the identities presented within the iSCSI Login for authorization purposes 🦋
in iFCP, basic access control properties come from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. the optional use of discovery domains in iSNS yields access control schemas of greater complexity 🧩
5.9. Use of AES in Counter Mode 🌈
when you're using AES modes, it may be necessary to use larger public keys. the tradeoffs are described in [KeyLen] 📏 additional MODP Diffie-Hellman groups for use with IKE are described in [RFC3526] 💖
when AES in counter mode is used, it is important to avoid reuse of the counter with the same key, even across all time 😭 counter mode creates ciphertext by XORing generated key stream with plaintext. it's fairly easy to recover the plaintext from two messages counter mode encrypted under the same counter value, simply by XORing the two packets together 💀 this means it is an error to use IPsec manual keying with counter mode, except when the implementation takes heroic measures to maintain state across sessions. in any case, manual keying MUST NOT be used, since it does not provide the necessary rekeying support 🚫
another counter mode issue is that it makes forgery of correct packets trivial 🙈 so counter mode should never be used without also using data authentication 🔐
6. IANA Considerations 🌸
this section gives guidance to the Internet Assigned Numbers Authority (IANA) about registering values of the SRP_GROUP key parameter within iSCSI, in accordance with BCP 26, [RFC2434] 📚
IANA considerations for the iSCSI protocol are described in [RFC3720], Section 13. for the iFCP protocol, they're in [iFCP], Section 12, and for the FCIP protocol they're in [FCIP], Appendix B 🧚
6.1. Definition of Terms 💅
the following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration" 🎀
the following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action" ✨
6.2. Recommended Registration Policies 🫶
for registration requests where a Designated Expert should be consulted, the responsible IESG Area Director should appoint the Designated Expert 👑
for registration requests requiring Expert Review, the IPS mailing list should be consulted, or if the IPS WG is disbanded, a mailing list designated by the IESG Area Director 📬
this document defines the following SRP_GROUP keys: SRP-768, SRP-1024, SRP-1280, SRP-1536, SRP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192 🌈
new SRP_GROUP keys MUST conform to the iSCSI extension item-label format described in [RFC3720] Section 13.5.4 🔥
registration of new SRP_GROUP keys is by Designated Expert with Specification Required 🧐 the request is posted to the IPS WG mailing list or its successor for comment and security review, and MUST include a non-probabalistic proof of primality for the proposed SRP group. after a period of one month as passed, the Designated Expert will either approve or deny the registration request 💖
7. Normative References ✨
okay bestie, the normative references are the ones you NEED to have read before this spec makes any sense, so let's go through the whole list 📚💅
[RFC793]Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.[RFC1191]Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.[RFC1435]Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.[RFC1981]McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.[RFC2104]Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2131]Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.[RFC2401]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[RFC2404]Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.[RFC2406]Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.[RFC2407]Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.[RFC2408]Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)," RFC 2408, November 1998.[RFC2409]Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.[RFC2412]Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.[RFC2434]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.[RFC2451]Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.[RFC2608]Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.[RFC2923]Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.[RFC2945]Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.[RFC3315]Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[RFC3456]Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.[RFC3526]Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.[RFC3566]Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use with IPsec", RFC 3566, September 2003.[RFC3643]Weber, R., Rajagopal, M., Trovostino, F., O'Donnel., M, Monia, C.and M. Mehrar, "Fibre Channel (FC) Frame Encapsuation", RFC 3643, December 2003.[RFC3686]Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.[RFC3720]Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.[3DESANSI]American National Standard for Financial Services X9.52-1998, "Triple Data Encryption Algorithm Modes of Operation", American Bankers Association, Washington, D.C., July 29, 1998[SRPNDSS]Wu, T., "The Secure Remote Password Protocol", in Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111
8. Informative References 🌸
these ones are the bonus reading 🤓 not strictly required, but honestly so iconic if you check them out, especially the ones about DES and MD5 because those attacks are wild 💀
[RFC1321]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.[RFC1994]Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.[RFC2230]Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.[RFC2373]Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.[RFC2402]Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998.[RFC2403]Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.[RFC2405]Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.[RFC2535]Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.[RFC2782]Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.[RFC2845]Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.[RFC2865]Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.[RFC2931]Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.[RFC2983]Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.[RFC3007]Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.[RFC3347]Krueger, M. and R. Haagens, "Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations", RFC 3347, July 2002.[RFC3721]Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.[AESPERF]Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions",http://www.counterpane.com/aes-performance.html[AuthMIB]Bakke, M., et al., "Definitions of Managed Objects for iSCSI", Work in Progress, September 2002.[CRCTCP]Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000.[DESANALY]Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", 1997,http://www-cse.ucsd.edu/users/mihir/papers/sym-enc.html[DESCRACK]Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.[DESDIFF]Biham, E., Shamir, A., "Differential Cryptanalysis of DES-like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.[DESINT]Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995[FCIP]Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", Work in Progress, August 2002.[FCIPSLP]Petersen, D., "Finding FCIP Entities Using SLPv2", Work in Progress, September 2002.[FIPS46-3]U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 25, 1999.[FIPS74]U.S. DoC/NIST, "Guidelines for implementing and using the nbs data encryption standard", FIPS 74, Apr 1981.[FIPS197]U.S. DoC/NIST, "Advanced Encryption Standard (AES)", FIPS 197, November 2001,http://csrc.nist.gov/CryptoToolkit/aes[iFCP]Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Work in Progress, August 2002.[RFC3715]Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.[iSCSISLP]Bakke, M., "Finding iSCSI targets and Name Servers Using SLP", Work in Progress, March 2002.[iSNS]Gibbons, K., et al., "iSNS Internet Storage Name Service", Work in Progress, August 2002.[KeyLen]Orman, H., Hoffman, P., "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", Work in Progress, December 2001.[MD5Attack]Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996[NATIKE]Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Work in Progress, June 2002.[NSPUE2]"Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-38A, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, July 2001.[PENTPERF]A. Bosselaers, "Performance of Pentium implementations",http://www.esat.kuleuven.ac.be/~bosselae/[PMAC]Rogaway, P., Black, J., "PMAC: Proposal to NIST for a parallelizable message authentication code",http://csrc.nist.gov/encryption/modes/proposedmodes/pmac/pmac-spec.pdf[Seq]Kent, S., "IP Encapsulating Security Payload (ESP)", Work in Progress, July 2002.[SRPDIST]Wu, T., "SRP Distribution",http://www-cs-students.stanford.edu/~tjw/srp/download.html[UDPIPsec]Huttunen, A., et. al., "UDP Encapsulation of IPsec Packets", Work in Progress, June 2002.[UMAC]Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway, P., "UMAC: Fast and provably secure message authentication", Advances in Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 216-233. Full version available fromhttp://www.cs.ucdavis.edu/~rogaway/umac[UMACKR]Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., Rogaway, P., "UMAC: Message Authentication Code using Universal Hashing", Work in Progress, October 2000. Also available at:http://www.cs.ucdavis.edu/~rogaway/umac/draft-krovetz-umac-01.txt[UMACPERF]Rogaway, P., "UMAC Performance",http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
9. Acknowledgments 🫶
Huge thanks to these legends for helping us figure out this whole problem space 💖: Steve Bellovin of AT&T Research, William Dixon of V6 Security, David Black of EMC, Joseph Tardo and Uri Elzur of Broadcom, Julo Satran, Ted Ts'o, Ofer Biran, and Charles Kunzinger of IBM, Allison Mankin of ISI, Mark Bakke and Steve Senum of Cisco, Erik Guttman of Sun Microsystems, and Howard Herbert of Intel. You all are absolutely iconic 👑✨
Appendix A - Well Known Groups for Use with SRP 🎀
okay so here are the modulus (N) and generator (g) values for a bunch of different modulus lengths 🧚. They come from software Tom Wu and Eugene Jhong made for the Stanford SRP distribution [SRPDIST], and they were rigorously verified to be prime, so no cap, these are legit 💅. Implementations that support SRP authentication MUST support groups up to 1536 bits, and 1536 bits is the default 🔥.
iSCSI Key="SRP-768" [768 bits]
Modulus (base 16) =
B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40
2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF
737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B
Generator = 2
iSCSI Key="SRP-1024" [1024 bits]
Modulus (base 16) =
EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576
D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1
5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC
68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
Generator = 2
iSCSI Key="SRP-1280" [1280 bits]
Modulus (base 16) =
D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4
3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78
6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891
690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163
EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B
Generator = 2
iSCSI Key="SRP-1536" [1536 bits]
Modulus (base 16) =
9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D
5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC
DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC
764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486
65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E
5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB
Generator = 2
iSCSI Key="SRP-2048" [2048 bits]
Modulus (base 16) =
AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050
A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50
E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8
55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B
CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748
544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6
AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6
94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73
Generator = 2Besides those, the following groups MAY be supported too 🌈. Each one has also been rigorously proven to be prime, so they're just as legit ⭐:
- [1]
iSCSI Key="MODP-3072": the 3072-bit [RFC3526] group, generator: 5 - [2]
iSCSI Key="MODP-4096": the 4096-bit [RFC3526] group, generator: 5 - [3]
iSCSI Key="MODP-6144": the 6144-bit [RFC3526] group, generator: 5 - [4]
iSCSI Key="MODP-8192": the 8192-bit [RFC3526] group, generator: 19
Appendix B - Software Performance of IPsec Transforms 📊
Okay bestie, this appendix is all about how fast IPsec encryption and authentication transforms run in software 🤓. Heads up, performance is super implementation dependent, so the numbers here might not match your exact situation. They're here purely for comparison, periodt 💅. If you want more performance data, check out [AESPERF], [PENTPERF] and [UMACPERF] 🦋.
B.1. Authentication Transforms 🔐
Table B-1 shows the cycles/byte needed by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at different packet sizes, all implemented in software 💖.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- |
| Size | PMAC | MAC | UMAC | MD5 | SHA1 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table B-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at various packet sizes.
Source: Jesse Walker, Intel 🌸
Table B-2 shows the cycles/second needed by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in software, assuming a 1500 byte packet 🍓.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B |
| (8 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B |
| (20 octets) | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B |
| (8 octets) | | | | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table B-2: Software performance of the HMAC-SHA1, HMAC-MD5, AES-CBC-MAC and AES-PMAC authentication algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet).
Source: Jesse Walker, Intel 💜
Now the big takeaway, bestie 👀. At 100 Mbps, AES-UMAC is implementable with only a modest processor, and the other algorithms are implementable as long as a single high-speed processor can be dedicated to the task. At 1 Gbps, only AES-UMAC is implementable on a single high-speed processor. Multiple high speed processors (1+ Ghz) will be required for the other algorithms. At 10 Gbps, only AES-UMAC is implementable even with multiple high speed processors, and the other algorithms will need a prodigious number of cycles/second 😭. So at 10 Gbps, hardware acceleration will be required for all algorithms, with the possible exception of AES-UMAC 🔥.
B.2. Encryption and Authentication Transforms ✨
okay so bestie, this part is all about how much CPU work the crypto takes, and it's giving spreadsheet energy 📊💅. Table B-3 shows the cycles/byte for AES-CBC, AES-CTR and 3DES-CBC (no MAC) done in software, across a bunch of packet sizes 🎀.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| Data size | AES-CBC | AES-CTR | 3DES-CBC |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 31.22 | 26.02 | 156.09 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 31.22 | 28.62 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 31.22 | 27.75 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 28.62 | 27.32 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 29.14 | 28.1 | 150.89 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 28.62 | 27.75 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 28.99 | 27.5 | 149.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 28.62 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 28.33 | 27.75 | 147.72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 28.62 | 27.06 | 147.77 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 28.18 | 27.32 | 147.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 28.25 | 27.5 | 147.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 27.97 | 27.32 | 148.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 28.33 | 27.46 | 147.13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 28.1 | 27.58 | 146.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 27.91 | 27.43 | 147.34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 27.97 | 27.53 | 147.85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms at various packet sizes, implemented in software.
Source: Jesse Walker, Intel
Table B-4 is the cycles/second version 🧚. It covers AES-CBC, AES-CTR and 3DES-CBC (no MAC), done in software, at 100 Mbps, 1 Gbps and 10 Gbps line rates (assuming a 1500 byte packet) 🌈.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table B-4: Software performance of the AES-CBC, AES-CTR, and 3DES encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet).
Source: Jesse Walker, Intel
The vibe check here: at 100 Mbps, AES-CBC and AES-CTR are implementable with a high-speed processor, but 3DES would need multiple high speed processors 🔥. At 1 Gbps, multiple high speed processors are required for AES-CBC and AES-CTR mode 💀. And at 1+ Gbps for 3DES, and 10 Gbps for all the algorithms, software is infeasible and hardware acceleration is required 😭. That's a lot of cycles, bestie.
Table B-5 covers the combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB, at various packet sizes, done in software 🦋.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 | 119.67 | 52.03 | 52.03 | 57.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 | 70.24 | 57.23 | 39.02 | 44.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192 | 58.97 | 55.5 | 36.42 | 41.63 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 256 | 57.23 | 55.93 | 35.12 | 40.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 320 | 57.23 | 55.15 | 33.3 | 38.5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 384 | 57.23 | 55.5 | 32.95 | 37.29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 448 | 58.72 | 55 | 32.71 | 37.17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 512 | 58.54 | 55.28 | 32.52 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 576 | 57.81 | 55.5 | 31.8 | 37 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 640 | 57.75 | 55.15 | 31.74 | 36.42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 768 | 57.67 | 55.5 | 31.65 | 35.99 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 896 | 57.61 | 55.75 | 31.22 | 35.68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024 | 57.56 | 55.61 | 31.22 | 35.45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152 | 57.52 | 55.21 | 31.22 | 35.55 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AES | AES | AES | |
| Data size | CBC + | CTR + | CTR + | AES- |
| | CBCMAC | CBCMAC | UMAC | OCB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280 | 57.75 | 55.15 | 31.22 | 36.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408 | 57.47 | 55.34 | 30.75 | 35.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500 | 57.72 | 55.5 | 30.86 | 35.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table B-5: Cycles/byte of combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software.
Table B-6 is the cycles/second for those same four combos (AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB) at 100 Mbps, 1 Gbps and 10 Gbps line rates, assuming 1500 byte packets 🍓.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec |
| Transform | octet | @ | @ | @ |
| | (software) | 100 Mbps | 1 Gbps | 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
|CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| AES | | | | |
| CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| | | | | |
| AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Table B-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms, operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 octet packets.
Source: Jesse Walker, Intel
At speeds of 100 Mbps, the algorithms are implementable on a high speed processor. At speeds of 1 Gbps, multiple high speed processors are required, and none of the algorithms are implementable in software at 10 Gbps line rate 🌸✨.
Authors' Addresses ✈️
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Joshua Tseng
McDATA Corporation
3850 North First Street
San Jose, CA 95134-1702
Phone: +1 650 207 8012
EMail: joshtseng@yahoo.com
Jesse Walker
Intel Corporation
2211 NE 25th Avenue
Hillboro, OR 97124
Phone: +1 503 712 1849
Fax: +1 503 264 4843
EMail: jesse.walker@intel.com
Venkat Rangan
Brocade Communications Systems Inc.
1745 Technology Drive,
San Jose, CA 95110
Phone: +1 408 333 7318
Fax: +1 408 333 7099
EMail: vrangan@brocade.com
Franco Travostino
Director, Content Internetworking Lab
Nortel Networks
3 Federal Street
Billerica, MA 01821
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.comThat's the whole crew, bestie 💜 these are the people who made this happen 🫶.
Full Copyright Statement 💖
Okay bestie, copyright time 📜 Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights. 🎀
This document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀 Legally serious, but you need to know it.
Intellectual Property 🦋
Okay so the IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this document are valid or how far they reach. It also doesn't say whether any license under those rights might or might not be available, and it hasn't done any independent digging to find such rights. 🧐 Info on how rights work for RFC documents is in BCP 78 and BCP 79. 📚
Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses that might be made available, are all over the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for the results of any attempt to get a general license or permission to use those proprietary rights, for implementers or users of this spec. 🔍
The IETF invites anyone who's interested to flag any copyrights, patents, patent applications or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 🫶
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 👑 Thank you, Internet Society, you're literally keeping the lights on for all of us. ✨
📦 where this page comes from
- ietf: rfc3723 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms