tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3723


Securing Block Storage Protocols over IP

Part 2 of 3, p. 28 to 51
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 28 
3.  iSCSI Security Interoperability Guidelines

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

3.1.  iSCSI Security Issues

   iSCSI provides for iSCSI Login, outlined in [RFC3720], which includes
   support for application-layer authentication.  This authentication is
   logically between the iSCSI initiator and the iSCSI target (as
   opposed to between the TCP/IP communication endpoints).  The intent
   of the iSCSI design is that the initiator and target represent the
   systems (e.g., host and disk array or tape system) participating in
   the communication, as opposed to network communication interfaces or

   The iSCSI protocol and iSCSI Login authentication do not meet the
   security requirements for iSCSI.  iSCSI Login authentication provides
   mutual authentication between the iSCSI initiator and target at
   connection origination, but does not protect control and data traffic
   on a per packet basis, leaving the iSCSI connection vulnerable to
   attack.  iSCSI Login authentication can mutually authenticate the
   initiator to the target, but does not by itself provide per-packet
   authentication, integrity, confidentiality or replay protection.  In

Top      Up      ToC       Page 29 
   addition, iSCSI Login authentication does not provide for a protected
   ciphersuite negotiation.  Therefore, iSCSI Login provides a weak
   security solution.

3.2.  iSCSI and IPsec Interaction

   An iSCSI session [RFC3720], comprised of one or more TCP connections,
   is identified by the 2-tuple of the initiator-defined identifier and
   the target-defined identifier, <ISID, TSIH>.  Each connection within
   a given session is assigned a unique Connection Identification, CID.
   The TCP connection is identified by the 5-tuple <Source IP address,
   Destination IP address, Protocol (TCP), Source Port, Destination
   Port>.  An IPsec Phase 2 SA is identified by the 3-tuple <Protocol
   (ESP),destination address, SPI>.

   The iSCSI session and connection information is carried within the
   iSCSI Login Commands, transported over TCP.  Since an iSCSI initiator
   may have multiple interfaces, iSCSI connections within an iSCSI
   session may be initiated from different IP addresses.  Similarly,
   multiple iSCSI targets may exist behind a single IP address, so that
   there may be multiple iSCSI sessions between a given <source IP
   address, destination IP address> pair.

   When multiple iSCSI sessions are active between a given <initiator,
   target> pair, the set of TCP connections used by a given iSCSI
   session must be disjoint from those used by all other iSCSI sessions
   between the same <initiator, target> pair.  Therefore a TCP
   connection can be associated with one and only one iSCSI session.

   The relationship between iSCSI sessions, TCP connections and IKE
   Phase 1 and Phase 2 SAs is as follows:

   [1]  An iSCSI initiator or target may have more than one interface,
        and therefore may have multiple IP addresses.  Also, multiple
        iSCSI initiators and targets may exist behind a single IP
        address.  As a result, an iSCSI Session may correspond to
        multiple IKE Phase 1 Security Associations, though typically a
        single IKE Phase 1 security association will exist for an
        <initiator IP address, target IP address> tuple.

   [2]  Each TCP connection within an iSCSI Session is protected by an
        IKE Phase 2 SA.  The selectors may be specific to that TCP
        connection or may cover multiple connections.  While each IKE
        Phase 2 SA may protect multiple TCP connections, each TCP
        connection is transported under only one IKE Phase 2 SA.

Top      Up      ToC       Page 30 
   Given this, all the information needed for the iSCSI/IPsec binding is
   contained within the iSCSI Login messages from the iSCSI initiator
   and target.  This includes the binding between an IKE Phase 1 SA and
   the corresponding iSCSI sessions, as well as the binding between a
   TCP connection, an IKE Phase 2 SA and the iSCSI connection ID.

3.3.  Initiating a New iSCSI Session

   In order to create a new iSCSI Session, if an IKE Phase 1 SA does not
   already exist, then it is established by an initiator implementing
   iSCSI security.  Subsequent iSCSI connections established within the
   iSCSI session will typically be protected by IKE Phase 2 SAs derived
   from that IKE Phase 1 SA, although additional IKE Phase 1 SAs can
   also be brought up.

   The initiator and target implementations successfully complete the
   IKE Phase 1 and Phase 2 negotiations before the iSCSI initiator
   contacts the target on well-known TCP port 3260, and sends the iSCSI
   Login command over the TCP connection.  IPsec implementations
   configured with the correct policies (e.g., use ESP with non-null
   transform for all traffic destined for the iSCSI well-known TCP port
   3260) will handle this automatically.

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

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

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

