IPS Working Group B. Aboba INTERNET-DRAFT Microsoft Category: Standards Track Joshua Tseng Nishan Systems 6 February 2002 Joseph Tardo, Uri Elzur Broadcom Jesse Walker Intel J. Satran, Ofer Biran Charles Kunzinger IBM Venkat Rangan Rhapsody Networks Inc. Franco Travostino Nortel Networks Securing Block Storage Protocols over IP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document discusses how block storage protocols running over IP, including iSCSI, iFCP and FCIP, can utilize IPsec for security. Table of Contents Aboba, et al. Standards Track [Page 1] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 1. Introduction .......................................... 4 1.1 iSCSI overview .................................. 4 1.2 iFCP overview ................................... 5 1.3 FCIP overview ................................... 5 1.4 IPsec overview .................................. 5 1.5 Terminology ..................................... 6 1.6 Requirements language ........................... 7 2. Block storage protocol security ....................... 8 2.1 Security requirements .......................... 8 2.2 Resource constraints ............................ 10 2.3 Security protocol ............................... 12 2.4 SLPv2 security .................................. 14 2.5 iSNS security .................................... 19 3. iSCSI security inter-operability guidelines ........... 23 3.1 iSCSI security issues ........................... 23 3.2 iSCSI and IPsec interaction ..................... 23 3.3 Initiating a new iSCSI session .................. 24 3.4 Graceful iSCSI teardown ......................... 25 3.5 Non-graceful iSCSI teardown ..................... 26 3.6 Application layer CRC ........................... 27 4. iFCP and FCIP security issues ......................... 29 4.1 iFCP and FCIP Authentication Requirements ....... 29 4.2 iFCP Interaction with IPsec and IKE ............. 29 4.3 FCIP Interaction with IPsec and IKE ............. 31 Aboba, et al. Standards Track [Page 2] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 5. Security considerations ............................... 31 5.1 Transport mode versus tunnel mode ............... 31 5.2 NAT traversal ................................... 33 5.3 IKE issues ...................................... 33 5.4 Rekeying issues ................................. 34 5.5 Transform issues ................................ 36 5.6 Fragmentation issues ............................ 38 5.7 Security checks ................................. 39 5.8 Authentication issues ........................... 40 5.9 Use of AES in counter mode ...................... 43 5.10 Use of SRP in iSCSI Authentication .............. 44 6. Normative references .................................. 44 7. Informative references ................................ 46 Appendix A - Well Known Groups for Use with SRP ............. 50 Appendix B - Software Performance of IPsec Transforms ....... 52 B.1 Authentication transforms ....................... 52 B.2 Encryption and Authentication transforms ........ 55 Acknowledgments .............................................. 60 Authors' Addresses ........................................... 61 Intellectual Property Statement .............................. 62 Full Copyright Statement ..................................... 63 Aboba, et al. Standards Track [Page 3] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 1. Introduction This draft proposes use of the IPsec protocol suite for protecting block storage protocols over IP networks, including iSCSI, iFCP and FCIP, and discusses how these protocols should be used with IPsec. 1.1. iSCSI overview iSCSI, described in [iSCSI], is a connection-oriented command/response protocol that runs over TCP, and is used to access disk, tape and other devices. iSCSI is a client-server protocol in which clients (Initiators) open connections to servers (Targets) and perform an iSCSI login. This draft uses the SCSI terms Initiator and Target for clarity and to avoid the common assumption that clients have considerably less computational and memory resources than servers; the reverse is often the case for SCSI, as Targets are commonly dedicated devices of some form. The iSCSI protocol has a text based negotiation mechanism as part of its initial (Login) procedure. The mechanism is extensible in what can be negotiated (new text keys and values can be defined) and also in the number of negotiation rounds (e.g., to accommodate functionality such as challenge-response authentication). While the iSCSI login may include mutual authentication of the iSCSI endpoints and negotiation of session parameters, iSCSI does not define its own per-packet authentication, integrity, confidentiality or replay protection mechanisms. After a successful login, the iSCSI Initiator may issue SCSI commands for execution by the iSCSI Target, which returns a status response for each command, over the same connection. A single connection is used for both command/status messages as well as transfer of data and/or optional command parameters. An iSCSI session may have multiple connections, but a separate login is performed on each. The iSCSI session terminates when its last connection is closed. iSCSI Initiators and Targets are layer 5 entities that are independent of TCP ports and IP addresses. Initiators and Targets have names whose syntax is defined in [iSCSIName]. iSCSI sessions between a given Initiator and Target are run over one or more TCP connections between those entities. That is, the Login process establishes an association between an iSCSI Session and the TCP connection(s) over which iSCSI PDUs will be carried. Aboba, et al. Standards Track [Page 4] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 1.2. iFCP overview iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to Fibre Channel devices over a TCP/IP network. iFCP's primary objective is to allow interconnection and networking of existing Fibre Channel devices at wire speeds over an IP network. The protocol achieves this transparency through a process that allows normal Fibre Channel frame traffic to pass through the gateway directly, with provisions where necessary for intercepting and emulating the fabric services required by a Fibre Channel device. Each IPsec SA established by IKE protects a single TCP connection, which is used to support storage traffic between a unique pair of Fibre Channel N_PORTs. iFCP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. iFCP uses TCP to provide 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. Current specification work intends this for interconnection of Fibre Channel switches over TCP/IP networks, but the protocol is not inherently limited to connecting FC switches. FCIP differs from iFCP in that no interception or emulation of fabric services is involved, and TCP connections are not bound or restricted to specific FC N_Port pairs. FCIP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. FCIP uses TCP to provide congestion control, error detection and error recovery. 1.4. IPsec overview IPsec is a protocol suite which is used to secure communication at the network layer between two peers. The IPsec protocol suite is specified within the IP Security Architecture [RFC2401], IKE [RFC2409], IPsec Authentication Header (AH) [RFC2402] and IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE is the key management protocol while AH and ESP are used to protect IP traffic. An IPsec SA is a one-way security association, uniquely identified by the 3-tuple: SPI, protocol (ESP) and destination IP. The parameters for an IPsec security association are typically established by a key Aboba, et al. Standards Track [Page 5] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 management protocol. These include the encapsulation mode, encapsulation type, session keys and SPI values. IKE is a two phase negotiation protocol based on the modular exchange of messages defined by ISAKMP [RFC2407],[RFC2408]. IKE has two phases, and accomplishes the following functions: [1] Protected cipher suite and options negotiation - using keyed HMACs and encryption and anti-replay mechanisms [2] Master key generation - via MODP Diffie-Hellman calculations [3] Authentication of end-points [4] IPsec SA management (selector negotiation, options negotiation, create, delete, and rekeying) Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is handled in IKE Phase 2. An IKE phase 2 negotiation is performed to establish both an inbound and an outbound IPsec SAs. The traffic to be protected by an IPsec SA is determined by a selector which has been proposed by the IKE Initiator and accepted by the IKE responder. In IPsec transport mode, the IPsec SA selector can be a "filter" or traffic classifier, defined as the 5-tuple: . The successful establishment of a IKE Phase-2 SA results in the creation of two uni- directional IPsec SAs fully qualified by the tuple . The session keys for each IPsec SA are derived from a master key, typically a MODP Diffie-Hellman computation. Rekeying of an existing IPsec SA pair is accomplished by creating two new IPsec SAs, making them active, and then optionally deleting the older IPsec SA pair. Typically the new outbound SA is used immediately, and the old inbound SA is left 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 primarily used to implement Storage Area Networks (SANs). FC is standardized under American National Standard for Information Systems of the National Committee for Information Technology Standards (ANSI-NCITS) in its T11 technical committee. Aboba, et al. Standards Track [Page 6] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 FCIP Fibre Channel over IP (FCIP) is a protocol for interconnecting islands of Fibre Channel SANs over IP Networks so as to 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. 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 used within this document, the term "IP block storage protocol" applies to 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, providing a consolidated information repository for an integrated IP storage network. iFCP requires iSNS for discovery and management, while 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. The iSCSI Initiator 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]. Although the security requirements in this document are already incorporated into the iSCSI [iSCSI], iFCP [iFCP] and FCIP [FCIP] standards track documents, they are reproduced here for convenience. In the event of a discrepancy, the individual protocol standards track documents take precedence. Aboba, et al. Standards Track [Page 7] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 2. Block storage protocol security 2.1. Security requirements IP Block storage protocols such as iSCSI, iFCP and FCIP are used to transmit SCSI commands over IP networks. Therefore, both the control and data packets of these IP block storage protocols are vulnerable to attack. Examples of attacks include: [1] An adversary may attempt to acquire confidential data and identities by snooping data packets. [2] An adversary may attempt to modify packets containing data and control messages. [3] An adversary may attempt to inject packets into an IP block storage connection. [4] An adversary may attempt to hijack TCP connection(s) corresponding to an IP block storage session. [5] An adversary may launch denial of service attacks against IP block storage devices such as by sending a TCP reset. [6] 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. [7] An adversary may attempt to impersonate a legitimate IP block storage entity. [8] 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. Since iFCP and FCIP devices are the last line of defense for a whole Fibre Channel island, the above attacks, if successful, could compromise the security of all the Fibre Channel hosts behind the devices. To address the above threats, IP block storage security protocols MUST provide confidentiality, data origin authentication, integrity, and replay protection on a per-datagram basis. Confidentiality services are important since IP block storage traffic may traverse insecure public networks. The IP block storage security protocols MUST support perfect forward secrecy in the rekeying process. Aboba, et al. Standards Track [Page 8] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Bi-directional authentication of the communication endpoints MUST be provided. There is no requirement that the identities used in authentication be kept confidential (e.g., from a passive eavesdropper). Given current networking technology, IP block storage security solutions must be implementable at 1 Gbps in terms of CPU overhead and/or availability of suitable hardware implementations and should be implementable at 10 Gbps in the near future. 10 Gbps implementations are desirable but are not an absolute requirement as implementation feasibility at these speeds is not yet demonstrated. These performance levels apply to aggregate throughput, and include all TCP connections used between IP block storage endpoints. IP block storage communications typically involve multiple TCP connections. Since each IPsec security association only protects a single TCP connection, it does not necessarily need to support the entire aggregate throughput. Through use of multiple processing engines that independently support individual security associations, implementations may be able to scale to 10 Gbps throughput in the aggregate. Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually 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 be typically be statically assigned in the same manner as most routers and switches. Consequently, support for dynamic IP address assignment, as described in [DHCPIPsec], will typically not be required, although it cannot be ruled out. Such facilities will also be relevant to 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 used depend on the configuration and security policies put in place. For example, configuration will influence the authentication algorithm negotiated within iSCSI Login, as well as the security services (encryption, authentication, integrity, replay protection) and transforms negotiated when IPsec is used to protect IP block storage protocols such as iSCSI, iFCP and FCIP. Aboba, et al. Standards Track [Page 9] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 It must be possible for compliant IP block storage security implementations to administratively disable any and all security mechanisms. FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. For iFCP, the granularity corresponds to a TCP connection (which corresponds to an session). For iSCSI, the granularity of control is typically that of an iSCSI session, although it is possible to exert control down to the granularity of the destination IP address and TCP port. IP block storage protocols can be expected to carry sensitive data and provide access to systems and data that require protection against security threats. SCSI and Fibre Channel currently contain little in the way of security mechanisms, and rely on physical security, administrative security, and correct configuration of the communication medium and systems/devices attached to it for their security properties. For most IP networks, it is 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 inband 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 storage network. The iSNS specification defines mechanisms to secure communication between an iSNS server and its clients. 2.2. Resource constraints iFCP and FCIP devices will typically be embedded systems deployed on racks in air-conditioned data center facilities. Such embedded systems may include hardware chipsets to provide data encryption, authentication, and integrity processing. Therefore, memory and CPU resources are generally not a constraining factor. iSCSI will be implemented on a variety of systems ranging from large servers running general purpose operating systems to embedded host bus adapters (HBAs). Host Bus Adapter 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 Aboba, et al. Standards Track [Page 10] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 TCP, UDP, or IP. In general, a host bus adapter is the most constrained iSCSI implementation environment, although an HBA may draw upon the resources of the system to which it is attached in some cases (e.g., authentication computations required for connection setup). More resources should be available to iSCSI implementations for embedded and general purpose operating systems. The following guidelines indicate the approximate level of resources that 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 implementation of authentication and keying mechanisms is code size, as iSCSI assumes that the computational horsepower to do exponentiations will be available. There is 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 (i.e., 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 will not see a large number of Initiator connections to a single Target or communication endpoint, as each tape drive is dedicated to a single use at a single time, and a dozen tape drives is a large tape device. Aboba, et al. Standards Track [Page 11] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 2.3. Security protocol All IP block storage security compliant implementations MUST support IPsec ESP [RFC2406] to provide security for both control packets and data packets. Conformant IP block storage protocol implementations MUST support ESP in tunnel mode and MUST conform to [RFC2401] requirements for support of ESP in transport mode. It is up to the implementor of an IP block storage protocol to determine whether their IPsec implementation conforms to the [RFC2401] definition of a host or an IPsec security gateway. Section 4.1 of [RFC2401] states: a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. All IP block storage security compliant implementations MUST support the replay protection mechanisms of IPsec. To provide confidentiality with ESP, ESP with 3DES in CBC mode MUST be supported, and AES in Counter mode, as described in [AESCTR], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions [AESCBC] 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. Conformant IP block storage security implementations MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407]. Manual keying MUST NOT be used since it does not provide the necessary rekeying support. Conformant IP block storage security implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used. Conformant IP block storage security implementations MUST support both IKE Main Mode and Aggressive Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. 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, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols. Aboba, et al. Standards Track [Page 12] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 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. The Phase 2 Quick Mode exchanges used to negotiate protection for the TCP connections used by IP block storage protocols MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI [RFC2407] provides for several types of identification data. 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, and MAY support the ID_USER_FQDN Identity Payload. This allows the Phase 2 security association to correspond to specific TCP and IP block storage connections. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD NOT be used. The ID_KEY_ID Identity Payload MUST NOT be used. Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down an IP block storage connection. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down. To support authentication between the iSCSI Initiator and Target, the Secure Remote Password (SRP) protocol described in [RFC2945] MUST be implemented within the iSCSI text-based multi-round negotiation mechanism. A number of additional authentication protocols have also been specified in the current iSCSI draft. Negotiation between Initiator and Target is used to determine which authentication algorithm to use (or whether to use one at all); the connection closes if either side requires authentication and no mutually acceptable algorithm can be agreed upon. One of the goals of this specification is to reduce the need for security policy configuration to a minimum, so as to enable a high level of interoperability. In terms of security policy configuration, the minimum piece of configuration required is whether an IP block storage endpoint requires IPsec or cleartext. This cannot be determined from the IKE conversation alone without risking a long timeout, which is highly undesirable for a disk access protocol. Aboba, et al. Standards Track [Page 13] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 The information can be configured manually or automatically via an IPsec security policy distribution mechanism. Alternatively, it can be supplied via iSNS or SLPv2. If an IP block storage endpoint can obtain its IPsec security policy by other means (manually, or automatically via an IPsec security policy distribution mechanism) then it need not request this information via iSNS or SLPv2. However, if the required security policy configuration is not available via other mechanisms, iSNS or SLPv2 can be used to obtain it. 2.4. SLPv2 Security Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer entities and management servers. 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 of such information not only increases the possibility of an attack over the network; there is also the risk of physical theft. [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, SrvReg and SrvDereg messages, needs to be kept confidential. [b] The UA has to be able to distinguish between legitimate and illegitimate service information from SrvRply and AttrRply messages. In the SLPv2 security model SAs are trusted to sign data. [c] The DA has to be able to distinguish between legitimate and illegitimate SrvReg and SrvDereg messages. [d] The UA has to be able to distinguish between legitimate and illegitimate DA Advertisements. This allows the UA to avoid rogue DAs which 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. Aboba, et al. Standards Track [Page 14] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [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. 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 with whose source address corresponds to a legitimate DAAdvert. 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.4.1. SLPv2 security protocol SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, SAAdvert. SLPv2 requires that UAs and SAs support SrvRqst, SrvRply, and DAAdvert. SAs must additionally support SrvReg, SrvAck, and SAAdvert. Where no DA exists, the SrvRqst is multicast, but the SrvRply is sent via unicast UDP. DAAdverts are also multicast. However, all other SLPv2 messages are sent via UDP unicast. In order to provide the required security functionality, iSCSI and FCIP security implementations SHOULD protect SLPv2 messages sent via unicast using IPsec ESP with a non-null transform. SLPv2 authentication blocks (carrying digital signatures), described in [RFC2608] MAY also be used to authenticate unicast and multicast messages. The usage of SLPv2 by iSCSI is described in [iSCSISLP]. iSCSI Initiators and Targets may enable IKE mechanisms to establish identity. In addition, a subsequent user-level iSCSI session login can protect the Initiator-Target nexus. This will protect them from any compromise of security in the SLPv2 discovery process. The usage of SLPv2 by FCIP is described in [FCIPSLP]. FCIP Entities assume that once the IKE identity of a peer is established, the FCIP Entity Name carried in FCIP Short Frame is also implicitly accepted as the authenticated peer. Any such association between the IKE identity and the FCIP Entity Name is administratively established. For use in securing SLPv2, when digital signatures are used to achieve authentication in IKE, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) Aboba, et al. Standards Track [Page 15] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 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. If key management of SLPv2 DAs needs to be coordinated with the SAs and the UAs as well as the protocol service implementations, one may use certificate based key management, with a shared root CA. One of the reasons for utilizing IPsec for SLPv2 security is that is more likely that certificates will be deployed for IPsec than for SLPv2. This both simplifies SLPv2 security and makes it more likely that it will be implemented interoperably and more importantly, that it will be employed. As a result, it is desirable that little additional effort be required to enable IPsec protection of SLPv2. However, just because a certificate is trusted for use with IPsec does not necessarily imply that the host is authorized to perform SLPv2 operations. When using IPsec to secure SLPv2, it may be desirable to distinguish between certificates appropriate for use by UAs, SAs, and DAs. For example, while a UA might be allowed to use any certificate conforming to IKE certificate policy, the certificate used by an SA might indicate that it is a legitimate source of service advertisements. Similarly, a DA certificate might indicate that it is a valid DA. This can be accomplished by using special CAs to issue certificates valid for use by SAs and DAs; alternatively SA and DA authorizations can be employed. Assume that the policy for issuing and distributing SLPv2 authorized certificates to SAs and DAs limits them only to legitimate SAs and DAs. In this case, IPsec is used to provide SLPv2 security as follows: [f] SLPv2 messages sent via unicast are IPsec protected, using ESP with a non-null transform. [g] SrvRply and AttrRply messages from either a DA or SA are unicast to UAs. Assuming that the SA used a certificate authorized for SLPv2 service advertisement in establishing the the IKE Phase 1 SA, or that the DA used a certificate authorized for DA usage, the UA can accept the information sent, even if it has no SLPv2 authentication block. [h] SrvReg and SrvDereg messages from a SA are unicast to DAs. Assuming that the SA used a certificate authorized for SLPv2 service advertisement in establishing the the IKE Phase 1 SA, the DA can accept the de/registration even if it has no SLPv2 authentication block. Typically, the SA will check the DA authorization prior to sending the service advertisement. Aboba, et al. Standards Track [Page 16] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [i] Multicast DAAdverts can be considered advisory. The UA will attempt to contact DAs via unicast. Assuming that the DA used a certificate authorized for SLPv2 DAAdverts in establishing the the IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no SLPv2 authentication block. [j] SAs can accept DAAdverts as described in i. 2.4.2. Confidentiality of service information Since SLPv2 messages can contain information that can potentially reveal the vendor of the device or its other associated characteristics, revealing service information constitutes a security risk. As an example, the FCIP Entity Name may reveal a WWN from which an attacker can learn potentially useful information about the Entity's characteristics. The SLPv2 security model assumes that service information is public, and therefore does not provide for confidentiality. However, storage devices represent mission critical infrastructure of substantial value, and so iSCSI and FCIP security implementations MUST support confidentiality as well as authentication of unicast SLPv2 messages. Assuming that all unicast SLPv2 messages are protected by IPsec, and that confidentiality is provided, then the risk of disclosure can be limited to SLPv2 messages sent via multicast, namely the SrvRqst and DAAdvert. The information leaked in a multicast SrvRqst depends on the level of detail in the query. If leakage is a concern, then a DA can be provided. If this is not feasible, then a general query can be sent via multicast, and then further detail can be obtained from the replying entities via additional unicast queries, protected by IPsec. Information leakage via a multicast DAAdvert is less of a concern than the authenticity of the message, since knowing that a DA is present on the network only enables an attacker to know that SLPv2 is in use, and possibly that a directory service is also present. This information is not considered very valuable. 2.4.3. SLPv2 security implications Through the definition of security attributes, it is possible to use SLPv2 to distribute information about security settings for IP block storage entities. SLPv2 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 Aboba, et al. Standards Track [Page 17] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 mechanisms, then it MUST NOT request security policy via SLPv2. Where SLPv2 is used to provide security policy information for use with IP block storage protocols, SLPv2 MUST be protected by IPsec as described in this document. Where SLPv2 is not used to distribute security policy information, implementations MAY implement SLPv2 security as described in this document. Where SLPv2 is used, but security is not implemented, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints which fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation. Since this document proposes that hop-by-hop security be used as the primary mechanism to protect SLPv2, UAs have to trust DAs to accurately relay data from SAs. This is a change to the SLPv2 security model described in [RFC2608]. When IPsec is used to protect SLPv2, it is not necessarily appropriate for all hosts with whom an IPsec security association can be established to be trusted to originate SLPv2 service advertisements. This is particularly the case in environments where it is easy to obtain certificates valid for use with IPsec (for example, where anyone with access to the network can obtain a machine certificate valid for use with IPsec). If not all hosts are authorized to originate service advertisements, then it is necessary to distinguish between authorized and unauthorized hosts. This can be accomplished by restricting the issuance of certificates valid for use in SLPv2 service advertisement. For example, while all certificates allowed for use with 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 security association is set up between the SLPv2 entities, the SLPv2 implementations can then retrieve the certificates used in the negotiation in order to determine whether the entities are authorized for the operations that are being performed. Use of IPsec for SLPv2 security has advantages over SLPv2 authentication as defined in [RFC2608], which does not provide a way to authenticate "zero result responses", leaving SLPv2 vulnerable to a denial of service attack. Such an attack can be carried out on a UA by sending it a "zero results" SrvRply or AttrRply, sent from a source address corresponding Aboba, et al. Standards Track [Page 18] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 to a DA issuing a legitimate DAAdvert. When IPsec with ESP and a non-null transform is used to protect SLPv2, not only can unicast requests and replies be authenticated, but confidentiality can also be provided. This includes unicast requests to DAs and SAs as well as replies. It is also possible to actively discover SAs using multicast SA discovery, and then to send unicast requests to the discovered SAs. Using IPsec to secure SLPv2 has performance implications. Security associations established 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). 2.5. iSNS security The iSCSI protocol may use iSNS for discovery and management services, while the iFCP protocol is required to use iSNS for such services. In addition, iSNS can be used to store and distribute security policy to iSCSI and iFCP devices. When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients are subject to the following additional security threats: [1] An attacker can alter iSNS protocol messages, directing iSCSI and iFCP devices to establish connections with rogue devices, or weakening IPsec protection for iSCSI or iFCP traffic. [2] An attacker can masquerade as the real iSNS server by sending false iSNS heartbeat messages. This could could deceive iSCSI and iFCP devices into using rogue iSNS servers. [3] An attacker can gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft. To address these threats, the following capabilities are required: [a] Unicast iSNS protocol messages need to be authenticated and confidential. Aboba, et al. Standards Track [Page 19] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [b] Multicast iSNS protocol messages such as the iSNS heartbeat message need to be authenticated. These messages need not be confidential since they do not leak critical information. There is no requirement that the identities of iSNS entities be kept confidential. Specifically, the identity and location of the iSNS server need not be kept confidential. In order to protect against an attacker masquerading as an iSNS server, client devices MUST be able to authenticate broadcast or multicast messages such as 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 used only for iSNS broadcast or multicast messages, and SHOULD NOT be used in unicast iSNS messages. To address these threats, IP block storage protocols using iSNS for service discovery MAY utilize IPsec for security. Where iSNS is used to distribute security policy, IPsec security MUST be implemented. Where iSNS is used, but security is not implemented, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints which fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation. For protecting unicast iSNS protocol messages, iSNS servers supporting security MUST implement ESP in tunnel mode and MUST conform to [RFC2401] requirements for support of ESP in transport mode. Section 4.1 of [RFC2401] states: a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. All iSNS implementations supporting security MUST support the replay protection mechanisms of IPsec. 2.5.1. Use of iSNS for security policy configuration In practice, within a single installation, iSCSI and/or iFCP devices may have different security settings. For example, some devices may be configured to initiate secure communication, while other devices may be Aboba, et al. Standards Track [Page 20] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 configured to respond to a request for secure communication, but not to require security. Still other devices, while security capable, may neither initiate nor respond securely. In practice, these variations in configuration can result in devices being unable to communicate with each other. For example, a device that is configured to always initiate secure communication will experience difficulties in communicating with a device that neither initiates nor responds securely. The iSNS protocol is used to transfer naming, discovery, and management information between iSCSI devices, iFCP gateways, management stations, and the iSNS server. This includes the ability to enable discovery of security settings used for communication via the iSCSI and/or iFCP protocols. Once communication between iSNS clients and the iSNS server are secured through use of IPsec, iSNS clients have the capability to discover the security settings required for communication via the iSCSI and/or iFCP protocols. Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and decrease the probability of communications failures due to incompatible security policies. The iSNS server stores security settings for each iSCSI and iFCP device interface. These security settings, which can be retrieved by authorized hosts, 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 of this in advance by consulting the iSNS server, it will not need to waste time and resources attempting to initiate an IKE Phase 1 SA with that device interface. 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. If iSNS is used to distribute security policy, then the minimum information 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 information is encoded in the Security Bitmap field of each Portal of the peer device, and is applicable on a per-interface basis for the peer device. iSNS queries to acquire security configuration data about peer devices MUST be protected by IPsec/ESP authentication. Aboba, et al. Standards Track [Page 21] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Additionally, the iSNS server can store policies that are 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 appropriate IPsec policy to use to protect iSCSI or iFCP traffic. For further details on how to store and retrieve IKE policy proposals in the iSNS server, see [iSNS]. 2.5.2. iSNS Interaction with IKE and IPsec When IPsec security is enabled, each iSNS client that is registered in the iSNS database maintains at least one phase 1 and one phase 2 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server are to be protected by a phase- 2 security association. When an iSNS client is removed from the iSNS database, the iSNS server sends an IKE phase 1 delete message to the associated IKE peer, and tears down all IKE phase 1 and phase 2 SAs associated with that iSNS client. 2.5.3. iSNS Server Implementation Requirements To provide confidentiality with ESP, 3DES in CBC mode MUST be supported, and AES in Counter mode, as described in [AESCTR], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions [AESCBC] 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]. Manual keying SHOULD NOT be used since it does not provide the necessary rekeying support. 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 supported. When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and the IKE Main Mode SHOULD NOT be used. 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, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols. Aboba, et al. Standards Track [Page 22] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 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 inter-operability guidelines The following guidelines are established to meet iSCSI security requirements using IPsec in practical situations. 3.1. iSCSI security issues iSCSI provides for iSCSI Login, which includes support for application- layer authentication. This authentication is logically between the iSCSI Initiator and the iSCSI Target (as opposed to between the TCP/IP communication endpoints). The intent of the iSCSI design is that the Initiator and Target represent the systems (e.g., host and disk array or tape system) participating in the communication, as opposed to network communication interfaces or endpoints. The iSCSI protocol, and iSCSI Login authentication do not meet the security requirements for iSCSI. iSCSI Login authentication provides mutual authentication between the iSCSI Initiator and Target at connection origination, but does not protect control and data traffic on a per packet basis, leaving the iSCSI connection vulnerable to attack. iSCSI Login authentication can mutually authenticates the Initiator to the Target, but does not by itself provide per-packet authentication, integrity, confidentiality or replay protection. In addition, iSCSI Login authentication, outlined in [iSCSI], does not provide for a protected ciphersuite negotiation. Therefore, iSCSI Login provides a weak security solution. 3.2. iSCSI and IPsec interaction An iSCSI session [iSCSI], comprised of one or more TCP connections, is identified by the 2-tuple of the Initiator-defined identifier and the Target-defined identifier, . Each connection within a given session is assigned a unique Connection Identification, CID. The TCP connection is identified by the 5-tuple . An IPsec Phase 2 SA is identified by the 3-tuple . The iSCSI session and connection information is carried within the iSCSI Login Commands, transported over TCP. Since an iSCSI Initiator may have multiple interfaces, iSCSI connections within an iSCSI session may be Aboba, et al. Standards Track [Page 23] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 initiated from different IP addresses. Similarly, multiple iSCSI Targets may exist behind a single IP address, so that there may be multiple iSCSI sessions between a given pair. When multiple iSCSI sessions are active between a given pair, the set of TCP connections used by a given iSCSI session must be disjoint from those used by all other iSCSI sessions between the same pair. Therefore 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 is as follows: [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 tuple. [2] Each TCP connection within an iSCSI Session is protected by a separate IKE Phase 2 SA, with selectors specific to that TCP connection. Each IKE Phase 2 SA protects only a single TCP connection, and each TCP connection is transported under only one IKE Phase 2 SA. Given this, all the information needed for the iSCSI/IPsec binding is contained within the iSCSI Login messages from the iSCSI Initiator and Target. This includes the binding between an IKE Phase 1 SA and the corresponding iSCSI sessions, as well as the binding between an IPsec Phase 2 SA and the TCP connection and iSCSI connection ID. 3.3. Initiating a New iSCSI Session In order to create a new iSCSI Session, an Initiator implementing iSCSI security first establishes IKE Phase 1 and Phase 2 SAs, then exchanges iSCSI control messages over an IPsec-secured TCP connection. The iSCSI Initiator contacts the Target on well-known TCP port 3260. Typically, the Initiator and Target implementations successfully complete the IKE phase 1 and Phase 2 negotiations before the initial TCP connection setup messages are exchanged so that these messages can be IPsec protected. IPsec implementations configured with the correct policies (e.g. use ESP with non-null transform for all traffic destined to or originating from the iSCSI well-known TCP port) will handle this automatically. Aboba, et al. Standards Track [Page 24] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Once an IKE Phase 1 SA is established, subsequent iSCSI connections established within the iSCSI session will typically be protected by IKE Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE Phase 1 SAs can also be brought up. Once the IKE Phase 2 negotiations are complete and the TCP connection is established over IPsec, the iSCSI Initiator sends the iSCSI Login command over the TCP connection secured by the recently negotiated Quick Mode SA. The Initiator fills in the ISID field, and leaves the TSID field set to zero, to indicate that it is the first message of a new session establishment exchange. The Initiator also fills in a CID value, that identifies the TCP connection over which the Login command is being exchanged. When the iSCSI Target replies with its Login Command, both iSCSI devices will know the TSID, and therefore the iSCSI session identifier . 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) and IPsec Phase 2 SA. Each IKE Phase 2 SA corresponds to a single IKE Phase 1 SA, and is identified by the combination. Before adding a new TCP connection to an existing iSCSI Session, a new IKE Quick Mode exchange MUST occur, under the protection of an IKE Phase 1 SA. This can be existing IKE Phase 1 SA, or a new IKE Phase 1 SA can be brought up for this purpose. Within IKE, each key refresh requires that a new security association be established. In practice there is a time interval during which an old, about-to-expire SA and newly established SA will both be valid. The IPsec implementation will choose which security association to use based on local policy, and iSCSI concerns play no role in this selection process. 3.4. Graceful iSCSI Teardown Mechanisms within iSCSI provide for both graceful and non-graceful teardown of iSCSI Sessions or individual TCP connections within a given session. The iSCSI Logout command is used to effect graceful teardown. This command allows the iSCSI Initiator to request that: [a] the session be closed Aboba, et al. Standards Track [Page 25] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [b] a specific connection within the session be closed [c] a specific connection be marked for recovery When the iSCSI implementation wishes to close a session, it uses the appropriate iSCSI commands to accomplish this. After exchanging the appropriate iSCSI control messages for session closure, the iSCSI security implementation will typically initiate a half-close of each TCP connection within the iSCSI session. Since a given IKE Phase 1 SA may correspond to multiple iSCSI sessions, the iSCSI implementation will only delete the IKE Phase 1 SAs corresponding to the iSCSI session if there are no remaining iSCSI sessions corresponding to those SAs. For those Phase 1 SAs that are deleted, the iSCSI security implementation will also delete the IKE Phase 2 SAs bound to them first, before deleting the Phase 1 SA. When the iSCSI security implementation wishes to close an individual TCP connection while leaving the parent iSCSI session active, it should half-close the TCP connection. This results in a FIN being sent, putting the TCP connection into the FIN WAIT-1 state, as described in [RFC793]. After the other side responds, the TIME WAIT state is entered. After the expiration of the TIME WAIT timeout, the IKE Phase 2 security association bound to the TCP connection can be closed. Closing the TCP connection prior to deleting the IKE Phase 2 SA ensures that all the TCP packets sent on the connection are IPsec-protected. 3.5. Non-graceful iSCSI Teardown If a given TCP connection unexpectedly fails, the associated iSCSI connection is torn down. Some time after this, the IKE Phase 2 security association will typically be deleted; however, there is no requirement that an IKE Phase 2 delete immediately follow iSCSI connection tear down of Phase 1 deletion. Similarly, if the IKE implementation receives a Phase 2 Delete message for a security association corresponding to a TCP connection, this does not necessarily imply that the TCP or iSCSI connection is to be torn down. If a Logout Command/Logout Response sequence marks a connection for removal from the iSCSI session, then after the iSCSI peer has executed an iSCSI teardown process for the connection, the TCP connection will be closed. The iSCSI connection state can then be safely removed. Since the IKE Phase 2 SA corresponding to the TCP connection may not be immediately deleted and can remain up for some time, iSCSI implementations should not depend on receiving the IPsec Phase 2 delete as confirmation that the iSCSI peer has executed an iSCSI teardown process for the connection. Aboba, et al. Standards Track [Page 26] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD 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. Rather, it is preferable to leave the iSCSI connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing iSCSI connections up and down. 3.6. Application-layer CRC iSCSI's error detection and recovery assumes that the TCP and IP checksums provide inadequate integrity protection for high speed communications. As described in [CRCTCP], when operating at high speeds, the 16-bit TCP checksum [RFC793] will not necessarily detect all errors, resulting in possible data corruption. iSCSI [iSCSI] therefore incorporates a 32-bit CRC to protect its headers and data. When a CRC check fails (i.e. CRC computed at receiver does not match the received CRC), the iSCSI PDU covered by that CRC is discarded. Since presumably the error was not detected by the TCP checksum, TCP retransmission will not occur and thus cannot assist in recovering from the error. iSCSI contains both data and command retry mechanisms to deal with the resulting situations, including SNACK, the ability to reissue R2T commands, and the retry (X) bit for commands. IPsec offers protection against an attacker attempting to modify packets in transit, as well as unintentional packet modifications caused by router malfunctions. In general, IPsec authentication transforms afford stronger integrity protection than both the 16-bit TCP checksum and the 32-bit application-layer CRC that has been proposed for use with iSCSI. Since IPsec integrity protection occurs below TCP, if an error is discovered, then the packet will be discarded and TCP retransmission will occur, so that no recovery action need be taken at the iSCSI layer. 3.6.1. Simplification of recovery logic Where IPsec integrity protection is known to be in place, and covers the entire connection between iSCSI endpoints (or the portion that requires additional integrity connection), portions of iSCSI can be simplified. For example, mechanisms to recover from CRC check failures are not necessary. If the iSCSI CRC is negotiated, the recovery logic can be simplified to regard any CRC check failure as fatal (e.g., generate a SCSI CHECK CONDITION on data error, close the corresponding TCP connection on Aboba, et al. Standards Track [Page 27] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 header error) because it will be very rare for errors undetected by IPsec integrity protection to be detected by the iSCSI CRC. 3.6.2. Omission of iSCSI CRC In some situations where IPsec is employed, the iSCSI CRC will not provide additional protection, and can be omitted. For example, where IPsec processing as well as TCP checksum and iSCSI CRC verification are offloaded within the NIC, each of these checks will be verified prior to transferring data across the bus, so that subsequent errors will not be detected. As a result, where IPsec processing is offloaded to the NIC, the iSCSI CRC is not necessary and the implementations may wish not to negotiate it. However, in other circumstances, the TCP checksum and iSCSI CRC will provide additional protection, and it is desirable to negotiate use of the iSCSI CRC even though IPsec is available. These situations occur 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 is not 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, then traffic will be effectively protected by the layer 2 CRC, so that negotiation of the iSCSI CRC is not necessary. Aboba, et al. Standards Track [Page 28] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 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. In iFCP and FCIP, IP addresses MUST be used as the identities for IKE authentication. 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 that they are 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 iFCP devices may have more than one interface and IP address. For iFCP, multiple TCP connections to other iFCP devices may exist at each interface and IP address. An active iFCP session is supported by one and only one TCP connection. This iFCP session is identified by the 2-tuple of the two communicating N_PORT ID's (3 byte Fibre Channel Port Identifier). A TCP connection is bound to an iFCP session using the CBIND message. Each IP address supporting iFCP communication can establish one or more Phase-1 IKE Security Associations (SA) to other IP addresses configured at peering iFCP gateways, using the IP address as identity. IKE Phase 1 SAs may be established at gateway initialization, or may be brought up when TCP connections matching the IPsec security policy are established. Unlike Phase 1 SAs, a Phase 2 SA maps to an individual TCP connection. Once the phase 2 security association is established, it protects the TCP setup process and all subsequent TCP traffic. Before a new TCP connection to a remote iFCP or device is established, IKE will typically negotiate a phase 2 security association using Quick Mode to protect that new connection. Where the correct IPsec policy is in place, mandating IPsec protection of packets destined to and from the iFCP Aboba, et al. Standards Track [Page 29] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 well-known port, this will occur automatically. iFCP connections protected by the phase 2 SA are either in the unbound state, or are bound to a specific session. The creation of an IKE Phase 2 SA to protect an iFCP connection may be triggered by a policy rule supplied through a management interface, or by N_PORT properties registered with the iSNS. For iFCP, the use of Key Exchange payload in Quick Mode for perfect forward secrecy may be dictated through a management interface, or by N_PORT properties registered with the iSNS. Multiple implementation strategies, are permitted so as to enable establishment of IKE Phase 2 SAs at different times. Examples of implementation strategies include: [1] There exists a unique iFCP security policy for all TCP connections regardless of their bound or unbound state. Thus, an unbound TCP connection can be bound to a session without the need to bring up a new IKE Phase-2 SA. [2] There exist multiple choices of iFCP security policy for unbound TCP connections and active sessions. An unbound TCP connection becomes bound to a session after establishing a new IKE Phase-2 SA matching the new security policy for that N_PORT session. [3] The iFCP implementation does not support TCP connections lingering in an unbound state. Both a IKE Phase-2 SA and a TCP connection need to be started anew anytime a new session is identified. If an iFCP implementation strategy uses unbound TCP connections, then an IKE Phase-2 SA MUST protect each of such unbound connections. iSNS [iSNS] is an invariant in all iFCP deployments. iFCP gateways use iSNS for discovery services, and MAY use security policies configured in the iSNS as the basis for algorithm negotiation in IKE. iFCP implementations MAY administratively disable any and all security mechanisms, on a per basis. This implies that IKE and IPsec security associations may not be established for one or more sessions. A configuration of this type may be accomplished through a management interface, or through attributes set in the iSNS server. 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 can encapsulate multiple TCP connections. The binding of TCP connections to an FCIP Link is performed using the Fibre Channel World Aboba, et al. Standards Track [Page 30] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Wide Names (WWNs) of the two FCIP Entities. FCIP Entities may have more than one interface and IP address, and it is 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 uses an independently negotiated 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. However, SLP is not used to distribute security policies. 5. Security considerations 5.1. Transport mode versus tunnel mode With respect to storage protocols, the major differences between the IPsec tunnel mode and transport mode are as follows: [1] MTU considerations. Tunnel mode introduces an additional IP header into the datagram that reflects itself in a corresponding decrease in the path MTU seen by packets traversing the tunnel. This may result in a decrease in the maximum segment size of TCP connections running over the tunnel. [2] Dynamic address assignment and configuration. Where IP addresses are dynamically assigned (such as with dynamically addressed hosts implementing iSCSI), it is necessary to support address assignment and configuration within IPsec tunnel mode. The use of DHCP within IPsec tunnel mode has been proposed for this, as described in [DHCPIPsec]. However, this mechanism is not yet widely deployed within IPsec security gateways. Existing IPsec tunnel mode servers typically implement the desired functionality via proprietary extensions to IKE. Aboba, et al. Standards Track [Page 31] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [3] NAT traversal. As noted in [IPsecNATReq], IPsec tunnel mode ESP can traverse NAT in limited circumstances, whereas transport mode ESP cannot traverse NAT. To enable NAT traversal in the general case, the IPsec NAT traversal functionality described in [UDPIPsec], [IPsecNATJust], [NATIKE] can be implemented. More details are provided in the next section. [4] Connection-specific selectors. For both transport and tunnel mode, it is possible to negotiate connection-specific selectors, so that only a single iSCSI, iFCP or FCIP connection will be protected by an IKE Phase 2 SA. However, while negotiation of connection- specific selectors is common within IPsec transport mode implementations, IPsec security gateway implementations typically negotiate "ANY to ANY" selectors by default. [5] Firewall traversal. Where a storage protocol is to traverse administrative domains, the firewall administrator may desire to verify the integrity and authenticity of each transiting packet, rather than opening a hole in the firewall for the storage protocol. IPsec tunnel mode lends itself to such verification, since the firewall can terminate the tunnel mode connection while still allowing the endpoints to communicate end-to-end. If desired, the endpoints can in addition utilize IPsec transport mode for end- to-end security, so that they can also verify authenticity and integrity of each packet for themselves. In contrast, carrying out this verification with IPsec transport mode is more complex, since the firewall will need to terminate the IPsec transport mode connection and will need to act as an iSCSI, iFCP or FCIP gateway or TCP proxy, originating a new IPsec transport mode connection from the firewall to the internal endpoint. Such an implementation cannot provide end-to-end authenticity or integrity protection, and an application-layer CRC (iSCSI) or forwarding of the Fibre Channel frame CRC (iFCP and FCIP) is necessary to protect against errors introduced by the firewall. [6] IPsec-application integration. Where IPsec and the application layer protocol are implemented on the same device or host, it is possible to enable tight integration between them. For example, the application layer can request and verify that connections are protected by IPsec, and can obtain attributes of the IPsec security association. While in transport mode implementations the IPsec and application protocol implementations typically reside on the same host, with IPsec tunnel mode, they may reside on different hosts. Where IPsec is implemented on an external gateway, integration between the application and IPsec is typically not possible. This limits the ability of the application to control and verify IPsec Aboba, et al. Standards Track [Page 32] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 behavior. 5.2. NAT traversal As noted in [IPsecNATJust], tunnel mode ESP can traverse NAT in a limited set of circumstances. For example, if there is only one protocol endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the receiver does not perform source address validation, then tunnel mode ESP may successfully traverse NATs. Since ignoring source address validation introduces new security vulnerabilities, and negotiation of specific selectors is desirable so as to limit the traffic that can be sent down the tunnel, these conditions may not necessarily apply, and tunnel mode NAT traversal will not always be possible. Transport mode ESP cannot traverse NAT, even though ESP itself does not include IP header fields within its message integrity check. This is because the 16-bit TCP checksum is calculated based on a "pseudo-header" that includes IP header fields, and the checksum is protected by the IPsec message integrity check. As a result, the TCP checksum will be invalidated by a NAT located between the two endpoints. Since TCP checksum calculation and verification is mandatory in both IPv4 and IPv6, it is not possible to omit checksum verification while remaining standards compliant. In order to enable traversal of NATs existing while remaining in compliance, iSCSI, iFCP or FCIP security implementations can implement IPsec/IKE NAT traversal, as described in [IPsecNATReq], [UDPIPsec], [IPsecNATJust], [NATIKE]. The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications enable UDP encapsulation of IPsec to be negotiated if a NAT is detected in the path. By determining the IP address of the NAT, the TCP checksum can be calculated based on a pseudo-header including the NAT-adjusted address and ports. If this is done prior to calculating the IPsec message integrity check, TCP checksum verification will not fail. 5.3. IKE issues There are situations where it is necessary for IKE to be implemented in firmware. In such situations, it is 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 currently exist which meet the requirements. Therefore, while removal of seldomly used IKE functionality (such as the nonce authentication methods) would reduce complexity, implementations typically will not require this in order to fit within the code size budget. Aboba, et al. Standards Track [Page 33] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 5.4. Rekeying issues It is expected that IP block storage implementations will need to operate at high speed. For example, implementations operating at 1 Gbps are currently in design, with 10 Gbps implementations to follow shortly thereafter. At these speeds, a single IPsec SA could rapidly cycle through the 32-bit IPsec sequence number space. For example, a single SA operating 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 occur in 14.5 hours. At 10 Gbs, exhaustion would occur in 220 seconds or 3.67 minutes. With 1518 octet packets, this would occur within 1.45 hours. In the future, it may be desirable forimplementations operating at speeds of 1 Gbps or greater to implement IPsec sequence number extension, described in [Seq]. Note that depending on the transform in use, it is possible that rekeying will be required prior to exhaustion of the sequence number space. In CBC-mode ciphers the ciphertext of one block depends on the plaintext of that block as well as the ciphertext of the previous block. This implies that if the ciphertext of two blocks are identical, and the plaintext of the next block is also identical, then the ciphertext of the next block will be identical. Thuss, if identical ciphertext blocks can be found with matching subsequent blocks, an attacker can determine the existence of matching plaintext. Such "Birthday attacks" were examined by Bellare et. al. in [DESANALY]. On average, a ciphertext block of size n bits will be expected to repeat every 2^[n/2] blocks. Although a single "birthday attack" does not provide much information to an attacker, multiple such attacks might provide useful information. To make this unlikely, it is recommended that a rekey occur before 2^[n/2] blocks have been sent on a given SA. These conclusions do not apply to counter mode. Bellare et. al. have 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. Aboba, et al. Standards Track [Page 34] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 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 the bytes that 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 bits This means that cipher block size as well as key length need to be considered in the rekey decision. 3DES uses a block size n = 64 bits (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) Aboba, et al. Standards Track [Page 35] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that 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 that 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, the ability to offer IPsec security services at high speeds is of intense concern. Since support for multiple algorithms multiplies the complexity and expense of hardware design, one of the goals of the transform selection effort is to find a minimal set of confidentiality and authentication algorithms implementable in hardware at speeds of up to 10 Gbps, as well as being efficient for implementation in software at speeds of 100 Mbps or slower. In this specification, we primarily concern ourselves with IPsec transforms that have already been specified, and for which parts are available that can run at 1 Gbps line rate. Where existing algorithms do not gracefully scale to 10 Gbps, we further consider algorithms for which transform specifications are not yet complete, but for which parts are expected to be available for inclusion in 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]. Aboba, et al. Standards Track [Page 36] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 The MD5 algorithm is specified in [MD5]; HMAC is defined in [RFC2104] and security issues with MD5 are discussed in [MD5Attack]. The HMAC-MD5 IPsec transform is specified in [HMACMD5IPsec]. 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 [RIJNDAEL],[NISTAES]: 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 The Modes [MODES] 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 [AESCBC]. HMAC-SHA1 [RFC2404] is to be preferred to 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 utilize HMAC-SHA1 as the authentication algorithm for products shipping in the near future. The HMAC-SHA2 algorithm [NISTSHA] is also under development, including an IPsec transform [SHAEXT], so that this may merit consideration in the future. AES in CBC-MAC authentication mode with XCBC extensions was selected since it avoids adding substantial additional code if AES is already being implemented for encryption; an IPsec transform document is available [AESCBC]. Authentication transforms also exist that are considerably more efficient to implement than HMAC-SHA1, HMAC-SHA2 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 [MODES] but an IPsec transform does not yet exist; 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 Aboba, et al. Standards Track [Page 37] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 computation resources, and so is inappropriate for use in situations requiring 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 [AESCTR] 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, 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 prior to exhaustion of the current 32-bit IPsec sequence number space, and thus would not be able to make use of sequence space extensions, if they were available. This means that 3DES will require very frequent rekeying at speeds of 10 Gbps or faster. Thus, 3DES is inconvenient for use at very high speeds, as well as being impractical for implementation in software at slower speeds (100+ Mbps). 5.6. Fragmentation Issues When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even when exchanging a single certificate if the key size, or size of other certificate fields (such as the distinguished name and other OIDs) is large enough. Many Network Address Translators (NATs) and firewalls do not handle fragments properly, dropping them on inbound and/or outbound. Routers in the path will also frequently discard fragments after the intial one, since they typically will not contain full IP headers that can be compared against an Access List. As a result, where IKE fragmentation occurs, the endpoints will often be unable to establish an IPsec security association. The solution to this problem is to install NAT, firewall or router code load that can properly support fragments. If this cannot be done, then the following 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. Aboba, et al. Standards Track [Page 38] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Fragmentation can become a concern when prepending IPsec headers to a frame. One mechanism which can be used to reduce this problem is to utilize path MTU discovery. For example, when TCP is used as the transport for iSCSI, iFCP or FCIP then path MTU discovery, described in [RFC1191], [RFC1435], [RFC1981], can be used to enable the TCP endpoints to discover the correct MTU, including effects due to IPsec encapsulation. However, Path MTU discovery fails when appropriate ICMP messages are not received by the host. This occurs in IPsec implementations which drop unauthenticated ICMP packets. This can result in blackholing in naive TCP implementations, as described in [RFC2923]. Appropriate 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 ICMP PMTU is received by an IPsec implementation that processes unauthenticated ICMP packets, this value should be stored in the SA as proposed in [RFC2401], and IPsec should also provide notification of this event to TCP so that the new MTU value can be correctly reflected. 5.7. Security Checks When a connection is opened which requires security, IP block storage security implementations may wish to check that the connection is protected by IPsec. If security is desired and IPsec protection is removed on a connection, it is reinstated before non-protected IP block storage packets are sent. Since IPsec verifies that each packet arrives on the correct SA, as long as it can be ensured that IPsec protection is in place, then IP block storage implementations can be assured that each received packet was sent by a trusted peer. When used with IP block storage protocols, IPsec MUST negotiate a separate Phase 2 SA for each TCP connection, with selectors specific to the TCP connection. As a result, only traffic for a single TCP connection will flow within each IPsec Phase 2 SA. IP block storage security implementations need not verify that the IP addresses and TCP port values in the packet match the socket information which was used to setup the connection. This check will be performed by IPsec, preventing malicious peers from sending commands on inappropriate Quick Mode SAs. Aboba, et al. Standards Track [Page 39] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 5.8. Authentication issues 5.8.1. Machine versus user certificates The certificate credentials provided by the iSCSI Initiator during the IKE negotiation may be those of the machine or of the iSCSI entity. When machine authentication is used, the machine certificate is typically stored on the iSCSI Initiator and Target during an enrollment process. When user certificates are used, the user certificate can be stored either on the machine or on a smartcard. For iFCP and FCIP, the certificate credentials provided will almost always be those of the device and will be stored on the device. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided within iSCSI Login (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user. Since iFCP and FCIP have no equivalent of iSCSI Login, for these protocols only the machine is authenticated. In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable. Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily 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 the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired. Aboba, et al. Standards Track [Page 40] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 5.8.2. Pre-shared keys Use of pre-shared keys in IKE main mode is vulnerable to man-in-the- middle attacks when used with dynamically addressed hosts (such as with iSCSI Initiators). In main mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, where dynamic IP address assignment is typical, it is often not possible to identify the required pre-shared key based on the IP address. Thus when main mode pre-shared keys are used with iSCSI, iFCP or FCIP entities whose address is dynamically assigned, the same pre-shared key is shared by a group of Initiators and is no longer able to function as an effective shared secret. In this situation, neither the Initiator nor responder identifies itself during IKE phase 1; it is only known that both parties are a member of the group with knowledge of the pre- shared key. This permits anyone with access to the group pre-shared key to act as a man-in-the-middle. This vulnerability is typically not of concern with iFCP and FCIP, since iFCP and FCIP devices typically use statically defined addresses, so that individual pre-shared keys are possible within IKE main mode. As a result, where main mode is used with pre-shared keys and dynamically addressed hosts, unless application-layer mutual authentication is performed (e.g. iSCSI Login), the Responder is not authenticated. This enables a rogue Responder in possession of the group pre-shared key to successfully masquerade as the actual Responder and mount a dictionary attack on legacy authentication methods such as CHAP [RFC1994]. Such an attack could potentially compromise many passwords at a time. This vulnerability is widely present in existing IPsec implementations. As a result, where iSCSI, iFCP, or FCIP Entities utilize dynamic address assignment along with pre-shared key authentication, IKE Agressive Mode MUST be used. Group pre-shared keys are not required in aggressive mode since the identity payload is sent earlier in the exchange, and therefore the pre- shared key can be selected based on the identity. However, when aggressive mode is used the user identity is exposed and this is often considered undesirable. Note that care needs to be taken with Identity Payload selection in order to enable mapping of identities to pre-shared keys even with aggressive mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and address are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are Aboba, et al. Standards Track [Page 41] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 still a practical necessity. As a result, IP block storage protocols MUST support ID_FQDN as well as ID_IPV4_ADDR and ID_IPV6_ADDR (if IPv6 is supported within the protocol stack) and MAY support ID_USER_FQDN. ID_FQDN SHOULD be used in situations where IP addresses are dynamically assigned. 5.8.3. IKE and application-layer authentication In addition to IKE authentication, iSCSI implementations utilize their own authentication methods, such as SRP described in [RFC2945]. Currently, work is underway on Fibre Channel security, so that a similar authentication process may eventually also apply to iFCP and FCIP as well. While iSCSI provides initial authentication, it does not provide per- packet authentication, integrity or replay protection. This implies that the identity verified in the iSCSI Login is not subsequently verified on reception of each packet. With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet. Let us assume that the identity claimed in iSCSI Login is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way for the recipient to verify that only the user authenticated via iSCSI Login is using the IPsec SA. In fact, IPsec implementations that only support machine authentication typically have no way to distinguish between user traffic within the kernel. As a result, where machine authentication is used, once an IPsec SA is opened, another user on a multi-user machine may be able to send traffic down the IPsec SA. To limit the potential vulnerability, iSCSI, iFCP or FCIP security implementations MUST negotiate a separate IPsec Phase 2 SA for each connection, with descriptors specific to that connection. This will prevent traffic for other connections from traveling within the IPsec SA negotiated for another connection. As a result, if access to the TCP socket used for the connection is exclusive, then access to the corresponding IPsec SA will also be exclusive, even if the IPsec implementation only supports machine authentication. While the identity asserted within IKE is verified on a per-packet basis, to avoid interference between users on a given machine, operating Aboba, et al. Standards Track [Page 42] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 system support is required. In order 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 perform user authentication. In this case the authentication is closer to machine authentication. In most operating systems device permissions would control the ability to read/write to the device prior to mounting. Once the device is mounted, ACLs set by the filesystem control access to the device. An administrator can access the blocks on the device directly (for instance, by sending pass through requests to the port driver directly such as in Windows NT). In the same way, an administrator can open raw socket and send IPsec protected packets to an iSCSI Target. The situation is analogous, and in this respect no new vulnerability is created that didn't previously exist. The Operating system's ACLs need to be effective to protect a device (whether it is 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. The configuration can occur manually, or automatically via iSNS or the iSCSI MIB, defined in [AuthMIB]. Assuming that IPsec authentication is successful, this list of FQDNs can be examined to determine authorization levels. Where certificate authentication is used, it is 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 this is 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 is also possible to use the identities presented within the iSCSI Login for authorization purposes. 5.9. Use of AES in counter mode 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 Aboba, et al. Standards Track [Page 43] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 ciphertext by XORing generated key stream with plaintext. It is fairly easy to recover the plaintext from two messages counter mode encrypted under the same counter value, simply by XORing together the two packets. The implication of this is that it is almost always an error to use IPsec manual keying with counter mode, except when the implementation takes heroic measures to maintain state across sessions. Another counter mode issue is it makes forgery of correct packets trivial. Counter mode should therefore never be used without also using data authentication. 5.10. Use of SRP in iSCSI Authentication The strength of SRP security is dependent 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) the generator g is a primitive root of GF(n) [SRPNDSS]. For use in iSCSI authentication, the prime modulus N MUST be at least 768 bits. Upon receiving N and g from the Target, the Initiator MUST verify that they satisfy the above requirements (and abort the connection otherwise). This verification MAY start by trying to match them with a well-known group that satisfies the above requirements. SRP well-known groups are included in Appendix A. 6. Normative references [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in progress), draft-ietf-ips-iSCSI-08.txt, September 2001 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Internet drafts (work in progress), draft-ietf-ips-ifcp-06.txt, October 2001 [FCIP] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", Internet draft (work in progress), draft-ietf-ips- fcovertcpip-06.txt, September 2001 [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M, "Service Location Protocol, Version 2", RFC 2608, June 1999 [iSCSIName] Bakke, M., et.al., "iSCSI Naming and Discovery", draft-ietf- ips-iscsi-name-disc-02.txt, Work in Progress, August 2001 [FCIPSLP] Petersen, D., "Finding FCIP Entities Using SLP", Internet draft (work in progress), draft-ietf-ips-fcip-slp-00.txt, Aboba, et al. Standards Track [Page 44] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 August 2001 [iSCSISLP] Bakke, M., "Finding iSCSI Targets and Name Servers Using SLP", Internet draft (work in progress), draft-ietf-ips-iscsi- slp-01.txt, July 2001 [iSNS] Gibbons, K., et al., "iSNS Internet Storage Name Service", Internet draft (work in progress), draft-ietf-ips-isns-05.txt, November 2001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [RFC2406] Kent,S., Atkinson, R., "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., Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, November 1998 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981 [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 [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 Aboba, et al. Standards Track [Page 45] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [RFC2923] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923, September 2000 [NISTAES] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", U.S. DoC/NIST, summer 2001 [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 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [RFC2451] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998 [AESCBC] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm and Its Use with IPsec", Internet draft (work in progress), draft-ietf-ipsec-ciph-aes-cbc-01.txt, May 2001 [AESCTR] Walker, J., Moskowitz, R., "The AES128 CTR Mode of Operation and Its Use with IPsec", Internet draft (work in progress), draft-moskowitz-aes128-ctr-00.txt, September 2001 [RFC2404] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998 [DHCPIPsec] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 Configuration of IPsec Tunnel Mode", Internet draft (work in progress), draft-ietf-ipsec-dhcp-13.txt, June 2001 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System," RFC 2945, September 2000 7. Informative references [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998 [AuthMIB] Bakke, M., et al., "Definitions of Managed Objects for iSCSI", Internet draft (work in progress), draft-ietf-ips-iscsi- mib-03.txt, October 2001. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992 Aboba, et al. Standards Track [Page 46] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996 [CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000 [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000 [iSCSIREQ] Krueger, M., et.al., "iSCSI Requirements and Design Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in Progress, July 2001 [IPsecNatReq] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-ietf- ipsec-nat-reqts-00.txt, Work in Progress, June 2001 [UDPIPsec] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", draft-ietf-ipsec-udp-encaps-01.txt, October 2001 [Seq] Kent, S., "IP Encapsulating Security Payload (ESP)", Internet draft (work in progress), draft-ietf-ipsec-esp-v3-01.txt, November 2002 [IPsecNATJust] Dixon, W. et. al., "IPsec over NAT Justification for UDP Encapsulation", draft-ietf-ipsec-udp-encaps- justification-00.txt, June 2001 [NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Internet draft (work in progress), draft-ietf-ipsec-nat- t-ike-01.txt, October 2001 [HMACMD5IPsec] Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998 [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 [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. Aboba, et al. Standards Track [Page 47] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 216-233. Full version available from http://www.cs.ucdavis.edu/~rogaway/umac [NISTSHA] "Descriptions of SHA-256, SHA-384, and SHA-512," http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf [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 [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- like cryptosystems", Journal of Cryptology Vol 4, Jan 1991 [RFC2405] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998 [RIJNDAEL] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES Proposal, June 1998 http://csrc.nist.gov/encryption/aes/round2/ AESAlgs/Rijndael/Rijndael.pdf [MODES] "Symmetric Key Block Cipher Modes of Operation," http://www.nist.gov/modes [NSPUE2] "Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, July 2001 [AESOCB] Moskowitz, R., Walker, J., "The AES128 OCB Mode of Operation and Its Use with IPsec", Internet draft (work in progress), draft-moskowitz-aes128-ocb-00.txt, September 2001 [CTR-MODE] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", Comment on mode of operations NIST, Jan 2001 [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 [PENTPERF] A. Bosselaers, "Performance of Pentium implementations", http://www.esat.kuleuven.ac.be/~bosselae/ Aboba, et al. Standards Track [Page 48] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [UMACPERF] Rogaway, P., "UMAC Performance", http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995 [UMACKR] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., Rogaway, P., "UMAC: Message Authentication Code using Universal Hashing", Internet draft (work in progress), draft- krovetz-umac-01.txt, October 2000. Also available at: http://www.cs.ucdavis.edu/~rogaway/umac/draft-krovetz- umac-01.txt [RFC1994] Simpson, W.,"PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996. [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/ [SRPDIST] Wu, T., "SRP Distribution", http://www-cs- students.stanford.edu/~tjw/srp/download.html [SHAEXT] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and SHA-512 within ESP, AH and IKE," Work in progress Aboba, et al. Standards Track [Page 49] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Appendix A - Well Known Groups for Use with SRP Modulus (N) and generator (g) values for various modulus lengths are given below. The values below are taken from software developed by Tom Wu and Eugene Jhong for the Stanford SRP distribution [SRPDIST]: [768 bits] Modulus (base 16) = B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B Generator = 2 [1024 bits] Modulus (base 16) = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 Generator = 2 [1280 bits] Modulus (base 16) = D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B Generator = 2 [1536 bits] Modulus (base 16) = 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB Generator = 2 Aboba, et al. Standards Track [Page 50] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 [2048 bits] Modulus (base 16) = AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 Generator = 2 In addition the Oakley Group 1 (768 bit prime) and Group 2 (1024 bit prime) defined in [RFC2412] Section E MAY be used. Aboba, et al. Standards Track [Page 51] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Appendix B - Software Performance of IPsec Transforms This Appendix provides data on the performance of IPsec encryption and authentication transforms in software. Since the performance of IPsec transforms is heavily implementation dependent, the data presented here may not be representative of performance in a given situation, and are presented solely for purposes of comparison. Other performance data is available in [AESPERF],[PENTPERF] and [UMACPERF]. B.1 Authentication transforms Table B-1 presents the cycles/byte required by the AES-PMAC, AES-CBC- MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet sizes, 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba, et al. Standards Track [Page 52] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | | Size | PMAC | MAC | UMAC | MD5 | SHA1 | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Aboba, et al. Standards Track [Page 53] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Table B-2 presents the cycles/second required 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 At speeds of 100 Mbps, AES-UMAC is implementable with only a modest processor, and the other algorithms are implementable, assuming that 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; the other algorithms will require a prodigious number of cycles/second. Thus at 10 Gbps, hardware acceleration will be required for all algorithms with the possible exception of AES-UMAC. Aboba, et al. Standards Track [Page 54] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 B.2 Encryption and Authentication transforms Table B-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, for various 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba, et al. Standards Track [Page 55] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Data size | AES-CBC | AES-CTR | 3DES-CBC | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Aboba, et al. Standards Track [Page 56] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Table B-4 presents the cycles/second required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented 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 At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a high-speed processor, while 3DES would require multiple high speed processors. At speeds of 1 Gbps, multiple high speed processors are required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, and 10 Gbps for all algorithms, implementation in software is infeasible, and hardware acceleration is required. Aboba, et al. Standards Track [Page 57] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Table B-5 presents the cycles/byte required for combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba, et al. Standards Track [Page 58] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AES | AES | AES | | | Data size | CBC + | CTR + | CTR + | AES- | | | CBCMAC | CBCMAC | UMAC | OCB | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. Aboba, et al. Standards Track [Page 59] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Table B-6 presents the 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 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. Acknowledgments Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft, David Black of EMC, Mark Bakke and Steve Senum of Cisco, Erik Guttman of Sun Microsystems and Howard Herbert of Intel for useful discussions of Aboba, et al. Standards Track [Page 60] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 this problem space. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 706 6605 Fax: +1 425 706 7329 EMail: bernarda@microsoft.com Joshua Tseng Nishan Systems 3850 North First Street San Jose, CA 95134-1702 Phone: +1 408 519 3749 EMail: jtseng@nishansystems.com Joseph J. Tardo Broadcom 3151 Zanker Road San Jose, CA 95134 Phone: +1 408 501 8445 Fax: +1 408 501 8460 EMail: jtardo@broadcom.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 Julian Satran IBM, Haifa Research Lab MATAM - Advanced Technology Center Haifa 31905, Israel Phone +972 4 829 6264 EMail: Julian_Satran@vnet.ibm.com Aboba, et al. Standards Track [Page 61] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 Ofer Biran IBM, Haifa Research Lab MATAM - Advanced Technology Center Haifa 31905, Israel Phone +972 4 829 6253 Email: biran@il.ibm.com Charles Kunzinger IBM Corporation Research Triangle Park, NC 27709 Phone: +1 919 254 4142 EMail: kunzinge@us.ibm.com Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont, CA 94538 Phone: +1 510 743 3018 Fax: +1 510 687 0136 EMail: venkat@rhapsodynetworks.com Franco Travostino Director, Content Internetworking Lab Nortel Networks 3 Federal Street Billerica, MA 01821 Phone: +1 978 288 7708 EMail: travos@nortelnetworks.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Aboba, et al. Standards Track [Page 62] INTERNET-DRAFT Securing IP Block Storage Protocols 6 February 2002 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Expiration Date This memo is filed as , and expires July 22, 2002. Aboba, et al. Standards Track [Page 63]