idnits 2.17.00 (12 Aug 2021) /tmp/idnits972/draft-ietf-ips-security-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 72 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 286 has weird spacing: '...ns, and retur...' == Line 510 has weird spacing: '... NOT be used ...' == Line 541 has weird spacing: '...private key f...' == Line 991 has weird spacing: '... not be maint...' == Line 1116 has weird spacing: '...not be mainta...' == (6 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2623 -- Looks like a reference, but probably isn't: '2' on line 2625 -- Looks like a reference, but probably isn't: '3' on line 2627 -- Looks like a reference, but probably isn't: '4' on line 2629 -- Looks like a reference, but probably isn't: '5' on line 1654 -- Looks like a reference, but probably isn't: '6' on line 657 -- Looks like a reference, but probably isn't: '7' on line 663 -- Looks like a reference, but probably isn't: '8' on line 339 == Missing Reference: 'IPsecNATReq' is mentioned on line 1762, but not defined == Missing Reference: 'RFC2131' is mentioned on line 1691, but not defined == Missing Reference: 'DHCPv6' is mentioned on line 1691, but not defined == Missing Reference: 'IPsecNATJust' is mentioned on line 1739, but not defined == Missing Reference: 'AESCBC' is mentioned on line 1957, but not defined == Unused Reference: 'RFC2412' is defined on line 2353, but no explicit reference was found in the text == Unused Reference: '3DESANSI' is defined on line 2371, but no explicit reference was found in the text == Unused Reference: 'IPsecNatReq' is defined on line 2481, but no explicit reference was found in the text == Unused Reference: 'CTR-MODE' is defined on line 2531, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1435 ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2923 -- Possible downref: Non-RFC (?) normative reference: ref. '3DESANSI' == Outdated reference: draft-ietf-ipsec-ciph-aes-xcbc-mac has been published as RFC 3566 == Outdated reference: draft-ietf-ipsec-ciph-aes-ctr has been published as RFC 3686 == Outdated reference: draft-ietf-ipsec-dhcp has been published as RFC 3456 == Outdated reference: draft-ietf-ips-fcovertcpip has been published as RFC 3821 == Outdated reference: draft-ietf-ips-fcip-slp has been published as RFC 3822 -- Possible downref: Non-RFC (?) normative reference: ref. 'SRPNDSS' == Outdated reference: draft-ietf-ipsec-ike-modp-groups has been published as RFC 3526 -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) == Outdated reference: draft-ietf-ips-iscsi-mib has been published as RFC 4544 == Outdated reference: draft-orman-public-key-lengths has been published as RFC 3766 == Outdated reference: draft-ietf-ipsec-nat-reqts has been published as RFC 3715 == Outdated reference: draft-ietf-ipsec-udp-encaps has been published as RFC 3948 == Outdated reference: draft-ietf-ipsec-esp-v3 has been published as RFC 4303 == Outdated reference: draft-ietf-ipsec-nat-t-ike has been published as RFC 3947 == Outdated reference: draft-krovetz-umac has been published as RFC 4418 Summary: 13 errors (**), 0 flaws (~~), 31 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Working Group B. Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track Joshua Tseng 5 Nishan Systems 6 14 January 2003 Jesse Walker 7 Intel 8 Venkat Rangan 9 Rhapsody Networks Inc. 10 Franco Travostino 11 Nortel Networks 13 Securing Block Storage Protocols over IP 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC 2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document discusses how to secure block storage and storage 42 discovery protocols running over IP using IPsec and IKE. Threat models 43 and security protocols are developed for iSCSI, iFCP and FCIP, as well 44 as the iSNS and SLPv2 discovery protocols. Performance issues and 45 resource constraints are analyzed. 47 Table of Contents 49 1. Introduction .......................................... 4 50 1.1 iSCSI overview .................................. 4 51 1.2 iFCP overview ................................... 5 52 1.3 FCIP overview ................................... 5 53 1.4 IPsec overview .................................. 5 54 1.5 Terminology ..................................... 7 55 1.6 Requirements language ........................... 8 56 2. Block storage protocol security ....................... 8 57 2.1 Security requirements .......................... 8 58 2.2 Resource constraints ............................ 11 59 2.3 Security protocol ............................... 12 60 2.4 iSCSI authentication ............................ 16 61 2.5 SLPv2 security .................................. 18 62 2.6 iSNS security .................................... 25 63 3. iSCSI security inter-operability guidelines ........... 29 64 3.1 iSCSI security issues ........................... 29 65 3.2 iSCSI and IPsec interaction ..................... 29 66 3.3 Initiating a new iSCSI session .................. 30 67 3.4 Graceful iSCSI teardown ......................... 31 68 3.5 Non-graceful iSCSI teardown ..................... 32 69 3.6 Application layer CRC ........................... 32 70 4. iFCP and FCIP security issues ......................... 34 71 4.1 iFCP and FCIP Authentication Requirements ....... 34 72 4.2 iFCP Interaction with IPsec and IKE ............. 35 73 4.3 FCIP Interaction with IPsec and IKE ............. 36 75 5. Security Considerations ............................... 37 76 5.1 Transport mode versus tunnel mode ............... 37 77 5.2 NAT traversal ................................... 39 78 5.3 IKE issues ...................................... 40 79 5.4 Rekeying issues ................................. 41 80 5.5 Transform issues ................................ 43 81 5.6 Fragmentation issues ............................ 45 82 5.7 Security checks ................................. 46 83 5.8 Authentication issues ........................... 47 84 5.9 Use of AES in counter mode ...................... 51 85 6. IANA Considerations ................................... 51 86 6.1 Definition of terms ............................. 52 87 6.2 Recommended registration policies ............... 52 88 7. Normative references .................................. 52 89 8. Informative references ................................ 55 90 Appendix A - Well Known Groups for Use with SRP ............. 59 91 Appendix B - Software Performance of IPsec Transforms ....... 61 92 B.1 Authentication transforms ....................... 61 93 B.2 Encryption and Authentication transforms ........ 65 94 Acknowledgments .............................................. 70 95 Authors' Addresses ........................................... 70 96 Intellectual Property Rights ................................. 71 97 Full Copyright Statement ..................................... 71 98 1. Introduction 100 This specification discusses use of the IPsec protocol suite for 101 protecting block storage protocols over IP networks (including iSCSI, 102 iFCP and FCIP), as well as storage discovery protocols (iSNS and SLPv2). 104 1.1. iSCSI overview 106 iSCSI, described in [iSCSI], is a connection-oriented command/response 107 protocol that runs over TCP, and is used to access disk, tape and other 108 devices. iSCSI is a client-server protocol in which clients 109 (initiators) open connections to servers (targets) and perform an iSCSI 110 login. 112 This draft uses the SCSI terms initiator and target for clarity and to 113 avoid the common assumption that clients have considerably less 114 computational and memory resources than servers; the reverse is often 115 the case for SCSI, as targets are commonly dedicated devices of some 116 form. 118 The iSCSI protocol has a text based negotiation mechanism as part of its 119 initial (login) procedure. The mechanism is extensible in what can be 120 negotiated (new text keys and values can be defined) and also in the 121 number of negotiation rounds (e.g., to accommodate functionality such as 122 challenge-response authentication). 124 After a successful login, the iSCSI initiator may issue SCSI commands 125 for execution by the iSCSI target, which returns a status response for 126 each command, over the same connection. A single connection is used for 127 both command/status messages as well as transfer of data and/or optional 128 command parameters. An iSCSI session may have multiple connections, but 129 a separate login is performed on each. The iSCSI session terminates 130 when its last connection is closed. 132 iSCSI initiators and targets are application layer entities that are 133 independent of TCP ports and IP addresses. initiators and targets have 134 names whose syntax is defined in [iSCSIName]. iSCSI sessions between a 135 given initiator and target are run over one or more TCP connections 136 between those entities. That is, the login process establishes an 137 association between an iSCSI Session and the TCP connection(s) over 138 which iSCSI PDUs will be carried. 140 While the iSCSI login may include mutual authentication of the iSCSI 141 endpoints and negotiation of session parameters, iSCSI does not define 142 its own per-packet authentication, integrity, confidentiality or replay 143 protection mechanisms. Rather, it relies upon the IPsec protocol suite 144 to provide per-packet data confidentiality and integrity and 145 authentication services, with IKE as the key management protocol. iSCSI 146 uses TCP to provide congestion control, error detection and error 147 recovery. 149 1.2. iFCP overview 151 iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which 152 provides transport services to Fibre Channel devices over a TCP/IP 153 network. iFCP allows interconnection and networking of existing Fibre 154 Channel devices at wire speeds over an IP network. iFCP implementations 155 emulate fabric services in order to improve fault tolerance and 156 scalability by fully leveraging IP technology. Each TCP connection is 157 used to support storage traffic between a unique pair of Fibre Channel 158 N_PORTs. 160 iFCP does not have a native, in-band security mechanism. Rather, it 161 relies upon the IPsec protocol suite to provide data confidentiality and 162 authentication services, and IKE as the key management protocol. iFCP 163 uses TCP to provide congestion control, error detection and error 164 recovery. 166 1.3. FCIP overview 168 FCIP, defined in [FCIP], is a pure FC encapsulation protocol that 169 transports FC frames. Current specification work intends this for 170 interconnection of Fibre Channel switches over TCP/IP networks, but the 171 protocol is not inherently limited to connecting FC switches. FCIP 172 differs from iFCP in that no interception or emulation of fabric 173 services is involved. One or more TCP connections are bound to an FCIP 174 Link, which is used to realize Inter-Switch Links (ISLs) between pairs 175 of Fibre Channel entities. 177 FCIP does not have a native, in-band security mechanism. Rather, it 178 relies upon the IPsec protocol suite to provide data confidentiality and 179 authentication services, and IKE as the key management protocol. FCIP 180 uses TCP to provide congestion control, error detection and error 181 recovery. 183 1.4. IPsec overview 185 IPsec is a protocol suite which is used to secure communication at the 186 network layer between two peers. The IPsec protocol suite is specified 187 within the IP Security Architecture [RFC2401], IKE [RFC2409], IPsec 188 Authentication Header (AH) [RFC2402] and IPsec Encapsulating Security 189 Payload (ESP) [RFC2406] documents. IKE is the key management protocol 190 while AH and ESP are used to protect IP traffic. 192 An IPsec SA is a one-way security association, uniquely identified by 193 the 3-tuple: Security Parameter Index (SPI), protocol (ESP) and 194 destination IP. The parameters for an IPsec security association are 195 typically established by a key management protocol. These include the 196 encapsulation mode, encapsulation type, session keys and SPI values. 198 IKE is a two phase negotiation protocol based on the modular exchange of 199 messages defined by ISAKMP [RFC2408],and the IP Security Domain of 200 Interpretation (DOI) [RFC2407]. IKE has two phases, and accomplishes the 201 following functions: 203 [1] Protected cipher suite and options negotiation - using keyed MACs 204 and encryption and anti-replay mechanisms 206 [2] Master key generation - such as via MODP Diffie-Hellman 207 calculations 209 [3] Authentication of end-points 211 [4] IPsec SA management (selector negotiation, options negotiation, 212 create, delete, and rekeying) 214 Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is 215 handled in IKE Phase 2. 217 An IKE Phase 2 negotiation is performed to establish both an inbound and 218 an outbound IPsec SA. The traffic to be protected by an IPsec SA is 219 determined by a selector which has been proposed by the IKE initiator 220 and accepted by the IKE Responder. In IPsec transport mode, the IPsec 221 SA selector can be a "filter" or traffic classifier, defined as the 222 5-tuple: . The successful 224 establishment of a IKE Phase-2 SA results in the creation of two uni- 225 directional IPsec SAs fully qualified by the tuple . 228 The session keys for each IPsec SA are derived from a master key, 229 typically via a MODP Diffie-Hellman computation. Rekeying of an 230 existing IPsec SA pair is accomplished by creating two new IPsec SAs, 231 making them active, and then optionally deleting the older IPsec SA 232 pair. Typically the new outbound SA is used immediately, and the old 233 inbound SA is left active to receive packets for some locally defined 234 time, perhaps 30 seconds or 1 minute. 236 1.5. Terminology 238 Fibre Channel 239 Fibre Channel (FC) is a gigabit speed networking technology 240 primarily used to implement Storage Area Networks (SANs), 241 although it also may be used to transport other frames types 242 as well, including IP. FC is standardized under American 243 National Standard for Information Systems of the InterNational 244 Committee for Informational Technology Standards (ANSI-INCITS) 245 in its T11 technical committee. 247 FCIP Fibre Channel over IP (FCIP) is a protocol for interconnecting 248 Fibre Channel islands over IP Networks so as to form a unified 249 SAN in a single Fibre Channel fabric. The principal FCIP 250 interface point to the IP Network is the FCIP Entity. The FCIP 251 Link represents one or more TCP connections that exist between 252 a pair of FCIP Entities. 254 HBA Host Bus Adapter (HBA) is a generic term for a SCSI interface 255 to other device(s); it's roughly analogous to the term Network 256 Interface Card (NIC) for a TCP/IP network interface, except 257 that HBAs generally have on-board SCSI implementations, 258 whereas most NICs do not implement TCP, UDP, or IP. 260 iFCP iFCP is a gateway-to-gateway protocol, which provides Fibre 261 Channel fabric services to Fibre Channel devices over a TCP/IP 262 network. 264 IP block storage protocol 265 Where used within this document, the term "IP block storage 266 protocol" applies to all block storage protocols running over 267 IP, including iSCSI, iFCP and FCIP. 269 iSCSI iSCSI is a client-server protocol in which clients 270 (initiators) open connections to servers (targets). 272 iSNS The Internet Storage Name Server (iSNS) protocol provides for 273 discovery and management of iSCSI and Fibre Channel (FCP) 274 storage devices. iSNS applications store iSCSI and FC device 275 attributes and monitor their availability and reachability, 276 providing a consolidated information repository for an 277 integrated IP block storage network. iFCP requires iSNS for 278 discovery and management, while iSCSI may use iSNS for 279 discovery, and FCIP does not use iSNS. 281 initiator The iSCSI initiator connects to the target on well-known TCP 282 port 3260. The iSCSI initiator then issues SCSI commands for 283 execution by the iSCSI target. 285 target The iSCSI target listens on a well-known TCP port for incoming 286 connections, and returns a status response for each command 287 issued by the iSCSI initiator, over the same connection. 289 1.6. Requirements language 291 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 292 "RECOMMENDED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT", are 293 to be interpreted as described in [RFC2119]. 295 Note that requirements specified in this document apply only to use of 296 IPsec and IKE with IP block storage protocols. Thus, these requirements 297 do not apply to IPsec implementations in general. Implementation 298 requirements language should therefore be assumed to relate to the 299 availability of features for use with IP block storage security only. 301 Although the security requirements in this document are already 302 incorporated into the iSCSI [iSCSI], iFCP [iFCP] and FCIP [FCIP] 303 standards track documents, they are reproduced here for convenience. In 304 the event of a discrepancy, the individual protocol standards track 305 documents take precedence. 307 2. Block storage protocol security 309 2.1. Security requirements 311 IP Block storage protocols such as iSCSI, iFCP and FCIP are used to 312 transmit SCSI commands over IP networks. Therefore, both the control 313 and data packets of these IP block storage protocols are vulnerable to 314 attack. Examples of attacks include: 316 [1] An adversary may attempt to acquire confidential data and 317 identities by snooping data packets. 319 [2] An adversary may attempt to modify packets containing data and 320 control messages. 322 [3] An adversary may attempt to inject packets into an IP block storage 323 connection. 325 [4] An adversary may attempt to hijack TCP connection(s) corresponding 326 to an IP block storage session. 328 [5] An adversary may launch denial of service attacks against IP block 329 storage devices such as by sending a TCP reset. 331 [6] An adversary may attempt to disrupt security negotiation process, 332 in order to weaken the authentication, or gain access to user 333 passwords. This includes disruption of application-layer 334 authentication negotiations such as iSCSI Login. 336 [7] An adversary may attempt to impersonate a legitimate IP block 337 storage entity. 339 [8] An adversary may launch a variety of attacks (packet modification 340 or injection, denial of service) against the discovery (SLPv2 341 [RFC2608]) or discovery and management (iSNS [iSNS]) process. iSCSI 342 can use SLPv2 or iSNS. FCIP only uses SLPv2, and iFCP only uses 343 iSNS. 345 Since iFCP and FCIP devices are the last line of defense for a whole 346 Fibre Channel island, the above attacks, if successful, could compromise 347 the security of all the Fibre Channel hosts behind the devices. 349 To address the above threats, IP block storage security protocols must 350 support confidentiality, data origin authentication, integrity, and 351 replay protection on a per-packet basis. Confidentiality services are 352 important since IP block storage traffic may traverse insecure public 353 networks. The IP block storage security protocols must support perfect 354 forward secrecy in the rekeying process. 356 Bi-directional authentication of the communication endpoints MUST be 357 provided. There is no requirement that the identities used in 358 authentication be kept confidential (e.g., from a passive eavesdropper). 360 For a security protocol to be useful, CPU overhead and hardware 361 availability must not preclude implementation at 1 Gbps today. 362 Implementation feasibility at 10 Gbps is highly desirable, but may not 363 be demonstrable at this time. These performance levels apply to 364 aggregate throughput, and include all TCP connections used between IP 365 block storage endpoints. IP block storage communications typically 366 involve multiple TCP connections. Performance issues are discussed 367 further in Appendix B. 369 Enterprise data center networks are considered mission-critical 370 facilities that must be isolated and protected from possible security 371 threats. Such networks are often protected by security gateways, which 372 at a minimum provide a shield against denial of service attacks. The IP 373 block storage security architecture should be able to leverage the 374 protective services of the existing security infrastructure, including 375 firewall protection, NAT and NAPT services, and VPN services available 376 on existing security gateways. 378 When iFCP or FCIP devices are deployed within enterprise networks, IP 379 addresses will be typically be statically assigned as is the case with 380 most routers and switches. Consequently, support for dynamic IP 381 address assignment, as described in [DHCPIPsec], will typically not be 382 required, although it cannot be ruled out. Such facilities will also be 383 relevant to iSCSI hosts whose addresses are dynamically assigned. As a 384 result, the IP block storage security protocols must not introduce 385 additional security vulnerabilities where dynamic address assignment is 386 supported. 388 While IP block storage security is mandatory to implement, it is not 389 mandatory to use. The security services used depend on the 390 configuration and security policies put in place. For example, 391 configuration will influence the authentication algorithm negotiated 392 within iSCSI Login, as well as the security services (confidentiality, 393 data origin authentication, integrity, replay protection) and transforms 394 negotiated when IPsec is used to protect IP block storage protocols such 395 as iSCSI, iFCP and FCIP. 397 FCIP implementations may allow enabling and disabling security 398 mechanisms at the granularity of an FCIP Link. For iFCP, the 399 granularity corresponds to an iFCP Portal. For iSCSI, the granularity of 400 control is typically that of an iSCSI session, although it is possible 401 to exert control down to the granularity of the destination IP address 402 and TCP port. 404 Note that with IPsec, security services are negotiated at the 405 granularity of an IPsec SA, so that IP block storage connections 406 requiring a set of security services different from those negotiated 407 with existing IPsec SAs will need to negotiate a new IPsec SA. Separate 408 IPsec SAs are also advisable where quality of service considerations 409 dictate different handling of IP block storage connections. Attempting 410 to apply different quality of service to connections handled by the same 411 IPsec SA can result in reordering, and falling outside the replay 412 window. For a discussion of the issues, see [RFC2983]. 414 IP block storage protocols can be expected to carry sensitive data and 415 provide access to systems and data that require protection against 416 security threats. SCSI and Fibre Channel currently contain little in 417 the way of security mechanisms, and rely on physical security, 418 administrative security, and correct configuration of the communication 419 medium and systems/devices attached to it for their security properties. 421 For most IP networks, it is inappropriate to assume physical security, 422 administrative security, and correct configuration of the network and 423 all attached nodes (a physically isolated network in a test lab may be 424 an exception). Therefore, authentication SHOULD be used by IP block 425 storage protocols (e.g., iSCSI SHOULD use one of its in-band 426 authentication mechanisms or the authentication provided by IKE) in 427 order to provide a minimal assurance that connections have initially 428 been opened with the intended counterpart. 430 iSNS, described in [iSNS], is required in all iFCP deployments. iSCSI 431 may use iSNS for discovery, and FCIP does not use iSNS. iSNS 432 applications store iSCSI and FC device attributes and monitor their 433 availability and reachability, providing a consolidated information 434 repository for an integrated IP block storage network. The iSNS 435 specification defines mechanisms to secure communication between an iSNS 436 server and its clients. 438 2.2. Resource constraints 440 iFCP and FCIP devices will typically be embedded systems deployed on 441 racks in air-conditioned data center facilities. Such embedded systems 442 may include hardware chipsets to provide data encryption, 443 authentication, and integrity processing. Therefore, memory and CPU 444 resources are generally not a constraining factor. 446 iSCSI will be implemented on a variety of systems ranging from large 447 servers running general purpose operating systems to embedded host bus 448 adapters (HBAs). In general, a host bus adapter is the most constrained 449 iSCSI implementation environment, although an HBA may draw upon the 450 resources of the system to which it is attached in some cases (e.g., 451 authentication computations required for connection setup). More 452 resources should be available to iSCSI implementations for embedded and 453 general purpose operating systems. The following guidelines indicate 454 the approximate level of resources that authentication, keying, and 455 rekeying functionality can reasonably expect to draw upon: 457 - Low power processors with small word size are generally not used, 458 as power is usually not a constraining factor, with the possible 459 exception of HBAs, which can draw upon the computational resources 460 of the system into which they are inserted. Computational 461 horsepower should be available to perform a reasonable amount of 462 exponentiation as part of authentication and key derivation for 463 connection setup. The same is true of rekeying, although the 464 ability to avoid exponentiation for rekeying may be desirable (but 465 is not an absolute requirement). 467 - RAM and/or flash resources tend to be constrained in embedded 468 implementations. 8-10 MB of code and data for authentication, 469 keying, and rekeying is clearly excessive, 800-1000 KB is clearly 470 larger than desirable, but tolerable if there is no other 471 alternative and 80-100 KB should be acceptable. These sizes are 472 intended as rough order of magnitude guidance, and should not be 473 taken as hard targets or limits (e.g., smaller code sizes are 474 always better). Software implementations for general purpose 475 operating systems may have more leeway. 477 The primary resource concern for implementation of authentication and 478 keying mechanisms is code size, as iSCSI assumes that the computational 479 horsepower to do exponentiations will be available. 481 There is no dominant iSCSI usage scenario - the scenarios range from a 482 single connection constrained only by media bandwidth to hundreds of 483 initiator connections to a single target or communication endpoint. 484 SCSI sessions and hence the connections they use tend to be relatively 485 long lived; for disk storage, a host typically opens a SCSI connection 486 on boot and closes it on shutdown. Tape session length tends to be 487 measured in hours or fractions thereof (i.e., rapid fire sharing of the 488 same tape device among different initiators is unusual), although tape 489 robot control sessions can be short when the robot is shared among tape 490 drives. On the other hand, tape will not see a large number of 491 initiator connections to a single target or communication endpoint, as 492 each tape drive is dedicated to a single use at a single time, and a 493 dozen tape drives is a large tape device. 495 2.3. Security protocol 497 2.3.1. Transforms 499 All IP block storage security compliant implementations MUST support 500 IPsec ESP [RFC2406] to provide security for both control packets and 501 data packets, as well as the replay protection mechanisms of IPsec. 502 When ESP is utilized, per-packet data origin authentication, integrity 503 and replay protection MUST be used. 505 To provide confidentiality with ESP, ESP with 3DES in CBC mode [RFC2451] 506 MUST be supported, and AES in Counter mode, as described in [AESCTR], 507 SHOULD be supported. To provide data origin authentication and 508 integrity with ESP, HMAC-SHA1 [RFC2404] MUST be supported, and AES in 509 CBC MAC mode with XCBC extensions [AESXCBC] SHOULD be supported. DES in 510 CBC mode SHOULD NOT be used due to its inherent weakness. ESP with 511 NULL encryption MUST be supported for authentication. 513 2.3.2. IPsec modes 515 Conformant IP block storage protocol implementations MUST support ESP 516 [RFC2406] in tunnel mode and MAY implement IPsec with ESP in transport 517 mode. 519 2.3.3. IKE 521 Conformant IP block storage security implementations MUST support IKE 522 [RFC2409] for peer authentication, negotiation of security associations, 523 and key management, using the IPsec DOI [RFC2407]. Manual keying MUST 524 NOT be used since it does not provide the necessary rekeying support. 525 Conformant IP block storage security implementations MUST support peer 526 authentication using a pre-shared key, and MAY support certificate-based 527 peer authentication using digital signatures. Peer authentication using 528 the public key encryption methods outlined in IKE's sections 5.2 and 5.3 529 [RFC2409] SHOULD NOT be used. 531 Conformant IP block storage security implementations MUST support IKE 532 Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre- 533 shared key authentication SHOULD NOT be used when either of the peers 534 use a dynamically assigned IP address. While Main Mode with pre-shared 535 key authentication offers good security in many cases, situations where 536 dynamically assigned addresses are used force use of a group pre-shared 537 key, which is vulnerable to man-in-the-middle attack. 539 When digital signatures are used for authentication, either IKE Main 540 Mode or IKE Aggressive Mode MAY be used. In all cases, access to 541 locally stored secret information (pre-shared key, or private key for 542 digital signing) must be suitably restricted, since compromise of the 543 secret information nullifies the security properties of the IKE/IPsec 544 protocols. 546 When digital signatures are used to achieve authentication, an IKE 547 negotiator SHOULD use IKE Certificate Request Payload(s) to specify the 548 certificate authority (or authorities) that are trusted in accordance 549 with its local policy. IKE negotiators SHOULD check the pertinent 550 Certificate Revocation List (CRL) before accepting a PKI certificate for 551 use in IKE's authentication procedures. 553 The IPsec DOI [RFC2407] provides for several types of identification 554 data. Within IKE Phase 1, for use within the IDii and IDir payloads, 555 conformant IP block storage security implementations MUST support the 556 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and 557 ID_FQDN Identity Payloads. iSCSI security implementations SHOULD support 558 the ID_USER_FQDN Identity Payload; other IP block storage protocols 559 (iFCP, FCIP) SHOULD NOT use the ID_USER_FQDN Identity Payload. 560 Identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or 561 ID_USER_FQDN) SHOULD be employed in situations where Aggressive mode is 562 utilized along with pre-shared keys and IP addresses are dynamically 563 assigned. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, 564 ID_DER_ASN1_GN formats SHOULD NOT be used for IP block storage protocol 565 security; The ID_KEY_ID Identity Payload MUST NOT be used. As described 566 in [RFC2407], within Phase 1 the ID port and protocol fields MUST be set 567 to zero or to UDP port 500. Also, as noted in [RFC2407]: 569 When an IKE exchange is authenticated using certificates (of any 570 format), any ID's used for input to local policy decisions SHOULD be 571 contained in the certificate used in the authentication of the 572 exchange. 574 The Phase 2 Quick Mode exchanges used by IP block storage protocol 575 implementations MUST explicitly carry the Identity Payload fields (IDci 576 and IDcr). Each Phase 2 IDci and IDcr Payload SHOULD carry a single IP 577 address (ID_IPV4_ADDR, ID_IPV6_ADDR) and SHOULD NOT use the IP Subnet or 578 IP Address Range formats. Other ID payload formats MUST NOT be used. 580 Since IPsec acceleration hardware may only be able to handle a limited 581 number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent 582 for idle SAs, as a means of keeping the number of active Phase 2 SAs to 583 a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be 584 interpreted as a reason for tearing down an IP block storage connection. 585 Rather, it is preferable to leave the connection up, and if additional 586 traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. 587 This avoids the potential for continually bringing connections up and 588 down. 590 2.3.4. Security policy configuration 592 One of the goals of this specification is to enable a high level of 593 interoperability without requiring extensive configuration. This 594 section provides guidelines on setting of IKE parameters so as to 595 enhance the probability of a successful negotiation. It also describes 596 how information on security policy configuration can be provided so as 597 to further enhance the chances of success. 599 To enhance the prospects for interoperability, some of the actions to 600 consider include: 602 [1] Transform restriction. Since support for 3DES-CBC and HMAC-SHA1 is 603 required of all implementations, offering these transforms enhances 604 the probability of a successful negotiation. If AES-CTR [AESCTR] 605 with XCBC-MAC [AESXCBC] is supported, this transform combination 606 will typically be preferred, with 3DES-CBC/HMAC-SHA1 as a secondary 607 offer. 609 [2] Group Restriction. If 3DES-CBC/HMAC-SHA1 is offered, and DH groups 610 are offered, then it is recommended that a DH group of at least 611 1024 bits be offered along with it. If AES-CTR/XCBC-MAC is the 612 preferred offer, and DH groups are offered, then it is recommended 613 that a DH group of at least 2048 bits be offered along with it, as 614 noted in [KeyLen]. If perfect forward secrecy is required in Quick 615 Mode, then it is recommended that the QM PFS DH group be the same 616 as the IKE Phase 1 DH group. This reduces the total number of 617 combinations, enhancing the chances for interoperability. 619 [3] Key lifetimes. If a key lifetime is offered that is longer than 620 desired, then rather than causing the IKE negotiation to fail, it 621 is recommended that the Responder consider the offered lifetime as 622 a maximum, and accept it. The key can then use a lesser value for 623 the lifetime, and utilize a Lifetime Notify in order to inform the 624 other peer of lifetime expiration. 626 Even when the above advice is taken, it still may be useful to be able 627 to provide additional configuration information in order to enhance the 628 chances of success, and it is useful to be able to manage security 629 configuration regardless of the scale of the deployment. 631 For example, it may be desirable to configure the security policy of an 632 IP block storage device. This can be done manually or automatically via 633 a security policy distribution mechanism. Alternatively, it can be 634 supplied via iSNS or SLPv2. If an IP block storage endpoint can obtain 635 the required security policy by other means (manually, or automatically 636 via a security policy distribution mechanism) then it need not request 637 this information via iSNS or SLPv2. However, if the required security 638 policy configuration is not available via other mechanisms, iSNS or 639 SLPv2 can be used to obtain it. 641 It may also be helpful to obtain information about the preferences of 642 the peer prior to initiating IKE. While it is generally possible to 643 negotiate security parameters within IKE, there are situations in which 644 incompatible parameters can cause the IKE negotiation to fail. The 645 following information can be provided via SLPv2 or iSNS: 647 [4] IPsec or cleartext support. The minimum piece of peer configuration 648 required is whether an IP block storage endpoint requires IPsec or 649 cleartext. This cannot be determined from the IKE negotiation alone 650 without risking a long timeout, which is highly undesirable for a 651 disk access protocol. 653 [5] Perfect Forward Secrecy (PFS) support. It is helpful to know 654 whether a peer allows PFS, since an IKE Phase 2 Quick Mode can fail 655 if an initiator proposes PFS to a Responder that does not allow it. 657 [6] Preference for tunnel mode. While it is legal to propose both 658 transport and tunnel mode within the same offer, not all IKE 659 implementations will support this. As a result, it is useful to 660 know whether a peer prefers tunnel mode or transport mode, so that 661 it is possible to negotiate the preferred mode on the first try. 663 [7] Main Mode and Aggressive Mode support. Since the IKE negotiation 664 can fail if a mode is proposed to a peer that doesn't allow it, it 665 is helpful to know which modes a peer allows, so that an allowed 666 mode can be negotiated on the first try. 668 Since iSNS or SLPv2 can be used to distribute IPsec security policy and 669 configuration information for use with IP block storage protocols, these 670 discovery protocols would constitute a 'weak link' were they not secured 671 at least as well as the protocols whose security they configure. Since 672 the major vulnerability is packet modification and replay, when iSNS or 673 SLPv2 are used to distribute security policy or configuration 674 information, at a minimum, per-packet data origin authentication, 675 integrity and replay protection MUST be used to protect the discovery 676 protocol. 678 2.4. iSCSI authentication 680 2.4.1. CHAP 682 Compliant iSCSI implementations MUST implement the CHAP authentication 683 method [RFC1994] (according to [iSCSI], section 11.1.4), which includes 684 support for bi-directional authentication, and the target authentication 685 option. 687 When CHAP is performed over non-encrypted channel, it is vulnerable to 688 an off-line dictionary attack. Implementations MUST support random CHAP 689 secrets of up to 128 bits, including the means to generate such secrets 690 and to accept them from an external generation source. Implementations 691 MUST NOT provide secret generation (or expansion) means other than 692 random generation. 694 If CHAP is used with secret smaller than 96 bits, then IPsec encryption 695 (according to the implementation requirements in [iSCSI] section 8.3.2) 696 MUST be used to protect the connection. Moreover, in this case IKE 697 authentication with group pre-shared keys SHOULD NOT be used. When CHAP 698 is used with a secret smaller then 96 bits, a compliant implementation 699 MUST NOT continue with the iSCSI login unless it can verify that IPsec 700 encryption is being used to protect the connection. 702 Originators MUST NOT reuse the CHAP challenge sent by the Responder for 703 the other direction of a bidirectional authentication. Responders MUST 704 check for this condition and close the iSCSI TCP connection if it 705 occurs. 707 The same CHAP secret SHOULD NOT be configured for authentication of 708 multiple initiators or multiple targets, as this enables any of them to 709 impersonate any other one of them, and compromising one of them enables 710 the attacker to impersonate any of them. It is recommended that iSCSI 711 implementations check for use of identical CHAP secrets by different 712 peers when this check is feasible, and take appropriate measures to warn 713 users and/or administrators when this is detected. A single CHAP secret 714 MAY be used for authentication of an individual initiator to multiple 715 targets. Likewise, a single CHAP secret MAY be used for authentication 716 of an individual target to multiple initiators. 718 A Responder MUST NOT send its CHAP response if the initiator has not 719 successfully authenticated. For example, the following exchange: 721 I->R CHAP_A= 722 R->I CHAP_A= CHAP_C= CHAP_I= 723 I->R CHAP_N= CHAP_C= CHAP_I= 725 (Where N, (A1,A2), I, C, and R are correspondingly the Name, 726 Algorithms, Identifier, Challenge, and Response as defined in 727 [RFC1994]) 729 MUST result in the Responder (target) closing the iSCSI TCP connection 730 because the initiator has failed to authenticate (there is no CHAP_R in 731 the third message). 733 Any CHAP secret used for initiator authentication MUST NOT be configured 734 for authentication of any target, and any CHAP secret used for target 735 authentication MUST NOT be configured for authentication of any 736 initiator. If the CHAP response received by one end of an iSCSI 737 connection is the same as the CHAP response that the receiving endpoint 738 would have generated for the same CHAP challenge, the response MUST be 739 treated as an authentication failure and cause the connection to close 740 (this ensures that the same CHAP secret is not used for authentication 741 in both directions). Also, if an iSCSI implementation can function as 742 both initiator and target, different CHAP secrets and identities MUST be 743 configured for these two roles. The following is an example of the 744 attacks prevented by the above requirements: 746 Rogue wants to impersonate Storage to Alice, and knows that a 747 single secret is used for both directions of Storage-Alice 748 authentication. 750 Rogue convinces Alice to open two connections to Rogue, and 751 Rogue identifies itself as Storage on both connections. 753 Rogue issues a CHAP challenge on connection 1, waits for Alice 754 to respond, and then reflects Alice's challenge as the initial 755 challenge to Alice on connection 2. 757 If Alice doesn't check for the reflection across connections, 758 Alice's response on connection 2 enables Rogue to impersonate 759 Storage on connection 1, even though Rogue does not know the 760 Alice-Storage CHAP secret. 762 Note that RADIUS [RFC2865] does not support bi-directional CHAP 763 authentication. Therefore, while a target acting as a RADIUS client 764 will be able to verify the initiator Response, it will not be able to 765 respond to an initiator challenge unless it has access to an appropriate 766 shared secret by some other means. 768 2.4.2. SRP 770 iSCSI implementations MAY implement the SRP authentication method 771 [RFC2945] (see [iSCSI], Section 11.1.3). The strength of SRP security 772 is dependent on the characteristics of the group being used (i.e., the 773 prime modulus N and generator g). As described in [RFC2945], N is 774 required to be a Sophie-German prime (of the form N = 2q + 1, where q is 775 also prime) the generator g is a primitive root of GF(n) [SRPNDSS]. 777 SRP well-known groups are included in Appendix A and additional groups 778 may be registered with IANA. iSCSI implementations MUST use one of these 779 well-known groups. All the groups specified in Appendix A up to 1536 780 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST be supported by 781 initiators and targets. To guarantee interoperability, targets MUST 782 always offer "SRP-1536" as one of the proposed groups. 784 2.5. SLPv2 Security 786 Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer 787 entities and management servers. SLPv2 may also be used to provide 788 information on peer security configuration. When SLPv2 is deployed, the 789 SA advertisements as well as UA requests and/or responses are subject to 790 the following security threats: 792 [1] An attacker could insert or alter SA advertisements or a response 793 to a UA request in order to masquerade as the real peer or launch a 794 denial of service attack. 796 [2] An attacker could gain knowledge about an SA or a UA through 797 snooping, and launch an attack against the peer. Given the 798 potential value of iSCSI targets and FCIP entities, leaking of such 799 information not only increases the possibility of an attack over 800 the network; there is also the risk of physical theft. 802 [3] An attacker could spoof a DAAdvert. This could cause UAs and SAs to 803 use a rogue DAs. 805 To address these threats, the following capabilities are required: 807 [a] Service information, as included in SrvRply, AttrRply, SrvReg and 808 SrvDereg messages, needs to be kept confidential. 810 [b] The UA has to be able to distinguish between legitimate and 811 illegitimate service information from SrvRply and AttrRply 812 messages. In the SLPv2 security model SAs are trusted to sign 813 data. 815 [c] The DA has to be able to distinguish between legitimate and 816 illegitimate SrvReg and SrvDereg messages. 818 [d] The UA has to be able to distinguish between legitimate and 819 illegitimate DA Advertisements. This allows the UA to avoid rogue 820 DAs that will return incorrect data or no data at all. In the 821 SLPv2 security model, UAs trust DAs to store, answer queries on and 822 forward data on services, but not necessarily to originate it. 824 [e] SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2 is 825 used. In this case, SAs register with only one DA and trust that 826 this DA will forward the registration to others. 828 By itself, SLPv2 security, defined in [RFC2608], does not satisfy these 829 security requirements. SLPv2 only provides end-to-end authentication, 830 but does not support confidentiality. In SLPv2 authentication there is 831 no way to authenticate "zero result responses". This enables an 832 attacker to mount a denial of service attack by sending UAs a "zero 833 results" SrvRply or AttrRply as if from a DA with whose source address 834 corresponds to a legitimate DAAdvert. 836 In all cases, there is a potential for denial of service attack against 837 protocol service providers, but such an attack is possible even in the 838 absence of SLPv2 based discovery mechanisms. 840 2.5.1. SLPv2 security protocol 842 SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, 843 AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, SAAdvert. SLPv2 844 requires that User Agents (UAs) and Service Agents (SAs) support 845 SrvRqst, SrvRply, and DAAdvert. SAs must additionally support SrvReg, 846 SrvAck, and SAAdvert. 848 Where no Directory Agent (DA) exists, the SrvRqst is multicast, but the 849 SrvRply is sent via unicast UDP. DAAdverts are also multicast. However, 850 all other SLPv2 messages are sent via UDP unicast. 852 In order to provide the required security functionality, iSCSI and FCIP 853 security implementations SHOULD protect SLPv2 messages sent via unicast 854 using IPsec ESP with a non-null transform. SLPv2 authentication blocks 855 (carrying digital signatures), described in [RFC2608] MAY also be used 856 to authenticate unicast and multicast messages. 858 The usage of SLPv2 by iSCSI is described in [iSCSISLP]. iSCSI initiators 859 and targets may enable IKE mechanisms to establish identity. In 860 addition, a subsequent user-level iSCSI session login can protect the 861 initiator-target nexus. This will protect them from any compromise of 862 security in the SLPv2 discovery process. 864 The usage of SLPv2 by FCIP is described in [FCIPSLP]. FCIP Entities 865 assume that once the IKE identity of a peer is established, the FCIP 866 Entity Name carried in FCIP Short Frame is also implicitly accepted as 867 the authenticated peer. Any such association between the IKE identity 868 and the FCIP Entity Name is administratively established. 870 For use in securing SLPv2, when digital signatures are used to achieve 871 authentication in IKE, an IKE negotiator SHOULD use IKE Certificate 872 Request Payload(s) to specify the certificate authority (or authorities) 873 that are trusted in accordance with its local policy. IKE negotiators 874 SHOULD check the pertinent Certificate Revocation List (CRL) before 875 accepting a PKI certificate for use in IKE's authentication procedures. 876 If key management of SLPv2 DAs needs to be coordinated with the SAs and 877 the UAs as well as the protocol service implementations, one may use 878 certificate based key management, with a shared root Certificate 879 Authority (CA). 881 One of the reasons for utilizing IPsec for SLPv2 security is that is 882 more likely that certificates will be deployed for IPsec than for SLPv2. 883 This both simplifies SLPv2 security and makes it more likely that it 884 will be implemented interoperably and more importantly, that it will be 885 used. As a result, it is desirable that little additional effort be 886 required to enable IPsec protection of SLPv2. 888 However, just because a certificate is trusted for use with IPsec does 889 not necessarily imply that the host is authorized to perform SLPv2 890 operations. When using IPsec to secure SLPv2, it may be desirable to 891 distinguish between certificates appropriate for use by UAs, SAs, and 892 DAs. For example, while a UA might be allowed to use any certificate 893 conforming to IKE certificate policy, the certificate used by an SA 894 might indicate that it is a legitimate source of service advertisements. 895 Similarly, a DA certificate might indicate that it is a valid DA. This 896 can be accomplished by using special CAs to issue certificates valid for 897 use by SAs and DAs; alternatively, SA and DA authorizations can be 898 employed. 900 Assume that the policy for issuing and distributing SLPv2 authorized 901 certificates to SAs and DAs limits them only to legitimate SAs and DAs. 902 In this case, IPsec is used to provide SLPv2 security as follows: 904 [a] SLPv2 messages sent via unicast are IPsec protected, using ESP with 905 a non-null transform. 907 [b] SrvRply and AttrRply messages from either a DA or SA are unicast to 908 UAs. Assuming that the SA used a certificate authorized for SLPv2 909 service advertisement in establishing the IKE Phase 1 SA, or that 910 the DA used a certificate authorized for DA usage, the UA can 911 accept the information sent, even if it has no SLPv2 authentication 912 block. 914 Note that where SrvRqst messages are multicast, they are not 915 protected. An attacker may attempt to exploit this by spoofing a 916 multicast SrvRqst from the UA, generating a SrvRply from an SA of 917 the attacker's choosing. Although the SrvRply is secured, it does 918 not correspond to a legitimate SrvRqst sent by the UA. To avoid 919 this attack, where SrvRqst messages are multicast, the UA MUST 920 check that SrvRply messages represent a legitimate reply to the 921 SrvRqst that was sent. 923 [c] SrvReg and SrvDereg messages from a SA are unicast to DAs. 924 Assuming that the SA used a certificate authorized for SLPv2 925 service advertisement in establishing the IKE Phase 1 SA, the DA 926 can accept the de/registration even if it has no SLPv2 927 authentication block. Typically, the SA will check the DA 928 authorization prior to sending the service advertisement. 930 [d] Multicast DAAdverts can be considered advisory. The UA will 931 attempt to contact DAs via unicast. Assuming that the DA used a 932 certificate authorized for SLPv2 DAAdverts in establishing the IKE 933 Phase 1 SA, the UA can accept the DAAdvert even if it has no SLPv2 934 authentication block. 936 [e] SAs can accept DAAdverts as described in [d]. 938 2.5.2. Confidentiality of service information 940 Since SLPv2 messages can contain information that can potentially reveal 941 the vendor of the device or its other associated characteristics, 942 revealing service information constitutes a security risk. As an 943 example, the FCIP Entity Name may reveal a WWN from which an attacker 944 can learn potentially useful information about the Entity's 945 characteristics. 947 The SLPv2 security model assumes that service information is public, and 948 therefore does not provide for confidentiality. However, storage devices 949 represent mission critical infrastructure of substantial value, and so 950 iSCSI and FCIP security implementations MUST support confidentiality as 951 well as authentication of unicast SLPv2 messages. 953 Assuming that all unicast SLPv2 messages are protected by IPsec, and 954 that confidentiality is provided, then the risk of disclosure can be 955 limited to SLPv2 messages sent via multicast, namely the SrvRqst and 956 DAAdvert. 958 The information leaked in a multicast SrvRqst depends on the level of 959 detail in the query. If leakage is a concern, then a DA can be provided. 960 If this is not feasible, then a general query can be sent via multicast, 961 and then further detail can be obtained from the replying entities via 962 additional unicast queries, protected by IPsec. 964 Information leakage via a multicast DAAdvert is less of a concern than 965 the authenticity of the message, since knowing that a DA is present on 966 the network only enables an attacker to know that SLPv2 is in use, and 967 possibly that a directory service is also present. This information is 968 not considered very valuable. 970 2.5.3. SLPv2 security implications 972 Through the definition of security attributes, it is possible to use 973 SLPv2 to distribute information about security settings for IP block 974 storage entities. SLPv2 distribution of security policy is not 975 necessary if the security settings can be determined by other means, 976 such as manual configuration or IPsec security policy distribution. If 977 an entity has already obtained its security configuration via other 978 mechanisms, then it MUST NOT request security policy via SLPv2. 980 Where SLPv2 is used to provide security policy information for use with 981 IP block storage protocols, SLPv2 MUST be protected by IPsec as 982 described in this document. Where SLPv2 is not used to distribute 983 security policy information, implementations MAY implement SLPv2 984 security as described in this document. 986 Where SLPv2 is used, but security is not implemented, IP block storage 987 protocol implementations MUST support a negative cache for 988 authentication failures. This allows implementations to avoid 989 continually contacting discovered endpoints that fail authentication 990 within IPsec or at the application layer (in the case of iSCSI Login). 991 The negative cache need not be maintained within the IPsec 992 implementation, but rather within the IP block storage protocol 993 implementation. 995 Since this document proposes that hop-by-hop security be used as the 996 primary mechanism to protect SLPv2, UAs have to trust DAs to accurately 997 relay data from SAs. This is a change to the SLPv2 security model 998 described in [RFC2608]. However, SLPv2 authentication as defined in 999 [RFC2608] does not provide a way to authenticate "zero result 1000 responses", leaving SLPv2 vulnerable to a denial of service attack. 1001 Such an attack can be carried out on a UA by sending it a "zero results" 1002 SrvRply or AttrRply, sent from a source address corresponding to a DA 1003 issuing a legitimate DAAdvert. 1005 In addition, SLPv2 security as defined in [RFC2608] does not support 1006 confidentiality. When IPsec with ESP and a non-null transform is used 1007 to protect SLPv2, not only can unicast requests and replies be 1008 authenticated, but confidentiality can also be provided. This includes 1009 unicast requests to DAs and SAs as well as replies. It is also possible 1010 to actively discover SAs using multicast SA discovery, and then to send 1011 unicast requests to the discovered SAs. 1013 As a result, for use with IP block storage protocols, it is believed 1014 that use of IPsec for security is more appropriate than the SLPv2 1015 security model defined in [RFC2608]. 1017 Using IPsec to secure SLPv2 has performance implications. Security 1018 associations established between: 1020 - UAs and SAs may be reused (the client on the UA host will use the 1021 service on the SA host). 1023 - SAs and DAs may be reused (the SAs will reregister services) 1025 - UAs and DAs will probably not be reused (many idle security 1026 associations are likely to result, and build up on the DA). 1028 When IPsec is used to protect SLPv2, it is not necessarily appropriate 1029 for all hosts with whom an IPsec security association can be established 1030 to be trusted to originate SLPv2 service advertisements. This is 1031 particularly the case in environments where it is easy to obtain 1032 certificates valid for use with IPsec (for example, where anyone with 1033 access to the network can obtain a machine certificate valid for use 1034 with IPsec). If not all hosts are authorized to originate service 1035 advertisements, then it is necessary to distinguish between authorized 1036 and unauthorized hosts. 1038 This can be accomplished by the following mechanisms: 1040 [1] Configuring SAs with the identities or certificate characteristics 1041 of valid DAs, and configuring DAs with the identities of SAs 1042 allowed to advertise IP block storage services. The DAs are then 1043 trusted to enforce policies on service registration. This approach 1044 involves manual configuration, but avoids certificate customization 1045 for SLPv2. 1047 [2] Restricting the issuance of certificates valid for use in SLPv2 1048 service advertisement. While all certificates allowed for use with 1049 IPsec will chain to a trusted root, certificates for hosts 1050 authorized to originate service advertisements could be signed by 1051 an SLPv2-authorized CA, or could contain explicit SLPv2 1052 authorizations within the certificate. After the IPsec security 1053 association is set up between the SLPv2 entities, the SLPv2 1054 implementations can then retrieve the certificates used in the 1055 negotiation in order to determine whether the entities are 1056 authorized for the operations that are being performed. This 1057 approach requires less configuration, but requires some certificate 1058 customization for use with SLPv2. 1060 2.6. iSNS security 1062 The iSCSI protocol may use iSNS for discovery and management services, 1063 while the iFCP protocol is required to use iSNS for such services. In 1064 addition, iSNS can be used to store and distribute security policy and 1065 authorization information to iSCSI and iFCP devices. When the iSNS 1066 protocol is deployed, the interaction between iSNS server and iSNS 1067 clients are subject to the following additional security threats: 1069 [1] An attacker can alter iSNS protocol messages, directing iSCSI and 1070 iFCP devices to establish connections with rogue devices, or 1071 weakening IPsec protection for iSCSI or iFCP traffic. 1073 [2] An attacker can masquerade as the real iSNS server by sending false 1074 iSNS heartbeat messages. This could deceive iSCSI and iFCP devices 1075 into using rogue iSNS servers. 1077 [3] An attacker can gain knowledge about iSCSI and iFCP devices by 1078 snooping iSNS protocol messages. Such information could aid an 1079 attacker in mounting a direct attack on iSCSI and iFCP devices, 1080 such as a denial-of-service attack or outright physical theft. 1082 To address these threats, the following capabilities are needed: 1084 [a] Unicast iSNS protocol messages may need to be authenticated. In 1085 addition, to protect against threat [3] above, confidentiality 1086 support is desirable, and REQUIRED when certain functions of iSNS 1087 are used. 1089 [b] Multicast iSNS protocol messages such as the iSNS heartbeat message 1090 need to be authenticated. These messages need not be confidential 1091 since they do not leak critical information. 1093 There is no requirement that the identities of iSNS entities be kept 1094 confidential. Specifically, the identity and location of the iSNS server 1095 need not be kept confidential. 1097 In order to protect against an attacker masquerading as an iSNS server, 1098 client devices MUST support authentication of broadcast or multicast 1099 messages such as the iSNS heartbeat. The iSNS authentication block 1100 (which is identical in format to the SLP authentication block) MAY be 1101 used for this purpose. Note that the authentication block is used only 1102 for iSNS broadcast or multicast messages, and SHOULD NOT be used in 1103 unicast iSNS messages. 1105 Since iSNS is used to distribute authorizations determining which client 1106 devices can communicate, IPsec authentication and data integrity MUST be 1107 supported. In addition, if iSNS is used to distribute security policy 1108 for iFCP and iSCSI devices, then authentication, data integrity, and 1109 confidentiality MUST be supported and used. 1111 Where iSNS is used without security, IP block storage protocol 1112 implementations MUST support a negative cache for authentication 1113 failures. This allows implementations to avoid continually contacting 1114 discovered endpoints that fail authentication within IPsec or at the 1115 application layer (in the case of iSCSI Login). The negative cache need 1116 not be maintained within the IPsec implementation, but rather within 1117 the IP block storage protocol implementation. 1119 2.6.1. Use of iSNS to Discover Security Configuration of Peer Devices 1121 In practice, within a single installation, iSCSI and/or iFCP devices may 1122 have different security settings. For example, some devices may be 1123 configured to initiate secure communication, while other devices may be 1124 configured to respond to a request for secure communication, but not to 1125 require security. Still other devices, while security capable, may 1126 neither initiate nor respond securely. 1128 In practice, these variations in configuration can result in devices 1129 being unable to communicate with each other. For example, a device that 1130 is configured to always initiate secure communication will experience 1131 difficulties in communicating with a device that neither initiates nor 1132 responds securely. 1134 The iSNS protocol is used to transfer naming, discovery, and management 1135 information between iSCSI devices, iFCP gateways, management stations, 1136 and the iSNS server. This includes the ability to enable discovery of 1137 security settings used for communication via the iSCSI and/or iFCP 1138 protocols. 1140 The iSNS server stores security settings for each iSCSI and iFCP device 1141 interface. These security settings, which can be retrieved by 1142 authorized hosts, include use or non-use of IPsec, IKE, Main Mode, 1143 Aggressive Mode, PFS, Pre-shared Key, and certificates. 1145 For example, IKE may not be enabled for a particular device interface. 1146 If a peer device can learn of this in advance by consulting the iSNS 1147 server, it will not need to waste time and resources attempting to 1148 initiate an IKE Phase 1 SA with that device interface. 1150 If iSNS is used to distribute security policy, then the minimum 1151 information that should be learned from the iSNS server is the use or 1152 non-use of IKE and IPsec by each iFCP or iSCSI peer device interface. 1153 This information is encoded in the Security Bitmap field of each Portal 1154 of the peer device, and is applicable on a per-interface basis for the 1155 peer device. iSNS queries to acquire security configuration data about 1156 peer devices MUST be protected by IPsec/ESP authentication. 1158 2.6.2. Use of iSNS to Distribute iSCSI and iFCP Security Policies 1160 Once communication between iSNS clients and the iSNS server are secured 1161 through use of IPsec, iSNS clients have the capability to discover the 1162 security settings required for communication via the iSCSI and/or iFCP 1163 protocols. Use of iSNS for distribution of security policies offers the 1164 potential to reduce the burden of manual device configuration, and 1165 decrease the probability of communications failures due to incompatible 1166 security policies. If iSNS is used to distribute security policies, 1167 then IPsec authentication, data integrity, and confidentiality MUST be 1168 used to protect all iSNS protocol messages. 1170 The complete IKE/IPsec configuration of each iFCP and/or iSCSI device 1171 can be stored in the iSNS server, including policies that are used for 1172 IKE Phase 1 and Phase 2 negotiations between client devices. The IKE 1173 payload format includes a series of one or more proposals that the iSCSI 1174 or iFCP device will use when negotiating the appropriate IPsec policy to 1175 use to protect iSCSI or iFCP traffic. 1177 Note that iSNS distribution of security policy is not necessary if the 1178 security settings can be determined by other means, such as manual 1179 configuration or IPsec security policy distribution. If an entity has 1180 already obtained its security configuration via other mechanisms, then 1181 it MUST NOT request security policy via iSNS. 1183 For further details on how to store and retrieve IKE policy proposals in 1184 the iSNS server, see [iSNS]. 1186 2.6.3. iSNS Interaction with IKE and IPsec 1188 When IPsec security is enabled, each iSNS client that is registered in 1189 the iSNS database maintains at least one Phase 1 and one Phase 2 1190 security association with the iSNS server. All iSNS protocol messages 1191 between iSNS clients and the iSNS server are to be protected by a phase- 1192 2 security association. 1194 2.6.4. iSNS Server Implementation Requirements 1196 All iSNS implementations MUST support the replay protection mechanisms 1197 of IPsec. ESP in tunnel mode MUST be implemented, and IPsec with ESP in 1198 transport mode MAY be implemented. 1200 To provide data origin authentication and integrity with ESP, HMAC-SHA1 1201 MUST be supported, and AES in CBC MAC mode with XCBC extensions 1202 [AESXCBC] SHOULD be supported. When confidentiality is implemented, 1203 3DES in CBC mode MUST be supported, and AES in Counter mode, as 1204 described in [AESCTR], SHOULD be supported. DES in CBC mode SHOULD NOT 1205 be used due to its inherent weakness. If confidentiality is not 1206 required but data origin authentication and integrity is enabled, ESP 1207 with NULL Encryption MUST be used. 1209 Conformant iSNS implementations MUST support IKE for authentication, 1210 negotiation of security associations, and key management, using the 1211 IPsec DOI, described in [RFC2407]. IP block storage protocols can be 1212 expected to send data in high volumes, thereby requiring rekey. Since 1213 manual keying does not provide rekeying support, its use is prohibited 1214 with IP block storage protocols. Although iSNS does not send a high 1215 volume of data, and therefore rekey is not a major concern, manual 1216 keying SHOULD NOT be used. This is for consistency, since dynamic keying 1217 support is already required in IP storage security implementations. 1219 Conformant iSNS security implementations MUST support authentication 1220 using a pre- shared key, and MAY support certificate-based peer 1221 authentication using digital signatures. Peer authentication using the 1222 public key encryption methods outlined in [RFC2409] sections 5.2 and 5.3 1223 SHOULD NOT be used. 1225 Conformant iSNS implementations MUST support IKE Main Mode and SHOULD 1226 support Aggressive Mode. IKE Main Mode with pre-shared key 1227 authentication SHOULD NOT be used when either of the peers use 1228 dynamically assigned IP addresses. While Main Mode with pre-shared key 1229 authentication offers good security in many cases, situations where 1230 dynamically assigned addresses are used force use of a group pre-shared 1231 key, which is vulnerable to man-in-the-middle attack. 1233 When digital signatures are used for authentication, either IKE Main 1234 Mode or IKE Aggressive Mode MAY be used. In all cases, access to 1235 locally stored secret information (pre-shared key or private key for 1236 digital signing) MUST be suitably restricted, since compromise of the 1237 secret information nullifies the security properties of the IKE/IPsec 1238 protocols. 1240 When digital signatures are used to achieve authentication, an IKE 1241 negotiator SHOULD use IKE Certificate Request Payload(s) to specify the 1242 certificate authority (or authorities) that are trusted in accordance 1243 with its local policy. IKE negotiators SHOULD check the pertinent 1244 Certificate Revocation List (CRL) before accepting a PKI certificate for 1245 use in IKE's authentication procedures. 1247 3. iSCSI security interoperability guidelines 1249 The following guidelines are established to meet iSCSI security 1250 requirements using IPsec in practical situations. 1252 3.1. iSCSI security issues 1254 iSCSI provides for iSCSI Login, outlined in [iSCSI], which includes 1255 support for application-layer authentication. This authentication is 1256 logically between the iSCSI initiator and the iSCSI target (as opposed 1257 to between the TCP/IP communication endpoints). The intent of the iSCSI 1258 design is that the initiator and target represent the systems (e.g., 1259 host and disk array or tape system) participating in the communication, 1260 as opposed to network communication interfaces or endpoints. 1262 The iSCSI protocol and iSCSI Login authentication do not meet the 1263 security requirements for iSCSI. iSCSI Login authentication provides 1264 mutual authentication between the iSCSI initiator and target at 1265 connection origination, but does not protect control and data traffic on 1266 a per packet basis, leaving the iSCSI connection vulnerable to attack. 1267 iSCSI Login authentication can mutually authenticate the initiator to 1268 the target, but does not by itself provide per-packet authentication, 1269 integrity, confidentiality or replay protection. In addition, iSCSI 1270 Login authentication does not provide for a protected ciphersuite 1271 negotiation. Therefore, iSCSI Login provides a weak security solution. 1273 3.2. iSCSI and IPsec interaction 1275 An iSCSI session [iSCSI], comprised of one or more TCP connections, is 1276 identified by the 2-tuple of the initiator-defined identifier and the 1277 target-defined identifier, . Each connection within a given 1278 session is assigned a unique Connection Identification, CID. The TCP 1279 connection is identified by the 5-tuple . An IPsec 1281 Phase 2 SA is identified by the 3-tuple . 1284 The iSCSI session and connection information is carried within the iSCSI 1285 Login Commands, transported over TCP. Since an iSCSI initiator may have 1286 multiple interfaces, iSCSI connections within an iSCSI session may be 1287 initiated from different IP addresses. Similarly, multiple iSCSI targets 1288 may exist behind a single IP address, so that there may be multiple 1289 iSCSI sessions between a given pair. 1292 When multiple iSCSI sessions are active between a given pair, the set of TCP connections used by a given iSCSI session 1294 must be disjoint from those used by all other iSCSI sessions between the 1295 same pair. Therefore a TCP connection can be 1296 associated with one and only one iSCSI session. 1298 The relationship between iSCSI sessions, TCP connections and IKE Phase 1 1299 and Phase 2 SAs is as follows: 1301 [1] An iSCSI initiator or target may have more than one interface, and 1302 therefore may have multiple IP addresses. Also, multiple iSCSI 1303 initiators and targets may exist behind a single IP address. As a 1304 result, an iSCSI Session may correspond to multiple IKE Phase 1 1305 Security Associations, though typically a single IKE Phase 1 1306 security association will exist for an tuple. 1309 [2] Each TCP connection within an iSCSI Session is protected by an IKE 1310 Phase 2 SA. The selectors may be specific to that TCP connection or 1311 may cover multiple connections. While each IKE Phase 2 SA may 1312 protect multiple TCP connections, each TCP connection is 1313 transported under only one IKE Phase 2 SA. 1315 Given this, all the information needed for the iSCSI/IPsec binding is 1316 contained within the iSCSI Login messages from the iSCSI initiator and 1317 target. This includes the binding between an IKE Phase 1 SA and the 1318 corresponding iSCSI sessions, as well as the binding between a TCP 1319 connection, an IKE Phase 2 SA and the iSCSI connection ID. 1321 3.3. Initiating a New iSCSI Session 1323 In order to create a new iSCSI Session, if an IKE Phase 1 SA does not 1324 already exist, then it is established by an initiator implementing iSCSI 1325 security. Subsequent iSCSI connections established within the iSCSI 1326 session will typically be protected by IKE Phase 2 SAs derived from that 1327 IKE Phase 1 SA, although additional IKE Phase 1 SAs can also be brought 1328 up. 1330 The initiator and target implementations successfully complete the IKE 1331 Phase 1 and Phase 2 negotiations before the iSCSI initiator contacts the 1332 target on well-known TCP port 3260, and sends the iSCSI Login command 1333 over the TCP connection. IPsec implementations configured with the 1334 correct policies (e.g. use ESP with non-null transform for all traffic 1335 destined for the iSCSI well-known TCP port 3260) will handle this 1336 automatically. 1338 The initiator fills in the ISID field, and leaves the TSIH field set to 1339 zero, to indicate that it is the first message of a new session 1340 establishment exchange. The initiator also fills in a CID value, that 1341 identifies the TCP connection over which the Login command is being 1342 exchanged. When the iSCSI target replies with its Login Command, both 1343 iSCSI devices will know the TSIH, and therefore the iSCSI session 1344 identifier . 1346 A single iSCSI session identifier may have multiple associated IKE Phase 1347 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI session 1348 identifiers. Each iSCSI connection (identified by the connection 1349 identifier) corresponds to a single TCP connection (identified by the 1350 5-tuple). Each IKE Phase 2 SA is identified by the combination. A Phase 2 SA may protect 1352 multiple TCP connections, and corresponds to a single IKE Phase 1 SA. 1354 Within IKE, each key refresh requires that a new security association be 1355 established. In practice there is a time interval during which an old, 1356 about-to-expire SA and newly established SA will both be valid. The 1357 IPsec implementation will choose which security association to use based 1358 on local policy, and iSCSI concerns play no role in this selection 1359 process. 1361 3.4. Graceful iSCSI Teardown 1363 Mechanisms within iSCSI provide for both graceful and non-graceful 1364 teardown of iSCSI Sessions or individual TCP connections within a given 1365 session. The iSCSI Logout command is used to effect graceful teardown. 1366 This command allows the iSCSI initiator to request that: 1368 [a] the session be closed 1370 [b] a specific connection within the session be closed 1372 [c] a specific connection be marked for recovery 1374 When the iSCSI implementation wishes to close a session, it uses the 1375 appropriate iSCSI commands to accomplish this. After exchanging the 1376 appropriate iSCSI control messages for session closure, the iSCSI 1377 security implementation will typically initiate a half-close of each TCP 1378 connection within the iSCSI session. 1380 When the iSCSI security implementation wishes to close an individual TCP 1381 connection while leaving the parent iSCSI session active, it should 1382 half-close the TCP connection. After the expiration of the TIME_WAIT 1383 timeout, the TCP connection is closed. 1385 3.5. Non-graceful iSCSI Teardown 1387 If a given TCP connection unexpectedly fails, the associated iSCSI 1388 connection is torn down. There is no requirement that an IKE Phase 2 1389 delete immediately follow iSCSI connection tear down or Phase 1 1390 deletion. Since an IKE Phase 2 SA may correspond to multiple TCP 1391 connections, such a deletion might be inappropriate. Similarly, if the 1392 IKE implementation receives a Phase 2 Delete message for a security 1393 association corresponding to a TCP connection, this does not necessarily 1394 imply that the TCP or iSCSI connection is to be torn down. 1396 If a Logout Command/Logout Response sequence marks a connection for 1397 removal from the iSCSI session, then after the iSCSI peer has executed 1398 an iSCSI teardown process for the connection, the TCP connection will be 1399 closed. The iSCSI connection state can then be safely removed. 1401 Since an IKE Phase 2 SA may be used by multiple TCP connections, an 1402 iSCSI implementation should not depend on receiving the IPsec Phase 2 1403 delete as confirmation that the iSCSI peer has executed an iSCSI 1404 teardown process for the connection. 1406 Since IPsec acceleration hardware may only be able to handle a limited 1407 number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent 1408 for idle SAs, as a means of keeping the number of active Phase 2 SAs to 1409 a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be 1410 interpreted as a reason for tearing down the corresponding iSCSI 1411 connection if no Logout Command/Logout Receive has been executed on the 1412 connection. Rather, it is preferable to leave the iSCSI connection up, 1413 and if additional traffic is sent on it, to bring up another IKE Phase 2 1414 SA to protect it. This avoids the potential for continually bringing 1415 iSCSI connections up and down. 1417 3.6. Application-layer CRC 1419 iSCSI's error detection and recovery assumes that the TCP and IP 1420 checksums provide inadequate integrity protection for high speed 1421 communications. As described in [CRCTCP], when operating at high speeds, 1422 the 16-bit TCP checksum [RFC793] will not necessarily detect all errors, 1423 resulting in possible data corruption. iSCSI [iSCSI] therefore 1424 incorporates a 32-bit CRC to protect its headers and data. 1426 When a CRC check fails (i.e. CRC computed at receiver does not match 1427 the received CRC), the iSCSI PDU covered by that CRC is discarded. 1428 Since presumably the error was not detected by the TCP checksum, TCP 1429 retransmission will not occur and thus cannot assist in recovering from 1430 the error. iSCSI contains both data and command retry mechanisms to 1431 deal with the resulting situations, including SNACK, the ability to 1432 reissue R2T commands, and the retry (X) bit for commands. 1434 IPsec offers protection against an attacker attempting to modify packets 1435 in transit, as well as unintentional packet modifications caused by 1436 network malfunctions or other errors. In general, IPsec authentication 1437 transforms afford stronger integrity protection than both the 16-bit TCP 1438 checksum and the 32-bit application-layer CRC specified for use with 1439 iSCSI. Since IPsec integrity protection occurs below TCP, if an error is 1440 discovered, then the packet will be discarded and TCP retransmission 1441 will occur, so that no recovery action need be taken at the iSCSI layer. 1443 3.6.1. Simplification of recovery logic 1445 Where IPsec integrity protection is known to be in place end-to-end 1446 between iSCSI endpoints (or the portion that requires additional 1447 integrity protection), portions of iSCSI can be simplified. For example, 1448 mechanisms to recover from CRC check failures are not necessary. 1450 If the iSCSI CRC is negotiated, the recovery logic can be simplified to 1451 regard any CRC check failure as fatal (e.g., generate a SCSI CHECK 1452 CONDITION on data error, close the corresponding TCP connection on 1453 header error) because it will be very rare for errors undetected by 1454 IPsec integrity protection to be detected by the iSCSI CRC. 1456 3.6.2. Omission of iSCSI CRC 1458 In some situations where IPsec is employed, the iSCSI CRC will not 1459 provide additional protection and can be omitted. 1461 For example, where IPsec processing as well as TCP checksum and iSCSI 1462 CRC verification are offloaded within the NIC, each of these checks will 1463 be verified prior to transferring data across the bus, so that 1464 subsequent errors will not be detected by these mechanisms. As a 1465 result, where IPsec processing is offloaded to the NIC, the iSCSI CRC is 1466 not necessary and the implementations may wish not to negotiate it. 1468 However, in other circumstances, the TCP checksum and iSCSI CRC will 1469 provide additional error coverage because they are computed and checked 1470 at a different point in the protocol stack or in devices different from 1471 those that implement the IPsec integrity checks. The resulting coverage 1472 of additional possible errors may make it desirable to negotiate use of 1473 the iSCSI CRC even when IPsec integrity protection is in use. Examples 1474 of these situations include where: 1476 [1] IPsec, TCP and iSCSI are implemented purely in software. Here, 1477 additional failure modes may be detected by the TCP checksum and/or 1478 iSCSI CRC. For example, after the IPsec message integrity check is 1479 successfully verified, the segment is copied as part of TCP 1480 processing, and a memory error during this process might cause the 1481 TCP checksum or iSCSI CRC verification to fail. 1483 [2] The implementation is an iSCSI-iSCSI proxy or gateway. Here the 1484 iSCSI CRC can be propagated from one iSCSI connection to another. 1485 In this case, the iSCSI CRC is useful to protect iSCSI data against 1486 memory, bus, or software errors within the proxy or gateway, and 1487 requesting it is desirable. 1489 [3] IPsec is provided by a device external to the actual iSCSI device. 1490 Here the iSCSI header and data CRCs can be kept across the part of 1491 the connection that is not protected by IPsec. For instance, the 1492 iSCSI connection could traverse an extra bus, interface card, 1493 network, interface card, and bus between the iSCSI device and the 1494 device providing IPsec. In this case, the iSCSI CRC is desirable, 1495 and the iSCSI implementation behind the IPsec device may request 1496 it. 1498 Note that if both ends of the connection are on the same segment, 1499 then traffic will be effectively protected by the layer 2 CRC, so 1500 that negotiation of the iSCSI CRC is not necessary to protect 1501 against NIC and network errors, although it may be desirable for 1502 other reasons (e.g., [1] and [2] above). 1504 4. iFCP and FCIP security issues 1506 4.1. iFCP and FCIP Authentication Requirements 1508 iFCP and FCIP are peer-to-peer protocols. iFCP and FCIP sessions may be 1509 initiated by either or both peer gateways. Consequently, bi-directional 1510 authentication of peer gateways MUST be provided. 1512 iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre 1513 Channel frames over IP. Therefore, Fibre Channel, operating system, and 1514 user identities are transparent to the iFCP and FCIP protocols. 1516 iFCP gateways use Discovery Domain information obtained from the iSNS 1517 server to determine whether the initiating Fibre Channel N_PORT should 1518 be allowed access to the target N_PORT. N_PORT identities used in the 1519 Port Login (PLOGI) process will be considered authenticated provided 1520 that they are received over a connection whose security complies with 1521 the local security policy. 1523 There is no requirement that the identities used in authentication be 1524 kept confidential. 1526 4.2. iFCP Interaction with IPsec and IKE 1528 A conformant iFCP Portal is capable of establishing one or more IKE 1529 Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA 1530 may be established when an iFCP Portal is initialized, or may be 1531 deferred until the first TCP connection with security requirements is 1532 established. 1534 An IKE Phase-2 SA protects one or more TCP connections within the same 1535 iFCP Portal. More specifically, the successful establishment of an IKE 1536 Phase-2 SA results in the creation of two uni-directional IPsec SAs 1537 fully qualified by the tuple . These 1538 SAs protect the setup process of the underlying TCP connections and all 1539 their subsequent TCP traffic. Each of the TCP connections protected by 1540 an SA is either in the unbound state, or is bound to a specific iFCP 1541 session. 1543 In summary, at any point in time: 1545 [1] There exist 0..M IKE Phase-1 SAs between peer iFCP portals 1546 [2] Each IKE Phase-1 SAs has 0..N IKE Phase-2 SAs 1547 [3] Each IKE Phase-2 SA protects 0..Z TCP connections 1549 The creation of an IKE Phase-2 SA may be triggered by security policy 1550 rules retrieved from an iSNS server. Alternately, the creation of an SA 1551 may be triggered by policy rules configured through a management 1552 interface, reflecting iSNS-resident policy rules. Likewise, the use of 1553 a Key Exchange payload in Quick Mode for perfect forward secrecy may be 1554 driven by security policy rules retrieved from the iSNS server, or set 1555 through a management interface. 1557 If an iFCP implementation makes use of unbound TCP connections, and such 1558 connections belong to an iFCP Portal with security requirements, then 1559 the unbound connections MUST be protected by an SA at all times just 1560 like bound connections. 1562 Upon receiving an IKE Phase-2 delete message, there is no requirement to 1563 terminate the protected TCP connections or delete the associated IKE 1564 Phase-1 SA. Since an IKE Phase-2 SA may be associated with multiple TCP 1565 connections, terminating such connections might in fact be inappropriate 1566 and untimely. 1568 To minimize the number of active Phase-2 SAs, IKE Phase-2 delete 1569 messages may be sent for Phase-2 SAs whose TCP connections have not 1570 handled data traffic for a while. To minimize the use of SA resources 1571 while the associated TCP connections are idle, creation of a new SA 1572 should be deferred until new data are to be sent over the connections. 1574 4.3. FCIP Interaction with IPsec and IKE 1576 FCIP Entities establish tunnels with other FCIP Entities in order to 1577 transfer IP encapsulated FC frames. Each tunnel is a separate FCIP Link, 1578 and can encapsulate multiple TCP connections. The binding of TCP 1579 connections to an FCIP Link is performed using the Fibre Channel World 1580 Wide Names (WWNs) of the two FCIP Entities. 1582 FCIP Entities may have more than one interface and IP address, and it is 1583 possible for an FCIP Link to contain multiple TCP connections whose FCIP 1584 endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is 1585 typically established for each FCIP endpoint IP Address pair. For the 1586 purposes of establishing an IKE Phase 1 SA, static IP addresses are 1587 typically used for identification. 1589 Each TCP connection within an FCIP Link corresponds to an IKE Phase 2 1590 (Quick Mode) SA. This is established prior to sending the initial TCP 1591 SYN packet and applies to the life of the connection. Phase 2 1592 negotiation is also required for rekeying, in order to protect against 1593 replay attacks. 1595 FCIP implementations MAY provide administrative management of 1596 Confidentiality usage. These management interfaces SHOULD be provided in 1597 a secure manner, so as to prevent an attacker from subverting the 1598 security process by attacking the management interface. 1600 FCIP Entities do not require any user-level authentication, since all 1601 FCIP Entities participate in a machine-level tunnel function. FCIP uses 1602 SLP for discovery, but not to distribute security policies. 1604 5. Security Considerations 1606 5.1. Transport mode versus tunnel mode 1608 With respect to block storage protocols, the major differences between 1609 the IPsec tunnel mode and transport mode are as follows: 1611 [1] MTU considerations. Tunnel mode introduces an additional IP header 1612 into the datagram that reflects itself in a corresponding decrease 1613 in the path MTU seen by packets traversing the tunnel. This may 1614 result in a decrease in the maximum segment size of TCP connections 1615 running over the tunnel. 1617 [2] Address assignment and configuration. Within IPsec tunnel mode, it 1618 is necessary for inner and outer source addresses to be configured, 1619 and for inner and outer destination addresses to be discovered. 1620 Within transport mode it is only necessary to discover a single 1621 destination address and configure a single source address. IPsec 1622 tunnel mode address usage considerations are discussed in more 1623 detail below. 1625 [3] NAT traversal. As noted in [IPsecNATReq], IPsec tunnel mode ESP can 1626 traverse NAT in limited circumstances, whereas transport mode ESP 1627 cannot traverse NAT. To enable NAT traversal in the general case, 1628 the IPsec NAT traversal functionality described in [IPsecNATReq], 1629 [UDPIPsec] and [NATIKE] can be implemented. More details are 1630 provided in the next section. 1632 [4] Firewall traversal. Where a block storage protocol is to traverse 1633 administrative domains, the firewall administrator may desire to 1634 verify the integrity and authenticity of each transiting packet, 1635 rather than opening a hole in the firewall for the block storage 1636 protocol. IPsec tunnel mode lends itself to such verification, 1637 since the firewall can terminate the tunnel mode connection while 1638 still allowing the endpoints to communicate end-to-end. If desired, 1639 the endpoints can in addition utilize IPsec transport mode for end- 1640 to-end security, so that they can also verify authenticity and 1641 integrity of each packet for themselves. 1643 In contrast, carrying out this verification with IPsec transport 1644 mode is more complex, since the firewall will need to terminate the 1645 IPsec transport mode connection and will need to act as an iSCSI, 1646 iFCP or FCIP gateway or TCP proxy, originating a new IPsec 1647 transport mode connection from the firewall to the internal 1648 endpoint. Such an implementation cannot provide end-to-end 1649 authenticity or integrity protection, and an application-layer CRC 1650 (iSCSI) or forwarding of the Fibre Channel frame CRC (iFCP and 1651 FCIP) is necessary to protect against errors introduced by the 1652 firewall. 1654 [5] IPsec-application integration. Where IPsec and the application 1655 layer protocol are implemented on the same device or host, it is 1656 possible to enable tight integration between them. For example, the 1657 application layer can request and verify that connections are 1658 protected by IPsec, and can obtain attributes of the IPsec security 1659 association. While in transport mode implementations the IPsec and 1660 application protocol implementations typically reside on the same 1661 host, with IPsec tunnel mode they may reside on different hosts. 1662 Where IPsec is implemented on an external gateway, integration 1663 between the application and IPsec is typically not possible. This 1664 limits the ability of the application to control and verify IPsec 1665 behavior. 1667 5.1.1. IPsec tunnel mode addressing considerations 1669 IPsec tunnels include both inner and outer source as well as destination 1670 addresses. 1672 When used with IP block storage protocols, the inner destination address 1673 represents the address of the IP block storage protocol peer (e.g. the 1674 ultimate destination for the packet). The inner destination address can 1675 be discovered using SLPv2 or iSNS, or can be resolved from an FQDN via 1676 DNS, so that obtaining this address is typically not an issue. 1678 The outer destination address represents the address of the IPsec 1679 security gateway used to reach the peer. Several mechanisms have been 1680 proposed for discovering the IPsec security gateway used to reach a 1681 particular peer. [RFC2230] discusses the use of KX Resource Records 1682 (RRs) for IPsec gateway discovery. However, while KX RRs are supported 1683 by many DNS server implementations, they have not yet been widely 1684 deployed. Alternatively, DNS SRV [RFC2782] can be used for this purpose. 1685 Where DNS is used for gateway location, DNS security mechanisms such as 1686 DNSSEC ([RFC2535], [RFC2931]), TSIG [RFC2845], and Simple Secure Dynamic 1687 Update [RFC3007] are advisable. 1689 When used with IP block storage protocols, the outer source address is 1690 configured either statically or dynamically, using mechanisms such as 1691 DHCPv4 [RFC2131], DHCPV6 [DHCPv6], or stateless address 1692 autoconfiguration [RFC2373]. 1694 The inner source address SHOULD be included in the Quick Mode ID payload 1695 when the peer establishes a tunnel mode SA with the IPsec security 1696 gateway. This enables the IPsec security gateway to properly route 1697 packets back to the remote peer. The inner source address can be 1698 configured via a variety of mechanisms, depending on the scenario. Where 1699 the IP block storage peers are located within the same administrative 1700 domain, it is typically possible for the inner and outer source 1701 addresses to be the same. This will work because the outer source 1702 address is presumably assigned from within a prefix assigned to the 1703 administrative domain, and is therefore routable within the domain. 1704 Assuming that the IPsec security gateway is aware of the inner source 1705 address used by the connecting peer and plumbs a host route for it, then 1706 packets arriving at the IPsec security gateway destined for the address 1707 can be correctly encapsulated and sent down the correct tunnel. 1709 Where IP block storage peers are located within different administrative 1710 domains, it may be necessary for the inner source address to be assigned 1711 by the IPsec security gateway, effectively "joining" the remote host to 1712 the LAN attached to the IPsec security gateway. For example, if the 1713 remote peer were to use its assigned (outer) source address as the inner 1714 source address, then a number of problems might result: 1716 [1] Intrusion detection systems sniffing the LAN behind the IPsec 1717 security gateway would notice source addresses originating outside 1718 the administrative domain. 1720 [2] Reply packets might not reach their destination, since the IPsec 1721 security gateway typically does not advertise the default route, 1722 but rather only the prefix that it allocates addresses from. Since 1723 the remote peer's address does not originate from with a prefix 1724 native to the administrative domain, it is likely that routers 1725 within the domain would not have a route for it, and would send the 1726 packet off to the router advertising the default route (perhaps a 1727 border router) instead of to the IPsec security gateway. 1729 For these reasons, for inter-domain use, assignment of inner source 1730 addresses may be needed. At present this is not a very common scenario; 1731 however, if address assignment is provided, then DHCP-based address 1732 assignment within IPsec tunnel mode [DHCPIPsec] MUST be supported. Note 1733 that this mechanism is not yet widely deployed within IPsec security 1734 gateways; existing IPsec tunnel mode servers typically implement this 1735 functionality via proprietary extensions to IKE. 1737 5.2. NAT traversal 1739 As noted in [IPsecNATJust], tunnel mode ESP can traverse NAT in a 1740 limited set of circumstances. For example, if there is only one protocol 1741 endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the 1742 receiver does not perform source address validation, then tunnel mode 1743 ESP may successfully traverse NATs. Since ignoring source address 1744 validation introduces new security vulnerabilities, and negotiation of 1745 specific selectors is desirable so as to limit the traffic that can be 1746 sent down the tunnel, these conditions may not necessarily apply, and 1747 tunnel mode NAT traversal will not always be possible. 1749 TCP carried within Transport mode ESP cannot traverse NAT, even though 1750 ESP itself does not include IP header fields within its message 1751 integrity check. This is because the 16-bit TCP checksum is calculated 1752 based on a "pseudo-header" that includes IP header fields, and the 1753 checksum is protected by the IPsec ESP message integrity check. As a 1754 result, the TCP checksum will be invalidated by a NAT located between 1755 the two endpoints. 1757 Since TCP checksum calculation and verification is mandatory in both 1758 IPv4 and IPv6, it is not possible to omit checksum verification while 1759 remaining standards compliant. In order to enable traversal of NATs 1760 existing while remaining in compliance, iSCSI, iFCP or FCIP security 1761 implementations can implement IPsec/IKE NAT traversal, as described in 1762 [IPsecNATReq], [UDPIPsec], and [NATIKE]. 1764 The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications 1765 enable UDP encapsulation of IPsec to be negotiated if a NAT is detected 1766 in the path. By determining the IP address of the NAT, the TCP checksum 1767 can be calculated based on a pseudo-header including the NAT-adjusted 1768 address and ports. If this is done prior to calculating the IPsec 1769 message integrity check, TCP checksum verification will not fail. 1771 5.3. IKE issues 1773 There are situations where it is necessary for IKE to be implemented in 1774 firmware. In such situations, it is important to keep the size of the 1775 IKE implementation within strict limits. An upper bound on the size of 1776 an IKE implementation might be considered to be 800 KB, with 80 KB 1777 enabling implementation in a wide range of situations. 1779 As noted in Table 5.3-1 on the next page, IKE implementations currently 1780 exist which meet the requirements. Therefore, while removal of seldom 1781 used IKE functionality (such as the nonce authentication methods) would 1782 reduce complexity, implementations typically will not require this in 1783 order to fit within the code size budget. 1785 5.4. Rekeying issues 1787 It is expected that IP block storage implementations will need to 1788 operate at high speed. For example, implementations operating at 1 Gbps 1789 are currently in design, with 10 Gbps implementations to follow shortly 1790 thereafter. At these speeds, a single IPsec SA could rapidly cycle 1791 through the 32-bit IPsec sequence number space. 1793 For example, a single SA operating at 1 Gbps line rate and sending 64 1794 octet packets would exhaust the 32-bit sequence number space in 2200 1795 seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur 1796 in 14.5 hours. At 10 Gbps, exhaustion would occur in 220 seconds or 1797 3.67 minutes. With 1518 octet packets, this would occur within 1.45 1798 hours. 1800 In the future, it may be desirable for implementations operating at 1801 speeds of 1 Gbps or greater to implement IPsec sequence number 1802 extension, described in [Seq]. Note that depending on the transform in 1803 use, it is possible that rekeying will be required prior to exhaustion 1804 of the sequence number space. 1806 In CBC-mode ciphers the ciphertext of one block depends on the plaintext 1807 of that block as well as the ciphertext of the previous block. This 1808 implies that if the ciphertext of two blocks are identical, and the 1809 plaintext of the next block is also identical, then the ciphertext of 1810 the next block will be identical. Thus, if identical ciphertext blocks 1811 can be found with matching subsequent blocks, an attacker can determine 1812 the existence of matching plaintext. 1814 Such "Birthday attacks" were examined by Bellare et. al. in [DESANALY]. 1815 On average, a ciphertext block of size n bits will be expected to repeat 1816 every 2^[n/2] blocks. Although a single "birthday attack" does not 1817 provide much information to an attacker, multiple such attacks might 1818 provide useful information. To make this unlikely, it is recommended 1819 that a rekey occur before 2^[n/2] blocks have been sent on a given SA. 1820 Bellare et. al. have formalized this in [DESANALY], showing that the 1821 insecurity of CBC mode increases as O(s^2/2^n), where n is the block 1822 size in bits, and s is the total number of blocks encrypted. These 1823 conclusions do not apply to counter mode. 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | | Code size | | 1827 |Implementation | (octets) | Release | 1828 | | | | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | | | Linux | 1831 | Pluto | 258KB | FreeSWAN | 1832 |(FreeSWAN) | | x86 | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | | | | 1835 | Racoon | 400KB | NetBSD 1.5 | 1836 | (KAME) | | x86 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | | | | 1839 | Isakmpd | 283KB | NetBSD 1.5 | 1840 | (Erickson) | | x86 | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | | | | 1843 | WindRiver | 142KB | PowerPC | 1844 | | | | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | | | | 1847 | Cisco | 222KB | PowerPC | 1848 | VPN1700 | | | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | | | | 1851 | Cisco | 350K | PowerPC | 1852 | VPN3000 | | | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | | | | 1855 | Cisco | 228KB | MIPS | 1856 | VPN7200 | | | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 Table 5.3-1 - Code Size for IKE implementations 1861 The formula below sets a limit on the bytes that can be sent on a CBC SA 1862 before a rekey is required: 1864 B = (n/8) * 2^[n/2] 1865 Where: 1866 B = maximum bytes sent on the SA 1867 n = block size in bits 1869 This means that cipher block size as well as key length needs to be 1870 considered in the rekey decision. 3DES uses a block size n = 64 bits 1871 (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) 1872 * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that a rekey 1873 will be required every 274.9 seconds (4.6 minutes); at 10 Gbps, a rekey 1874 is required every 27.5 seconds. 1876 In terms of the sequence number space, for a 3DES encrypted message of 1877 512 = 2^9 bytes (2^6 blocks) this implies that the key has become 1878 insecure after about 2^26 messages. 1880 5.5. Transform issues 1882 Since IP block storage implementations may operate at speeds of 1 Gbps 1883 or greater, the ability to offer IPsec security services at high speeds 1884 is of intense concern. Since support for multiple algorithms multiplies 1885 the complexity and expense of hardware design, one of the goals of the 1886 transform selection effort is to find a minimal set of confidentiality 1887 and authentication algorithms implementable in hardware at speeds of up 1888 to 10 Gbps, as well as being efficient for implementation in software at 1889 speeds of 100 Mbps or slower. 1891 In this specification, we primarily concern ourselves with IPsec 1892 transforms that have already been specified, and for which parts are 1893 available that can run at 1 Gbps line rate. Where existing algorithms do 1894 not gracefully scale to 10 Gbps, we further consider algorithms for 1895 which transform specifications are not yet complete, but for which parts 1896 are expected to be available for inclusion in products shipping within 1897 the next 12 months. As the state of the art advances, the range of 1898 feasible algorithms will broaden and additional mandatory-to-implement 1899 algorithms may be considered. 1901 Section 5 of [RFC2406] states: 1903 "A compliant ESP implementation MUST support the following 1904 mandatory-to-implement algorithms: 1906 - DES in CBC mode 1907 - HMAC with MD5 1908 - HMAC with SHA-1 1909 - NULL Authentication algorithm 1910 - NULL Encryption algorithm 1911 " 1913 The DES algorithm is specified in [FIPS46-3]; implementation guidelines 1914 are found in [FIPS74], and security issues are discussed in 1915 [DESDIFF],[DESINT], [DESCRACK]. The DES IPsec transform is defined in 1916 [RFC2405] and the 3DES in CBC mode IPsec transform is specified in 1917 [RFC2451]. 1919 The MD5 algorithm is specified in [MD5]; HMAC is defined in [RFC2104] 1920 and security issues with MD5 are discussed in [MD5Attack]. The HMAC-MD5 1921 IPsec transform is specified in [HMACMD5IPsec]. The HMAC-SHA1 IPsec 1922 transform is specified in [RFC2404]. 1924 In addition to these existing algorithms, NIST is currently evaluating 1925 the following modes [NSPUE2] of AES, defined in [FIPS197]: 1927 AES in Electronic Codebook (ECB) confidentiality mode 1928 AES in Cipher Block Chaining (CBC) confidentiality mode 1929 AES in Cipher Feedback (CFB) confidentiality mode 1930 AES in Output Feedback (OFB) confidentiality mode 1931 AES in Counter (CTR) confidentiality mode 1932 AES CBC-MAC authentication mode 1934 When utilizing AES modes, it may be necessary to use larger public keys; 1935 the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman 1936 groups for use with IKE are described in [MODP]. 1938 The Modes [NSPUE2] effort is also considering a number of additional 1939 algorithms, including the following: 1941 PMAC 1943 To provide authentication, integrity and replay protection, IP block 1944 storage security implementations MUST support HMAC-SHA1 [RFC2404] for 1945 authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be 1946 supported [AESXCBC]. 1948 HMAC-SHA1 [RFC2404] is to be preferred to HMAC-MD5, due to concerns that 1949 have been raised about the security of MD5 [MD5Attack]. HMAC-SHA1 parts 1950 are currently available that run at 1 Gbps, the algorithm is 1951 implementable in hardware at speeds up to 10 Gbps, and an IPsec 1952 transform specification [RFC2404] exists. As a result, it is most 1953 practical to utilize HMAC-SHA1 as the authentication algorithm for 1954 products shipping in the near future. AES in CBC-MAC authentication 1955 mode with XCBC extensions was selected since it avoids adding 1956 substantial additional code if AES is already being implemented for 1957 encryption; an IPsec transform document is available [AESCBC]. 1959 Authentication transforms also exist that are considerably more 1960 efficient to implement than HMAC-SHA1, or AES in CBC-MAC authentication 1961 mode. UMAC [UMAC],[UMACKR] is more efficient to implement in software 1962 and PMAC [PMAC] is more efficient to implement in hardware. PMAC is 1963 currently being evaluated as part of the NIST modes effort [NSPUE2] but 1964 an IPsec transform does not yet exist; neither does a UMAC transform. 1966 For confidentiality, the ESP mandatory-to-implement algorithm (DES) is 1967 unacceptable. As noted in [DESCRACK], DES is crackable with modest 1968 computation resources, and so is inappropriate for use in situations 1969 requiring high levels of security. 1971 To provide confidentiality for iSCSI, iFCP, and FCIP, 3DES in CBC mode 1972 [RFC2451] MUST be supported and AES in Counter Mode [AESCTR] SHOULD be 1973 supported. For use in high speed implementations, 3DES has significant 1974 disadvantages. However, a 3DES IPsec transform has been specified and 1975 parts are available that can run at 1 Gbps, so implementing 3DES in 1976 products is practical for the short term. 1978 As described in Appendix B, 3DES software implementations make excessive 1979 computational demands at speeds of 100 Mbps or greater, effectively 1980 ruling out software-only implementations. In addition, 3DES 1981 implementations require rekeying prior to exhaustion of the current 1982 32-bit IPsec sequence number space, and thus would not be able to make 1983 use of sequence space extensions if they were available. This means that 1984 3DES will require very frequent rekeying at speeds of 10 Gbps or faster. 1985 Thus, 3DES is inconvenient for use at very high speeds, as well as being 1986 impractical for implementation in software at slower speeds (100+ Mbps). 1988 5.6. Fragmentation Issues 1990 When certificate authentication is used, IKE fragmentation can be 1991 encountered. This can occur when certificate chains are used, or even 1992 when exchanging a single certificate if the key size or size of other 1993 certificate fields (such as the distinguished name and other OIDs) is 1994 large enough. Many Network Address Translators (NATs) and firewalls do 1995 not handle fragments properly, dropping them on inbound and/or outbound. 1997 Routers in the path will also frequently discard fragments after the 1998 initial one, since they typically will not contain full IP headers that 1999 can be compared against an Access List. 2001 As a result, where IKE fragmentation occurs, the endpoints will often be 2002 unable to establish an IPsec security association. The solution to this 2003 problem is to install NAT, firewall or router code load that can 2004 properly support fragments. If this cannot be done, then the following 2005 alternatives can be considered: 2007 [1] Obtaining certificates by other means. 2009 [2] Reducing the size of the certificate chain. 2011 [3] Reducing the size of fields within the certificates. This includes 2012 reduction in the key size, the distinguished name or other fields. 2013 This should be considered only as a last resort. 2015 Fragmentation can become a concern when prepending IPsec headers to a 2016 frame. One mechanism that can be used to reduce this problem is to 2017 utilize path MTU discovery. For example, when TCP is used as the 2018 transport for iSCSI, iFCP or FCIP then path MTU discovery, described in 2019 [RFC1191], [RFC1435], [RFC1981], can be used to enable the TCP endpoints 2020 to discover the correct MTU, including effects due to IPsec 2021 encapsulation. 2023 However, Path MTU discovery fails when appropriate ICMP messages are not 2024 received by the host. This occurs in IPsec implementations that drop 2025 unauthenticated ICMP packets. This can result in blackholing in naive 2026 TCP implementations, as described in [RFC2923]. Appropriate TCP 2027 behavior is described in section 2.1 of [RFC2923]: 2029 "TCP should notice that the connection is timing out. After several 2030 timeouts, TCP should attempt to send smaller packets, perhaps turning 2031 off the DF flag for each packet. If this succeeds, it should continue 2032 to turn off PMTUD for the connection for some reasonable period of 2033 time, after which it should probe again to try to determine if the 2034 path has changed." 2036 If an ICMP PMTU is received by an IPsec implementation that processes 2037 unauthenticated ICMP packets, this value should be stored in the SA as 2038 proposed in [RFC2401], and IPsec should also provide notification of 2039 this event to TCP so that the new MTU value can be correctly reflected. 2041 5.7. Security Checks 2043 When a connection is opened which requires security, IP block storage 2044 security implementations may wish to check that the connection is 2045 protected by IPsec. If security is desired and IPsec protection is 2046 removed on a connection, it is reinstated before non-protected IP block 2047 storage packets are sent. Since IPsec verifies that each packet arrives 2048 on the correct SA, as long as it can be ensured that IPsec protection is 2049 in place, then IP block storage implementations can be assured that each 2050 received packet was sent by a trusted peer. 2052 When used with IP block storage protocols, each TCP connection MUST be 2053 protected by an IKE Phase 2 SA. Traffic from one or more than one TCP 2054 connection may flow within each IPsec Phase 2 SA. IP block storage 2055 security implementations need not verify that the IP addresses and TCP 2056 port values in the packet match the socket information that was used to 2057 setup the connection. This check will be performed by IPsec, preventing 2058 malicious peers from sending commands on inappropriate Quick Mode SAs. 2060 5.8. Authentication issues 2062 5.8.1. Machine versus user certificates 2064 The certificate credentials provided by the iSCSI initiator during the 2065 IKE negotiation may be those of the machine or of the iSCSI entity. When 2066 machine authentication is used, the machine certificate is typically 2067 stored on the iSCSI initiator and target during an enrollment process. 2068 When user certificates are used, the user certificate can be stored 2069 either on the machine or on a smartcard. For iFCP and FCIP, the 2070 certificate credentials provided will almost always be those of the 2071 device and will be stored on the device. 2073 Since the value of a machine certificate is inversely proportional to 2074 the ease with which an attacker can obtain one under false pretenses, it 2075 is advisable that the machine certificate enrollment process be strictly 2076 controlled. For example, only administrators may have the ability to 2077 enroll a machine with a machine certificate. 2079 While smartcard certificate storage lessens the probability of 2080 compromise of the private key, smartcards are not necessarily desirable 2081 in all situations. For example, some organizations deploying machine 2082 certificates use them so as to restrict use of non-approved hardware. 2083 Since user authentication can be provided within iSCSI login (keeping in 2084 mind the weaknesses described earlier), support for machine 2085 authentication in IPsec makes it is possible to authenticate both the 2086 machine as well as the user. Since iFCP and FCIP have no equivalent of 2087 iSCSI Login, for these protocols only the machine is authenticated. 2089 In circumstances in which this dual assurance is considered valuable, 2090 enabling movement of the machine certificate from one machine to 2091 another, as would be possible if the machine certificate were stored on 2092 a smart card, may be undesirable. 2094 Similarly, when user certificate are deployed, it is advisable for the 2095 user enrollment process to be strictly controlled. If for example, a 2096 user password can be readily used to obtain a certificate (either a 2097 temporary or a longer term one), then that certificate has no more 2098 security value than the password. To limit the ability of an attacker to 2099 obtain a user certificate from a stolen password, the enrollment period 2100 can be limited, after which password access will be turned off. Such a 2101 policy will prevent an attacker obtaining the password of an unused 2102 account from obtaining a user certificate once the enrollment period has 2103 expired. 2105 5.8.2. Pre-shared keys 2107 Use of pre-shared keys in IKE Main Mode is vulnerable to man-in-the- 2108 middle attacks when used with dynamically addressed hosts (such as with 2109 iSCSI initiators). In Main Mode it is necessary for SKEYID_e to be used 2110 prior to the receipt of the identification payload. Therefore the 2111 selection of the pre-shared key may only be based on information 2112 contained in the IP header. However, where dynamic IP address assignment 2113 is typical, it is often not possible to identify the required pre-shared 2114 key based on the IP address. 2116 Thus when pre-shared key authentication is used in Main Mode along with 2117 entities whose address is dynamically assigned, the same pre-shared key 2118 is shared by a group and is no longer able to function as an effective 2119 shared secret. In this situation, neither the initiator nor Responder 2120 identifies itself during IKE Phase 1; it is only known that both parties 2121 are a member of the group with knowledge of the pre-shared key. This 2122 permits anyone with access to the group pre-shared key to act as a man- 2123 in-the-middle. This vulnerability is typically not of concern where IP 2124 addresses are typically statically assigned (such as with iFCP and 2125 FCIP), since in this situation individual pre-shared keys are possible 2126 within IKE Main Mode. 2128 However, where IP addresses are dynamically assigned and Main Mode is 2129 used along with pre-shared keys, the Responder is not authenticated 2130 unless application-layer mutual authentication is performed (e.g. iSCSI 2131 login authentication). This enables an attacker in possession of the 2132 group pre-shared key to masquerade as the Responder. In addition to 2133 enabling the attacker to present false data, the attacker would also be 2134 able to mount a dictionary attack on legacy authentication methods such 2135 as CHAP [RFC1994], potentially compromising many passwords at a time. 2136 This vulnerability is widely present in existing IPsec implementations. 2138 Group pre-shared keys are not required in Aggressive Mode since the 2139 identity payload is sent earlier in the exchange, and therefore the pre- 2140 shared key can be selected based on the identity. However, when 2141 Aggressive Mode is used the user identity is exposed and this is often 2142 considered undesirable. 2144 Note that care needs to be taken with IKE Phase 1 Identity Payload 2145 selection in order to enable mapping of identities to pre-shared keys 2146 even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR 2147 Identity Payloads are used and addresses are dynamically assigned, 2148 mapping of identities to keys is not possible, so that group pre-shared 2149 keys are still a practical necessity. As a result, identities other than 2150 ID_IPV4_ADDR and ID_IPV6_ADDR (such as ID_FQDN or ID_USER_FQDN) SHOULD 2151 be employed in situations where Aggressive mode is utilized along with 2152 pre-shared keys and IP addresses are dynamically assigned. 2154 5.8.3. IKE and application-layer authentication 2156 In addition to IKE authentication, iSCSI implementations utilize their 2157 own authentication methods. Currently, work is underway on Fibre 2158 Channel security, so that a similar authentication process may 2159 eventually also apply to iFCP and FCIP as well. 2161 While iSCSI provides initial authentication, it does not provide per- 2162 packet authentication, integrity or replay protection. This implies that 2163 the identity verified in the iSCSI Login is not subsequently verified on 2164 reception of each packet. 2166 With IPsec, when the identity asserted in IKE is authenticated, the 2167 resulting derived keys are used to provide per-packet authentication, 2168 integrity and replay protection. As a result, the identity verified in 2169 the IKE conversation is subsequently verified on reception of each 2170 packet. 2172 Let us assume that the identity claimed in iSCSI Login is a user 2173 identity, while the identity claimed within IKE is a machine identity. 2174 Since only the machine identity is verified on a per-packet basis, there 2175 is no way for the recipient to verify that only the user authenticated 2176 via iSCSI Login is using the IPsec SA. 2178 In fact, IPsec implementations that only support machine authentication 2179 typically have no way to distinguish between user traffic within the 2180 kernel. As a result, where machine authentication is used, once an IPsec 2181 SA is opened, another user on a multi-user machine may be able to send 2182 traffic down the IPsec SA. This is true for both transport mode and 2183 tunnel mode SAs. 2185 To limit the potential vulnerability, IP block storage implementations 2186 MUST do the following: 2188 [1] Ensure that socket access is appropriately controlled. On a multi- 2189 user operating system, this implies that sockets opened for use by 2190 IP block storage protocols MUST be exclusive. 2192 [2] In the case of iSCSI, implementations MUST also ensure that 2193 application layer login credentials (such as iSCSI login 2194 credentials) are protected from unauthorized access. 2196 If these directives are followed, then a rogue process will not be able 2197 to access an IP block storage volume. 2199 While the identity asserted within IKE is verified on a per-packet 2200 basis, to avoid interference between users on a given machine, operating 2201 system support is required. In order to segregate traffic between users 2202 when user authentication is supported, the IPsec endpoints must ensure 2203 that only traffic from that particular user is sent or received within 2204 the IPsec SA. Enforcement of this restriction is the responsibility of 2205 the operating system. 2207 In kernel mode iSCSI drivers there typically is no user context to 2208 perform user authentication. In this case the authentication is closer 2209 to machine authentication. In most operating systems device permissions 2210 would control the ability to read/write to the device prior to mounting. 2211 Once the device is mounted, ACLs set by the filesystem control access to 2212 the device. An administrator can access the blocks on the device 2213 directly (for instance, by sending pass through requests to the port 2214 driver directly such as in Windows NT). In the same way, an 2215 administrator can open a raw socket and send IPsec protected packets to 2216 an iSCSI target. The situation is analogous, and in this respect no new 2217 vulnerability is created that didn't previously exist. The Operating 2218 system's ACLs need to be effective to protect a device (whether it is a 2219 SCSI device or an iSCSI device). 2221 5.8.4. IP block storage authorization 2223 IP block storage protocols can use a variety of mechanisms for 2224 authorization. Where ID_FQDN is used as the Identity Payload, IP block 2225 storage endpoints can be configured with a list of authorized FQDNs. The 2226 configuration can occur manually, or automatically via iSNS or the iSCSI 2227 MIB, defined in [AuthMIB]. 2229 Assuming that IPsec authentication is successful, this list of FQDNs can 2230 be examined to determine authorization levels. Where certificate 2231 authentication is used, it is possible to configure IP block storage 2232 protocol endpoints with trusted roots. The trusted roots used with IP 2233 block storage protocols might be different from the trusted roots used 2234 for other purposes. If this is the case, then the burden of negotiating 2235 use of the proper certificates lies with the IPsec initiator. 2237 Note that because IKE does not deal well with certificate chains, and is 2238 typically configured with a limited set of trusted roots, it is most 2239 appropriate for intra-domain usage. 2241 Since iSCSI supports Login authentication, it is also possible to use 2242 the identities presented within the iSCSI Login for authorization 2243 purposes. 2245 In iFCP, basic access control properties stem from the requirement that 2246 two communicating iFCP gateways be known to one or more iSNS servers 2247 before they can engage in iFCP exchanges. The optional use of discovery 2248 domains in iSNS yields access control schemas of greater complexity. 2250 5.9. Use of AES in counter mode 2252 When utilizing AES modes, it may be necessary to use larger public keys; 2253 the tradeoffs are described in [KeyLen]. Additional MODP Diffie-Hellman 2254 groups for use with IKE are described in [MODP]. 2256 When AES in counter mode is used, it is important to avoid reuse of the 2257 counter with the same key, even across all time. Counter mode creates 2258 ciphertext by XORing generated key stream with plaintext. It is fairly 2259 easy to recover the plaintext from two messages counter mode encrypted 2260 under the same counter value, simply by XORing together the two packets. 2261 The implication of this is that it is an error to use IPsec manual 2262 keying with counter mode, except when the implementation takes heroic 2263 measures to maintain state across sessions. In any case, manual keying 2264 MUST NOT be used since it does not provide the necessary rekeying 2265 support. 2267 Another counter mode issue is it makes forgery of correct packets 2268 trivial. Counter mode should therefore never be used without also using 2269 data authentication. 2271 6. IANA Considerations 2273 IANA considerations for the iSCSI protocol are described in [iSCSI], 2274 Section 13; for the iFCP protocol in [iFCP], Section 12; and for the 2275 FCIP protocol in [FCIP], Appendix B. 2277 This section provides guidance to the Internet Assigned Numbers 2278 Authority (IANA) regarding registration of values of the SRP_GROUP key 2279 parameter within iSCSI, in accordance with BCP 26, [RFC2434]. 2281 6.1. Definition of Terms 2283 The following terms are used here with the meanings defined in BCP 26: 2284 "name space", "assigned value", "registration". 2286 The following policies are used here with the meanings defined in BCP 2287 26: "Private Use", "First Come First Served", "Expert Review", 2288 "Specification Required", "IETF Consensus", "Standards Action". 2290 6.2. Recommended Registration Policies 2292 For registration requests where a Designated Expert should be consulted, 2293 the responsible IESG Area Director should appoint the Designated Expert. 2295 For registration requests requiring Expert Review, the IPS mailing list 2296 should be consulted, or if the IPS WG is disbanded, to a mailing list 2297 designated by the IESG Area Director. 2299 This document defines the following SRP_GROUP keys: 2301 SRP-768, SRP-1024, SRP-1280, SRP-1536, SRP-2048, MODP-3072, 2302 MODP-4096, MODP-6144, MODP-8192 2304 New SRP_GROUP keys MUST conform to the iSCSI extension item-label format 2305 described in [iSCSI] Section 13.5.4. 2307 Registration of new SRP_GROUP keys is by Designated Expert with 2308 Specification Required. The request is posted to the IPS WG mailing list 2309 or its successor for comment and security review, and MUST include a 2310 non-probabalistic proof of primality for the proposed SRP group. After 2311 a period of one month as passed, the Designated Expert will either 2312 approve or deny the registration request. 2314 7. Normative references 2316 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2317 September 1981 2319 [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, 2320 November 1990 2322 [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU 2323 Discovery", RFC 1435, March 1993 2325 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery 2326 for IP version 6", RFC 1981, August 1996 2328 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 2329 Hashing for Message Authentication", RFC 2104, February 1997 2331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2332 Requirement Levels", BCP 14, RFC 2119, March 1997 2334 [RFC2401] Atkinson, R. and Kent, S., "Security Architecture for the 2335 Internet Protocol", RFC 2401, November 1998 2337 [RFC2404] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 2338 and AH", RFC 2404, November 1998 2340 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 2341 (ESP)", RFC 2406, November 1998 2343 [RFC2407] Piper, D., "The Internet IP Security Domain of 2344 Interpretation of ISAKMP", RFC 2407, November 1998 2346 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 2347 "Internet Security Association and Key Management Protocol 2348 (ISAKMP), RFC 2408, November 1998 2350 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 2351 RFC 2409, November 1998 2353 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2354 2412, November 1998 2356 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 2357 Considerations Section in RFCs", RFC 2434, October 1998 2359 [RFC2451] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 2360 Algorithms", RFC 2451, November 1998 2362 [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M, "Service 2363 Location Protocol, Version 2", RFC 2608, June 1999 2365 [RFC2923] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923, 2366 September 2000 2368 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System," 2369 RFC 2945, September 2000 2371 [3DESANSI] American National Standard for Financial Services 2372 X9.52-1998, "Triple Data Encryption Algorithm Modes of 2373 Operation", American Bankers Association, Washington, D.C., 2374 July 29, 1998 2376 [AESXCBC] Frankel, S., Herbert, H., "The AES-XCBC-MAC-96 Algorithm and 2377 Its Use with IPsec", Internet draft (work in progress), 2378 draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt, June 2002 2380 [AESCTR] Housley, R., "Using AES Counter Mode With IPsec ESP", 2381 Internet draft (work in progress), draft-ietf-ipsec-ciph- 2382 aes-ctr-01.txt, September 2002 2384 [DHCPIPsec] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 2385 Configuration of IPsec Tunnel Mode", Internet draft (work in 2386 progress), draft-ietf-ipsec-dhcp-13.txt, June 2001 2388 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 2389 progress), draft-ietf-ips-iSCSI-19.txt, November 2002 2391 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 2392 Channel Storage Networking", Internet drafts (work in 2393 progress), draft-ietf-ips-ifcp-13.txt, August 2002 2395 [FCIP] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", 2396 Internet draft (work in progress), draft-ietf-ips- 2397 fcovertcpip-12.txt, August 2002 2399 [iSCSIName] Bakke, M., et al., "iSCSI Naming and Discovery", draft-ietf- 2400 ips-iscsi-name-disc-08.txt, Work in Progress, October 2002 2402 [FCIPSLP] Petersen, D., "Finding FCIP Entities Using SLPv2", Internet 2403 draft (work in progress), draft-ietf-ips-fcip-slp-04.txt, 2404 September 2002 2406 [iSCSISLP] Bakke, M., "Finding iSCSI targets and Name Servers Using 2407 SLP", Internet draft (work in progress), draft-ietf-ips- 2408 iscsi-slp-03.txt, March 2002 2410 [iSNS] Gibbons, K., et al., "iSNS Internet Storage Name Service", 2411 Internet draft (work in progress), draft-ietf-ips- 2412 isns-12.txt, August 2002 2414 [SRPNDSS] Wu, T., "The Secure Remote Password Protocol", in 2415 Proceedings of the 1998 Internet Society Symposium on 2416 Network and Distributed Systems Security, San Diego, CA, pp. 2417 97-111 2419 [MODP] Kivinen, T., Kojo, M., "More MODP Diffie-Hellman groups for 2420 IKE", Internet draft (work in progress), draft-ietf-ipsec- 2421 ike-modp-groups-04.txt, December 2001 2423 8. Informative references 2425 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", 2426 RFC 2230, November 1997. 2428 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 2429 Architecture", RFC 2373, July 1998 2431 [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2432 2402, November 1998 2434 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2435 2535, March 1999 2437 [RFC2782] Gulbrandsen, A., Vixie, P., Esibov, L. "A DNS RR for 2438 specifying the location of services (DNS SRV)", RFC 2782, 2439 February 2000 2441 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., Wellington, B., 2442 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2443 2845, May 2000 2445 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2446 Authentication Dial In User Service (RADIUS)", RFC 2865, 2447 June 2000 2449 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures 2450 (SIG(0)s )", RFC 2931, September 2000 2452 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, 2453 October 2000. 2455 [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) 2456 Dynamic Update", RFC 3007, November 2000 2458 [AuthMIB] Bakke, M., et al., "Definitions of Managed Objects for 2459 iSCSI", Internet draft (work in progress), draft-ietf-ips- 2460 iscsi-mib-06.txt, September 2002 2462 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2463 April 1992 2465 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", 2466 CryptoBytes Vol.2 No.2, Summer 1996 2468 [CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum 2469 disagree", ACM Sigcomm, Sept. 2000 2471 [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000 2473 [KeyLen] Orman, H., Hoffman, P., "Determining Strengths For Public 2474 Keys Used For Exchanging Symmetric Keys", Internet draft 2475 (work in progress), draft-orman-public-key-lengths-05.txt, 2476 December 2001 2478 [iSCSIREQ] Krueger, M., et al., "SCSI over the Internet (isCSI) 2479 Requirements and Design Considerations", RFC 3347, July 2002 2481 [IPsecNatReq] 2482 Aboba, B., "IPsec-NAT Compatibility Requirements", draft- 2483 ietf-ipsec-nat-reqts-02.txt, Work in Progress, August 2002 2485 [UDPIPsec] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 2486 draft-ietf-ipsec-udp-encaps-03.txt, June 2002 2488 [Seq] Kent, S., "IP Encapsulating Security Payload (ESP)", 2489 Internet draft (work in progress), draft-ietf-ipsec-esp- 2490 v3-03.txt, July 2002 2492 [NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the 2493 IKE", Internet draft (work in progress), draft-ietf-ipsec- 2494 nat-t-ike-03.txt, June 2002 2496 [HMACMD5IPsec] 2497 Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP 2498 and AH", RFC 2403, November 1998 2500 [PMAC] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a 2501 parallelizable message authentication code", 2502 http://csrc.nist.gov/encryption/modes/proposedmodes/ 2503 pmac/pmac-spec.pdf 2505 [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway, 2506 P., "UMAC: Fast and provably secure message authentication", 2507 Advances in Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 2508 216-233. Full version available from 2509 http://www.cs.ucdavis.edu/~rogaway/umac 2511 [FIPS46-3] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, 2512 October 25, 1999 2514 [FIPS74] U.S. DoC/NIST, "Guidelines for implementing and using the 2515 nbs data encryption standard", FIPS 74, Apr 1981 2517 [FIPS197] U.S. DoC/NIST, "Advanced Encryption Standard (AES)", FIPS 2518 197, November 2001, http://csrc.nist.gov/publications/ 2520 [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- 2521 like cryptosystems", Journal of Cryptology Vol 4, Jan 1991 2523 [RFC2405] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm 2524 With Explicit IV", RFC 2405, November 1998 2526 [NSPUE2] "Recommendation for Block Cipher Modes of Operation", 2527 National Institute of Standards and Technology (NIST) 2528 Special Publication 800-38A, CODEN: NSPUE2, U.S. Government 2529 Printing Office, Washington, DC, July 2001 2531 [CTR-MODE] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", 2532 Comment on mode of operations NIST, Jan 2001 2534 [AESPERF] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, 2535 and N. Ferguson, "Performance Comparison of the AES 2536 Submissions", http://www.counterpane.com/AES- 2537 performance.html 2539 [PENTPERF] A. Bosselaers, "Performance of Pentium implementations", 2540 http://www.esat.kuleuven.ac.be/~bosselae/ 2542 [UMACPERF] Rogaway, P., "UMAC Performance", 2543 http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 2545 [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without 2546 Strong Integrity", Proceedings of the 32nd IETF, Danvers, 2547 MA, April 1995 2549 [UMACKR] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., 2550 Rogaway, P., "UMAC: Message Authentication Code using 2551 Universal Hashing", Internet draft (work in progress), 2552 draft-krovetz-umac-01.txt, October 2000. Also available at: 2553 http://www.cs.ucdavis.edu/~rogaway/umac/draft-krovetz- 2554 umac-01.txt 2556 [RFC1994] Simpson, W.,"PPP Challenge Handshake Authentication Protocol 2557 (CHAP)," RFC 1994, August 1996. 2559 [DESANALY] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of 2560 Symmetric Encryption: Analysis of the DES Modes of 2561 Operation", 1997, http://www-cse.ucsd.edu/users/mihir/ 2563 [SRPDIST] Wu, T., "SRP Distribution", http://www-cs- 2564 students.stanford.edu/~tjw/srp/download.html 2566 Appendix A - Well Known Groups for Use with SRP 2568 Modulus (N) and generator (g) values for various modulus lengths are 2569 given below. The values below are taken from software developed by Tom 2570 Wu and Eugene Jhong for the Stanford SRP distribution [SRPDIST], and 2571 subsequently rigorously verified to be prime. Implementations supporting 2572 SRP authentication MUST support groups up to 1536 bits, with 1536 bits 2573 being the default. 2575 iSCSI Key="SRP-768" [768 bits] 2576 Modulus (base 16) = 2577 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2578 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 2579 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B 2580 Generator = 2 2582 iSCSI Key="SRP-1024" [1024 bits] 2583 Modulus (base 16) = 2584 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 2585 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 2586 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 2587 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 2588 Generator = 2 2590 iSCSI Key="SRP-1280" [1280 bits] 2591 Modulus (base 16) = 2592 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 2593 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 2594 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 2595 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 2596 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B 2597 Generator = 2 2599 iSCSI Key="SRP-1536" [1536 bits] 2600 Modulus (base 16) = 2601 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 2602 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC 2603 DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 2604 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 2605 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 2606 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB 2607 Generator = 2 2608 iSCSI Key="SRP-2048" [2048 bits] 2609 Modulus (base 16) = 2610 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 2611 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 2612 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 2613 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B 2614 CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 2615 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 2616 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 2617 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 2618 Generator = 2 2620 In addition to these groups, the following groups MAY be supported, each 2621 of which has also been rigorously proven to be prime: 2623 [1] iSCSI Key="MODP-3072": the 3072-bit [MODP] group, generator: 5 2625 [2] iSCSI Key="MODP-4096": the 4096-bit [MODP] group, generator: 5 2627 [3] iSCSI Key="MODP-6144": the 6144-bit [MODP] group, generator: 5 2629 [4] iSCSI Key="MODP-8192": the 8192-bit [MODP] group, generator: 19 2630 Appendix B - Software Performance of IPsec Transforms 2632 This Appendix provides data on the performance of IPsec encryption and 2633 authentication transforms in software. Since the performance of IPsec 2634 transforms is heavily implementation dependent, the data presented here 2635 may not be representative of performance in a given situation, and are 2636 presented solely for purposes of comparison. Other performance data is 2637 available in [AESPERF],[PENTPERF] and [UMACPERF]. 2639 B.1 Authentication transforms 2641 Table B-1 presents the cycles/byte required by the AES-PMAC, AES-CBC- 2642 MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet 2643 sizes, implemented in software. 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | | | | | | | 2647 | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | 2648 | Size | PMAC | MAC | UMAC | MD5 | SHA1 | 2649 | | | | | | | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 | 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 | 2662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2663 | 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 | 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 | 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 | 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 | 2668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2669 | 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2672 | | | | | | | 2673 | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | 2674 | Size | PMAC | MAC | UMAC | MD5 | SHA1 | 2675 | | | | | | | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 | 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 | 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 Table B-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, 2693 AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at 2694 various packet sizes. 2696 Source: Jesse Walker, Intel 2697 Table B-2 presents the cycles/second required by the AES-PMAC, AES-CBC- 2698 MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in 2699 software, assuming a 1500 byte packet. 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 2703 | Transform | octet | @ | @ | @ | 2704 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 | | | | | | 2707 | AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B | 2708 | (8 octets) | | | | | 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | | | | | | 2711 | HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B | 2712 | (20 octets) | | | | | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 | | | | | | 2715 | HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B | 2716 | | | | | | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | | | | | | 2719 | AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B | 2720 | | | | | | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 | | | | | | 2723 | AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B | 2724 | (8 octets) | | | | | 2725 | | | | | | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 Table B-2: Software performance of the HMAC-SHA1, HMAC-MD5, 2729 AES-CBC-MAC and AES-PMAC authentication algorithms at 100 Mbps, 2730 1 Gbps, and 10 Gbps line rates (1500 byte packet). 2732 Source: Jesse Walker, Intel 2734 At speeds of 100 Mbps, AES-UMAC is implementable with only a modest 2735 processor, and the other algorithms are implementable, assuming that a 2736 single high-speed processor can be dedicated to the task. At 1 Gbps, 2737 only AES-UMAC is implementable on a single high-speed processor; 2738 multiple high speed processors (1+ Ghz) will be required for the other 2739 algorithms. At 10 Gbps, only AES-UMAC is implementable even with 2740 multiple high speed processors; the other algorithms will require a 2741 prodigious number of cycles/second. Thus at 10 Gbps, hardware 2742 acceleration will be required for all algorithms with the possible 2743 exception of AES-UMAC. 2745 B.2 Encryption and Authentication transforms 2747 Table B-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 2748 3DES-CBC encryption algorithms (no MAC), implemented in software, for 2749 various packet sizes. 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 | | | | | 2753 | Data size | AES-CBC | AES-CTR | 3DES-CBC | 2754 | | | | | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | 64 | 31.22 | 26.02 | 156.09 | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 | 128 | 31.22 | 28.62 | 150.89 | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 | 192 | 31.22 | 27.75 | 150.89 | 2761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 | 256 | 28.62 | 27.32 | 150.89 | 2763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2764 | 320 | 29.14 | 28.1 | 150.89 | 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | 384 | 28.62 | 27.75 | 148.29 | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | 448 | 28.99 | 27.5 | 149.4 | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2770 | 512 | 28.62 | 27.32 | 148.29 | 2771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2772 | 576 | 28.33 | 27.75 | 147.72 | 2773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2774 | 640 | 28.62 | 27.06 | 147.77 | 2775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | | | | | 2778 | Data size | AES-CBC | AES-CTR | 3DES-CBC | 2779 | | | | | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | 768 | 28.18 | 27.32 | 147.42 | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | 896 | 28.25 | 27.5 | 147.55 | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | 1024 | 27.97 | 27.32 | 148.29 | 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2787 | 1152 | 28.33 | 27.46 | 147.13 | 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | 1280 | 28.1 | 27.58 | 146.99 | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | 1408 | 27.91 | 27.43 | 147.34 | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 | 1500 | 27.97 | 27.53 | 147.85 | 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 2797 3DES-CBC encryption algorithms at various packet sizes, 2798 implemented in software. 2800 Source: Jesse Walker, Intel 2801 Table B-4 presents the cycles/second required by the AES-CBC, AES-CTR 2802 and 3DES-CBC encryption algorithms (no MAC), implemented in software, at 2803 100 Mbps, 1 Gbps, and 10 Gbps line rates (assuming a 1500 byte packet). 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 2807 | Transform | octet | @ | @ | @ | 2808 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | | | | | | 2811 | AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B | 2812 | | | | | | 2813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2814 | | | | | | 2815 | AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B | 2816 | | | | | | 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2818 | | | | | | 2819 | 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B | 2820 | | | | | | 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 Table B-4: Software performance of the AES-CBC, AES-CTR, and 3DES 2824 encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates 2825 (1500 byte packet). 2827 Source: Jesse Walker, Intel 2829 At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a 2830 high-speed processor, while 3DES would require multiple high speed 2831 processors. At speeds of 1 Gbps, multiple high speed processors are 2832 required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, 2833 and 10 Gbps for all algorithms, implementation in software is 2834 infeasible, and hardware acceleration is required. 2836 Table B-5 presents the cycles/byte required for combined 2837 encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + 2838 CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented 2839 in software. 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2842 | | AES | AES | AES | | 2843 | Data size | CBC + | CTR + | CTR + | AES- | 2844 | | CBCMAC | CBCMAC | UMAC | OCB | 2845 | | | | | | 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2847 | 64 | 119.67 | 52.03 | 52.03 | 57.23 | 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2849 | 128 | 70.24 | 57.23 | 39.02 | 44.23 | 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | 192 | 58.97 | 55.5 | 36.42 | 41.63 | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 | 256 | 57.23 | 55.93 | 35.12 | 40.32 | 2854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2855 | 320 | 57.23 | 55.15 | 33.3 | 38.5 | 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 | 384 | 57.23 | 55.5 | 32.95 | 37.29 | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2859 | 448 | 58.72 | 55 | 32.71 | 37.17 | 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 | 512 | 58.54 | 55.28 | 32.52 | 36.42 | 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | | AES | AES | AES | | 2865 | Data size | CBC + | CTR + | CTR + | AES- | 2866 | | CBCMAC | CBCMAC | UMAC | OCB | 2867 | | | | | | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | 576 | 57.81 | 55.5 | 31.8 | 37 | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 | 640 | 57.75 | 55.15 | 31.74 | 36.42 | 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 | 768 | 57.67 | 55.5 | 31.65 | 35.99 | 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 | 896 | 57.61 | 55.75 | 31.22 | 35.68 | 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2877 | 1024 | 57.56 | 55.61 | 31.22 | 35.45 | 2878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2879 | 1152 | 57.52 | 55.21 | 31.22 | 35.55 | 2880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 | 1280 | 57.75 | 55.15 | 31.22 | 36.16 | 2882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2883 | 1408 | 57.47 | 55.34 | 30.75 | 35.24 | 2884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2885 | 1500 | 57.72 | 55.5 | 30.86 | 35.3 | 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 Table B-5: Cycles/byte of combined encryption/authentication 2889 algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, 2890 and AES-OCB at various packet sizes, implemented in software. 2892 Table B-6 presents the cycles/second required for the AES CBC + CBCMAC, 2893 AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and 2894 authentication algorithms operating at line rates of 100 Mbps, 1 Gbps 2895 and 10 Gbps, assuming 1500 byte packets. 2897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 2899 | Transform | octet | @ | @ | @ | 2900 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2902 | | | | | | 2903 | AES | | | | | 2904 |CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B | 2905 | | | | | | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 | | | | | | 2908 | AES | | | | | 2909 |CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B | 2910 | | | | | | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | | | | | | 2913 | AES | | | | | 2914 | CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B | 2915 | | | | | | 2916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 | | | | | | 2918 | | | | | | 2919 | AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B | 2920 | | | | | | 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 Table B-6: Cycles/second required for the AES CBC + CBCMAC, 2924 AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and 2925 authentication algorithms, operating at line rates of 100 Mbps, 2926 1 Gbps and 10 Gbps, assuming 1500 octet packets. 2928 Source: Jesse Walker, Intel 2930 At speeds of 100 Mbps, the algorithms are implementable on a high speed 2931 processor. At speeds of 1 Gbps, multiple high speed processors are 2932 required, and none of the algorithms are implementable in software at 10 2933 Gbps line rate. 2935 Acknowledgments 2937 Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft, 2938 David Black of EMC, Joseph Tardo and Uri Elzur of Broadcom, Julo Satran, 2939 Ted Ts'o, Ofer Biran, and Charles Kunzinger of IBM, Allison Mankin of 2940 ISI, Mark Bakke and Steve Senum of Cisco, Erik Guttman of Sun 2941 Microsystems and Howard Herbert of Intel for useful discussions of this 2942 problem space. 2944 Authors' Addresses 2946 Bernard Aboba 2947 Microsoft Corporation 2948 One Microsoft Way 2949 Redmond, WA 98052 2951 Phone: +1 425 706 6605 2952 Fax: +1 425 936 7329 2953 EMail: bernarda@microsoft.com 2955 Joshua Tseng 2956 Nishan Systems 2957 3850 North First Street 2958 San Jose, CA 95134-1702 2960 Phone: +1 408 519 3749 2961 EMail: jtseng@nishansystems.com 2963 Jesse Walker 2964 Intel Corporation 2965 2211 NE 25th Avenue 2966 Hillboro, OR 97124 2968 Phone: +1 503 712 1849 2969 Fax: +1 503 264 4843 2970 Email: jesse.walker@intel.com 2972 Venkat Rangan 2973 Rhapsody Networks Inc. 2974 3450 W. Warren Ave. 2975 Fremont, CA 94538 2977 Phone: +1 510 743 3018 2978 Fax: +1 510 687 0136 2979 EMail: venkat@rhapsodynetworks.com 2980 Franco Travostino 2981 Director, Content Internetworking Lab 2982 Nortel Networks 2983 3 Federal Street 2984 Billerica, MA 01821 2986 Phone: +1 978 288 7708 2987 EMail: travos@nortelnetworks.com 2989 Intellectual Property Rights 2991 The IETF takes no position regarding the validity or scope of any 2992 intellectual property or other rights that might be claimed to pertain 2993 to the implementation or use of the technology described in this 2994 document or the extent to which any license under such rights might or 2995 might not be available; neither does it represent that it has made any 2996 effort to identify any such rights. Information on the IETF's 2997 procedures with respect to rights in standards-track and standards- 2998 related documentation can be found in BCP-11. Copies of claims of 2999 rights made available for publication and any assurances of licenses to 3000 be made available, or the result of an attempt made to obtain a general 3001 license or permission for the use of such proprietary rights by 3002 implementors or users of this specification can be obtained from the 3003 IETF Secretariat. 3005 The IETF invites any interested party to bring to its attention any 3006 copyrights, patents or patent applications, or other proprietary rights 3007 which may cover technology that may be required to practice this 3008 standard. Please address the information to the IETF Executive 3009 Director. 3011 Full Copyright Statement 3013 Copyright (C) The Internet Society (2003). All Rights Reserved. 3015 This document and translations of it may be copied and furnished to 3016 others, and derivative works that comment on or otherwise explain it or 3017 assist in its implmentation may be prepared, copied, published and 3018 distributed, in whole or in part, without restriction of any kind, 3019 provided that the above copyright notice and this paragraph are included 3020 on all such copies and derivative works. However, this document itself 3021 may not be modified in any way, such as by removing the copyright notice 3022 or references to the Internet Society or other Internet organizations, 3023 except as needed for the purpose of developing Internet standards in 3024 which case the procedures for copyrights defined in the Internet 3025 Standards process must be followed, or as required to translate it into 3026 languages other than English. 3028 The limited permissions granted above are perpetual and will not be 3029 revoked by the Internet Society or its successors or assigns. 3031 This document and the information contained herein is provided on an "AS 3032 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3033 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3034 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3035 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3036 FITNESS FOR A PARTICULAR PURPOSE. 3038 Expiration Date 3040 This memo is filed as , and expires 3041 August 22, 2003.