GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc3723

Network Working Group B. Aboba Request for Comments: 3723 Microsoft Category: Standards Track J. Tseng

                                                    McDATA Corporation
                                                             J. Walker
                                                                 Intel
                                                             V. Rangan
                                   Brocade Communications Systems Inc.
                                                         F. Travostino
                                                       Nortel Networks
                                                            April 2004
              Securing Block Storage Protocols over IP

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

 This document discusses how to secure block storage and storage
 discovery protocols running over IP (Internet Protocol) using IPsec
 and IKE (Internet Key Exchange).  Threat models and security
 protocols are developed for iSCSI (Internet Protocol Small Computer
 System Interface), iFCP (Internet Fibre Channel Storage Networking)
 and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet
 Storage Name Server) and SLPv2 (Service Location Protocol v2)
 discovery protocols.  Performance issues and resource constraints are
 analyzed.

Table of Contents

 1.  Introduction .................................................  3
     1.1.  iSCSI Overview .........................................  3
     1.2.  iFCP Overview ..........................................  4
     1.3.  FCIP Overview ..........................................  4
     1.4.  IPsec Overview .........................................  4
     1.5.  Terminology ............................................  6
     1.6.  Requirements Language ..................................  7

Aboba, et al. Standards Track [Page 1] RFC 3723 Securing Block Storage Protocols over IP April 2004

 2.  Block Storage Protocol Security ..............................  7
     2.1.  Security Requirements  .................................  7
     2.2.  Resource Constraints ................................... 10
     2.3.  Security Protocol ...................................... 12
     2.4.  iSCSI Authentication ................................... 16
     2.5.  SLPv2 Security ......................................... 18
     2.6.  iSNS Security .......................................... 24
 3.  iSCSI security Inter-Operability Guidelines .................. 28
     3.1.  iSCSI Security Issues .................................. 28
     3.2.  iSCSI and IPsec Interaction ............................ 29
     3.3.  Initiating a New iSCSI Session ......................... 30
     3.4.  Graceful iSCSI Teardown ................................ 31
     3.5.  Non-graceful iSCSI Teardown ............................ 31
     3.6.  Application Layer CRC .................................. 32
 4.  iFCP and FCIP Security Issues ................................ 34
     4.1.  iFCP and FCIP Authentication Requirements .............. 34
     4.2.  iFCP Interaction with IPsec and IKE .................... 34
     4.3.  FCIP Interaction with IPsec and IKE .................... 35
 5.  Security Considerations ...................................... 36
     5.1.  Transport Mode Versus Tunnel Mode ...................... 36
     5.2.  NAT Traversal .......................................... 39
     5.3.  IKE Issues ............................................. 40
     5.4.  Rekeying Issues ........................................ 40
     5.5.  Transform Issues ....................................... 43
     5.6.  Fragmentation Issues ................................... 45
     5.7.  Security Checks ........................................ 46
     5.8.  Authentication Issues .................................. 47
     5.9.  Use of AES in Counter Mode ............................. 51
 6.  IANA Considerations .......................................... 51
     6.1.  Definition of Terms .................................... 52
     6.2.  Recommended Registration Policies ...................... 52
 7.  Normative References ......................................... 52
 8.  Informative References ....................................... 54
 9.  Acknowledgments .............................................. 58
 Appendix A - Well Known Groups for Use with SRP  ................. 59
 Appendix B - Software Performance of IPsec Transforms  ........... 61
     B.1.  Authentication Transforms .............................. 61
     B.2.  Encryption and Authentication Transforms ............... 64
 Authors' Addresses ............................................... 69
 Full Copyright Statement ......................................... 70

Aboba, et al. Standards Track [Page 2] RFC 3723 Securing Block Storage Protocols over IP April 2004

1. Introduction

 This specification discusses use of the IPsec protocol suite for
 protecting block storage protocols over IP networks (including iSCSI,
 iFCP and FCIP), as well as storage discovery protocols (iSNS and
 SLPv2).

1.1. iSCSI Overview

 iSCSI, described in [RFC3720], 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 document 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).
 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 application layer entities that are
 independent of TCP ports and IP addresses.  Initiators and targets
 have names whose syntax is defined in [RFC3721].  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.
 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.  Rather, it relies upon the IPsec
 protocol suite to provide per-packet data confidentiality and

Aboba, et al. Standards Track [Page 3] RFC 3723 Securing Block Storage Protocols over IP April 2004

 integrity and authentication services, with IKE as the key management
 protocol.  iSCSI uses TCP to provide congestion control, error
 detection and error recovery.

1.2. iFCP Overview

 iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which
 provides transport services to Fibre Channel devices over a TCP/IP
 network.  iFCP allows interconnection and networking of existing
 Fibre Channel devices at wire speeds over an IP network.  iFCP
 implementations emulate fabric services in order to improve fault
 tolerance and scalability by fully leveraging IP technology.  Each
 TCP connection 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.  One or more TCP connections are bound to an
 FCIP Link, which is used to realize Inter-Switch Links (ISLs) between
 pairs of Fibre Channel entities.  FCIP Frame Encapsulation is
 described in [RFC3643].
 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][RFC2412], 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.

Aboba, et al. Standards Track [Page 4] RFC 3723 Securing Block Storage Protocols over IP April 2004

 An IPsec SA is a one-way security association, uniquely identified by
 the 3-tuple: Security Parameter Index (SPI), protocol (ESP) and
 destination IP.  The parameters for an IPsec security association are
 typically established by a key 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 [RFC2408],and the IP Security Domain of
 Interpretation (DOI) [RFC2407].  IKE has two phases, and accomplishes
 the following functions:
 [1]  Protected cipher suite and options negotiation - using keyed
      MACs and encryption and anti-replay mechanisms
 [2]  Master key generation - such as 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 SA.  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: <Source IP address, Destination IP address,
 transport protocol (UDP/SCTP/TCP), Source port, Destination port>.
 The successful establishment of a IKE Phase-2 SA results in the
 creation of two uni-directional IPsec SAs fully qualified by the
 tuple <Protocol (ESP/AH), destination address, SPI>.
 The session keys for each IPsec SA are derived from a master key,
 typically via 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.

Aboba, et al. Standards Track [Page 5] RFC 3723 Securing Block Storage Protocols over IP April 2004

1.5. Terminology

 Fibre Channel
    Fibre Channel (FC) is a gigabit speed networking technology
    primarily used to implement Storage Area Networks (SANs), although
    it also may be used to transport other frames types as well,
    including IP.  FC is standardized under American National Standard
    for Information Systems of the InterNational Committee for
    Informational Technology Standards (ANSI-INCITS) in its T11
    technical committee.
 FCIP
     Fibre Channel over IP (FCIP) is a protocol for interconnecting
    Fibre Channel islands 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.
 HBA
    Host Bus Adapter (HBA) is a generic term for a SCSI interface to
    other device(s); it's roughly analogous to the term Network
    Interface Card (NIC) for a TCP/IP network interface, except that
    HBAs generally have on-board SCSI implementations, whereas most
    NICs do not implement TCP, UDP, or IP.
 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).

Aboba, et al. Standards Track [Page 6] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 block
    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].
 Note that requirements specified in this document apply only to use
 of IPsec and IKE with IP block storage protocols.  Thus, these
 requirements do not apply to IPsec implementations in general.
 Implementation requirements language should therefore be assumed to
 relate to the availability of features for use with IP block storage
 security only.
 Although the security requirements in this document are already
 incorporated into the iSCSI [RFC3720], iFCP [iFCP] and FCIP [FCIP]
 standards track documents, they are reproduced here for convenience.
 In the event of a discrepancy, the individual protocol standards
 track documents take precedence.

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:

Aboba, et al. Standards Track [Page 7] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [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 support confidentiality, data origin authentication, integrity,
 and replay protection on a per-packet 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.
 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).

Aboba, et al. Standards Track [Page 8] RFC 3723 Securing Block Storage Protocols over IP April 2004

 For a security protocol to be useful, CPU overhead and hardware
 availability must not preclude implementation at 1 Gbps today.
 Implementation feasibility at 10 Gbps is highly desirable, but may
 not be demonstrable at this time.  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.  Performance issues are discussed
 further in Appendix B.
 Enterprise data center networks are considered mission-critical
 facilities that must be isolated and protected from possible security
 threats.  Such networks are often protected by security gateways,
 which at a minimum provide a shield against denial of service
 attacks.  The IP block storage security architecture should be able
 to leverage the protective services of the existing security
 infrastructure, including firewall protection, NAT and NAPT services,
 and VPN services available on existing security gateways.
 When iFCP or FCIP devices are deployed within enterprise networks, IP
 addresses will be typically be statically assigned as is the case
 with most routers and switches.  Consequently, support for dynamic IP
 address assignment, as described in [RFC3456], 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
 (confidentiality, data origin authentication, integrity, replay
 protection) and transforms negotiated when IPsec is used to protect
 IP block storage protocols such as iSCSI, iFCP and FCIP.
 FCIP implementations may allow enabling and disabling security
 mechanisms at the granularity of an FCIP Link.  For iFCP, the
 granularity corresponds to an iFCP Portal.  For iSCSI, the
 granularity of control is typically that of an iSCSI session,
 although it is possible to exert control down to the granularity of
 the destination IP address and TCP port.
 Note that with IPsec, security services are negotiated at the
 granularity of an IPsec SA, so that IP block storage connections
 requiring a set of security services different from those negotiated
 with existing IPsec SAs will need to negotiate a new IPsec SA.

