IPS Working Group                                          Bernard Aboba
INTERNET-DRAFT                                             William Dixon
Category: Informational                                        Microsoft
<draft-ietf-ips-security-03.txt>                             David Black
10 October 2001                                                      EMC
                                                            Joshua Tseng
                                                          Nishan Systems
                                                 Joseph Tardo, Uri Elzur
                                                                Broadcom
                                                      M. Bakke, S. Senum
                                                           Cisco Systems
                                            Howard Herbert, Jesse Walker
                                                                   Intel
                                                               J. Satran
                                                              Ofer Biran
                                                       Charles Kunzinger
                                                                     IBM
                                                           Venkat Rangan
                                                  Rhapsody Networks Inc.
                                                       Franco Travostino
                                                         Nortel Networks

                     Securing iSCSI, iFCP and FCIP

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

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




Aboba, et al.                 Informational                     [Page 1]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Abstract

This document discusses how iSCSI, iFCP, and FCIP may utilize IPsec to
provide authentication, integrity, confidentiality and replay
protection.

Table of Contents

1.     Introduction ..........................................    3
   1.1       iSCSI overview ..................................    3
   1.2       iFCP overview ...................................    3
   1.3       FCIP overview ...................................    4
   1.4       IPsec overview ..................................    4
   1.5       Terminology .....................................    5
   1.6       Requirements language ...........................    6
2.     iSCSI, iFCP and FCIP security .........................    6
   2.1       Security requirements  ..........................    6
   2.2       Resource constraints ............................    9
   2.3       Security protocol ...............................   10
3.     iSCSI security inter-operability guidelines ...........   12
   3.1       iSCSI security issues ...........................   12
   3.2       iSCSI and IPsec interaction .....................   12
   3.3       Initiating a new iSCSI session ..................   13
   3.4       Graceful iSCSI teardown .........................   14
   3.5       Non-graceful iSCSI teardown .....................   15
   3.6       Application layer CRC ...........................   16
4.     iFCP and FCIP security issues .........................   18
   4.1       iFCP and FCIP Authentication Requirements .......   18
   4.2       iFCP Interaction with IPsec and IKE .............   18
   4.3       FCIP Interaction with IPsec and IKE .............   20
5.     Security considerations ...............................   20
   5.1       Transport mode versus tunnel mode ...............   20
   5.2       NAT traversal ...................................   22
   5.3       IKE issues ......................................   22
   5.4       Rekeying issues .................................   23
   5.5       Transform issues ................................   25
   5.6       Fragmentation issues ............................   27
   5.7       Security checks .................................   28
   5.8       Authentication issues ...........................   29
   5.9       Use of AES in counter mode ......................   32
6.     References ............................................   32
Appendix A - Software Performance of IPsec Transforms  .......   37
   A.1       Authentication transforms .......................   37
   A.2       Encryption and Authentication transforms ........   40
Acknowledgments ..............................................   45
Authors' Addresses ...........................................   46
Intellectual property statement ..............................   48
Full Copyright Statement .....................................   49



Aboba, et al.                 Informational                     [Page 2]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


1.  Introduction

This draft proposes use of the IPsec protocol suite for protecting
iSCSI, iFCP and FCIP traffic over IP networks, and discusses how iSCSI,
iFCP and FCIP should be used with IPsec.

1.1.  iSCSI overview

iSCSI, described in [1], is a connection-oriented command/response
protocol that runs over TCP, and is used to access disk, tape and other
devices.  iSCSI is a client-server protocol in which clients
(Initiators) open connections to servers (Targets) and perform an iSCSI
login.

This draft uses the SCSI terms Initiator and Target for clarity and to
avoid the common assumption that clients have considerably less
computational and memory resources than servers; the reverse is often
the case for SCSI, as Targets are commonly dedicated devices of some
form.

The iSCSI protocol has a text based negotiation mechanism as part of its
initial (Login) procedure.  The mechanism is extensible in what can be
negotiated (new text keys and values can be defined) and also in the
number of negotiation rounds (e.g., to accommodate functionality such as
challenge-response authentication).  While the iSCSI login may include
mutual authentication of the iSCSI endpoints and negotiation of session
parameters, iSCSI does not define its own per-packet authentication,
integrity, confidentiality or replay protection mechanisms.

After a successful login, the iSCSI Initiator may issue SCSI commands
for execution by the iSCSI Target, which returns a status response for
each command, over the same connection.  A single connection is used for
both command/status messages as well as transfer of data and/or optional
command parameters.  An iSCSI session may have multiple connections, but
a separate login is performed on each.  The iSCSI session terminates
when its last connection is closed.

iSCSI Initiators and Targets are layer 5 entities that are independent
of TCP ports and IP addresses.  Initiators and Targets have names whose
syntax is defined in [52].  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.

1.2.  iFCP overview

iFCP, defined in [56], is a gateway-to-gateway protocol, which provides
Fibre Channel fabric services to Fibre Channel devices over a TCP/IP



Aboba, et al.                 Informational                     [Page 3]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


network.  iFCP's  primary objective is to allow interconnection and
networking of existing Fibre Channel devices at wire speeds over an IP
network.  The protocol achieves this transparency through a process that
allows normal Fibre Channel frame traffic to pass through the gateway
directly, with provisions where necessary for intercepting and emulating
the fabric services required by a Fibre Channel device. Each IPsec SA
established by IKE protects a single TCP connection, which is used to
support storage traffic between a unique pair of Fibre Channel N_PORTs.

iFCP does not have a native, in-band security mechanism.  Rather, it
relies upon the IPsec protocol suite to provide data confidentiality and
authentication services, and IKE as the key management protocol.  iFCP
uses TCP to provide congestion control, error detection and error
recovery.

1.3.  FCIP overview

FCIP, defined in [57], is a pure FC encapsulation protocol that
transports FC frames. Current specification work intends this for
interconnection of Fibre Channel switches over TCP/IP networks, but the
protocol is not inherently limited to connecting FC switches.  FCIP
differs from iFCP in that no interception or emulation of fabric
services is involved, and  TCP connections are not bound or restricted
to specific FC N_Port pairs.

FCIP does not have a native, in-band security mechanism.  Rather, it
relies upon the IPsec protocol suite to provide data confidentiality and
authentication services, and IKE as the key management protocol.  FCIP
uses TCP to provide congestion control, error detection and error
recovery.

1.4.  IPsec overview

IPsec is a protocol suite which is used to secure communication at the
network layer between two peers.  The IPsec protocol suite is specified
within the IP Security Architecture [6], IKE [7], IPsec Authentication
Header (AH) [3] and IPsec Encapsulating Security Payload (ESP) [4]
documents.  IKE is the key management protocol while AH and ESP are used
to protect IP traffic.

An IPsec SA is a one-way security association, uniquely identified by
the 3-tuple: SPI, protocol (ESP) and destination IP.  The parameters for
an IPsec security association are typically established by a key
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 [54]. IKE has two phases, and accomplishes



Aboba, et al.                 Informational                     [Page 4]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


the following functions:

[1]  Protected cipher suite and options negotiation - using keyed HMACs
     and encryption and anti-replay mechanisms

[2]  Master key generation - via MODP Diffie-Hellman calculations

[3]  Authentication of end-points

[4]  IPsec SA management (selector negotiation, options negotiation,
     create, delete, and rekeying)

Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is
handled in IKE Phase 2.

An IKE phase 2 negotiation is performed to establish both an inbound and
an outbound IPsec SAs.  The traffic to be protected by an IPSec SA is
determined by a selector which has been proposed by the IKE Initiator
and accepted by the IKE responder.  In IPsec transport mode, the IPsec
SA selector can be a "filter" or traffic classifier, defined as the
5-tuple: <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 a MODP Diffie-Hellman computation.  Rekeying of an existing
IPsec SA pair is accomplished by creating two new IPsec SAs, making them
active, and then optionally deleting the older IPsec SA pair.  Typically
the new outbound SA is used immediately, and the old inbound SA is left
active to receive packets for some locally defined time, perhaps 30
seconds or 1 minute.

1.5.  Terminology

Fibre Channel
          Fibre Channel (FC) is a gigabit speed networking technology
          primarily used to implement Storage Area Networks (SANs).  FC
          is standardized under American National Standard for
          Information Systems of the National Committee for Information
          Technology Standards (ANSI-NCITS) in its T11 technical
          committee.