Top      Up      ToC       Page 31 
3.4.  Graceful iSCSI Teardown

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

   [a]  the session be closed

   [b]  a specific connection within the session be closed

   [c]  a specific connection be marked for recovery

   When the iSCSI implementation wishes to close a session, it uses the
   appropriate iSCSI commands to accomplish this.  After exchanging the
   appropriate iSCSI control messages for session closure, the iSCSI
   security implementation will typically initiate a half-close of each
   TCP connection within the iSCSI session.

   When the iSCSI security implementation wishes to close an individual
   TCP connection while leaving the parent iSCSI session active, it
   should half-close the TCP connection.  After the expiration of the
   TIME_WAIT timeout, the TCP connection is closed.

3.5.  Non-graceful iSCSI Teardown

   If a given TCP connection unexpectedly fails, the associated iSCSI
   connection is torn down.  There is no requirement that an IKE Phase 2
   delete immediately follow iSCSI connection tear down or Phase 1
   deletion.  Since an IKE Phase 2 SA may correspond to multiple TCP
   connections, such a deletion might be inappropriate.  Similarly, if
   the IKE implementation receives a Phase 2 Delete message for a
   security association corresponding to a TCP connection, this does not
   necessarily imply that the TCP or iSCSI connection is to be torn

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

   Since an IKE Phase 2 SA may be used by multiple TCP connections, an
   iSCSI implementation should not depend on receiving the IPsec Phase 2
   delete as confirmation that the iSCSI peer has executed an iSCSI
   teardown process for the connection.

Top      Up      ToC       Page 32 
   Since IPsec acceleration hardware may only be able to handle a
   limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
   be sent for idle SAs, as a means of keeping the number of active
   Phase 2 SAs to a minimum.  The receipt of an IKE Phase 2 delete
   message MUST NOT be interpreted as a reason for tearing down the
   corresponding iSCSI connection if no Logout Command/Logout Receive
   has been executed on the connection.  Rather, it is preferable to
   leave the iSCSI connection up, and if additional traffic is sent on
   it, to bring up another IKE Phase 2 SA to protect it.  This avoids
   the potential for continually bringing iSCSI connections up and down.

3.6.  Application-Layer CRC

   iSCSI's error detection and recovery assumes that the TCP and IP
   checksums provide inadequate integrity protection for high speed
   communications.  As described in [CRCTCP], when operating at high
   speeds, the 16-bit TCP checksum [RFC793] will not necessarily detect
   all errors, resulting in possible data corruption.  iSCSI [RFC3720]
   therefore incorporates a 32-bit CRC to protect its headers and data.

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

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

3.6.1.  Simplification of Recovery Logic

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

Top      Up      ToC       Page 33 
   If the iSCSI CRC is negotiated, the recovery logic can be simplified
   to regard any CRC check failure as fatal (e.g., generate a SCSI CHECK
   CONDITION on data error, close the corresponding TCP connection on
   header error) because it will be very rare for errors undetected by
   IPsec integrity protection to be detected by the iSCSI CRC.

3.6.2.  Omission of iSCSI CRC

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

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

   However, in other circumstances, the TCP checksum and iSCSI CRC will
   provide additional error coverage because they are computed and
   checked at a different point in the protocol stack or in devices
   different from those that implement the IPsec integrity checks.  The
   resulting coverage of additional possible errors may make it
   desirable to negotiate use of the iSCSI CRC even when IPsec integrity
   protection is in use.  Examples of these situations include where:

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

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

   [3]  IPsec is provided by a device external to the actual iSCSI
        device.  Here the iSCSI header and data CRCs can be kept across
        the part of the connection that is not protected by IPsec.  For
        instance, the iSCSI connection could traverse an extra bus,
        interface card, network, interface card, and bus between the