Aboba, et al. Standards Track [Page 9] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Separate IPsec SAs are also advisable where quality of service
 considerations dictate different handling of IP block storage
 connections.  Attempting to apply different quality of service to
 connections handled by the same IPsec SA can result in reordering,
 and falling outside the replay window.  For a discussion of the
 issues, see [RFC2983].
 IP block storage protocols can be expected to carry sensitive data
 and provide access to systems and data that 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
 in-band authentication mechanisms or the authentication provided by
 IKE) in order to provide a minimal assurance that connections have
 initially been opened with the intended counterpart.
 iSNS, described in [iSNS], is required in all iFCP deployments.
 iSCSI may use iSNS for discovery, and FCIP does not use iSNS.  iSNS
 applications store iSCSI and FC device attributes and monitor their
 availability and reachability, providing a consolidated information
 repository for an integrated IP block storage network.  The iSNS
 specification defines mechanisms to secure communication between an
 iSNS server and its clients.

2.2. Resource Constraints

 Resource constraints and performance requirements for iSCSI are
 discussed in [RFC3347] Section 3.2.  iFCP and FCIP devices will
 typically be embedded systems 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).  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

Aboba, et al. Standards Track [Page 10] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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:
  1. 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).
  1. 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] RFC 3723 Securing Block Storage Protocols over IP April 2004

2.3. Security Protocol

2.3.1. Transforms

 All IP block storage security compliant implementations MUST support
 IPsec ESP [RFC2406] to provide security for both control packets and
 data packets, as well as the replay protection mechanisms of IPsec.
 When ESP is utilized, per-packet data origin authentication,
 integrity and replay protection MUST be used.
 To provide confidentiality with ESP, ESP with 3DES in CBC mode
 [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as
 described in [RFC3686], SHOULD be supported.  To provide data origin
 authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be
 supported, and AES in CBC MAC mode with XCBC extensions [RFC3566]
 SHOULD be supported.  DES in CBC mode SHOULD NOT be used due to its
 inherent weakness.  ESP with NULL encryption MUST be supported for
 authentication.

2.3.2. IPsec Modes

 Conformant IP block storage protocol implementations MUST support ESP
 [RFC2406] in tunnel mode and MAY implement IPsec with ESP in
 transport mode.

2.3.3. IKE

 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 IKE
 Main Mode and SHOULD support Aggressive Mode.  IKE Main Mode with
 pre-shared key authentication SHOULD NOT be used when either of the
 peers use a dynamically assigned IP address.  While Main Mode with
 pre-shared key authentication offers good security in many cases,
 situations where dynamically assigned addresses are used force use of
 a group pre-shared key, which is vulnerable to man-in-the-middle
 attack.

Aboba, et al. Standards Track [Page 12] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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.
 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 IPsec DOI [RFC2407] provides for several types of identification
 data.  Within IKE Phase 1, for use within the IDii and IDir payloads,
 conformant IP block storage security implementations MUST support the
 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and
 ID_FQDN Identity Payloads.  iSCSI security implementations SHOULD
 support the ID_USER_FQDN Identity Payload; other IP block storage
 protocols (iFCP, FCIP) SHOULD NOT use the ID_USER_FQDN Identity
 Payload.  Identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such
 as ID_FQDN or ID_USER_FQDN) SHOULD be employed in situations where
 Aggressive mode is utilized along with pre-shared keys and IP
 addresses are dynamically assigned.  The IP Subnet, IP Address Range,
 ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD NOT be used for IP
 block storage protocol security; The ID_KEY_ID Identity Payload MUST
 NOT be used.  As described in [RFC2407], within Phase 1 the ID port
 and protocol fields MUST be set to zero or to UDP port 500.  Also, as
 noted in [RFC2407]:
    When an IKE exchange is authenticated using certificates (of any
    format), any ID's used for input to local policy decisions SHOULD
    be contained in the certificate used in the authentication of the
    exchange.
 The Phase 2 Quick Mode exchanges used by IP block storage protocol
 implementations MUST explicitly carry the Identity Payload fields
 (IDci and IDcr).  Each Phase 2 IDci and IDcr Payload SHOULD carry a
 single IP address (ID_IPV4_ADDR, ID_IPV6_ADDR) and SHOULD NOT use the
 IP Subnet or IP Address Range formats.  Other ID payload formats MUST
 NOT be used.
 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 MUST NOT be interpreted as a reason for tearing down an IP

Aboba, et al. Standards Track [Page 13] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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.

2.3.4. Security Policy Configuration

 One of the goals of this specification is to enable a high level of
 interoperability without requiring extensive configuration.  This
 section provides guidelines on setting of IKE parameters so as to
 enhance the probability of a successful negotiation.  It also
 describes how information on security policy configuration can be
 provided so as to further enhance the chances of success.
 To enhance the prospects for interoperability, some of the actions to
 consider include:
 [1]  Transform restriction.
      Since support for 3DES-CBC and HMAC-SHA1 is required of all
      implementations, offering these transforms enhances the
      probability of a successful negotiation.  If AES-CTR [RFC3686]
      with XCBC-MAC [RFC3566] is supported, this transform combination
      will typically be preferred, with 3DES-CBC/HMAC-SHA1 as a
      secondary offer.
 [2]  Group Restriction.
      If 3DES-CBC/HMAC-SHA1 is offered, and DH groups are offered,
      then it is recommended that a DH group of at least 1024 bits be
      offered along with it.  If AES-CTR/XCBC-MAC is the preferred
      offer, and DH groups are offered, then it is recommended that a
      DH group of at least 2048 bits be offered along with it, as
      noted in [KeyLen].  If perfect forward secrecy is required in
      Quick Mode, then it is recommended that the QM PFS DH group be
      the same as the IKE Phase 1 DH group.  This reduces the total
      number of combinations, enhancing the chances for
      interoperability.
 [3]  Key lifetimes.
      If a key lifetime is offered that is longer than desired, then
      rather than causing the IKE negotiation to fail, it is
      recommended that the Responder consider the offered lifetime as
      a maximum, and accept it.  The key can then use a lesser value
      for the lifetime, and utilize a Lifetime Notify in order to
      inform the other peer of lifetime expiration.