FCIP      Fibre Channel over IP (FCIP) is a protocol for interconnecting
          islands of Fibre Channel SANs over IP Networks so as to form a
          unified SAN in a single Fibre Channel fabric. The principal
          FCIP interface point to the IP Network is the FCIP Entity. The



Aboba, et al.                 Informational                     [Page 5]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


          FCIP Link represents one or more TCP connections that exist
          between a pair of FCIP Entities.

iFCP      iFCP is a gateway-to-gateway protocol, which provides Fibre
          Channel fabric services to Fibre Channel devices over a TCP/IP
          network.

iSCSI     iSCSI is a client-server protocol in which clients
          (Initiators) open connections to servers (Targets).

iSNS      The Internet Storage Name Server (iSNS) protocol provides for
          discovery and management of iSCSI and Fibre Channel (FCP)
          storage devices.  iSNS applications store iSCSI and FC device
          attributes and monitor their availability and reachability,
          providing a consolidated information repository for an
          integrated IP storage network.  iFCP requires iSNS for
          discovery and management, while iSCSI may use iSNS for
          discovery, and FCIP does not use iSNS.

Initiator The iSCSI Initiator connects to the Target on well-known TCP
          port <TBD>. 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",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
described in [2].

Although the security requirements in this document are already
incorporated into the iSCSI [1], iFCP [56] and FCIP [57] standards track
documents, they are reproduced here for convenience.  In the event of a
discrepancy, the standards track documents take precedence.

2.  iSCSI, iFCP and FCIP security

2.1.  Security requirements

The iSCSI, iFCP and FCIP protocols are used to transmit SCSI commands
over IP networks.  Therefore, both the control and data packets of
iSCSI, iFCP and FCIP are vulnerable to attack.  Examples of attacks
include:





Aboba, et al.                 Informational                     [Page 6]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