Top      Up      ToC       Page 34 
        iSCSI device and the device providing IPsec.  In this case, the
        iSCSI CRC is desirable, and the iSCSI implementation behind the
        IPsec device may request it.

        Note that if both ends of the connection are on the same
        segment, then traffic will be effectively protected by the layer
        2 CRC, so that negotiation of the iSCSI CRC is not necessary to
        protect against NIC and network errors, although it may be
        desirable for other reasons (e.g., [1] and [2] above).

4.  iFCP and FCIP Security Issues

4.1.  iFCP and FCIP Authentication Requirements

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

   iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre
   Channel frames over IP.  Therefore, Fibre Channel, operating system,
   and user identities are transparent to the iFCP and FCIP protocols.

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

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

4.2.  iFCP Interaction with IPsec and IKE

   A conformant iFCP Portal is capable of establishing one or more IKE
   Phase-1 Security Associations (SAs) to a peer iFCP Portal.  A Phase-1
   SA may be established when an iFCP Portal is initialized, or may be
   deferred until the first TCP connection with security requirements is

   An IKE Phase-2 SA protects one or more TCP connections within the
   same iFCP Portal.  More specifically, the successful establishment of
   an IKE Phase-2 SA results in the creation of two uni-directional
   IPsec SAs fully qualified by the tuple <SPI, destination IP address,
   ESP>.  These SAs protect the setup process of the underlying TCP
   connections and all their subsequent TCP traffic.  Each of the TCP
   connections protected by an SA is either in the unbound state, or is
   bound to a specific iFCP session.