Aboba, et al. Standards Track [Page 14] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Even when the above advice is taken, it still may be useful to be
 able to provide additional configuration information in order to
 enhance the chances of success, and it is useful to be able to manage
 security configuration regardless of the scale of the deployment.
 For example, it may be desirable to configure the security policy of
 an IP block storage device.  This can be done manually or
 automatically via a security policy distribution mechanism.
 Alternatively, it can be supplied via iSNS or SLPv2.  If an IP block
 storage endpoint can obtain the required security policy by other
 means (manually, or automatically via a 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.
 It may also be helpful to obtain information about the preferences of
 the peer prior to initiating IKE.  While it is generally possible to
 negotiate security parameters within IKE, there are situations in
 which incompatible parameters can cause the IKE negotiation to fail.
 The following information can be provided via SLPv2 or iSNS:
 [4]  IPsec or cleartext support.
      The minimum piece of peer configuration required is whether an
      IP block storage endpoint requires IPsec or cleartext.  This
      cannot be determined from the IKE negotiation alone without
      risking a long timeout, which is highly undesirable for a disk
      access protocol.
 [5]  Perfect Forward Secrecy (PFS) support.
      It is helpful to know whether a peer allows PFS, since an IKE
      Phase 2 Quick Mode can fail if an initiator proposes PFS to a
      Responder that does not allow it.
 [6]  Preference for tunnel mode.
      While it is legal to propose both transport and tunnel mode
      within the same offer, not all IKE implementations will support
      this.  As a result, it is useful to know whether a peer prefers
      tunnel mode or transport mode, so that it is possible to
      negotiate the preferred mode on the first try.
 [7]  Main Mode and Aggressive Mode support.
      Since the IKE negotiation can fail if a mode is proposed to a
      peer that doesn't allow it, it is helpful to know which modes a
      peer allows, so that an allowed mode can be negotiated on the
      first try.

Aboba, et al. Standards Track [Page 15] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Since iSNS or SLPv2 can be used to distribute IPsec security policy
 and configuration information for use with IP block storage
 protocols, these discovery protocols would constitute a 'weak link'
 were they not secured at least as well as the protocols whose
 security they configure.  Since the major vulnerability is packet
 modification and replay, when iSNS or SLPv2 are used to distribute
 security policy or configuration information, at a minimum, per-
 packet data origin authentication, integrity and replay protection
 MUST be used to protect the discovery protocol.

2.4. iSCSI Authentication

2.4.1. CHAP

 Compliant iSCSI implementations MUST implement the CHAP
 authentication method [RFC1994] (according to [RFC3720], section
 11.1.4), which includes support for bi-directional authentication,
 and the target authentication option.
 When CHAP is performed over non-encrypted channel, it is vulnerable
 to an off-line dictionary attack.  Implementations MUST support
 random CHAP secrets of up to 128 bits, including the means to
 generate such secrets and to accept them from an external generation
 source.  Implementations MUST NOT provide secret generation (or
 expansion) means other than random generation.
 If CHAP is used with secret smaller than 96 bits, then IPsec
 encryption (according to the implementation requirements in [RFC3720]
 section 8.3.2) MUST be used to protect the connection.  Moreover, in
 this case IKE authentication with group pre-shared keys SHOULD NOT be
 used.  When CHAP is used with a secret smaller then 96 bits, a
 compliant implementation MUST NOT continue with the iSCSI login
 unless it can verify that IPsec encryption is being used to protect
 the connection.
 Originators MUST NOT reuse the CHAP challenge sent by the Responder
 for the other direction of a bidirectional authentication.
 Responders MUST check for this condition and close the iSCSI TCP
 connection if it occurs.
 The same CHAP secret SHOULD NOT be configured for authentication of
 multiple initiators or multiple targets, as this enables any of them
 to impersonate any other one of them, and compromising one of them
 enables the attacker to impersonate any of them.  It is recommended
 that iSCSI implementations check for use of identical CHAP secrets by
 different peers when this check is feasible, and take appropriate
 measures to warn users and/or administrators when this is detected.
 A single CHAP secret MAY be used for authentication of an individual

Aboba, et al. Standards Track [Page 16] RFC 3723 Securing Block Storage Protocols over IP April 2004

 initiator to multiple targets.  Likewise, a single CHAP secret MAY be
 used for authentication of an individual target to multiple
 initiators.
 A Responder MUST NOT send its CHAP response if the initiator has not
 successfully authenticated.  For example, the following exchange:
    I->R     CHAP_A=<A1,A2,...>
    R->I     CHAP_A=<A1> CHAP_C=<C> CHAP_I=<I>
    I->R     CHAP_N=<N> CHAP_C=<C> CHAP_I=<I>
 (Where N, (A1,A2), I, C, and R are correspondingly the Name,
 Algorithms, Identifier, Challenge, and Response as defined in
 [RFC1994])
 MUST result in the Responder (target) closing the iSCSI TCP
 connection because the initiator has failed to authenticate (there is
 no CHAP_R in the third message).
 Any CHAP secret used for initiator authentication MUST NOT be
 configured for authentication of any target, and any CHAP secret used
 for target authentication MUST NOT be configured for authentication
 of any initiator.  If the CHAP response received by one end of an
 iSCSI connection is the same as the CHAP response that the receiving
 endpoint would have generated for the same CHAP challenge, the
 response MUST be treated as an authentication failure and cause the
 connection to close (this ensures that the same CHAP secret is not
 used for authentication in both directions).  Also, if an iSCSI
 implementation can function as both initiator and target, different
 CHAP secrets and identities MUST be configured for these two roles.
 The following is an example of the attacks prevented by the above
 requirements:
 Rogue wants to impersonate Storage to Alice, and knows that a
    single secret is used for both directions of Storage-Alice
    authentication.
 Rogue convinces Alice to open two connections to Rogue, and
    Rogue identifies itself as Storage on both connections.
 Rogue issues a CHAP challenge on connection 1, waits for Alice
    to respond, and then reflects Alice's challenge as the initial
    challenge to Alice on connection 2.
    If Alice doesn't check for the reflection across connections,
    Alice's response on connection 2 enables Rogue to impersonate
    Storage on connection 1, even though Rogue does not know the
    Alice-Storage CHAP secret.

Aboba, et al. Standards Track [Page 17] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Note that RADIUS [RFC2865] does not support bi-directional CHAP
 authentication.  Therefore, while a target acting as a RADIUS client
 will be able to verify the initiator Response, it will not be able to
 respond to an initiator challenge unless it has access to an
 appropriate shared secret by some other means.

2.4.2. SRP

 iSCSI implementations MAY implement the SRP authentication method
 [RFC2945] (see [RFC3720], Section 11.1.3).  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].
 SRP well-known groups are included in Appendix A and additional
 groups may be registered with IANA.  iSCSI implementations MUST use
 one of these well-known groups.  All the groups specified in Appendix
 A up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST
 be supported by initiators and targets.  To guarantee
 interoperability, targets MUST always offer "SRP-1536" as one of the
 proposed groups.

2.5. SLPv2 Security

 Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer
 entities and management servers.  SLPv2 may also be used to provide
 information on peer security configuration.  When SLPv2 is deployed,
 the SA advertisements as well as UA requests and/or responses are
 subject to the following security threats:
 [1]  An attacker could insert or alter SA advertisements or a
      response to a UA request in order to masquerade as the real peer
      or launch a denial of service attack.
 [2]  An attacker could gain knowledge about an SA or a UA through
      snooping, and launch an attack against the peer.  Given the
      potential value of iSCSI targets and FCIP entities, leaking 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.

Aboba, et al. Standards Track [Page 18] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 that will return incorrect data or no data at all.  In
      the SLPv2 security model, UAs trust DAs to store, answer queries
      on and forward data on services, but not necessarily to
      originate it.
 [e]  SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2
      is used.  In this case, SAs register with only one DA and trust
      that this DA will forward the registration to others.
 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.5.1. SLPv2 Security Protocol

 SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg,
 SrvAck, AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply,
 SAAdvert.  SLPv2 requires that User Agents (UAs) and Service Agents
 (SAs) support SrvRqst, SrvRply, and DAAdvert.  SAs must additionally
 support SrvReg, SrvAck, and SAAdvert.
 Where no Directory Agent (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.

Aboba, et al. Standards Track [Page 19] RFC 3723 Securing Block Storage Protocols over IP April 2004

 In order to provide the required security functionality, iSCSI and
 FCIP implementations supporting SLPv2 security 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) 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 Certificate Authority (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 used.  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.

Aboba, et al. Standards Track [Page 20] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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:
 [a]  SLPv2 messages sent via unicast are IPsec protected, using ESP
      with a non-null transform.
 [b]  SrvRply and AttrRply messages from either a DA or SA are unicast
      to UAs.  Assuming that the SA used a certificate authorized for
      SLPv2 service advertisement in establishing 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.
      Note that where SrvRqst messages are multicast, they are not
      protected.  An attacker may attempt to exploit this by spoofing
      a multicast SrvRqst from the UA, generating a SrvRply from an SA
      of the attacker's choosing.  Although the SrvRply is secured, it
      does not correspond to a legitimate SrvRqst sent by the UA.  To
      avoid this attack, where SrvRqst messages are multicast, the UA
      MUST check that SrvRply messages represent a legitimate reply to
      the SrvRqst that was sent.
 [c]  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 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.
 [d]  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
      IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no
      SLPv2 authentication block.
 [e]  SAs can accept DAAdverts as described in [d].

2.5.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.

Aboba, et al. Standards Track [Page 21] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 supporting
 SLPv2 security SHOULD encrypt as well as authenticate and integrity-
 protect 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.5.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 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 that 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.

Aboba, et al. Standards Track [Page 22] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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].  However, SLPv2 authentication
 as defined in [RFC2608] 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 to a DA issuing a legitimate DAAdvert.
 In addition, SLPv2 security as defined in [RFC2608] does not support
 confidentiality.  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.
 As a result, for use with IP block storage protocols, it is believed
 that use of IPsec for security is more appropriate than the SLPv2
 security model defined in [RFC2608].
 Using IPsec to secure SLPv2 has performance implications.  Security
 associations established between:
  1. UAs and SAs may be reused (the client on the UA host will use the

service on the SA host).

  1. SAs and DAs may be reused (the SAs will reregister services)
  1. UAs and DAs will probably not be reused (many idle security

associations are likely to result, and build up on the DA).

 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 the following mechanisms:
 [1]  Configuring SAs with the identities or certificate
      characteristics of valid DAs, and configuring DAs with the
      identities of SAs allowed to advertise IP block storage

Aboba, et al. Standards Track [Page 23] RFC 3723 Securing Block Storage Protocols over IP April 2004

      services.  The DAs are then trusted to enforce policies on
      service registration.  This approach involves manual
      configuration, but avoids certificate customization for SLPv2.
 [2]  Restricting the issuance of certificates valid for use in SLPv2
      service advertisement.  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.  This
      approach requires less configuration, but requires some
      certificate customization for use with SLPv2.