[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 iSCSI, iFCP or
     FCIP connection.

[4]  An adversary may attempt to hijack TCP connection(s) corresponding
     to an iSCSI, iFCP or FCIP session.

[5]  An adversary may launch denial of service attacks against iSCSI,
     iFCP or FCIP 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 logon.

[7]  An adversary may attempt to impersonate a legitimate FCIP Entity,
     iSCSI Target or Initiator, or iFCP gateway.

[8]  An adversary may launch a variety of attacks (packet modification
     or injection, denial of service) against the discovery (SLPv2) or
     discovery and management (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, the iSCSI, iFCP and FCIP security
protocols MUST provide confidentiality, data origin authentication,
integrity, and replay protection on a per-datagram basis.  They also
MUST provide a scalable approach to key management.  Confidentiality
services are important since iSCSI, iFCP and FCIP traffic may traverse
insecure public networks.

Due to the high data transfer rates and the amount of data involved,
iSCSI, iFCP and FCIP security protocols MUST support rekeying each phase
2 SA in time intervals as often as every 25 seconds.  The iSCSI, iFCP
and FCIP 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.                 Informational                     [Page 7]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Given current networking technology, iSCSI, iFCP and FCIP security MUST
be implementable at 1 Gbps in terms of CPU overhead and/or availability
of suitable hardware implementations and SHOULD be implementable at 10
Gbps in the near future. 10 Gbps implementations are desirable but are
not an absolute requirement as implementation feasibility at these
speeds is not yet demonstrated.

These performance levels apply to aggregate throughput, and include all
TCP connections used between iSCSI, iFCP or FCIP endpoints.  iSCSI, iFCP
and FCIP communications typically involve multiple TCP connections.
Since each IPsec security association only protects a single TCP
connection, it does not necessarily need to support the entire aggregate
throughput. Through use of multiple processing engines that
independently support individual security associations, implementations
may be able to scale to 10Gbps throughput in the aggregate.

Enterprise data center networks are considered mission-critical
facilities that must be isolated and protected from all possible
security threats.  Such networks are usually protected by security
gateways, which at a minimum provide a shield against denial of service
attacks.  The iSCSI, iFCP and FCIP security architecture should be able
to leverage the protective services of the existing security
infrastructure, including firewall protection, NAT and NAPT services,
and VPN services available on existing security gateways.

When iFCP or FCIP devices are deployed within enterprise networks, IP
addresses will be typically be statically assigned in the same manner as
most routers and switches.  Consequently, support for dynamic IP
address assignment, as described in [55], 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 iSCSI, iFCP, and FCIP security protocols MUST NOT introduce
additional security vulnerabilities where dynamic address assignment is
supported.

Note that while iSCSI, iFCP and FCIP 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 logon, as well as the security services (encryption,
authentication, integrity, replay protection) and transforms negotiated
when IPsec is used to protect iSCSI, iFCP or FCIP.

It MUST be possible for compliant iSCSI, iFCP and FCIP implementations
to administratively disable any and all security mechanisms.  FCIP
implementations may allow enabling and disabling security mechanisms at
the granularity of an FCIP Link.  For iFCP, the granularity corresponds
to a TCP connection (which corresponds to an  <N_PORT, N_PORT> session).



Aboba, et al.                 Informational                     [Page 8]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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.

iSNS, described in [58], is required in all iFCP deployments.  iSCSI may
use iSNS for discovery, and FCIP does not use iSNS.  iSNS applications
store iSCSI and FC device attributes and monitor their availability and
reachability, providing a consolidated information repository for an
integrated IP storage network.  The iSNS specification defines
mechanisms to secure communication between an iSNS server and its
clients.

2.2.  Resource constraints

iFCP and FCIP devices will typically be embedded systems deployed on
racks in air-conditioned data center facilities.  Such embedded systems
may include hardware chipsets to provide data encryption,
authentication, and integrity processing.  Therefore, memory and CPU
resources are generally not a constraining factor.

iSCSI will be implemented on a variety of systems ranging from large
servers running general purpose operating systems to embedded host bus
adapters (HBAs). Host Bus Adapter is a generic term for a SCSI interface
to other device(s); it's roughly analogous to the term Network Interface
Card (NIC) for a TCP/IP network interface, except that HBAs generally
have on-board SCSI implementations, whereas most NICs do not implement
TCP, UDP, or IP.  In general, a host bus adapter is the most constrained
iSCSI implementation environment, although an HBA may draw upon the
resources of the system to which it is attached in some cases (e.g.,
authentication computations required for connection setup).  More
resources should be available to iSCSI implementations for embedded and
general purpose operating systems.  The following guidelines indicate
the approximate level of resources that authentication, keying, and
rekeying functionality can reasonably expect to draw upon:

  - Low power processors with small word size are generally not used,
    as power is usually not a constraining factor, with the possible
    exception of HBAs, which can draw upon the computational resources
    of the system into which they are inserted).  Computational
    horsepower should be available to perform a reasonable amount of
    exponentiation as part of authentication and key derivation for
    connection setup.  The same is true of rekeying, although the
    ability to avoid exponentiation for rekeying may be desirable (but
    is not an absolute requirement).

  - RAM and/or flash resources tend to be constrained in embedded
    implementations.  8-10 MB of code and data for authentication,
    keying, and rekeying is clearly excessive, 800-1000 KB is clearly



Aboba, et al.                 Informational                     [Page 9]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


    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.

2.3.  Security protocol

All iSCSI, iFCP, and FCIP security compliant implementations MUST
support the ESP protocol  [4] to provide security for both control
packets and data packets. Conformant  iSCSI security implementations
MUST support ESP in transport mode.  Conformant iFCP and FCIP
implementations MUST support ESP in tunnel mode and MAY support ESP in
transport mode, such as when there are no intervening IPsec gateways or
NA(P)Ts, and use of middleboxes is not contemplated by local
administrative policies.  All iSCSI, FCIP, and iFCP security compliant
implementations MUST support the replay protection mechanisms of IPsec.

To provide confidentiality with ESP, ESP with 3DES in CBC mode MUST be
supported, and AES in Counter mode, as described in [53], SHOULD be
supported.  To provide data origin authentication and integrity with
ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC
extensions [38] SHOULD be supported. DES in CBC mode SHOULD NOT be  used
due to its inherent weakness.  ESP with NULL encryption MUST be
supported.  If confidentiality is not required but data origin
authentication and integrity is enabled,  ESP with NULL encryption MUST
be used.





Aboba, et al.                 Informational                    [Page 10]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Conformant iSCSI, FCIP, and iFCP security implementations MUST support
IKE [7] for peer authentication, negotiation of security associations,
and key management, using the IPSec DOI [5].  Manual keying MUST NOT be
used since it does not provide the necessary rekeying support.
Conformant iSCSI, iFCP and FCIP 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
[7] SHOULD NOT be used.

Conformant iSCSI, FCIP and iFCP security implementations MUST support
both IKE Main Mode and Aggressive Mode.  When pre-shared keys are used
for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main
Mode SHOULD NOT be used.  When digital signatures are used for
authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used.
In all cases, access to  locally stored secret information (pre-shared
key,  or private  key for digital signing) MUST be suitably restricted,
since compromise of the secret information nullifies the security
properties of the IKE/IPsec protocols.

When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify the
certificate authority (or authorities) that are trusted in accordance
with its local policy.  IKE negotiators SHOULD check the pertinent
Certificate Revocation List (CRL) before accepting a PKI certificate for
use in IKE's authentication procedures.

The Phase 2 Quick Mode exchanges used to negotiate protection for the
TCP connections used by iSCSI, iFCP and FCIP MUST explicitly carry the
Identity Payload fields (IDci and IDcr).  The DOI [5] provides for
several types of identification data.  However, when used in conformant
iSCSI, iFCP and FCIP security  implementations, each ID Payload MUST
carry a single IP address and a single non-zero port number, and MUST
NOT use the IP Subnet or IP Address Range formats.  This allows the
Phase 2 security association to correspond to specific TCP and iSCSI,
iFCP and FCIP connections.

To support authenticaiton between the iSCSI Initiator and Target, the
Secure Remote Password (SRP) protocol described in RFC 2945 [48] MUST be
implemented within the iSCSI text-based multi-round negotiation
mechanism. A number of additional authentication protocols have also
been specified in the current iSCSI draft.  Negotiation between
Initiator and Target is used to determine which authentication algorithm
to use (or whether to use one at all); the connection closes if either
side requires authentication and no mutually acceptable algorithm can be
agreed upon.





Aboba, et al.                 Informational                    [Page 11]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


3.  iSCSI security inter-operability guidelines

The following guidelines are established to meet iSCSI security
requirements using IPsec in practical situations.

3.1.  iSCSI security issues

iSCSI provides for iSCSI logon, 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 logon authentication do not meet the
security requirements for iSCSI. iSCSI logon 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 logon authentication can mutually authenticates the Initiator to
the Target, but does not by itself provide per-packet authentication,
integrity, confidentiality or replay protection. In addition, iSCSI
logon authentication, outlined in [1], does not provide for a protected
ciphersuite negotiation.  Therefore, iSCSI logon provides a weak
security solution.

3.2.  iSCSI and IPsec interaction

An iSCSI session [1], comprised of one or more TCP connections, is
identified by the 2-tuple of the Initiator-defined identifier and the
Target-defined identifier, <ISID, TSID>.  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



Aboba, et al.                 Informational                    [Page 12]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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 a
     separate IKE Phase 2 SA, with selectors specific to that TCP
     connection. Each IKE Phase 2 SA protects only a single TCP
     connection, and each TCP connection is transported under only one
     IKE Phase 2 SA.

Given this, all the information needed for the iSCSI/IPsec binding is
contained within the iSCSI Login messages from the iSCSI Initiator and
Target. This includes the binding between an IKE Phase 1 SA and the
corresponding iSCSI sessions, as well as the binding between an IPsec
Phase 2 SA and the TCP connection and iSCSI connection ID.

3.3.  Initiating a New iSCSI Session

In order to create a new iSCSI Session, an Initiator implementing iSCSI
security first establishes IKE Phase 1 and Phase 2 SAs, then exchanges
iSCSI control messages over an IPsec-secured TCP connection.  The iSCSI
Initiator contacts the Target on well-known TCP port <TBD>. The
Initiator and Target implementations MUST successfully complete the IKE
phase 1 and Phase 2 negotiations before the initial TCP connection setup
messages are exchanged so that these messages can be IPsec protected.
IPsec implementations configured with the correct policies (e.g. use ESP
with non-null transform for all traffic destined to or originating from
the iSCSI well-known TCP port) will handle this automatically.

Once an IKE Phase 1 SA is established, subsequent iSCSI connections
established within the iSCSI session will typically be protected by IKE
Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE
Phase 1 SAs can also be brought up.

Once the IKE Phase 2 negotiations are complete and the TCP connection is
established over IPsec, the iSCSI Initiator MUST send the iSCSI Login
command over the TCP connection secured by the recently negotiated Quick



Aboba, et al.                 Informational                    [Page 13]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Mode SA.

The Initiator fills in the ISID field, and leaves the TSID field set to
zero, to indicate that it is the first message of a new session
establishment exchange.  The Initiator also fills in a CID value, that
identifies the TCP connection over which the Login command is being
exchanged. When the iSCSI Target replies with its Login Command, both
iSCSI devices will know the TSID, and therefore the iSCSI session
identifier <ISID, TSID>.

A single iSCSI session identifier may have multiple associated IKE Phase
1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI session
identifiers. Each iSCSI connection (identified by the connection
identifier) corresponds to a single TCP connection (identified by the
5-tuple) and IPsec Phase 2 SA. Each IKE Phase 2 SA corresponds to a
single IKE Phase 1 SA, and is identified by the <Protocol (ESP),
destination address, SPI> combination.

Before adding a new TCP connection to an existing iSCSI Session, a new
IKE Quick Mode exchange MUST occur, under the protection of an IKE Phase
1 SA. This can be existing IKE Phase 1 SA, or a new IKE Phase 1 SA can
be brought up for this purpose.

Within IKE, each key refresh requires that a new security association be
established.  In practice there is a time interval during which an old,
about-to-expire SA and newly established SA will both be valid.  The
IPsec implementation will choose which security association to use based
on local policy, and iSCSI concerns play no role in this selection
process.

3.4.  Graceful iSCSI Teardown

Mechanisms within iSCSI provide for both graceful and non-graceful
teardown of iSCSI Sessions or individual TCP connections within a given
session.  The iSCSI Logout command is used to effect graceful teardown.
This command allows the iSCSI Initiator to request that:

[a]  the session be closed

[b]  a specific connection within the session be closed

[c]  a specific connection be marked for recovery, or

[d]  a specific connection be closed at the Target's request.  LP
     Command [d] is distinct from [b] in that it indicates that the
     connection is being closed in response to a request from the Target
     for it to be closed. Due to asymmetries in the iSCSI protocol,
     Targets cannot close a connection on their own initiative.



Aboba, et al.                 Informational                    [Page 14]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


When the iSCSI implementation wishes to close a session, it MUST use the
appropriate iSCSI commands to accomplish this.  After exchanging the
appropriate iSCSI control messages for session closure, the iSCSI
security implementation SHOULD initiate a half-close of each TCP
connection within the iSCSI session. Since a given IKE Phase 1 SA may
correspond to multiple iSCSI sessions, the iSCSI implementation will
only delete the IKE Phase 1 SAs corresponding to the iSCSI session if
there are no remaining iSCSI sessions corresponding to those SAs. For
those Phase 1 SAs that are deleted, the iSCSI security implementation
will also delete the IKE Phase 2 SAs bound to them first, before
deleting the Phase 1 SA.

When the iSCSI security implementation wishes to close an individual TCP
connection while leaving the parent iSCSI session active, it SHOULD
half-close the TCP connection. This results in a FIN being sent, putting
the TCP connection into the FIN WAIT-1 state, as described in [10].
After the other side responds, the TIME WAIT state is entered. After the
expiration of the TIME WAIT timeout, the IKE Phase 2 security
association bound to the TCP connection can be closed. Closing the TCP
connection prior to deleting the IKE Phase 2 SA ensures that all the TCP
packets sent on the connection are IPsec-protected.

3.5.  Non-graceful iSCSI Teardown

If a given TCP connection unexpectedly fails, the associated iSCSI
connection is torn down. Some time after this, the IKE Phase 2 security
association will typically be deleted; however, there is no requirement
that an IKE Phase 2 delete immediately follow iSCSI connection tear
down. Similarly, if the IKE implementation receives a Phase 2 Delete
message for a security association corresponding to a TCP connection,
this does not necessarily imply that the TCP or iSCSI connection is to
be torn down.

If a Logout Command/Logout Response sequence marks a connection for
removal from the iSCSI session, then after the iSCSI peer has executed
an iSCSI teardown process for the connection, the TCP connection will be
closed. The iSCSI connection state can then be safely removed.

Since the IKE Phase 2 SA corresponding to the TCP connection may not be
immediately deleted and can remain up for some time, iSCSI
implementations SHOULD NOT depend on receiving the IPsec Phase 2 delete
as confirmation that the iSCSI peer has executed an iSCSI teardown
process for the connection.

Since IPsec acceleration hardware may only be able to handle a limited
number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent
for idle SAs, as a means of keeping the number of active Phase 2 SAs to
a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be



Aboba, et al.                 Informational                    [Page 15]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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.

If an IKE implementation receives a Phase 1 Delete message for a Phase 1
Security Association bound to one or more iSCSI sessions, then it SHOULD
delete the associated IKE Phase 2 security associations.

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 [16], when operating at high speeds, the
16-bit TCP checksum [11] will not necessarily detect all errors,
resulting in possible data corruption.  iSCSI [1] therefore incorporates
a 32-bit CRC to protect its headers and data.

When a CRC check fails (i.e.  CRC computed at receiver does not match
the received CRC), the iSCSI PDU covered by that CRC is discarded.
Since presumably the error was not detected by the TCP checksum, TCP
retransmission will not occur and thus cannot assist in recovering from
the error.  iSCSI contains both data and command retry mechanisms to
deal with the resulting situations, including SNACK, the ability to
reissue R2T commands, and the retry (X) bit for commands.

IPsec offers protection against an attacker attempting to modify packets
in transit, as well as unintentional packet modifications caused by
router malfunctions. In general, IPsec authentication transforms afford
stronger integrity protection than both the 16-bit TCP checksum and the
32-bit application-layer CRC that has been proposed for use with iSCSI.
Since IPsec integrity protection occurs below TCP, if an error is
discovered, then the packet will be discarded and TCP retransmission
will occur, so that no recovery action need be taken at the iSCSI layer.

3.6.1.  Simplification of recovery logic

Where IPsec integrity protection is known to be in place, and covers the
entire connection between iSCSI endpoints (or the portion that requires
additional integrity connection), portions of iSCSI can be simplified.
For example, mechanisms to recover from CRC check failures are not
necessary.

If the iSCSI CRC is negotiated, the recovery logic SHOULD simplified to
regard any CRC check failure as fatal (e.g., generate a SCSI CHECK
CONDITION on data error, close the corresponding TCP connection on



Aboba, et al.                 Informational                    [Page 16]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


header error) because it will be very rare for errors undetected by
IPsec integrity protection to be detected by the iSCSI CRC.

3.6.2.  Omission of iSCSI CRC

In some situations where IPsec is employed, the iSCSI CRC will not
provide additional protection, and can be omitted.

For example, where IPsec processing as well as TCP checksum and iSCSI
CRC verification are offloaded within the NIC, each of these checks will
be verified prior to transferring data across the bus, so that
subsequent errors will not be detected.  As a result, where IPsec
processing is offloaded to the NIC, the iSCSI CRC is not necessary and
the implementations may wish not to negotiate it.

However, in other circumstances, the TCP checksum and iSCSI CRC will
provide additional protection, and it is desirable to negotiate use of
the iSCSI CRC even though IPsec is available. These situations occur
where:

[1]  IPsec, TCP and iSCSI are implemented purely in software.  Here,
     additional failure modes may be detected by the TCP checksum and/or
     iSCSI CRC. For example, after the IPsec message integrity check is
     successfully verified, the segment is copied as part of TCP
     processing, and a memory error during this process might cause the
     TCP checksum or iSCSI CRC verification to fail.

[2]  The implementation is an iSCSI-iSCSI proxy or gateway. Here the
     iSCSI CRC can be propagated from one iSCSI connection to another.
     In this case, the iSCSI CRC is useful to protect iSCSI data against
     memory, bus, or software errors within the proxy or gateway, and
     requesting it is desirable.

[3]  IPsec is provided by a device external to the actual iSCSI device.
     Here the iSCSI header and data CRCs can be kept across the part of
     the connection that is not protected by IPsec. For instance, the
     iSCSI connection could traverse an extra bus, interface card,
     network, interface card, and bus between the iSCSI device and the
     device providing IPsec. In this case, the iSCSI CRC is desirable,
     and the iSCSI implementation behind the IPsec device may request
     it.

     Note that if both ends of the connection are on the same segment,
     then traffic will be effectively protected by the layer 2 CRC, so
     that negotiation of the iSCSI CRC is not necessary.






Aboba, et al.                 Informational                    [Page 17]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


4.  iFCP and FCIP security issues

4.1.  iFCP and FCIP Authentication Requirements

iFCP and FCIP are peer-to-peer protocols.  iFCP and FCIP sessions may be
initiated by either or both peer gateways. Consequently, bi-directional
authentication of peer gateways MUST be provided.

iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre
Channel frames over IP. Therefore, Fibre Channel, operating system, and
user identities are transparent to the iFCP and FCIP protocols.  In iFCP
and FCIP, IP addresses MUST be used as the identities for IKE
authentication.

iFCP gateways use Discovery Domain information obtained from the iSNS
server to determine whether the initiating Fibre Channel N_PORT should
be allowed access to the Target N_PORT.  N_PORT identities used in the
Port Login (PLOGI) process will be considered authenticated provided
that they are received over a connection whose security complies with
the local security policy.

There is no requirement that the identities used in authentication be
kept confidential.

4.2.  iFCP Interaction with IPsec and IKE

iFCP devices may have more than one interface and IP address.  For iFCP,
multiple TCP connections to other iFCP devices may exist at each
interface and IP address.

An active iFCP session is supported by one and only one TCP connection.
This iFCP session is identified by the 2-tuple of the two communicating
N_PORT ID's (3 byte Fibre Channel Port Identifier).  A TCP connection is
bound to an iFCP session using the CBIND message.

Each IP address supporting iFCP communication can establish one or more
Phase-1 IKE Security Associations (SA) to other IP addresses configured
at peering iFCP gateways, using the IP address as identity.  IKE Phase 1
SAs may be established at gateway initialization, or may be brought up
when TCP connections matching the IPsec security policy are established.

Unlike Phase-1 SAs, a Phase-2 SA maps to an individual TCP connection.
Once the phase 2 security association is established, it protects the
TCP setup process and all subsequent TCP traffic.  As a result, before a
new TCP connection to a remote iFCP or device is established, IKE MUST
negotiate a phase 2 security association using Quick Mode to protect
that new connection.  Where the correct IPsec policy is in place,
mandating IPsec protection of packets destined to and from the iFCP



Aboba, et al.                 Informational                    [Page 18]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


well-known port, this will occur automatically.

iFCP connections protected by the phase 2 SA are either in the unbound
state, or are bound to a specific <N_PORT, N_PORT> session.  The
creation of an IKE Phase-2 SA to protect an iFCP connection may be
triggered by a policy rule supplied through a management interface, or
by N_PORT properties registered with the iSNS. For iFCP, the use of Key
Exchange payload in Quick Mode for perfect forward secrecy may be
dictated through a management interface, or by N_PORT properties
registered with the iSNS.  Multiple implementation strategies, are
permitted so as to enable establishment of IKE Phase 2 SAs at different
times. Examples of implementation strategies include:

[1]  There exists a unique iFCP security policy for all TCP connections
     regardless of their bound or unbound state. Thus, an unbound TCP
     connection can be bound to a <N_PORT, N_PORT> session without the
     need to bring up a new IKE Phase-2 SA.

[2]  There exist multiple choices of iFCP security policy for unbound
     TCP connections and active <N_PORT, N_PORT> sessions. An unbound
     TCP connection becomes bound to a <N_PORT, N_PORT> session after
     establishing a new IKE Phase-2 SA matching the new security policy
     for that N_PORT session.

[3]  The iFCP implementation does not support TCP connections lingering
     in an unbound state. Both a IKE Phase-2 SA and a TCP connection
     need to be started anew anytime a new <N_PORT, N_PORT> session is
     identified.

If an iFCP implementation strategy uses unbound TCP connections, then an
IKE Phase-2 SA MUST protect each of such unbound connections.

Upon receiving a Phase 1 delete message, an iFCP implementation MUST
tear down all the Phase 2 SAs spawned off of that Phase 1 SA, and then
the Phase 1 SA itself.

iSNS [52] is an invariant in all iFCP deployments. iFCP gateways use
iSNS for discovery services, and MAY use security policies configured in
the iSNS as the basis for algorithm negotiation in IKE.  iFCP
implementations MAY administratively disable any and all security
mechanisms, on a per <N_PORT, N_PORT> basis. This implies that IKE and
IPsec security associations may not be established for one or more
<N_PORT, N_PORT> sessions. A configuration of this type may be
accomplished through a management interface, or through attributes set
in the iSNS server.






Aboba, et al.                 Informational                    [Page 19]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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.

Each TCP connection within an FCIP Link uses an independently negotiated
IKE Phase 2 (Quick Mode) SA. This is established prior to sending the
initial TCP SYN packet and applies to the life of the connection. Phase
2 negotiation is also required for rekeying, in order to protect against
replay attacks.

FCIP implementations MAY provide administrative management of
Confidentiality usage. These management interfaces SHOULD be provided in
a secure manner, so as to prevent an attacker from subverting the
security process by attacking the management interface.

FCIP Entites do not require any user-level authentication, since all
FCIP Entities participate in a machine-level tunnel function.

FCIP uses SLP for discovery. However, SLP is not used to distribute
security policies.

5.  Security considerations

5.1.  Transport mode versus tunnel mode

With respect to storage protocols, the major differences between the
IPsec tunnel mode and transport mode are as follows:

[1]  MTU considerations. Tunnel mode introduces an additional IP header
     into the datagram that reflects itself in a corresponding decrease
     in the path MTU seen by packets traversing the tunnel. This may
     result in a decrease in the maximum segment size of TCP connections
     running over the tunnel.

[2]  Dynamic address assignment. Where tunnel mode is used in situations
     where IP addresses are dynamically assigned (such as with
     dynamically addressed hosts implementing iSCSI), support for



Aboba, et al.                 Informational                    [Page 20]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


     address assignment within IPsec tunnel mode is required.  The use
     of DHCP within IPsec tunnel mode has been proposed for this, as
     described in [55]. However, this mechanism is not yet widely
     deployed within IPsec security gateways.

[3]  NAT traversal. As noted in [20], 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 [21]-[23] can be
     implemented. More details are provided in the next section.

[4]  Connection-specific selectors. For both transport and tunnel mode,
     it is possible to negotiate connection-specific selectors, so that
     only a single iSCSI, iFCP or FCIP connection will be protected by
     an IKE Phase 2 SA. While negotiation of connection-specific
     selectors is common within IPsec transport mode implementations,
     IPsec security gateway implementations typically negotiate "ANY to
     ANY" selectors by default.

[5]  Firewall traversal. Where a storage protocol is to traverse
     administrative domains, the firewall administrator may desire to
     verify the integrity and authenticity of each transiting packet,
     rather than opening a hole in the firewall for the storage
     protocol. IPsec tunnel mode lends itself to such verification,
     since the firewall can terminate the tunnel mode connection while
     still allowing the endpoints to communicate end-to-end. If desired,
     the endpoints can in addition utilize IPsec transport mode for end-
     to-end security, so that they can also verify authenticity and
     integrity of each packet for themselves.

     In contrast, carrying out this verification with IPsec transport
     mode is more complex, since the firewall will need to terminate the
     IPsec transport mode connection and will need to act as an iSCSI,
     iFCP or FCIP gateway or TCP proxy, originating a new IPsec
     transport mode connection from the firewall to the internal
     endpoint. Such an implementation cannot provide end-to-end
     authenticity or integrity protection, and an application-layer CRC
     (iSCSI) or forwarding of the Fibre Channel frame CRC (iFCP and
     FCIP) is necessary to protect against errors introduced by the
     firewall.

[6]  IPsec-application integration. Where IPsec and the application
     layer protocol are implemented on the same device or host, it is
     possible to enable tight integration between them. For example, the
     application layer can request and verify that connections are
     protected by IPsec, and can obtain attributes of the IPsec security
     association. While in transport mode implementations the IPsec and
     application protocol implementations typically reside on the same



Aboba, et al.                 Informational                    [Page 21]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


     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.2.  NAT traversal

As noted in [20], tunnel mode ESP can traverse NAT in a limited set of
circumstances. For example, if there is only one protocol endpoint
behind a NAT, "ANY to ANY" selectors are negotiated, and the receiver
does not perform source address validation, then tunnel mode ESP may
successfully traverse NATs.  Since ignoring source address validation
introduces new security vulnerabilities, and negotiation of specific
selectors is desirable so as to limit the traffic that can be sent down
the tunnel, these conditions may not necessarily apply, and tunnel mode
NAT traversal will not always be possible.

Transport mode ESP cannot traverse NAT, even though ESP itself does not
include IP header fields within its message integrity check. This is
because the 16-bit TCP checksum is calculated based on a "pseudo-header"
that includes IP header fields, and the checksum is protected by the
IPsec message integrity check. As a result, the TCP checksum will be
invalidated by a NAT located between the two endpoints.

Since TCP checksum calculation and verification is mandatory in both
IPv4 and IPv6, it is not possible to omit checksum verification while
remaining standards compliant.  In order to enable traversal of NATs
existing while remaining in compliance, iSCSI, iFCP or FCIP security
implementations MAY implement IPsec/IKE NAT traversal, as described in
[20]-[23].

The IPsec/IKE NAT traversal specification [23] enables 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.





Aboba, et al.                 Informational                    [Page 22]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


As noted in Table 1 on the next page, IKE implementations currently
exist which meet the requirements. Therefore, while removal of seldomly
used IKE functionality (such as the nonce authentication methods) would
reduce complexity, implementations typically will not require this in
order to fit within the code size budget.

5.4.  Rekeying issues

It is expected that iSCSI, iFCP and FCIP implementations will need to
operate at high speed. For example, implementations operating at 1 Gbps
are currently in design, with 10 Gbps implementations to follow shortly
thereafter. At these speeds, a single IPsec SA could rapidly cycle
through the 32-bit IPsec sequence number space.

For example, a single SA operating at 1 Gbps line rate and sending 64
octet packets would exhaust the 32-bit sequence number space in 2200
seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur
in 14.5 hours.

At 10 Gbs, exhaustion would occur in 220 seconds or 3.67 minutes. With
1518 octet packets, this would occur within 1.45 hours.

As a result, iSCSI, iFCP and FCIP implementations operating at speeds of
1 Gbps or less MAY implement the IPsec sequence number extension,
described in [49]. 10 Gbps or faster implementations SHOULD implement
the extension specification.

Note that depending on the transform in use, it is possible that
rekeying will be required prior to exhaustion of the sequence number
space.  Bellare et. al. have formalized this in [51], 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.

This formula sets a limit on the bytes that can be sent on a CBC SA
before a rekey is required:

            B = s * n/8 = (n/8) * 2^(n/2)

Where:
            B = maximum bytes sent on the SA
            n = block size in bits









Aboba, et al.                 Informational                    [Page 23]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | 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 1 - Code Size for IKE implementations















Aboba, et al.                 Informational                    [Page 24]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


This means that cipher block size as well as key length need to be
considered in the rekey decision. 3DES uses a block size n = 64 bits
(2^3 bytes); this implies that the SA must be rekeyed before B = (64/8)
* (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 practice, a safety margin is required
so the required rekey times will be even smaller.

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.  This is s = 2^26 * 2^6 = 2^32
blocks and (2^32)^2/2^64 = 1.  With the 3DES cipher in CBC mode, it
would be prudent to rekey more often, such as every 2^20 messages or
2^29 bytes. This would imply a rekey time of 4.29 seconds at 1 Gbps or
0.43 seconds at 10 Gbps.

In comparison, AES-CBC uses a block size of 128 bits (2^4 bytes).  This
enables B = (128/8) * (2^64) = 2^68 bytes to be sent prior to requiring
a rekey. This means that the required rekey times are 2^33 times longer
than for 3DES.

In terms of the sequence number space, for an AES encrypted message of
512 = 2^9 bytes (2^5 blocks) this implies that the key has become
insecure after about 2^59 messages (2^59 * 2^5)^2/2^128 = 1.  This means
that the entire current ESP sequence space of 2^32 messages could be
consumed without compromising the key. AES would still permit a safe CBC
mode construction if the ESP sequence space were expanded to 48 bits,
since (2^48 * 2^5)^2/2^128 = 2^-22.

5.5.  Transform issues

Since iSCSI, iFCP and FCIP 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



Aboba, et al.                 Informational                    [Page 25]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


algorithms may be considered.

Section 5 of RFC 2406 [4] states:

   "A compliant ESP implementation MUST support the following
   mandatory-to-implement algorithms:

         - DES in CBC mode
         - HMAC with MD5
         - HMAC with SHA-1
         - NULL Authentication algorithm
         - NULL Encryption algorithm
   "

The DES algorithm is specified in [29]; implementation guidelines are
found in [30], and security issues are discussed in [31],[43], [17]. The
DES IPsec transform is defined in [32] and the 3DES in CBC mode IPsec
transform is specified in [33].

The MD5 algorithm is specified in [8]; HMAC is defined in [19] and
security issues with MD5 are discussed in [19]. The HMAC-MD5 IPsec
transform is specified in [24].  The HMAC-SHA1 IPsec transform is
specified in [25].

In addition to these existing algorithms, NIST is currently evaluating
the following modes [37] of AES, defined in [34],[35]:

     AES in Electronic Codebook (ECB) confidentiality mode
     AES in Cipher Block Chaining (CBC) confidentiality mode
     AES in Cipher Feedback (CFB) confidentiality mode
     AES in Output Feedback (OFB) confidentiality mode
     AES in Counter (CTR) confidentiality mode
     AES CBC-MAC authentication mode

The Modes [36] effort is also considering a number of additional
algorithms, including the following:

     PMAC

To provide authentication, integrity and replay protection, iSCSI, iFCP
and FCIP security implementations MUST support HMAC-SHA1 for
authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be
supported [38].

HMAC-SHA1 [25] is to be preferred to HMAC-MD5, due to concerns that have
been raised about the security of MD5 [9].  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



Aboba, et al.                 Informational                    [Page 26]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


specification [25] exists. As a result, it is most practical to utilize
HMAC-SHA1 as the authentication algorithm for products shipping in the
near future.  The HMAC-SHA2 algorithm [28] is also under development,
including an IPsec transform [45], so that this may merit consideration
in the future.  AES in CBC-MAC authentication mode with XCBC extensions
was selected since it avoids adding substantial additional code if AES
is already being implemented for encryption; an IPsec transform document
is available [38].

Authentication transforms also exist that are considerably more
efficient to implement than HMAC-SHA1, HMAC-SHA2 or AES in CBC-MAC
authentication mode.  UMAC [27],[44] is more efficient to implement in
software and PMAC [26] is more efficient to implement in hardware.  PMAC
is currently being evaluated as part of the NIST modes effort [36] but
an IPsec transform does not yet exist; neither does a UMAC transform.

For confidentiality, the ESP mandatory-to-implement algorithm (DES) is
unacceptable.  As noted in [17], 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
[33] MUST be supported and AES in Counter Mode [53] SHOULD be supported.
Note that 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 that it is practical to
implement 3DES in products for the short term.

As described in Appendix A, 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, and the certificate chains are
long enough, then IKE fragmentation can occur. Routers in the path will
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, the endpoints will be unable to establish an IPsec
security association.  The solution to this problem is to reduce the
size of the certificate chain, or to install router code loads that can



Aboba, et al.                 Informational                    [Page 27]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


support fragment filtering.

Fragmentation can become a concern when prepending IPsec headers to a
frame. One mechanism which can be used to reduce this problem is to
utilize path MTU discovery.  For example, when TCP is used as the
transport for iSCSI, iFCP or FCIP then path MTU discovery [11]-[13], can
be used to enable the TCP endpoints to discover the correct MTU,
including effects due to IPsec encapsulation.

However, Path MTU discovery fails when appropriate ICMP messages are not
received by the host. This occurs in IPsec implementations which drop
unauthenticated ICMP packets.  This can result in blackholing in naive
TCP implementations, as described in [14].  Appropriate TCP behavior is
described in section 2.1 of [14]:

   "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 [6], 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, iSCSI, iFCP and
FCIP SHOULD check to ensure that the connection is protected by IPsec.
If IPsec protection is removed on a connection, it MUST be reinstated
before iSCSI, iFCP or FCIP 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 iSCSI, iFCP and FCIP can be assured
that each received packet was sent by a trusted peer.

When used with iSCSI, iFCP or FCIP, IPsec MUST negotiate a separate
Phase 2 SA for each TCP connection, with selectors specific to the TCP
connection.  As a result, only traffic for a single TCP connection will
flow within each IPsec Phase 2 SA. iSCSI, iFCP and FCIP security
implementations need not verify that the IP addresses and TCP port
values in the packet match the socket information which was used to
setup the connection. This check will be performed by IPsec, preventing
malicious peers from sending commands on inappropriate Quick Mode SAs.






Aboba, et al.                 Informational                    [Page 28]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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 user. 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 logon (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 logon, for these protocols only the machine is authenticated.

In circumstances in which this dual assurance is considered valuable,
enabling movement of the machine certificate from one machine to
another, as would be possible if the machine certificate were stored on
a smart card, may be undesirable.

Similarly, when user certificate are deployed, it is advisable for the
user enrollment process to be strictly controlled. If for example, a
user password can be readily used to obtain a certificate (either a
temporary or a longer term one), then that certificate has no more
security value than the password. To limit the ability of an attacker to
obtain a user certificate from a stolen password, the enrollment period
can be limited, after which password access will be turned off.  Such a
policy will prevent an attacker obtaining the password of an unused
account from obtaining a user certificate once the enrollment period has
expired.







Aboba, et al.                 Informational                    [Page 29]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


5.8.2.  Pre-shared keys

Use of pre-shared keys in IKE main mode is vulnerable to man-in-the-
middle attacks when used with dynamically addressed hosts (such as with
iSCSI Initiators). In main mode it is necessary for SKEYID_e to be used
prior to the receipt of the identification payload. Therefore the
selection of the pre-shared key may only be based on information
contained in the IP header. However, where dynamic IP address assignment
is typical, it is often not possible to identify the required pre-shared
key based on the IP address.

Thus when main mode pre-shared keys are used with iSCSI, iFCP or FCIP
entities whose address is dynamically assigned, the same pre-shared key
is shared by a group of Initiators and is no longer able to function as
an effective shared secret.  In this situation, neither the Initiator
nor responder identifies itself during IKE phase 1; it is only known
that both parties are a member of the group with knowledge of the pre-
shared key. This permits anyone with access to the group pre-shared key
to act as a man-in-the-middle.  This vulnerability is typically not of
concern with iFCP and FCIP, since iFCP and FCIP devices typically use
statically defined addresses, so that individual pre-shared keys are
possible within IKE main mode.

This vulnerability also does not occur 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.

As a result, where main mode is used with pre-shared keys and
dynamically addressed hosts, unless application-layer mutual
authentication is performed (e.g. iSCSI logon), the Responder is not
authenticated. This enables a rogue Responder in possession of the group
pre-shared key to successfully masquerade as the actual Responder and
mount a dictionary attack on legacy authentication methods such as CHAP
[47]. Such an attack could potentially compromise many passwords at a
time.  This vulnerability is widely present in existing IPsec
implementations.

As a result, where iSCSI, iFCP, or FCIP Entities utilize dynamic address
assignment along with pre-shared key authentication, IKE Agressive Mode
MUST be used.

5.8.3.  IKE and application-layer authentication

In addition to IKE authentication, iSCSI implementations utilize their
own authentication methods, such as those described in [48]. Currently,
work is underway on Fibre Channel security, so that a similar



Aboba, et al.                 Informational                    [Page 30]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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 logon 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 logon 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 logon is using the IPsec SA.

In fact, IPsec implementations that only support machine authentication
typically have no way to distinguish between user traffic within the
kernel. As a result, where machine authentication is used, once an IPsec
SA is opened, another user on a multi-user machine may be able to send
traffic down the IPsec SA.

To limit the potential vulnerability, iSCSI, iFCP or FCIP security
implementations MUST negotiate a separate IPsec Phase 2 SA for each
connection, with descriptors specific to that connection. This will
prevent traffic for other connections from traveling within the IPsec SA
negotiated for another connection.  As a result, if access to the TCP
socket used for the connection is exclusive, then access to the
corresponding IPsec SA will also be exclusive, even if the IPsec
implementation only supports machine authentication.

If the IPsec implementation supports user authentication, the user
identity asserted within IKE will be verified on a per-packet basis, and
stronger assurances can be provided.  In this case, the user identity
asserted within IKE will be verified on a per-packet basis. In order to
provide segregation of traffic between users when user authentication is
used, the sender MUST ensure that only traffic from that particular user
is sent down the 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.



Aboba, et al.                 Informational                    [Page 31]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Once the device is mounted, ACLs set by the filesystem control access to
the device. An administrator can access the blocks on the device
directly (for instance, by sending pass through requests to the port
driver directly such as in Windows NT). In the same way, an
administrator can open raw socket and send IPsec protected packets to an
iSCSI Target. The situation is analogous, and in this respect no new
vulnerability is created that didn't previously exist. The Operating
system's ACLs need to be effective to protect a device (whether it is a
SCSI device or an iSCSI device).

5.9.  Use of AES in counter mode

When AES in counter mode is used, it is important to avoid reuse of the
counter with the same key, even across all time. Counter mode creates
ciphertext by XORing generated key stream with plaintext. It is fairly
easy to recover the plaintext from two messages counter mode encrypted
under the same counter value, simply by XORing together the two packets.
The implication of this is that it is almost always an error to use
IPsec manual keying with counter mode, except when the implementation
takes heroic measures to maintain state across sessions.

Another counter mode issue is it makes forgery of correct packets
trivial. Counter mode should therefore never be used without also using
data authentication.

6.  References

[1]  Satran, J., et al., "iSCSI", Internet draft (work in progress),
     draft-ietf-ips-iSCSI-06.txt, April 2001.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[3]  Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402,
     November 1998.

[4]  Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)",
     RFC 2406, November 1998.

[5]  Piper, D., "The Internet IP Security Domain of Interpretation of
     ISAKMP", RFC 2407, November 1998.

[6]  Atkinson, R., Kent, S., "Security Architecture for the Internet
     Protocol", RFC 2401, November 1998.

[7]  Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
     2409, November 1998.




Aboba, et al.                 Informational                    [Page 32]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


[8]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
     1992.

[9]  Dobbertin, H., "The Status of MD5 After a Recent Attack",
     CryptoBytes Vol.2 No.2, Summer 1996.

[10] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
     September 1981.

[11] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November
     1990.

[12] Knowles, S., "IESG Advice from Experience with Path MTU Discovery",
     RFC 1435, March 1993.

[13] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
     version 6", RFC 1981, August 1996.

[14] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923,
     September 2000.

[15] Paxon, V., "End-to-end internet packet dynamics", IEEE Transactions
     on Networking 7,3 (June 1999) pg 277-292.

[16] Stone J., Partridge, C., "When the CRC and TCP checksum disagree",
     ACM Sigcomm, Sept. 2000.

[17] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.

[18] Krueger, M., et.al., "iSCSI Requirements and Design
     Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in
     Progress, July 2001.

[19] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for
     Message Authentication", RFC 2104, February 1997.

[20] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-ietf-
     ipsec-nat-reqts-00.txt, Work in Progress, June 2001.

[21] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", draft-
     ietf-ipsec-udp-encaps-00.txt, June 2001

[22] Dixon, W. et. al., "IPsec over NAT Justification for UDP
     Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt,
     June 2001

[23] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE",
     Internet draft (work in progress), draft-ietf-ipsec-nat-t-



Aboba, et al.                 Informational                    [Page 33]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


     ike-00.txt, June 2001.

[24] Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP and AH",
     RFC 2403, November 1998.

[25] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and
     AH", RFC 2404, November 1998.

[26] 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

[27] 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

[28] "Descriptions of SHA-256, SHA-384, and SHA-512,"
     http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf.

[29] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October
     25, 1999.

[30] U.S. DoC/NIST, "Guidelines for implementing and using the nbs data
     encryption standard", FIPS 74, Apr 1981.

[31] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- like
     cryptosystems", Journal of Cryptology Vol 4, Jan 1991.

[32] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With
     Explicit IV", RFC 2405, November 1998.

[33] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms", RFC
     2451, November 1998.

[34] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES
     Proposal, June 1998.  http://csrc.nist.gov/encryption/aes/round2/
     AESAlgs/Rijndael/Rijndael.pdf

[35] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)",
     U.S. DoC/NIST, summer 2001.