Top      Up      ToC       Page 35 
   In summary, at any point in time:

   [1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals
   [2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs
   [3] Each IKE Phase-2 SA protects 0..Z TCP connections

   The creation of an IKE Phase-2 SA may be triggered by security policy
   rules retrieved from an iSNS server.  Alternately, the creation of an
   SA may be triggered by policy rules configured through a management
   interface, reflecting iSNS-resident policy rules.  Likewise, the use
   of a Key Exchange payload in Quick Mode for perfect forward secrecy
   may be driven by security policy rules retrieved from the iSNS
   server, or set through a management interface.

   If an iFCP implementation makes use of unbound TCP connections, and
   such connections belong to an iFCP Portal with security requirements,
   then the unbound connections MUST be protected by an SA at all times
   just like bound connections.

   Upon receiving an IKE Phase-2 delete message, there is no requirement
   to terminate the protected TCP connections or delete the associated
   IKE Phase-1 SA.  Since an IKE Phase-2 SA may be associated with
   multiple TCP connections, terminating such connections might in fact
   be inappropriate and untimely.

   To minimize the number of active Phase-2 SAs, IKE Phase-2 delete
   messages may be sent for Phase-2 SAs whose TCP connections have not
   handled data traffic for a while.  To minimize the use of SA
   resources while the associated TCP connections are idle, creation of
   a new SA should be deferred until new data are to be sent over the

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.

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

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

   FCIP Entities do not require any user-level authentication, since all
   FCIP Entities participate in a machine-level tunnel function.  FCIP
   uses SLP for discovery, but not to distribute security policies.

5.  Security Considerations

5.1.  Transport Mode Versus Tunnel Mode

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

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

   [2]  Address assignment and configuration.
        Within IPsec tunnel mode, it is necessary for inner and outer
        source addresses to be configured, and for inner and outer
        destination addresses to be discovered.  Within transport mode
        it is only necessary to discover a single destination address
        and configure a single source address.  IPsec tunnel mode
        address usage considerations are discussed in more detail below.

   [3]  NAT traversal.
        As noted in [RFC3715], IPsec tunnel mode ESP can traverse NAT in
        limited circumstances, whereas transport mode ESP cannot
        traverse NAT.  To enable NAT traversal in the general case, the
        IPsec NAT traversal functionality described in [RFC3715],
        [UDPIPsec] and [NATIKE] can be implemented.  More details are
        provided in the next section.

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

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

   [5]  IPsec-application integration.
        Where IPsec and the application layer protocol are implemented
        on the same device or host, it is possible to enable tight
        integration between them.  For example, the application layer
        can request and verify that connections are protected by IPsec,
        and can obtain attributes of the IPsec security association.
        While in transport mode implementations the IPsec and
        application protocol implementations typically reside on the
        same host, with IPsec tunnel mode they may reside on different
        hosts. Where IPsec is implemented on an external gateway,
        integration between the application and IPsec is typically not
        possible.  This limits the ability of the application to control
        and verify IPsec behavior.

5.1.1.  IPsec Tunnel Mode Addressing Considerations

   IPsec tunnels include both inner and outer source as well as
   destination addresses.

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

Top      Up      ToC       Page 38 
   The outer destination address represents the address of the IPsec
   security gateway used to reach the peer.  Several mechanisms have
   been proposed for discovering the IPsec security gateway used to
   reach a particular peer.  [RFC2230] discusses the use of KX Resource
   Records (RRs) for IPsec gateway discovery.  However, while KX RRs are
   supported by many DNS server implementations, they have not yet been
   widely deployed.  Alternatively, DNS SRV [RFC2782] can be used for
   this purpose.  Where DNS is used for gateway location, DNS security
   mechanisms such as DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and
   Simple Secure Dynamic Update [RFC3007] are advisable.

   When used with IP block storage protocols, the outer source address
   is configured either statically or dynamically, using mechanisms such
   as DHCPv4 [RFC2131], DHCPV6 [RFC3315], or stateless address
   autoconfiguration [RFC2373].

   The inner source address SHOULD be included in the Quick Mode ID
   payload when the peer establishes a tunnel mode SA with the IPsec
   security gateway.  This enables the IPsec security gateway to
   properly route packets back to the remote peer.  The inner source
   address can be configured via a variety of mechanisms, depending on
   the scenario.  Where the IP block storage peers are located within
   the same administrative domain, it is typically possible for the
   inner and outer source addresses to be the same.  This will work
   because the outer source address is presumably assigned from within a
   prefix assigned to the administrative domain, and is therefore
   routable within the domain. Assuming that the IPsec security gateway
   is aware of the inner source address used by the connecting peer and
   plumbs a host route for it, then packets arriving at the IPsec
   security gateway destined for the address can be correctly
   encapsulated and sent down the correct tunnel.

   Where IP block storage peers are located within different
   administrative domains, it may be necessary for the inner source
   address to be assigned by the IPsec security gateway, effectively
   "joining" the remote host to the LAN attached to the IPsec security
   gateway.  For example, if the remote peer were to use its assigned
   (outer) source address as the inner source address, then a number of
   problems might result:

   [1]  Intrusion detection systems sniffing the LAN behind the IPsec
        security gateway would notice source addresses originating
        outside the administrative domain.

   [2]  Reply packets might not reach their destination, since the IPsec
        security gateway typically does not advertise the default route,
        but rather only the prefix that it allocates addresses from.
        Since the remote peer's address does not originate from with a

Top      Up      ToC       Page 39 
        prefix native to the administrative domain, it is likely that
        routers within the domain would not have a route for it, and
        would send the packet off to the router advertising the default
        route (perhaps a border router) instead of to the IPsec security

   For these reasons, for inter-domain use, assignment of inner source
   addresses may be needed.  At present this is not a very common
   scenario; however, if address assignment is provided, then DHCP-based
   address assignment within IPsec tunnel mode [RFC3456] MUST be
   supported.  Note that this mechanism is not yet widely deployed
   within IPsec security gateways; existing IPsec tunnel mode servers
   typically implement this functionality via proprietary extensions to

5.2.  NAT Traversal

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

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

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

Top      Up      ToC       Page 40 
   The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications
   enable UDP encapsulation of IPsec to be negotiated if a NAT is
   detected in the path.  By determining the IP address of the NAT, the
   TCP checksum can be calculated based on a pseudo-header including the
   NAT-adjusted address and ports.  If this is done prior to calculating
   the IPsec message integrity check, TCP checksum verification will not

5.3.  IKE Issues

   There are situations where it is necessary for IKE to be implemented
   in firmware.  In such situations, it is important to keep the size of
   the IKE implementation within strict limits.  An upper bound on the
   size of an IKE implementation might be considered to be 800 KB, with
   80 KB enabling implementation in a wide range of situations.

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

5.4.  Rekeying Issues

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

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

   In the future, it may be desirable for implementations operating at
   speeds of 1 Gbps or greater to implement IPsec sequence number
   extension, described in [Seq].  Note that depending on the transform
   in use, it is possible that rekeying will be required prior to
   exhaustion of the sequence number space.

   In CBC-mode ciphers the ciphertext of one block depends on the
   plaintext of that block as well as the ciphertext of the previous
   block.  This implies that if the ciphertext of two blocks are
   identical, and the plaintext of the next block is also identical,

Top      Up      ToC       Page 41 
   then the ciphertext of the next block will be identical.  Thus, if
   identical ciphertext blocks can be found with matching subsequent
   blocks, an attacker can determine the existence of matching

   Such "Birthday attacks" were examined by Bellare et. al. in
   [DESANALY].  On average, a ciphertext block of size n bits will be
   expected to repeat every 2^[n/2] blocks.  Although a single "birthday
   attack" does not provide much information to an attacker, multiple
   such attacks might provide useful information.  To  make this
   unlikely, it is recommended that a rekey occur before 2^[n/2] blocks
   have been sent on a given SA.  Bellare et. al. have formalized this
   in [DESANALY], showing that the insecurity of CBC mode increases as
   O(s^2/2^n), where n is the block size in bits, and s is the total
   number of blocks encrypted.  These conclusions do not apply to
   counter mode.

Top      Up      ToC       Page 42 
   |               | Code size   |             |
   |Implementation |  (octets)   | Release     |
   |               |             |             |
   |               |             | Linux       |
   | Pluto         |  258KB      | FreeSWAN    |
   |(FreeSWAN)     |             | x86         |
   |               |             |             |
   | Racoon        |  400KB      | NetBSD 1.5  |
   | (KAME)        |             | x86         |
   |               |             |             |
   | Isakmpd       |  283KB      | NetBSD 1.5  |
   | (Erickson)    |             | x86         |
   |               |             |             |
   | WindRiver     |  142KB      | PowerPC     |
   |               |             |             |
   |               |             |             |
   | Cisco         |  222KB      | PowerPC     |
   | VPN1700       |             |             |
   |               |             |             |
   | Cisco         |  350K       | PowerPC     |
   | VPN3000       |             |             |
   |               |             |             |
   | Cisco         |  228KB      | MIPS        |
   | VPN7200       |             |             |

   Table 5.3-1 - Code Size for IKE implementations

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

               B = (n/8) * 2^[n/2]
               B = maximum bytes sent on the SA
               n = block size in bits

Top      Up      ToC       Page 43 
   This means that cipher block size as well as key length needs to be
   considered in the rekey decision.  3DES uses a block size n = 64 bits
   (2^3 bytes); this implies that the SA must be rekeyed before B =
   (64/8) * (2^32) = 2^35 bytes are sent.  At 1 Gbps, this implies that
   a rekey will be required every 274.9 seconds (4.6 minutes); at 10
   Gbps, a rekey is required every 27.5 seconds.

   In terms of the sequence number space, for a 3DES encrypted message
   of 512 = 2^9 bytes (2^6 blocks) this implies that the key has become
   insecure after about 2^26 messages.

5.5.  Transform Issues

   Since IP block storage implementations may operate at speeds of 1
   Gbps or greater, the ability to offer IPsec security services at high
   speeds is of intense concern.  Since support for multiple algorithms
   multiplies the complexity and expense of hardware design, one of the
   goals of the transform selection effort is to find a minimal set of
   confidentiality and authentication algorithms implementable in
   hardware at speeds of up to 10 Gbps, as well as being efficient for
   implementation in software at speeds of 100 Mbps or slower.

   In this specification, we primarily concern ourselves with IPsec
   transforms that have already been specified, and for which parts are
   available that can run at 1 Gbps line rate.  Where existing
   algorithms do not gracefully scale to 10 Gbps, we further consider
   algorithms for which transform specifications are not yet complete,
   but for which parts are expected to be available for inclusion in
   products shipping within the next 12 months.  As the state of the art
   advances, the range of feasible algorithms will broaden and
   additional mandatory-to-implement algorithms may be considered.

   Section 5 of [RFC2406] states:

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

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

   The DES algorithm is specified in [FIPS46-3]; implementation
   guidelines are found in [FIPS74], and security issues are discussed
   in [DESDIFF],[DESINT], [DESCRACK].  The DES IPsec transform is
   defined in [RFC2405] and the 3DES in CBC mode IPsec transform is
   specified in [RFC2451].

Top      Up      ToC       Page 44 
   The MD5 algorithm is specified in [RFC1321]; HMAC is defined in
   [RFC2104] and security issues with MD5 are discussed in [MD5Attack].
   The HMAC-MD5 IPsec transform is specified in [RFC2403].  The HMAC-
   SHA1 IPsec transform is specified in [RFC2404].

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

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

   When utilizing AES modes, it may be necessary to use larger public
   keys; the tradeoffs are described in [KeyLen].  Additional MODP
   Diffie-Hellman groups for use with IKE are described in [RFC3526].

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


   To provide authentication, integrity and replay protection, IP block
   storage security implementations MUST support HMAC-SHA1 [RFC2404] for
   authentication, and AES in CBC MAC mode with XCBC extensions SHOULD
   be supported [RFC3566].

   HMAC-SHA1 [RFC2404] is to be preferred to HMAC-MD5, due to concerns
   that have been raised about the security of MD5 [MD5Attack].  HMAC-
   SHA1 parts are currently available that run at 1 Gbps, the algorithm
   is implementable in hardware at speeds up to 10 Gbps, and an IPsec
   transform specification [RFC2404] exists.  As a result, it is most
   practical to utilize HMAC-SHA1 as the authentication algorithm for
   products shipping in the near future.  AES in CBC-MAC authentication
   mode with XCBC extensions was selected since it avoids adding
   substantial additional code if AES is already being implemented for
   encryption; an IPsec transform document is available [RFC3566].

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

Top      Up      ToC       Page 45 
   For confidentiality, the ESP mandatory-to-implement algorithm (DES)
   is unacceptable.  As noted in [DESCRACK], DES is crackable with
   modest computation resources, and so is inappropriate for use in
   situations requiring high levels of security.

   To provide confidentiality for iSCSI, iFCP, and FCIP, 3DES in CBC
   mode [RFC2451] MUST be supported and AES in Counter Mode [RFC3686]
   SHOULD be supported.  For use in high speed implementations, 3DES has
   significant disadvantages.  However, a 3DES IPsec transform has been
   specified and parts are available that can run at 1 Gbps, so
   implementing 3DES in products is practical for the short term.

   As described in Appendix B, 3DES software implementations make
   excessive computational demands at speeds of 100 Mbps or greater,
   effectively ruling out software-only implementations.  In addition,
   3DES implementations  require rekeying prior to exhaustion of the
   current 32-bit IPsec sequence number space, and thus would not be
   able to make use of sequence space extensions if they were available.
   This means that 3DES will require very frequent rekeying at speeds of
   10 Gbps or faster.  Thus, 3DES is inconvenient for use at very high
   speeds, as well as being impractical for implementation in software
   at slower speeds (100+ Mbps).

5.6.  Fragmentation Issues

   When certificate authentication is used, IKE fragmentation can be
   encountered.  This can occur when certificate chains are used, or
   even when exchanging a single certificate if the key size or size of
   other certificate fields (such as the distinguished name and other
   OIDs) is large enough.  Many Network Address Translators (NATs) and
   firewalls do not handle fragments properly, dropping them on inbound
   and/or outbound.

   Routers in the path will also frequently discard fragments after the
   initial one, since they typically will not contain full IP headers
   that can be compared against an Access List.

   As a result, where IKE fragmentation occurs, the endpoints will often
   be unable to establish an IPsec security association.  The solution
   to this problem is to install NAT, firewall or router code load that
   can properly support fragments. If this cannot be done, then the
   following alternatives can be considered:

   [1]  Obtaining certificates by other means.

   [2]  Reducing the size of the certificate chain.

Top      Up      ToC       Page 46 
   [3]  Reducing  the size of fields within the certificates.  This
        includes reduction in the key size, the distinguished name or
        other fields.  This should be considered only as a last resort.

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

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

      "TCP should notice that the connection is timing out.  After
      several timeouts, TCP should attempt to send smaller packets,
      perhaps turning off the DF flag for each packet.  If this
      succeeds, it should continue to turn off PMTUD for the connection
      for some reasonable period of time, after which it should probe
      again to try to determine if the path has changed."

   If an ICMP PMTU is received by an IPsec implementation that processes
   unauthenticated ICMP packets, this value should be stored in the SA
   as proposed in [RFC2401], and IPsec should also provide notification
   of this event to TCP so that the new MTU value can be correctly

5.7.  Security Checks

   When a connection is opened which requires security, IP block storage
   security implementations may wish to check that the connection is
   protected by IPsec.  If security is desired and IPsec protection is
   removed on a connection, it is reinstated before non-protected IP
   block storage packets are sent.  Since IPsec verifies that each
   packet arrives on the correct SA, as long as it can be ensured that
   IPsec protection is in place, then IP block storage implementations
   can be assured that each received packet was sent by a trusted peer.

   When used with IP block storage protocols, each TCP connection MUST
   be protected by an IKE Phase 2 SA.  Traffic from one or more than one
   TCP connection may flow within each IPsec Phase 2 SA.  IP block
   storage security implementations need not verify that the IP
   addresses and TCP port values in the packet match the socket

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

5.8.  Authentication Issues

5.8.1.  Machine Versus User Certificates

   The certificate credentials provided by the iSCSI initiator during
   the IKE negotiation may be those of the machine or of the iSCSI
   entity.  When machine authentication is used, the machine certificate
   is typically stored on the iSCSI initiator and target during an
   enrollment process.  When user certificates are used, the user
   certificate can be stored either on the machine or on a smartcard.
   For iFCP and FCIP, the certificate credentials provided will almost
   always be those of the device and will be stored on the device.

   Since the value of a machine certificate is inversely proportional to
   the ease with which an attacker can obtain one under false pretenses,
   it is advisable that the machine certificate enrollment process be
   strictly controlled.  For example, only administrators may have the
   ability to enroll a machine with a machine certificate.

   While smartcard certificate storage lessens the probability of
   compromise of the private key, smartcards are not necessarily
   desirable in all situations.  For example, some organizations
   deploying machine certificates use them so as to restrict use of
   non-approved hardware.  Since user authentication can be provided
   within iSCSI login (keeping in mind the weaknesses described
   earlier), support for machine authentication in IPsec makes it is
   possible to authenticate both the machine as well as the user.  Since
   iFCP and FCIP have no equivalent of iSCSI Login, for these protocols
   only the machine is authenticated.

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

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

Top      Up      ToC       Page 48 
   turned off.  Such a policy will prevent an attacker obtaining the
   password of an unused account from obtaining a user certificate once
   the enrollment period has expired.

5.8.2.  Pre-Shared Keys

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

   Thus when pre-shared key authentication is used in Main Mode along
   with entities whose address is dynamically assigned, the same pre-
   shared key is shared by a group and is no longer able to function as
   an effective shared secret.  In this situation, neither the initiator
   nor Responder identifies itself during IKE Phase 1; it is only known
   that both parties are a member of the group with knowledge of the
   pre-shared key.  This permits anyone with access to the group pre-
   shared key to act as a man-in-the-middle.  This vulnerability is
   typically not of concern where IP addresses are typically statically
   assigned (such as with iFCP and FCIP), since in this situation
   individual pre-shared keys are possible within IKE Main Mode.

   However, where IP addresses are dynamically assigned and Main Mode is
   used along with pre-shared keys, the Responder is not authenticated
   unless application-layer mutual authentication is performed (e.g.,
   iSCSI login authentication).  This enables an attacker in possession
   of the group pre-shared key to masquerade as the Responder.  In
   addition to enabling the attacker to present false data, the attacker
   would also be able to mount a dictionary attack on legacy
   authentication methods such as CHAP [RFC1994], potentially
   compromising many passwords at a time.  This vulnerability is widely
   present in existing IPsec implementations.

   Group pre-shared keys are not required in Aggressive Mode since the
   identity payload is sent earlier in the exchange, and therefore the
   pre-shared key can be selected based on the identity.  However, when
   Aggressive Mode is used the user identity is exposed and this is
   often considered undesirable.

   Note that care needs to be taken with IKE Phase 1 Identity Payload
   selection in order to enable mapping of identities to pre-shared keys
   even with Aggressive Mode.  Where the ID_IPV4_ADDR or ID_IPV6_ADDR
   Identity Payloads are used and addresses are dynamically assigned,

Top      Up      ToC       Page 49 
   mapping of identities to keys is not possible, so that group pre-
   shared keys are still a practical necessity.  As a result, identities
   other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or
   ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode
   is utilized along with pre-shared keys and IP addresses are
   dynamically assigned.

5.8.3.  IKE and Application-Layer Authentication

   In addition to IKE authentication, iSCSI implementations utilize
   their own authentication methods.  Currently, work is underway on
   Fibre Channel security, so that a similar authentication process may
   eventually also apply to iFCP and FCIP as well.

   While iSCSI provides initial authentication, it does not provide
   per-packet authentication, integrity or replay protection.  This
   implies that the identity verified in the iSCSI Login is not
   subsequently verified on reception of each packet.

   With IPsec, when the identity asserted in IKE is authenticated, the
   resulting derived keys are used to provide per-packet authentication,
   integrity and replay protection.  As a result, the identity verified
   in the IKE conversation is subsequently verified on reception of each

   Let us assume that the identity claimed in iSCSI Login is a user
   identity, while the identity claimed within IKE is a machine
   identity.  Since only the machine identity is verified on a per-
   packet basis, there is no way for the recipient to verify that only
   the user authenticated via iSCSI Login is using the IPsec SA.

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

   To limit the potential vulnerability, IP block storage
   implementations MUST do the following:

   [1]  Ensure that socket access is appropriately controlled.  On a
        multi-user operating system, this implies that sockets opened
        for use by IP block storage protocols MUST be exclusive.

   [2]  In the case of iSCSI, implementations MUST also ensure that
        application layer login credentials (such as iSCSI login
        credentials) are protected from unauthorized access.

Top      Up      ToC       Page 50 
   If these directives are followed, then a rogue process will not be
   able to access an IP block storage volume.

   While the identity asserted within IKE is verified on a per-packet
   basis, to avoid interference between users on a given machine,
   operating system support is required.  In order to segregate traffic
   between users when user authentication is supported, the IPsec
   endpoints must ensure that only traffic from that particular user is
   sent or received within the IPsec SA.  Enforcement of this
   restriction is the responsibility of the operating system.

   In kernel mode iSCSI drivers there typically is no user context to
   perform user authentication.  In this case the authentication is
   closer to machine authentication.  In most operating systems device
   permissions would control the ability to read/write to the device
   prior to mounting.  Once the device is mounted, ACLs set by the
   filesystem control access to the device.  An administrator can access
   the blocks on the device directly (for instance, by sending pass
   through requests to the port driver directly such as in Windows NT).
   In the same way, an administrator can open a raw socket and send
   IPsec protected packets to an iSCSI target.  The situation is
   analogous, and in this respect no new vulnerability is created that
   didn't previously exist.  The Operating system's ACLs need to be
   effective to protect a device (whether it is a SCSI device or an
   iSCSI device).

5.8.4.  IP Block Storage Authorization

   IP block storage protocols can use a variety of mechanisms for
   authorization.  Where ID_FQDN is used as the Identity Payload, IP
   block storage endpoints can be configured with a list of authorized
   FQDNs.  The configuration can occur manually, or automatically via
   iSNS or the iSCSI MIB, defined in [AuthMIB].

   Assuming that IPsec authentication is successful, this list of FQDNs
   can be examined to determine authorization levels.  Where certificate
   authentication is used, it is possible to configure IP block storage
   protocol endpoints with trusted roots.  The trusted roots used with
   IP block storage protocols might be different from the trusted roots
   used for other purposes.  If this is the case, then the burden of
   negotiating use of the proper certificates lies with the IPsec

   Note that because IKE does not deal well with certificate chains, and
   is typically configured with a limited set of trusted roots, it is
   most appropriate for intra-domain usage.

Top      Up      ToC       Page 51 
   Since iSCSI supports Login authentication, it is also possible to use
   the identities presented within the iSCSI Login for authorization

   In iFCP, basic access control properties stem from the requirement
   that two communicating iFCP gateways be known to one or more iSNS
   servers before they can engage in iFCP exchanges.  The optional use
   of discovery domains in iSNS yields access control schemas of greater

5.9.  Use of AES in Counter Mode

   When utilizing AES modes, it may be necessary to use larger public
   keys; the tradeoffs are described in [KeyLen].  Additional MODP
   Diffie-Hellman groups for use with IKE are described in [RFC3526].

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

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

(page 51 continued on part 3)

Next RFC Part