2.6. iSNS Security

 The iSCSI protocol may use iSNS for discovery and management
 services, while the iFCP protocol is required to use iSNS for such
 services.  In addition, iSNS can be used to store and distribute
 security policy and authorization information 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 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 needed:
 [a]  Unicast iSNS protocol messages may need to be authenticated.  In
      addition, to protect against threat [3] above, confidentiality
      support is desirable, and REQUIRED when certain functions of
      iSNS are used.

Aboba, et al. Standards Track [Page 24] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [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 support authentication of 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.
 Since iSNS is used to distribute authorizations determining which
 client devices can communicate, IPsec authentication and data
 integrity MUST be supported.  In addition, if iSNS is used to
 distribute security policy for iFCP and iSCSI devices, then
 authentication, data integrity, and confidentiality MUST be supported
 and used.
 Where iSNS is used without security, IP block storage protocol
 implementations MUST support a negative cache for authentication
 failures.  This allows implementations to avoid continually
 contacting discovered endpoints that 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.

2.6.1. Use of iSNS to Discover Security Configuration of Peer Devices

 In practice, within a single installation, iSCSI and/or iFCP devices
 may have different security settings.  For example, some devices may
 be configured to initiate secure communication, while other devices
 may be 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.

Aboba, et al. Standards Track [Page 25] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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.
 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.
 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.

2.6.2. Use of iSNS to Distribute iSCSI and iFCP Security Policies

 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.  If iSNS is used to
 distribute security policies, then IPsec authentication, data
 integrity, and confidentiality MUST be used to protect all iSNS
 protocol messages.
 The complete IKE/IPsec configuration of each iFCP and/or iSCSI device
 can be stored in the iSNS server, including 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.

Aboba, et al. Standards Track [Page 26] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Note that iSNS distribution of security policy is not necessary if
 the security settings can be determined by other means, such as
 manual configuration or IPsec security policy distribution.  If an
 entity has already obtained its security configuration via other
 mechanisms, then it MUST NOT request security policy via iSNS.
 For further details on how to store and retrieve IKE policy proposals
 in the iSNS server, see [iSNS].

2.6.3. iSNS Interaction with IKE and IPsec

 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.

2.6.4. iSNS Server Implementation Requirements

 All iSNS implementations MUST support the replay protection
 mechanisms of IPsec.  ESP in tunnel mode MUST be implemented, and
 IPsec with ESP in transport mode MAY be implemented.
 To provide data origin authentication and integrity with ESP, HMAC-
 SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions
 [RFC3566] SHOULD be supported.  When confidentiality is implemented,
 3DES in CBC mode MUST be supported, and AES in Counter mode, as
 described in [RFC3686], SHOULD be supported.  DES in CBC mode SHOULD
 NOT be used due to its inherent weakness.  If confidentiality is not
 required but data origin authentication and integrity is enabled, ESP
 with NULL Encryption MUST be used.
 Conformant iSNS implementations MUST support IKE for authentication,
 negotiation of security associations, and key management, using the
 IPsec DOI, described in [RFC2407].  IP block storage protocols can be
 expected to send data in high volumes, thereby requiring rekey.
 Since manual keying does not provide rekeying support, its use is
 prohibited with IP block storage protocols.  Although iSNS does not
 send a high volume of data, and therefore rekey is not a major
 concern, manual keying SHOULD NOT be used.  This is for consistency,
 since dynamic keying support is already required in IP storage
 security implementations.
 Conformant iSNS security implementations MUST support authentication
 using a pre- shared key, and MAY support certificate-based peer
 authentication using digital signatures.  Peer authentication using
 the public key encryption methods outlined in [RFC2409] sections 5.2
 and 5.3 SHOULD NOT be used.

Aboba, et al. Standards Track [Page 27] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Conformant iSNS implementations MUST support IKE Main Mode and SHOULD
 support Aggressive Mode.  IKE Main Mode with pre-shared key
 authentication SHOULD NOT be used when either of the peers use
 dynamically assigned IP addresses.  While Main Mode with pre-shared
 key authentication offers good security in many cases, situations
 where dynamically assigned addresses are used force use of a group
 pre-shared key, which is vulnerable to man-in-the-middle attack.
 When digital signatures are used for authentication, either IKE Main
 Mode or IKE Aggressive Mode MAY be used.  In all cases, access to
 locally stored secret information (pre-shared key or private key for
 digital signing) MUST be suitably restricted, since compromise of the
 secret information nullifies the security properties of the IKE/IPsec
 protocols.
 When digital signatures are used to achieve authentication, an IKE
 negotiator SHOULD use IKE Certificate Request Payload(s) to specify
 the certificate authority (or authorities) that are trusted in
 accordance with its local policy.  IKE negotiators SHOULD check the
 pertinent Certificate Revocation List (CRL) before accepting a PKI
 certificate for use in IKE's authentication procedures.

3. iSCSI Security Interoperability Guidelines

 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, outlined in [RFC3720], 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 authenticate the
 initiator to the target, but does not by itself provide per-packet
 authentication, integrity, confidentiality or replay protection.  In

Aboba, et al. Standards Track [Page 28] RFC 3723 Securing Block Storage Protocols over IP April 2004

 addition, iSCSI Login authentication 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 [RFC3720], comprised of one or more TCP connections,
 is identified by the 2-tuple of the initiator-defined identifier and
 the target-defined identifier, <ISID, TSIH>.  Each connection within
 a given session is assigned a unique Connection Identification, CID.
 The TCP connection is identified by the 5-tuple <Source IP address,
 Destination IP address, Protocol (TCP), Source Port, Destination
 Port>.  An IPsec Phase 2 SA is identified by the 3-tuple <Protocol
 (ESP),destination address, SPI>.
 The iSCSI session and connection 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 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 <source IP
 address, destination IP address> pair.
 When multiple iSCSI sessions are active between a given <initiator,
 target> pair, the set of TCP connections used by a given iSCSI
 session must be disjoint from those used by all other iSCSI sessions
 between the same <initiator, target> 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
      <initiator IP address, target IP address> tuple.
 [2]  Each TCP connection within an iSCSI Session is protected by an
      IKE Phase 2 SA.  The selectors may be specific to that TCP
      connection or may cover multiple connections.  While each IKE
      Phase 2 SA may protect multiple TCP connections, each TCP
      connection is transported under only one IKE Phase 2 SA.

Aboba, et al. Standards Track [Page 29] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 a
 TCP connection, an IKE Phase 2 SA and the iSCSI connection ID.

3.3. Initiating a New iSCSI Session

 In order to create a new iSCSI Session, if an IKE Phase 1 SA does not
 already exist, then it is established by an initiator implementing
 iSCSI security.  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.
 The initiator and target implementations successfully complete the
 IKE Phase 1 and Phase 2 negotiations before the iSCSI initiator
 contacts the target on well-known TCP port 3260, and sends the iSCSI
 Login command over the TCP connection.  IPsec implementations
 configured with the correct policies (e.g., use ESP with non-null
 transform for all traffic destined for the iSCSI well-known TCP port
 3260) will handle this automatically.
 The initiator fills in the ISID field, and leaves the TSIH field set
 to zero, 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 TSIH, and therefore the
 iSCSI session identifier <ISID, TSIH>.
 A single iSCSI session identifier may have multiple associated IKE
 Phase 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI
 session identifiers.  Each iSCSI connection (identified by the
 connection identifier) corresponds to a single TCP connection
 (identified by the 5-tuple).  Each IKE Phase 2 SA is identified by
 the <Protocol (ESP), destination address, SPI> combination.  A Phase
 2 SA may protect multiple TCP connections, and corresponds to a
 single IKE Phase 1 SA.
 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.

Aboba, et al. Standards Track [Page 30] RFC 3723 Securing Block Storage Protocols over IP April 2004

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
 [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.
 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.  After the expiration of the
 TIME_WAIT timeout, the TCP connection is closed.

3.5. Non-graceful iSCSI Teardown

 If a given TCP connection unexpectedly fails, the associated iSCSI
 connection is torn down.  There is no requirement that an IKE Phase 2
 delete immediately follow iSCSI connection tear down or Phase 1
 deletion.  Since an IKE Phase 2 SA may correspond to multiple TCP
 connections, such a deletion might be inappropriate.  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 an IKE Phase 2 SA may be used by multiple TCP connections, an
 iSCSI implementation should not depend on receiving the IPsec Phase 2
 delete as confirmation that the iSCSI peer has executed an iSCSI
 teardown process for the connection.

Aboba, et al. Standards Track [Page 31] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 MUST NOT be interpreted as a reason for tearing down the
 corresponding iSCSI connection if no Logout Command/Logout Receive
 has been executed on the connection.  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 [RFC3720]
 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 network malfunctions or other errors.  In general, IPsec
 authentication transforms afford stronger integrity protection than
 both the 16-bit TCP checksum and the 32-bit application-layer CRC
 specified 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 end-to-end
 between iSCSI endpoints (or the portion that requires additional
 integrity protection), portions of iSCSI can be simplified.  For
 example, mechanisms to recover from CRC check failures are not
 necessary.

Aboba, et al. Standards Track [Page 32] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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
 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 by these mechanisms.  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 error coverage because they are computed and
 checked at a different point in the protocol stack or in devices
 different from those that implement the IPsec integrity checks.  The
 resulting coverage of additional possible errors may make it
 desirable to negotiate use of the iSCSI CRC even when IPsec integrity
 protection is in use.  Examples of these situations include where:
 [1]  IPsec, TCP and iSCSI are implemented purely in software.  Here,
      additional failure modes may be detected by the TCP checksum
      and/or iSCSI CRC.  For example, after the IPsec message
      integrity check is successfully verified, the segment is copied
      as part of TCP processing, and a memory error during this
      process might cause the TCP checksum or iSCSI CRC verification
      to fail.
 [2]  The implementation is an iSCSI-iSCSI proxy or gateway.  Here the
      iSCSI CRC can be propagated from one iSCSI connection to
      another.  In this case, the iSCSI CRC is useful to protect iSCSI
      data against memory, bus, or software errors within the proxy or
      gateway, and requesting it is desirable.
 [3]  IPsec is provided by a device external to the actual iSCSI
      device.  Here the iSCSI header and data CRCs can be kept across
      the part of the connection that is not protected by IPsec.  For
      instance, the iSCSI connection could traverse an extra bus,
      interface card, network, interface card, and bus between the

Aboba, et al. Standards Track [Page 33] RFC 3723 Securing Block Storage Protocols over IP April 2004

      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 to
      protect against NIC and network errors, although it may be
      desirable for other reasons (e.g., [1] and [2] above).

4. iFCP and FCIP Security Issues

4.1. iFCP and FCIP Authentication Requirements

 iFCP and FCIP are peer-to-peer protocols.  iFCP and FCIP sessions may
 be initiated by either or both peer gateways.  Consequently, bi-
 directional authentication of peer gateways MUST be provided.
 iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre
 Channel frames over IP.  Therefore, Fibre Channel, operating system,
 and user identities are transparent to the iFCP and FCIP protocols.
 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

 A conformant iFCP Portal is capable of establishing one or more IKE
 Phase-1 Security Associations (SAs) to a peer iFCP Portal.  A Phase-1
 SA may be established when an iFCP Portal is initialized, or may be
 deferred until the first TCP connection with security requirements is
 established.
 An IKE Phase-2 SA protects one or more TCP connections within the
 same iFCP Portal.  More specifically, the successful establishment of
 an IKE Phase-2 SA results in the creation of two uni-directional
 IPsec SAs fully qualified by the tuple <SPI, destination IP address,
 ESP>.  These SAs protect the setup process of the underlying TCP
 connections and all their subsequent TCP traffic.  Each of the TCP
 connections protected by an SA is either in the unbound state, or is
 bound to a specific iFCP session.

Aboba, et al. Standards Track [Page 34] RFC 3723 Securing Block Storage Protocols over IP April 2004

 In summary, at any point in time:
 [1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals
 [2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs
 [3] Each IKE Phase-2 SA protects 0..Z TCP connections
 The creation of an IKE Phase-2 SA may be triggered by security policy
 rules retrieved from an iSNS server.  Alternately, the creation of an
 SA may be triggered by policy rules configured through a management
 interface, reflecting iSNS-resident policy rules.  Likewise, the use
 of a Key Exchange payload in Quick Mode for perfect forward secrecy
 may be driven by security policy rules retrieved from the iSNS
 server, or set through a management interface.
 If an iFCP implementation makes use of unbound TCP connections, and
 such connections belong to an iFCP Portal with security requirements,
 then the unbound connections MUST be protected by an SA at all times
 just like bound connections.
 Upon receiving an IKE Phase-2 delete message, there is no requirement
 to terminate the protected TCP connections or delete the associated
 IKE Phase-1 SA.  Since an IKE Phase-2 SA may be associated with
 multiple TCP connections, terminating such connections might in fact
 be inappropriate and untimely.
 To minimize the number of active Phase-2 SAs, IKE Phase-2 delete
 messages may be sent for Phase-2 SAs whose TCP connections have not
 handled data traffic for a while.  To minimize the use of SA
 resources while the associated TCP connections are idle, creation of
 a new SA should be deferred until new data are to be sent over the
 connections.

4.3. FCIP Interaction with IPsec and IKE

 FCIP Entities establish tunnels with other FCIP Entities in order to
 transfer IP encapsulated FC frames.  Each tunnel is a separate FCIP
 Link, and can encapsulate multiple TCP connections.  The binding of
 TCP connections to an FCIP Link is performed using the Fibre Channel
 World Wide Names (WWNs) of the two FCIP Entities.
 FCIP Entities may have more than one interface and IP address, and it
 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.

Aboba, et al. Standards Track [Page 35] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Each TCP connection within an FCIP Link corresponds to an IKE Phase 2
 (Quick Mode) SA.  This is established prior to sending the initial
 TCP SYN packet and applies to the life of the connection.  Phase 2
 negotiation is also required for rekeying, in order to protect
 against replay attacks.
 FCIP implementations MAY provide administrative management of
 Confidentiality usage.  These management interfaces SHOULD be
 provided in a secure manner, so as to prevent an attacker from
 subverting the security process by attacking the management
 interface.
 FCIP Entities do not require any user-level authentication, since all
 FCIP Entities participate in a machine-level tunnel function.  FCIP
 uses SLP for discovery, but not to distribute security policies.

5. Security Considerations

5.1. Transport Mode Versus Tunnel Mode

 With respect to block 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]  Address assignment and configuration.
      Within IPsec tunnel mode, it is necessary for inner and outer
      source addresses to be configured, and for inner and outer
      destination addresses to be discovered.  Within transport mode
      it is only necessary to discover a single destination address
      and configure a single source address.  IPsec tunnel mode
      address usage considerations are discussed in more detail below.
 [3]  NAT traversal.
      As noted in [RFC3715], 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 [RFC3715],
      [UDPIPsec] and [NATIKE] can be implemented.  More details are
      provided in the next section.

Aboba, et al. Standards Track [Page 36] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [4]  Firewall traversal.
      Where a block 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 block 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.
 [5]  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 behavior.

5.1.1. IPsec Tunnel Mode Addressing Considerations

 IPsec tunnels include both inner and outer source as well as
 destination addresses.
 When used with IP block storage protocols, the inner destination
 address represents the address of the IP block storage protocol peer
 (e.g., the ultimate destination for the packet).  The inner
 destination address can be discovered using SLPv2 or iSNS, or can be
 resolved from an FQDN via DNS, so that obtaining this address is
 typically not an issue.

Aboba, et al. Standards Track [Page 37] RFC 3723 Securing Block Storage Protocols over IP April 2004

 The outer destination address represents the address of the IPsec
 security gateway used to reach the peer.  Several mechanisms have
 been proposed for discovering the IPsec security gateway used to
 reach a particular peer.  [RFC2230] discusses the use of KX Resource
 Records (RRs) for IPsec gateway discovery.  However, while KX RRs are
 supported by many DNS server implementations, they have not yet been
 widely deployed.  Alternatively, DNS SRV [RFC2782] can be used for
 this purpose.  Where DNS is used for gateway location, DNS security
 mechanisms such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and
 Simple Secure Dynamic Update [RFC3007] are advisable.
 When used with IP block storage protocols, the outer source address
 is configured either statically or dynamically, using mechanisms such
 as DHCPv4 [RFC2131], DHCPV6 [RFC3315], or stateless address
 autoconfiguration [RFC2373].
 The inner source address SHOULD be included in the Quick Mode ID
 payload when the peer establishes a tunnel mode SA with the IPsec
 security gateway.  This enables the IPsec security gateway to
 properly route packets back to the remote peer.  The inner source
 address can be configured via a variety of mechanisms, depending on
 the scenario.  Where the IP block storage peers are located within
 the same administrative domain, it is typically possible for the
 inner and outer source addresses to be the same.  This will work
 because the outer source address is presumably assigned from within a
 prefix assigned to the administrative domain, and is therefore
 routable within the domain. Assuming that the IPsec security gateway
 is aware of the inner source address used by the connecting peer and
 plumbs a host route for it, then packets arriving at the IPsec
 security gateway destined for the address can be correctly
 encapsulated and sent down the correct tunnel.
 Where IP block storage peers are located within different
 administrative domains, it may be necessary for the inner source
 address to be assigned by the IPsec security gateway, effectively
 "joining" the remote host to the LAN attached to the IPsec security
 gateway.  For example, if the remote peer were to use its assigned
 (outer) source address as the inner source address, then a number of
 problems might result:
 [1]  Intrusion detection systems sniffing the LAN behind the IPsec
      security gateway would notice source addresses originating
      outside the administrative domain.
 [2]  Reply packets might not reach their destination, since the IPsec
      security gateway typically does not advertise the default route,
      but rather only the prefix that it allocates addresses from.
      Since the remote peer's address does not originate from with a

Aboba, et al. Standards Track [Page 38] RFC 3723 Securing Block Storage Protocols over IP April 2004

      prefix native to the administrative domain, it is likely that
      routers within the domain would not have a route for it, and
      would send the packet off to the router advertising the default
      route (perhaps a border router) instead of to the IPsec security
      gateway.
 For these reasons, for inter-domain use, assignment of inner source
 addresses may be needed.  At present this is not a very common
 scenario; however, if address assignment is provided, then DHCP-based
 address assignment within IPsec tunnel mode [RFC3456] MUST be
 supported.  Note that this mechanism is not yet widely deployed
 within IPsec security gateways; existing IPsec tunnel mode servers
 typically implement this functionality via proprietary extensions to
 IKE.

5.2. NAT Traversal

 As noted in [RFC3715], tunnel mode ESP can traverse NAT in a limited
 set of circumstances.  For example, 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.
 TCP carried within 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 ESP 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 [RFC3715], [UDPIPsec], and [NATIKE].

Aboba, et al. Standards Track [Page 39] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 seldom 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.

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 Gbps, 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 for implementations 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,

Aboba, et al. Standards Track [Page 40] RFC 3723 Securing Block Storage Protocols over IP April 2004

 then the ciphertext of the next block will be identical.  Thus, 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.  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 41] RFC 3723 Securing Block Storage Protocols over IP April 2004

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               | 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

Aboba, et al. Standards Track [Page 42] RFC 3723 Securing Block Storage Protocols over IP April 2004

 This means that cipher block size as well as key length needs 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) * (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:
  1. DES in CBC mode
  2. HMAC with MD5
  3. HMAC with SHA-1
  4. NULL Authentication algorithm
  5. 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 43] RFC 3723 Securing Block Storage Protocols over IP April 2004

 The MD5 algorithm is specified in [RFC1321]; HMAC is defined in
 [RFC2104] and security issues with MD5 are discussed in [MD5Attack].
 The HMAC-MD5 IPsec transform is specified in [RFC2403].  The HMAC-
 SHA1 IPsec transform is specified in [RFC2404].
 In addition to these existing algorithms, NIST is currently
 evaluating the following modes [NSPUE2] of AES, defined in [FIPS197]:
    AES in Electronic Codebook (ECB) confidentiality mode
    AES in Cipher Block Chaining (CBC) confidentiality mode
    AES in Cipher Feedback (CFB) confidentiality mode
    AES in Output Feedback (OFB) confidentiality mode
    AES in Counter (CTR) confidentiality mode
    AES CBC-MAC authentication mode
 When utilizing AES modes, it may be necessary to use larger public
 keys; the tradeoffs are described in [KeyLen].  Additional MODP
 Diffie-Hellman groups for use with IKE are described in [RFC3526].
 The Modes [NSPUE2] effort is also considering a number of additional
 algorithms, including the following:
    PMAC
 To provide authentication, integrity and replay protection, IP block
 storage security implementations MUST support HMAC-SHA1 [RFC2404] for
 authentication, and AES in CBC MAC mode with XCBC extensions SHOULD
 be supported [RFC3566].
 HMAC-SHA1 [RFC2404] is to be preferred 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.  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 [RFC3566].
 Authentication transforms also exist that are considerably more
 efficient to implement than HMAC-SHA1, or AES in CBC-MAC
 authentication mode.  UMAC [UMAC],[UMACKR] is more efficient to
 implement in software and PMAC [PMAC] is more efficient to implement
 in hardware.  PMAC is currently being evaluated as part of the NIST
 modes effort [NSPUE2] but an IPsec transform does not yet exist;
 neither does a UMAC transform.

Aboba, et al. Standards Track [Page 44] RFC 3723 Securing Block Storage Protocols over IP April 2004

 For confidentiality, the ESP mandatory-to-implement algorithm (DES)
 is unacceptable.  As noted in [DESCRACK], DES is crackable with
 modest 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 [RFC3686]
 SHOULD be supported.  For use in high speed implementations, 3DES has
 significant disadvantages.  However, a 3DES IPsec transform has been
 specified and parts are available that can run at 1 Gbps, so
 implementing 3DES in products is practical for the short term.
 As described in Appendix B, 3DES software implementations make
 excessive computational demands at speeds of 100 Mbps or greater,
 effectively ruling out software-only implementations.  In addition,
 3DES implementations  require rekeying 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
 initial 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.

Aboba, et al. Standards Track [Page 45] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [3]  Reducing  the size of fields within the certificates.  This
      includes reduction in the key size, the distinguished name or
      other fields.  This should be considered only as a last resort.
 Fragmentation can become a concern when prepending IPsec headers to a
 frame.  One mechanism that 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 that
 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, each TCP connection MUST
 be protected by an IKE Phase 2 SA.  Traffic from one or more than one
 TCP connection may flow within each IPsec Phase 2 SA.  IP block
 storage security implementations need not verify that the IP
 addresses and TCP port values in the packet match the socket

Aboba, et al. Standards Track [Page 46] RFC 3723 Securing Block Storage Protocols over IP April 2004

 information that was used to setup the connection.  This check will
 be performed by IPsec, preventing malicious peers from sending
 commands on inappropriate Quick Mode SAs.

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

Aboba, et al. Standards Track [Page 47] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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.

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 pre-shared key authentication is used in Main Mode along
 with entities whose address is dynamically assigned, the same pre-
 shared key is shared by a group 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 where IP addresses are typically statically
 assigned (such as with iFCP and FCIP), since in this situation
 individual pre-shared keys are possible within IKE Main Mode.
 However, where IP addresses are dynamically assigned and Main Mode is
 used along with pre-shared keys, the Responder is not authenticated
 unless application-layer mutual authentication is performed (e.g.,
 iSCSI login authentication).  This enables an attacker in possession
 of the group pre-shared key to masquerade as the Responder.  In
 addition to enabling the attacker to present false data, the attacker
 would also be able to mount a dictionary attack on legacy
 authentication methods such as CHAP [RFC1994], potentially
 compromising many passwords at a time.  This vulnerability is widely
 present in existing IPsec implementations.
 Group pre-shared keys are not required in Aggressive Mode since the
 identity payload is sent earlier in the exchange, 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 IKE Phase 1 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 addresses are dynamically assigned,

Aboba, et al. Standards Track [Page 48] RFC 3723 Securing Block Storage Protocols over IP April 2004

 mapping of identities to keys is not possible, so that group pre-
 shared keys are still a practical necessity.  As a result, identities
 other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or
 ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode
 is utilized along with pre-shared keys and 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.  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.  This is true
 for both transport mode and tunnel mode SAs.
 To limit the potential vulnerability, IP block storage
 implementations MUST do the following:
 [1]  Ensure that socket access is appropriately controlled.  On a
      multi-user operating system, this implies that sockets opened
      for use by IP block storage protocols MUST be exclusive.
 [2]  In the case of iSCSI, implementations MUST also ensure that
      application layer login credentials (such as iSCSI login
      credentials) are protected from unauthorized access.

Aboba, et al. Standards Track [Page 49] RFC 3723 Securing Block Storage Protocols over IP April 2004

 If these directives are followed, then a rogue process will not be
 able to access an IP block storage volume.
 While the identity asserted within IKE is verified on a per-packet
 basis, to avoid interference between users on a given machine,
 operating 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 a 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.

Aboba, et al. Standards Track [Page 50] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Since iSCSI supports Login authentication, it is also possible to use
 the identities presented within the iSCSI Login for authorization
 purposes.
 In iFCP, basic access control properties stem from the requirement
 that two communicating iFCP gateways be known to one or more iSNS
 servers before they can engage in iFCP exchanges.  The optional use
 of discovery domains in iSNS yields access control schemas of greater
 complexity.

5.9. Use of AES in Counter Mode

 When utilizing AES modes, it may be necessary to use larger public
 keys; the tradeoffs are described in [KeyLen].  Additional MODP
 Diffie-Hellman groups for use with IKE are described in [RFC3526].
 When AES in counter mode is used, it is important to avoid reuse of
 the counter with the same key, even across all time.  Counter mode
 creates ciphertext by XORing generated key stream with plaintext.  It
 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 an
 error to use IPsec manual keying with counter mode, except when the
 implementation takes heroic measures to maintain state across
 sessions.  In any case, manual keying MUST NOT be used since it does
 not provide the necessary rekeying support.
 Another counter mode issue is it makes forgery of correct packets
 trivial.  Counter mode should therefore never be used without also
 using data authentication.

6. IANA Considerations

 This section provides guidance to the Internet Assigned Numbers
 Authority (IANA) regarding registration of values of the SRP_GROUP
 key parameter within iSCSI, in accordance with BCP 26, [RFC2434].
 IANA considerations for the iSCSI protocol are described in
 [RFC3720], Section 13; for the iFCP protocol in [iFCP], Section 12;
 and for the FCIP protocol in [FCIP], Appendix B.

Aboba, et al. Standards Track [Page 51] RFC 3723 Securing Block Storage Protocols over IP April 2004

6.1. Definition of Terms

 The following terms are used here with the meanings defined in BCP
 26:  "name space", "assigned value", "registration".
 The following policies are used here with the meanings defined in BCP
 26: "Private Use", "First Come First Served", "Expert Review",
 "Specification Required", "IETF Consensus", "Standards Action".

6.2. Recommended Registration Policies

 For registration requests where a Designated Expert should be
 consulted, the responsible IESG Area Director should appoint the
 Designated Expert.
 For registration requests requiring Expert Review, the IPS mailing
 list should be consulted, or if the IPS WG is disbanded, to a mailing
 list designated by the IESG Area Director.
 This document defines the following SRP_GROUP keys:
    SRP-768, SRP-1024, SRP-1280, SRP-1536, SRP-2048, MODP-3072, MODP-
    4096, MODP-6144, MODP-8192
 New SRP_GROUP keys MUST conform to the iSCSI extension item-label
 format described in [RFC3720] Section 13.5.4.
 Registration of new SRP_GROUP keys is by Designated Expert with
 Specification Required.  The request is posted to the IPS WG mailing
 list or its successor for comment and security review, and MUST
 include a non-probabalistic proof of primality for the proposed SRP
 group.  After a period of one month as passed, the Designated Expert
 will either approve or deny the registration request.

7. Normative References

 [RFC793]       Postel, J., "Transmission Control Protocol", STD 7,
                RFC 793, September 1981.
 [RFC1191]      Mogul, J. and S. Deering, "Path MTU Discovery", RFC
                1191, November 1990.
 [RFC1435]      Knowles, S., "IESG Advice from Experience with Path
                MTU Discovery", RFC 1435, March 1993.
 [RFC1981]      McCann, J., Deering, S. and J. Mogul, "Path MTU
                Discovery for IP version 6", RFC 1981, August 1996.

Aboba, et al. Standards Track [Page 52] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                Keyed- Hashing for Message Authentication", RFC 2104,
                February 1997.
 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2131]      Droms, R., "Dynamic Host Configuration Protocol", RFC
                2131, March 1997.
 [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                the Internet Protocol", RFC 2401, November 1998.
 [RFC2404]      Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
                within ESP and AH", RFC 2404, November 1998.
 [RFC2406]      Kent, S. and R. Atkinson, "IP Encapsulating Security
                Payload (ESP)", RFC 2406, November 1998.
 [RFC2407]      Piper, D., "The Internet IP Security Domain of
                Interpretation of ISAKMP", RFC 2407, November 1998.
 [RFC2408]      Maughan, D., Schertler, M., Schneider, M. and J.
                Turner, "Internet Security Association and Key
                Management Protocol (ISAKMP)," RFC 2408, November
                1998.
 [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
                (IKE)", RFC 2409, November 1998.
 [RFC2412]      Orman, H., "The OAKLEY Key Determination Protocol",
                RFC 2412, November 1998.
 [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
                an IANA Considerations Section in RFCs", BCP 26, RFC
                2434, October 1998.
 [RFC2451]      Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
                Algorithms", RFC 2451, November 1998.
 [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
                "Service Location Protocol, Version 2", RFC 2608, June
                1999.
 [RFC2923]      Lahey, K., "TCP Problems with Path MTU Discovery", RFC
                2923, September 2000.

Aboba, et al. Standards Track [Page 53] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [RFC2945]      Wu, T., "The SRP Authentication and Key Exchange
                System", RFC 2945, September 2000.
 [RFC3315]      Droms, R., Ed., Bound, J., Volz,, B., Lemon, T.,
                Perkins, C. and M. Carney, "Dynamic Host Configuration
                Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC3456]      Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
                Host Configuration Protocol (DHCPv4) Configuration of
                IPsec Tunnel Mode", RFC 3456, January 2003.
 [RFC3526]      Kivinen, T. and M. Kojo, "More Modular Exponential
                (MODP) Diffie-Hellman groups for Internet Key Exchange
                (IKE)", RFC 3526, May 2003.
 [RFC3566]      Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
                Algorithm and Its Use with IPsec", RFC 3566, September
                2003.
 [RFC3643]      Weber, R., Rajagopal, M., Trovostino, F., O'Donnel.,
                M, Monia, C.and M. Mehrar, "Fibre Channel (FC) Frame
                Encapsuation", RFC 3643, December 2003.
 [RFC3686]      Housley, R., "Using Advanced Encryption Standard (AES)
                Counter Mode With IPsec Encapsulating Security Payload
                (ESP)", RFC 3686, January 2004.
 [RFC3720]      Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M.
                and E. Zeidner, "Internet Small Computer Systems
                Interface (iSCSI)", RFC 3720, April 2004.
 [3DESANSI]     American National Standard for Financial Services
                X9.52-1998, "Triple Data Encryption Algorithm Modes of
                Operation", American Bankers Association, Washington,
                D.C., July 29, 1998
 [SRPNDSS]      Wu, T., "The Secure Remote Password Protocol", in
                Proceedings of the 1998 Internet Society Symposium on
                Network and Distributed Systems Security, San Diego,
                CA, pp.  97-111

8. Informative References

 [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                1321, April 1992.
 [RFC1994]      Simpson, W., "PPP Challenge Handshake Authentication
                Protocol (CHAP)", RFC 1994, August 1996.

Aboba, et al. Standards Track [Page 54] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [RFC2230]      Atkinson, R., "Key Exchange Delegation Record for the
                DNS", RFC 2230, November 1997.
 [RFC2373]      Hinden, R. and S. Deering, "IP Version 6 Addressing
                Architecture", RFC 2373, July 1998.
 [RFC2402]      Kent, S., Atkinson, R., "IP Authentication Header",
                RFC 2402, November 1998.
 [RFC2403]      Madson, C. and R. Glenn, "The Use of HMAC-MD5-96
                within ESP and AH", RFC 2403, November 1998.
 [RFC2405]      Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
                Algorithm With Explicit IV", RFC 2405, November 1998.
 [RFC2535]      Eastlake, D., "Domain Name System Security
                Extensions", RFC 2535, March 1999.
 [RFC2782]      Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR
                for specifying the location of services (DNS SRV)",
                RFC 2782, February 2000.
 [RFC2845]      Vixie, P., Gudmundsson, O., Eastlake, D. and B.
                Wellington, "Secret Key Transaction Authentication for
                DNS (TSIG)", RFC 2845, May 2000.
 [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
                "Remote Authentication Dial In User Service (RADIUS)",
                RFC 2865, June 2000.
 [RFC2931]      Eastlake, D., "DNS Request and Transaction Signatures
                (SIG(0)s )", RFC 2931, September 2000.
 [RFC2983]      Black, D. "Differentiated Services and Tunnels", RFC
                2983, October 2000.
 [RFC3007]      Wellington, B., "Simple Secure Domain Name System
                (DNS) Dynamic Update", RFC 3007, November 2000.
 [RFC3347]      Krueger, M. and R. Haagens, "Small Computer Systems
                Interface protocol over the Internet (iSCSI)
                Requirements and Design Considerations", RFC 3347,
                July 2002.
 [RFC3721]      Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and
                M. Krueger, "Internet Small Computer Systems Interface
                (iSCSI) Naming and Discovery", RFC 3721, April 2004.

Aboba, et al. Standards Track [Page 55] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [AESPERF]      Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C.
                Hall, and N. Ferguson, "Performance Comparison of the
                AES Submissions", http://www.counterpane.com/aes-
                performance.html
 [AuthMIB]      Bakke, M., et al., "Definitions of Managed Objects for
                iSCSI", Work in Progress, September 2002.
 [CRCTCP]       Stone J., Partridge, C., "When the CRC and TCP
                checksum disagree", ACM Sigcomm, Sept. 2000.
 [DESANALY]     Bellare, Desai, Jokippi, Rogaway, "A Concrete
                Treatment of Symmetric Encryption: Analysis of the DES
                Modes of Operation", 1997, http://www-
                cse.ucsd.edu/users/mihir/papers/sym-enc.html
 [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA
                2000.
 [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
                DES-like cryptosystems", Journal of Cryptology Vol 4,
                Jan 1991.
 [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
                Strong Integrity", Proceedings of the 32nd IETF,
                Danvers, MA, April 1995
 [FCIP]         Rajagopal, M., et al., "Fibre Channel over TCP/IP
                (FCIP)", Work in Progress, August 2002.
 [FCIPSLP]      Petersen, D., "Finding FCIP Entities Using SLPv2",
                Work in Progress, September 2002.
 [FIPS46-3]     U.S. DoC/NIST, "Data encryption standard (DES)", FIPS
                46-3, October 25, 1999.
 [FIPS74]       U.S. DoC/NIST, "Guidelines for implementing and using
                the nbs data encryption standard", FIPS 74, Apr 1981.
 [FIPS197]      U.S. DoC/NIST, "Advanced Encryption Standard (AES)",
                FIPS 197, November 2001,
                http://csrc.nist.gov/CryptoToolkit/aes
 [iFCP]         Monia, C., et al., "iFCP - A Protocol for Internet
                Fibre Channel Storage Networking", Work in Progress,
                August 2002.

Aboba, et al. Standards Track [Page 56] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [RFC3715]      Aboba, B. and W. Dixon, "IPsec-Network Address
                Translation (NAT) Compatibility Requirements", RFC
                3715, March 2004.
 [iSCSISLP]     Bakke, M., "Finding iSCSI targets and Name Servers
                Using SLP", Work in Progress, March 2002.
 [iSNS]         Gibbons, K., et al., "iSNS Internet Storage Name
                Service", Work in Progress, August 2002.
 [KeyLen]       Orman, H., Hoffman, P., "Determining Strengths For
                Public Keys Used For Exchanging Symmetric Keys", Work
                in Progress, December 2001.
 [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
                Attack", CryptoBytes Vol.2 No.2, Summer 1996
 [NATIKE]       Kivinen, T., et al., "Negotiation of NAT-Traversal in
                the IKE", Work in Progress, June 2002.
 [NSPUE2]       "Recommendation for Block Cipher Modes of Operation",
                National Institute of Standards and Technology (NIST)
                Special Publication 800-38A, CODEN: NSPUE2, U.S.
                Government Printing Office, Washington, DC, July 2001.
 [PENTPERF]     A. Bosselaers, "Performance of Pentium
                implementations",
                http://www.esat.kuleuven.ac.be/~bosselae/
 [PMAC]         Rogaway, P., Black, J., "PMAC: Proposal to NIST for a
                parallelizable message authentication code",
                http://csrc.nist.gov/encryption/modes/proposedmodes/
                pmac/pmac-spec.pdf
 [Seq]          Kent, S., "IP Encapsulating Security Payload (ESP)",
                Work in Progress, July 2002.
 [SRPDIST]      Wu, T., "SRP Distribution", http://www-cs-
                students.stanford.edu/~tjw/srp/download.html
 [UDPIPsec]     Huttunen, A., et. al., "UDP Encapsulation of IPsec
                Packets", Work in Progress, June 2002.
 [UMAC]         Black, J., Halevi, S., Krawczyk, H., Krovetz, T.,
                Rogaway, P., "UMAC: Fast and provably secure message
                authentication", Advances in Cryptology - CRYPTO '99,
                LNCS vol. 1666, pp.  216-233.  Full version available
                from http://www.cs.ucdavis.edu/~rogaway/umac

Aboba, et al. Standards Track [Page 57] RFC 3723 Securing Block Storage Protocols over IP April 2004

 [UMACKR]       Krovetz, T., Black, J., Halevi, S., Hevia, A.,
                Krawczyk, H., Rogaway, P., "UMAC: Message
                Authentication Code using Universal Hashing", Work in
                Progress, October 2000.  Also available
                at:http://www.cs.ucdavis.edu/~rogaway/umac/draft-
                krovetz-umac-01.txt
 [UMACPERF]     Rogaway, P., "UMAC Performance",
                http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html

9. Acknowledgments

 Thanks to Steve Bellovin of AT&T Research, William Dixon of V6
 Security, David Black of EMC, Joseph Tardo and Uri Elzur of Broadcom,
 Julo Satran, Ted Ts'o, Ofer Biran, and Charles Kunzinger of IBM,
 Allison Mankin of ISI, Mark Bakke and Steve Senum of Cisco, Erik
 Guttman of Sun Microsystems and Howard Herbert of Intel for useful
 discussions of this problem space.

Aboba, et al. Standards Track [Page 58] RFC 3723 Securing Block Storage Protocols over IP April 2004

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],
 and subsequently rigorously verified to be prime.  Implementations
 supporting SRP authentication MUST support groups up to 1536 bits,
 with 1536 bits being the default.
 iSCSI Key="SRP-768" [768 bits]
 Modulus (base 16) =
 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40
 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF
 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B
 Generator = 2
 iSCSI Key="SRP-1024" [1024 bits]
 Modulus (base 16) =
 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576
 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1
 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC
 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
 Generator = 2
 iSCSI Key="SRP-1280" [1280 bits]
 Modulus (base 16) =
 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4
 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78
 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891
 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163
 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B
 Generator = 2
 iSCSI Key="SRP-1536" [1536 bits]
 Modulus (base 16) =
 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D
 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC
 DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC
 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486
 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E
 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB
 Generator = 2

Aboba, et al. Standards Track [Page 59] RFC 3723 Securing Block Storage Protocols over IP April 2004

 iSCSI Key="SRP-2048" [2048 bits]
 Modulus (base 16) =
 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050
 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50
 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8
 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B
 CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748
 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6
 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6
 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73
 Generator = 2
 In addition to these groups, the following groups MAY be supported,
 each of which has also been rigorously proven to be prime:
 [1]  iSCSI Key="MODP-3072": the 3072-bit [RFC3526] group, generator:
      5
 [2]  iSCSI Key="MODP-4096": the 4096-bit [RFC3526] group, generator:
      5
 [3]  iSCSI Key="MODP-6144": the 6144-bit [RFC3526] group, generator:
      5
 [4]  iSCSI Key="MODP-8192": the 8192-bit [RFC3526] group, generator:
      19

Aboba, et al. Standards Track [Page 60] RFC 3723 Securing Block Storage Protocols over IP April 2004

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  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  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  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aboba, et al. Standards Track [Page 61] RFC 3723 Securing Block Storage Protocols over IP April 2004

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         |         |           |         |         |         |
 |  Data   |  AES-   | AES-CBC-  |  AES-   |  HMAC-  |  HMAC-  |
 |  Size   |  PMAC   | MAC       |  UMAC   |  MD5    |  SHA1   |
 |         |         |           |         |         |         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1152    |  33.53  |   27.17   |   3.69  |  26.3   |  23.99  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1280    |  33.56  |   26.8    |   3.58  |  26.28  |  23.67  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1408    |  33.58  |   26.96   |   3.55  |  25.54  |  23.41  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 1500    |  33.52  |   26.86   |   3.5   |  25.09  |  22.87  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Table B-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, AES-
 UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at various
 packet sizes.
 Source: Jesse Walker, Intel

Aboba, et al. Standards Track [Page 62] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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 63] RFC 3723 Securing Block Storage Protocols over IP April 2004

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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     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     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aboba, et al. Standards Track [Page 64] RFC 3723 Securing Block Storage Protocols over IP April 2004

 Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC
 encryption algorithms at various packet sizes, implemented in
 software.
 Source: Jesse Walker, Intel
 Table B-4 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

Aboba, et al. Standards Track [Page 65] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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.
 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  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     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  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Aboba, et al. Standards Track [Page 66] RFC 3723 Securing Block Storage Protocols over IP April 2004

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |  AES      | AES     |  AES    |         |
 |  Data size    |  CBC +    | CTR +   |  CTR +  |  AES-   |
 |               |  CBCMAC   | CBCMAC  |  UMAC   |  OCB    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    1280       |   57.75   |  55.15  |  31.22  |  36.16  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    1408       |   57.47   |  55.34  |  30.75  |  35.24  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    1500       |   57.72   |  55.5   |  30.86  |  35.3   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Table B-5: Cycles/byte of combined encryption/authentication
 algorithms:  AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and
 AES-OCB at various packet sizes, implemented in software.

Aboba, et al. Standards Track [Page 67] RFC 3723 Securing Block Storage Protocols over IP April 2004

 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.

Aboba, et al. Standards Track [Page 68] RFC 3723 Securing Block Storage Protocols over IP April 2004

Authors' Addresses

 Bernard Aboba
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 Phone: +1 425 706 6605
 Fax:   +1 425 936 7329
 EMail: bernarda@microsoft.com
 Joshua Tseng
 McDATA Corporation
 3850 North First Street
 San Jose, CA 95134-1702
 Phone: +1 650 207 8012
 EMail: joshtseng@yahoo.com
 Jesse Walker
 Intel Corporation
 2211 NE 25th Avenue
 Hillboro, OR 97124
 Phone: +1 503 712 1849
 Fax:   +1 503 264 4843
 EMail: jesse.walker@intel.com
 Venkat Rangan
 Brocade Communications Systems Inc.
 1745 Technology Drive,
 San Jose, CA 95110
 Phone: +1 408 333 7318
 Fax: +1 408 333 7099
 EMail: vrangan@brocade.com
 Franco Travostino
 Director, Content Internetworking Lab
 Nortel Networks
 3 Federal Street
 Billerica, MA  01821
 Phone: +1 978 288 7708
 EMail: travos@nortelnetworks.com

Aboba, et al. Standards Track [Page 69] RFC 3723 Securing Block Storage Protocols over IP April 2004

Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78 and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights 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; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Aboba, et al. Standards Track [Page 70]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3723.txt · Last modified: 2004/04/09 20:10 (external edit)