[36] "Symmetric Key Block Cipher Modes of Operation,"
     http://www.nist.gov/modes.

[37] "Recommendation for Block Cipher Modes of Operation", National
     Institute of Standards and Technology (NIST) Special Publication



Aboba, et al.                 Informational                    [Page 34]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


     800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington,
     DC, July 2001.

[38] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm and
     Its Use with IPsec", Internet draft (work in progress), draft-ietf-
     ipsec-ciph-aes-cbc-01.txt, May 2001.

[39] Moskowitz, R., Walker, J., "The AES128 OCB Mode of Operation and
     Its Use with IPsec", Internet draft (work in progress), draft-
     moskowitz-aes128-ocb-00.txt, September 2001.

[40] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", Comment
     on mode of operations NIST, Jan 2001.

[41] 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

[42] A. Bosselaers, "Performance of Pentium implementations",
     http://www.esat.kuleuven.ac.be/~bosselae/

[43] Bellovin, S., "An Issue With DES-CBC When Used Without Strong
     Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995.

[44] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H.,
     Rogaway, P., "UMAC: Message Authentication Code using Universal
     Hashing", Internet draft (work in progress), draft-krovetz-
     umac-01.txt, October 2000.

[45] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and SHA-512
     within ESP, AH and IKE," Work in progress.

[46] Dierks, T. and  C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
     November 1998.

[47] Simpson, W.,"PPP Challenge Handshake Authentication Protocol
     (CHAP)," RFC 1994, August 1996.

[48] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945,
     September 2000.

[49] Steve Kent, IPsec sequence number extension proposal, IETF 50.

[50] 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.





Aboba, et al.                 Informational                    [Page 35]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


[51] 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/

[52] Bakke, M., et.al., "iSCSI Naming and Discovery", draft-ietf-ips-
     iscsi-name-disc-02.txt, Work in Progress, August 2001.

[53] Walker, J., Moskowitz, R., "The AES128 CTR Mode of Operation and
     Its Use with IPsec", Internet draft (work in progress), draft-
     moskowitz-aes128-ctr-00.txt, September 2001.

[54] Maughan, D., Schertler, M., Schneider, M., Turner, J., "Internet
     Security Association and Key Management Protocol (ISAKMP), RFC
     2408, November 1998.

[55] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 Configuration
     of IPsec Tunnel Mode", Internet draft (work in progress), draft-
     ietf-ipsec-dhcp-13.txt, June 2001.

[56] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel
     Storage Networking", Internet drafts (work in progress), draft-
     ietf-ips-ifcp-04.txt, August 2001.

[57] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", Internet
     draft (work in progress), draft-ietf-ips-fcovertcpip-05.txt, August
     2001.

[58] Gibbons, K., et al., "iSNS Internet Storage Name Service", Internet
     draft (work in progress), draft-ietf-ips-isns-04.txt, June 2001.






















Aboba, et al.                 Informational                    [Page 36]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


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

A.1 Authentication transforms

Table A-1 presents the cycles/byte required by the AES-PMAC, AES-CBC-
MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet
sizes, implemented in software.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         |         |           |         |         |         |
|  Data   |  AES-   | AES-CBC-  |  AES-   |  HMAC-  |  HMAC-  |
|  Size   |  PMAC   | MAC       |  UMAC   |  MD5    |  SHA1   |
|         |         |           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   64    |  31.22  |   26.02   |  19.51  |  93.66  | 109.27  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  128    |  33.82  |   28.62   |  11.06  |  57.43  |  65.04  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  192    |  34.69  |   26.02   |   8.67  |  45.09  |  48.56  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  256    |  33.82  |   27.32   |   7.15  |  41.63  |  41.63  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  320    |  33.3   |   27.06   |   6.24  |  36.42  |  37.46  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  384    |  33.82  |   26.88   |   5.42  |  34.69  |  34.69  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  448    |  33.45  |   26.76   |   5.39  |  32.71  |  31.96  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  512    |  33.82  |   26.67   |   4.88  |  31.22  |  30.57  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  576    |  33.53  |   26.59   |   4.77  |  30.64  |  29.48  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  640    |  33.3   |   26.54   |   4.42  |  29.66  |  28.62  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+











Aboba, et al.                 Informational                    [Page 37]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         |         |           |         |         |         |
|  Data   |  AES-   | AES-CBC-  |  AES-   |  HMAC-  |  HMAC-  |
|  Size   |  PMAC   | MAC       |  UMAC   |  MD5    |  SHA1   |
|         |         |           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  768    |  33.82  |   26.88   |   4.23  |  28.18  |  27.32  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  896    |  33.45  |   27.13   |   3.9   |  27.5   |  25.64  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1024    |  33.5   |   26.67   |   3.82  |  26.99  |  24.71  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1152    |  33.53  |   27.17   |   3.69  |  26.3   |  23.99  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1280    |  33.56  |   26.8    |   3.58  |  26.28  |  23.67  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1408    |  33.58  |   26.96   |   3.55  |  25.54  |  23.41  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1500    |  33.52  |   26.86   |   3.5   |  25.09  |  22.87  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Table A-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
(See also http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html
for additional data)























Aboba, et al.                 Informational                    [Page 38]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Table A-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 A-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.                 Informational                    [Page 39]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


A.2 Encryption and Authentication transforms

Table A-3 presents the cycles/byte required by the AES-CBC, AES-CTR and
3DES-CBC encryption algorithms (no MAC), implemented in software, for
various packet sizes.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             |             |             |
|  Data size    |   AES-CBC   |   AES-CTR   |  3DES-CBC   |
|               |             |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      64       |   31.22     |    26.02    |  156.09     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     128       |   31.22     |    28.62    |  150.89     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     192       |   31.22     |    27.75    |  150.89     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     256       |   28.62     |    27.32    |  150.89     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     320       |   29.14     |    28.1     |  150.89     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     384       |   28.62     |    27.75    |  148.29     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     448       |   28.99     |    27.5     |  149.4      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     512       |   28.62     |    27.32    |  148.29     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     576       |   28.33     |    27.75    |  147.72     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     640       |   28.62     |    27.06    |  147.77     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




















Aboba, et al.                 Informational                    [Page 40]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             |             |             |
|  Data size    |   AES-CBC   |   AES-CTR   |  3DES-CBC   |
|               |             |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     768       |   28.18     |    27.32    |  147.42     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     896       |   28.25     |    27.5     |  147.55     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1024       |   27.97     |    27.32    |  148.29     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1152       |   28.33     |    27.46    |  147.13     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1280       |   28.1      |    27.58    |  146.99     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1408       |   27.91     |    27.43    |  147.34     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1500       |   27.97     |    27.53    |  147.85     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Table A-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC
encryption algorithms at various packet sizes, implemented in
software.

Source: Jesse Walker, Intel


























Aboba, et al.                 Informational                    [Page 41]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Table A-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 A-4: Software performance of the AES-CBC, AES-CTR, and 3DES
encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates
(1500 byte packet).

Source: Jesse Walker, Intel

At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a
high-speed processor, while 3DES would require multiple high speed
processors. At speeds of 1 Gbps, multiple high speed processors are
required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES,
and 10 Gbps for all algorithms, implementation in software is
infeasible, and hardware acceleration is required.

















Aboba, et al.                 Informational                    [Page 42]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Table A-5 presents the cycles/byte required for combined
encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR +
CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented
in software.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |  AES      | AES     |  AES    |         |
|  Data size    |  CBC +    | CTR +   |  CTR +  |  AES-   |
|               |  CBCMAC   | CBCMAC  |  UMAC   |  OCB    |
|               |           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      64       |  119.67   |  52.03  |  52.03  |  57.23  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     128       |   70.24   |  57.23  |  39.02  |  44.23  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     192       |   58.97   |  55.5   |  36.42  |  41.63  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     256       |   57.23   |  55.93  |  35.12  |  40.32  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     320       |   57.23   |  55.15  |  33.3   |  38.5   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     384       |   57.23   |  55.5   |  32.95  |  37.29  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     448       |   58.72   |    55   |  32.71  |  37.17  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     512       |   58.54   |  55.28  |  32.52  |  36.42  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
























Aboba, et al.                 Informational                    [Page 43]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |  AES      | AES     |  AES    |         |
|  Data size    |  CBC +    | CTR +   |  CTR +  |  AES-   |
|               |  CBCMAC   | CBCMAC  |  UMAC   |  OCB    |
|               |           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     576       |   57.81   |  55.5   |  31.8   |  37     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     640       |   57.75   |  55.15  |  31.74  |  36.42  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     768       |   57.67   |  55.5   |  31.65  |  35.99  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     896       |   57.61   |  55.75  |  31.22  |  35.68  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1024       |   57.56   |  55.61  |  31.22  |  35.45  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1152       |   57.52   |  55.21  |  31.22  |  35.55  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1280       |   57.75   |  55.15  |  31.22  |  36.16  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1408       |   57.47   |  55.34  |  30.75  |  35.24  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    1500       |   57.72   |  55.5   |  30.86  |  35.3   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Table A-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.                 Informational                    [Page 44]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Table A-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 A-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC,
AES CTR + UMAC, and AES-OCB encryption and authentication algorithms,
operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps,
assuming 1500 octet packets.

Source: Jesse Walker, Intel

At speeds of 100 Mbps, the algorithms are implementable on a high speed
processor. At speeds of 1 Gbps, multiple high speed processors are
required, and none of the algorithms are implementable in software at 10
Gbps line rate.

Acknowledgments

Thanks to Steve Bellovin of AT&T Research for useful discussions of this
problem space.




Aboba, et al.                 Informational                    [Page 45]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 936 6605
EMail: bernarda@microsoft.com

William Dixon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 703 8729
EMail: wdixon@microsoft.com

David L. Black
EMC Corporation
42 South Street
Hopkinton, MA 01748

Phone: +1 508 435 1000 x75140
EMail: black_david@emc.com

Joshua Tseng
Nishan Systems
3850 North First Street
San Jose, CA 95134-1702

Phone: +1 408 519 3749
EMail: jtseng@nishansystems.com

Joseph J. Tardo
Broadcom
3151 Zanker Road
San Jose, CA 95134

Phone: +1 408 501 8445
Fax: +1 408 501 8460
EMail: jtardo@broadcom.com

Mark Bakke
Cisco Systems, Inc.
6450 Wedgwood Road, Suite 130
Maple Grove, MN 55311




Aboba, et al.                 Informational                    [Page 46]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Phone: +1 763 398 1000
Fax: +1 763 398 1001
EMail: mbakke@cisco.com

Steve Senum
Cisco Systems, Inc.
6450 Wedgwood Road, Suite 130
Maple Grove, MN 55311

Phone: <TBD>
Fax: +1 763 398 1001
EMail: ssenum@cisco.com

Howard Herbert
Intel Corporation
5000 West Chandler Blvd.
M/S CH7-404
Chandler, Arizona 85226

Phone: +1 480 554 3116
EMail: howard.c.herbert@intel.com

Jesse Walker
Intel Corporation
2211 NE 25th Avenue
Hillboro, Oregon 97124

Phone: +1 503 712 1849
Fax:   +1 503 264 4843
Email: jesse.walker@intel.com

Julian Satran
IBM, Haifa Research Lab
MATAM - Advanced Technology Center
Haifa 31905, Israel

Phone +972 4 829 6264
EMail: Julian_Satran@vnet.ibm.com

Ofer Biran
IBM, Haifa Research Lab
MATAM - Advanced Technology Center
Haifa 31905, Israel

Phone +972 4 829 6253
Email: biran@il.ibm.com





Aboba, et al.                 Informational                    [Page 47]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Charles Kunzinger
IBM Corporation
Research Triangle Park, NC 27709

Phone: +1 919 254 4142
EMail: kunzinge@us.ibm.com

Venkat Rangan
Rhapsody Networks Inc.
3450 W. Warren Ave.
Fremont, CA 94538

Phone: +1 510 743 3018
Fax: +1 510 687 0136
EMail: venkat@rhapsodynetworks.com

Franco Travostino
Director, Content Internetworking Lab,
Nortel Networks
3 Federal Street
Billerica, MA  01821

Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.





Aboba, et al.                 Informational                    [Page 48]


INTERNET-DRAFT         Securing iSCSI, iFCP & FCIP       10 October 2001


Full Copyright Statement

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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expiration Date

This memo is filed as <draft-ietf-ips-security-03.txt>, and expires May
1, 2002.























Aboba, et al.                 Informational                    [Page 49]