idnits 2.17.00 (12 Aug 2021) /tmp/idnits16526/draft-aboba-ips-iscsi-security-00.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. == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 69 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 123 has weird spacing: '...ns, and retur...' == Line 359 has weird spacing: '...tations requi...' == Line 548 has weird spacing: '...nection has u...' == Line 549 has weird spacing: '...ecurity assoc...' == 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) == Unused Reference: '12' is defined on line 891, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 894, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 900, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 903, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 908, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 918, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 921, but no explicit reference was found in the text == Unused Reference: '38' is defined on line 978, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 982, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 986, but no explicit reference was found in the text == Unused Reference: '41' is defined on line 989, but no explicit reference was found in the text == Unused Reference: '42' is defined on line 993, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: '50' is defined on line 1019, but no explicit reference was found in the text -- No information found for draft-ietf-ips-iSCSI - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1435 (ref. '12') ** Obsolete normative reference: RFC 1981 (ref. '13') (Obsoleted by RFC 8201) ** Downref: Normative reference to an Informational RFC: RFC 2923 (ref. '14') -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' == Outdated reference: draft-ietf-ips-iscsi-reqmts has been published as RFC 3347 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '19') -- No information found for draft-ietf-IPsec-nat-reqts - is the name correct? -- Possible downref: Normative reference to a draft: ref. '20' -- No information found for draft-ietf-IPsec-udp-encaps - is the name correct? -- Possible downref: Normative reference to a draft: ref. '21' -- No information found for draft-ietf-IPsec-udp-encaps-justification - is the name correct? -- Possible downref: Normative reference to a draft: ref. '22' -- No information found for draft-ietf-IPsec-nat-t-ike - is the name correct? -- Possible downref: Normative reference to a draft: ref. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' -- Possible downref: Non-RFC (?) normative reference: ref. '28' -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' -- Possible downref: Non-RFC (?) normative reference: ref. '34' -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '37' == Outdated reference: draft-ietf-ipsec-ciph-aes-cbc has been published as RFC 3602 -- Possible downref: Normative reference to a draft: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' -- Possible downref: Non-RFC (?) normative reference: ref. '41' -- Possible downref: Non-RFC (?) normative reference: ref. '42' -- Possible downref: Non-RFC (?) normative reference: ref. '43' == Outdated reference: draft-krovetz-umac has been published as RFC 4418 ** Downref: Normative reference to an Informational draft: draft-krovetz-umac (ref. '44') -- Possible downref: Non-RFC (?) normative reference: ref. '45' ** Obsolete normative reference: RFC 2246 (ref. '46') (Obsoleted by RFC 4346) == Outdated reference: A later version (-01) exists of draft-black-ips-iscsi-security-00 -- Possible downref: Normative reference to a draft: ref. '48' -- Possible downref: Non-RFC (?) normative reference: ref. '49' -- Possible downref: Non-RFC (?) normative reference: ref. '50' -- Possible downref: Non-RFC (?) normative reference: ref. '51' Summary: 17 errors (**), 0 flaws (~~), 26 warnings (==), 36 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Working Group Bernard Aboba 3 INTERNET-DRAFT William Dixon 4 Category: Standards Track Microsoft 5 Joseph Tardo 6 18 August 2001 Uri Elzur 7 Broadcom 8 M. Bakke 9 S. Senum 10 Cisco Systems 11 Howard Herbert 12 Jesse Walker 13 Intel 14 J. Satran 15 Ofer Biran 16 Charles Kunzinger 17 IBM 18 David Black 19 EMC 21 Securing iSCSI using IPsec 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with all 26 provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering Task 29 Force (IETF), its areas, and its working groups. Note that other groups 30 may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference material 35 or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright Notice 45 Copyright (C) The Internet Society (2001). All Rights Reserved. 47 Abstract 49 This document discusses how iSCSI may utilize IPsec to provide 50 authentication, integrity, confidentiality and replay protection. 52 Table of Contents 54 1. Introduction .......................................... 3 55 1.1 Terminology ..................................... 3 56 1.2 Requirements language ........................... 4 57 2. iSCSI security requirements .......................... 4 58 2.1 iSCSI security protocol ......................... 4 59 2.2 Rekeying issues ................................ 5 60 2.3 IKE issues ...................................... 6 61 2.4 Transform issues ................................ 6 62 3. iSCSI/IPsec inter-operability guidelines .............. 10 63 3.1 iSCSI/IPsec binding ............................. 10 64 3.2 Initiating a new iSCSI session .................. 11 65 3.3 Graceful iSCSI teardown ......................... 12 66 3.4 Non-graceful iSCSI teardown ..................... 12 67 3.5 Fragmentation Issues ............................ 13 68 3.6 Per-packet Security Checks ...................... 13 69 3.7 Application layer CRC ........................... 14 70 3.8 NAT traversal ................................... 15 71 4. Security considerations ............................... 16 72 4.1 IKE and iSCSI authentication .................... 16 73 4.2 Certificate authentication ...................... 17 74 4.3 Machine versus user authentication .............. 17 75 4.4 Pre-shared keys ................................. 18 76 5. References ............................................ 19 77 Appendix A - Software Performance of IPsec Transforms ....... 23 78 A.1 Authentication transforms ....................... 23 79 A.2 Encryption and Authentication transforms ........ 26 80 ACKNOWLEDGMENTS .............................................. 31 81 AUTHORS' ADDRESSES ........................................... 32 82 Intellectual property statement .............................. 34 83 Full Copyright Statement ..................................... 34 84 1. Introduction 86 iSCSI, described in [1], is a connection-oriented command/response 87 protocol. An iSCSI session begins with an iSCSI Initiator connecting to 88 an iSCSI Target over TCP, and performing an iSCSI login. While the 89 iSCSI logon may include mutual authentication of the iSCSI endpoints and 90 negotiation of session parameters, iSCSI does not define its own per- 91 packet authentication, integrity, confidentiality or replay protection 92 mechanisms. 94 After a successful login, the iSCSI Initiator may issue SCSI commands 95 for execution by the iSCSI Target, which returns a status response for 96 each command, over the same connection. A single connection is used for 97 both command/status messages as well as transfer of data and/or optional 98 command parameters. An iSCSI session may have multiple connections, but 99 a separate login is performed on each. The iSCSI session terminates 100 when its last connection is closed. 102 IPsec is a protocol suite which is used to secure communication at the 103 network layer between two peers. The IPsec protocol suite is specified 104 within the IP Security Architecture [6], IKE [7], IPsec Authentication 105 Header (AH) [3] and IPsec Encapsulating Security Payload (ESP) [4] 106 documents. IKE is the key management protocol while AH and ESP are used 107 to protect IP traffic. 109 This draft proposes use of the IPsec protocol suite for protecting iSCSI 110 traffic over IP networks, and discusses how IPsec and iSCSI should be 111 used together. 113 1.1. Terminology 115 iSCSI iSCSI is a client-server protocol in which clients 116 (Initiators) open connections to servers (Targets). 118 Initiator The iSCSI Initiator connects to the Target on well-known TCP 119 port . The iSCSI Initiator then issues SCSI commands for 120 execution by the iSCSI Target. 122 Target The iSCSI Target listens on a well-known TCP port for incoming 123 connections, and returns a status response for each command 124 issued by the iSCSI Initiator, over the same connection. 126 1.2. Requirements language 128 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 129 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 130 described in [2]. 132 2. iSCSI security requirements 134 The iSCSI protocol is used to transmit SCSI commands over IP networks. 135 Therefore, both the control and data packets of iSCSI are vulnerable to 136 attack. Examples of attacks include: 138 [1] An adversary may try to discover user identities by snooping data 139 packets. 141 [2] An adversary may try to modify packets (both control and data). 143 [3] An adversary may try to hijack the iSCSI connection. 145 [4] An adversary can launch denial of service attacks by terminating 146 iSCSI connections, such as by sending a TCP reset. 148 [5] An adversary may attempt to disrupt the iSCSI logon negotiation so 149 as to weaken the iSCSI authentication process or gain access to 150 user passwords. 152 To address these threats, the iSCSI security protocol MUST provide 153 authentication, integrity and replay protection for control and data 154 packets. It MUST provide confidentiality for control and data packets. 155 An iSCSI security protocol MUST also provide a scalable approach to key 156 management. 158 The iSCSI protocol, and iSCSI logon authentication do not meet the 159 security requirements for iSCSI. iSCSI logon authentication provides 160 mutual authentication between the iSCSI Initiator and Target at 161 connection origination, but does not protect control and data traffic on 162 a per packet basis, leaving the iSCSI connection vulnerable to attack. 163 iSCSI logon authentication via SRP [48] mutually authenticates the 164 Initiator to the Target, but does not by itself provide per-packet 165 authentication, integrity, confidentiality or replay protection. In 166 addition, iSCSI logon authentication, outlined in [1], does not provide 167 for a protected ciphersuite negotiation. Therefore, iSCSI logon 168 provides a weak security solution. 170 2.1. iSCSI Security Protocol 172 All iSCSI security compliant implementations MUST implement IPsec ESP in 173 transport mode for securing both iSCSI control and data packets. If 174 confidentiality is not used (e.g., iSCSI data traffic), ESP with NULL 175 encryption may be used. The implementations MUST implement replay 176 protection mechanisms of IPsec. 178 iSCSI security MUST meet the key management requirements of the IPsec 179 protocol suite. IKE SHOULD be supported for authentication, security 180 association negotiation, and key management using the IPsec DOI [5]. 182 To provide authentication, integrity and replay protection of iSCSI 183 PDUs, iSCSI security implementations MUST support transport mode ESP 184 with NULL encryption and HMAC-SHA1 authentication. Transport mode ESP 185 with AES in OCB mode MUST be supported to provide confidentiality as 186 well as authentication, integrity and replay protection. 188 2.2. Rekeying issues 190 It is expected that iSCSI implementations will need to operate at high 191 speed. For example, implementations operating at 1 Gbps are currently in 192 design, with 10 Gbps implementations to follow shortly thereafter. At 193 these speeds, iSCSI will rapidly cycle through the 32-bit IPsec sequence 194 number space. 196 For example, a 1 Gbps implementation sending 64 octet packets 197 exclusively would exhaust the 32-bit sequence number space in 2200 198 seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur 199 in 14.5 hours. 201 A 10 Gbs implementation sending 64 octet packets would exhaust the 202 sequence number space in 220 seconds or 3.67 minutes. With 1518 octet 203 packets, this would occur within 1.45 hours. 205 As a result, iSCSI implementations operating at speeds of 1 Gbps or less 206 MAY implement the IPsec sequence number extension, described in [49]. 10 207 Gbps or faster implementations SHOULD implement the extension 208 specification. 210 Note that depending on the transform in use, it is possible that 211 rekeying will be required prior to exhaustion of the sequence number 212 space. Bellare et. al. have formalized this in [51], showing that the 213 insecurity of CBC mode increases as O(s^2/2^n), where n is the block 214 size in bits, and s is the total number of blocks encrypted. 216 This formula sets a limit on the bytes that can be sent on a CBC SA 217 before a rekey is required: 219 B = s * n/8 = (n/8) * 2^(n/2) 221 Where: 222 B = maximum bytes sent on the SA 223 n = block size in bits 225 This means that cipher block size as well as key length need to be 226 considered in the rekey decision. 3DES uses a block size n = 64 bits 227 (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) 228 * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that a rekey 229 will be required every 274.9 seconds (4.6 minutes); at 10 Gbps, a rekey 230 is required every 27.5 seconds. In practice, a safety margin is required 231 so the required rekey times will be even smaller. 233 In terms of the sequence number space, for a 3DES encrypted message of 234 512 = 2^9 bytes (2^6 blocks) this implies that the key has become 235 insecure after about 2^26 messages. This is s = 2^26 * 2^6 = 2^32 236 blocks and (2^32)^2/2^64 = 1. With the 3DES cipher in CBC mode, it 237 would be prudent to rekey more often, such as every 2^20 messages or 238 2^29 bytes. This would imply a rekey time of 4.29 seconds at 1 Gbps or 239 0.43 seconds at 10 Gbps. These exceedingly short rekey times make it 240 very difficult to utilize 3DES effectively to secure iSCSI. 242 In comparision, AES-CBC uses a block size of 128 bits (2^4 bytes). This 243 enables B = (128/8) * (2^64) = 2^68 bytes to be sent prior to requiring 244 a rekey. This means that the required rekey times are 2^33 times longer 245 than for 3DES. 247 In terms of the sequence number space, for an AES encrypted message of 248 512 = 2^9 bytes (2^5 blocks) this implies that the key has become 249 insecure after about 2^59 messages (2^59 * 2^5)^2/2^128 = 1. This means 250 that the entire current ESP sequence space of 2^32 messages could be 251 consumed without compromising the key. AES would still permit a safe CBC 252 mode construction if the ESP sequence space were expanded to 48 bits, 253 since (2^48 * 2^5)^2/2^128 = 2^-22. 255 2.3. IKE issues 257 As noted in [48], there are situations where it is necessary for IKE to 258 be implemented in firmware. With the proliferation of IPsec host 259 implementations, these issues are most likely to arise in Target 260 designs. 262 In such situations, it is important to keep the size of the IKE 263 implementation within strict limits. As noted in [48] an upper bound on 264 the size of an IKE implementation might be considered to be 800 KB, with 265 80 KB enabling implementation in a wide range of situations. 267 As noted in Table 1 on the next page, IKE implementations currently 268 exist which meet the requirements. Therefore, while removal of seldomly 269 used IKE functionality (such as the nonce authentication methods) would 270 reduce complexity, iSCSI implementations typically will not require this 271 in order to fit within the code size budget. 273 2.4. Transform issues 275 Since iSCSI implementations may operate at speeds of 1 Gbps or greater, 276 the ability to offer IPsec security services at high speeds is of 277 intense concern. Since support for multiple algorithms multiplies the 278 complexity and expense of hardware design, one of the goals of the 279 transform selection effort is to find a minimal set of confidentiality 280 and authentication algorithms implementable in hardware at speeds of up 281 to 10 Gbps, as well as being efficient for implementation in software at 282 speeds of 100 Mbps. 284 In this specification, we primarily concern ourselves with IPsec 285 transforms that have already been specified, and for which parts are 286 available that can run at 1 Gbps line rate. Where existing algorithms do 287 not gracefully scale to 10 Gbps, we further consider algorithms for 288 which transform specifications are not yet complete, but for which parts 289 are expected to be available for inclusion in products shipping within 290 the next 12 months. As the state of the art advances, the range of 291 feasible algorithms will broaden and additional mandatory-to-implement 292 algorithms may be considered. 294 This draft proposes that iSCSI security utilize IPsec transport mode 295 ESP. Section 5 of RFC 2406 [4] states: 297 "A compliant ESP implementation MUST support the following 298 mandatory-to-implement algorithms: 300 - DES in CBC mode 301 - HMAC with MD5 302 - HMAC with SHA-1 303 - NULL Authentication algorithm 304 - NULL Encryption algorithm 305 " 307 The DES algorithm is specified in [29]; implementation guidelines are 308 found in [30], and security issues are discussed in [31],[43], [17]. The 309 DES IPsec transform is defined in [32] and the 3DES in CBC mode IPsec 310 transform is specified in [33]. 312 The MD5 algorithm is specified in [8]; HMAC is defined in [19] and 313 security issues with MD5 are discussed in [19]. The HMAC-MD5 IPsec 314 transform is specified in [24]. The HMAC-SHA1 IPsec transform is 315 specified in [25]. 317 In addition to these existing algorithms, NIST is currently evaluating 318 the following modes [37] of AES, defined in [34],[35]: 320 AES in Electronic Codebook (ECB) confidentiality mode 321 AES in Cipher Block Chaining (CBC) confidentiality mode 322 AES in Cipher Feedback (CFB) confidentiality mode 323 AES in Output Feedback (OFB) confidentiality mode 324 AES in Counter (CTR) confidentiality mode 325 AES CBC-MAC authentication mode 327 The Modes [36] effort is also considering a number of additional 328 algorithms, including the following: 330 PMAC 332 HMAC-SHA1 [25] is to be preferred to HMAC-MD5, due to concerns that have 333 been raised about the security of MD5 [9]. HMAC-SHA1 parts are 334 currently available that run at 1 Gbps, the algorithm is implementable 335 in hardware at speeds up to 10 Gbps, and an IPsec transform 336 specification [25] exists. As a result, it is most practical to utilize 337 HMAC-SHA1 as the authentication algorithm for products shipping in the 338 near future. As a result, iSCSI security implementations MUST implement 339 HMAC with SHA1. 341 The HMAC-SHA2 algorithm [28] is also under development, including an 342 IPsec transform [45], so that this may merit consideration in the 343 future. Authentication transforms also exist that are considerably more 344 efficient to implement than either HMAC-SHA1 or HMAC-SHA2. UMAC 345 [27],[44] is more efficient to implement in software and PMAC [26] is 346 more efficient to implement in hardware. PMAC is currently being 347 evaluated as part of the NIST modes effort [36] but an IPsec transform 348 does not yet exist; neither does a UMAC transform. 350 For confidentiality, the ESP mandatory-to-implement algorithm (DES) is 351 unacceptable for use with iSCSI security. As noted in [17], DES is 352 crackable with modest computation resources, and so is inappropriate for 353 use in situations requiring high levels of security. 3DES also has 354 significant disadvantages. As described in Appendix A, 3DES software 355 implementations make excessive computational demands at speeds of 100 356 Mbps or greater, effectively ruling out software-only iSCSI 357 implementations at speeds of 100 Mbps or less. 359 In addition, 3DES implementations require rekeying prior to exhaustion 360 of the current 32-bit IPsec sequence number space, and thus would not be 361 able to make use of sequence space extensions, if they were available. 362 This means that 3DES will require very frequent rekeying at speeds of 10 363 Gbps or greater. 365 For these reasons, while hardware implementations of 3DES are available 366 at the required speeds, and IPsec transforms are available, 3DES is 367 inconvenient for use at high speeds, as well as being impractical for 368 implementation in software at slower speeds (100 Mbps). As a result, 369 3DES is optional for use with iSCSI security. 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | Code size | | 373 |Implementation | (octets) | Release | 374 | | | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | | Linux | 377 | Pluto | 258KB | FreeSWAN | 378 |(FreeSWAN) | | x86 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | | | 381 | Racoon | 400KB | NetBSD 1.5 | 382 | (KAME) | | x86 | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | | | 385 | Isakmpd | 283KB | NetBSD 1.5 | 386 | (Erickson) | | x86 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | | | 389 | WindRiver | 142KB | PowerPC | 390 | | | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | | | 393 | Cisco | 222KB | PowerPC | 394 | VPN1700 | | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | | | 397 | Cisco | 350K | PowerPC | 398 | VPN3000 | | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | | | 401 | Cisco | 228KB | MIPS | 402 | VPN7200 | | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Table 1 - Code Size for IKE implementations 406 iSCSI security implementations MUST implement AES in OCB mode; an IPsec 407 transform for this does not yet exist. 409 3. iSCSI/IPsec inter-operability guidelines 411 The following guidelines are established to meet iSCSI security 412 requirements using IPsec in practical situations. 414 3.1. iSCSI/IPsec binding 416 An iSCSI session [1], comprised of one or more TCP connections, is 417 identified by the 2-tuple of the Initiator-defined identifier and the 418 Target-defined identifier, . Each connection within a given 419 session is assigned a unique Connection Identification, CID. The TCP 420 connection is identified by the 5-tuple . An IPsec Phase 2 SA is 422 identified by the 3-tuple . 424 The iSCSI session and connection information is carried within the iSCSI 425 Login Commands, transported over TCP. Since an iSCSI initiator may have 426 multiple interfaces, iSCSI connections within an iSCSI session may be 427 initiated from different IP addresses. Similarly, multiple iSCSI targets 428 may exist behind a single IP address, so that there may be multiple 429 iSCSI sessions between a given pair. 432 The relationship between iSCSI sessions, TCP connections and IKE Phase 1 433 and Phase 2 SAs is as follows: 435 [1] An iSCSI initiator or target may have more than one interface, and 436 therefore may have multiple IP addresses. Also, multiple iSCSI 437 initiators and targets may exist behind a single IP address. As a 438 result, an iSCSI Session may correspond to multiple IKE Phase 1 439 Security Associations, though typically a single IKE Phase 1 440 security association will exist for an tuple. 443 [2] Each TCP connection within an iSCSI Session is protected by a 444 separate IKE Phase 2 SA, with descriptors specific to that TCP 445 connection. Each IKE Phase 2 SA protects only a single TCP 446 connection, and each TCP connection is transported under only one 447 IKE Phase 2 SA. 449 Given this, all the information needed for the iSCSI/IPsec binding is 450 contained within the iSCSI Login messages from the iSCSI Initiator and 451 Target. This includes the binding between an IKE Phase 1 SA and the 452 corresponding iSCSI sessions, as well as the binding between an IPsec 453 Phase 2 SA and the TCP connection and iSCSI connection ID. 455 3.2. Initiating a New iSCSI Session 457 In order to create a new iSCSI Session, an Initiator implementing iSCSI 458 security first establishes IKE Phase 1 and Phase 2 SAs, then exchanges 459 iSCSI control messages over an IPSec-secured TCP connection. The iSCSI 460 Initiator contacts the Target on well-known TCP port . The 461 Initiator and Target IKE implementation MUST successfully complete the 462 IKE phase 1 and Phase 2 negotiations before the initial TCP connection 463 setup messages are exchanged so that these messages can be IPsec 464 protected. From this point forward, subsequent iSCSI connections 465 established within the iSCSI session will be protected by IKE Phase 2 466 SAs derived from the IKE Phase 1 SA. 468 In the Phase 2 Quick Mode exchanges used to protected individual iSCSI 469 connections, the Identity Payload fields MUST be present. These fields 470 carry the source and destination addresses and source and destination 471 ports of the iSCSI Initiator and Targets, thus binding the Phase 2 472 security association to specific TCP and iSCSI connections. The IKE 473 Quick Mode ID payloads MUST carry individual addresses, and MUST NOT 474 use the IP Subnet or IP Address Range formats. 476 Once the IKE Phase 2 negotiations are complete and the TCP connection is 477 established over IPsec, the iSCSI Initiator MUST send the iSCSI Login 478 command over the TCP connection secured by the recently negotiated Quick 479 Mode SA. 481 The Initiator fills in the ISID field, and leaves the TSID field set to 482 zero, to indicate that it is the first message of a new session 483 establishment exchange. The Initiator also fills in a CID value, which 484 is associated with the iSCSI connection corresponding to the the TCP 485 connection secured by the Quick Mode SA. When the iSCSI Target replies 486 with its Login Command, both iSCSI devices will know the TSID, and 487 therefore the iSCSI session identifier . 489 At this point, a binding is established between the iSCSI session 490 identifier and the IKE Phase 1 SAs. A single iSCSI session identifier 491 may have multiple associated IKE Phase 1 SAs, and each IKE Phase 1 SA 492 may have multiple associated iSCSI session identifiers. In addition, a 493 binding is established between the iSCSI connection identifier CID, the 494 TCP connection 5-tuple, and the IPsec Phase 2 SA, as identified by the 495 combination. Each iSCSI connection 496 corresponds to a single TCP connection and IPsec Phase 2 SA. 498 Before adding a new connection to an existing iSCSI Session, a new IKE 499 Quick Mode exchange MUST occur, under the protection of an IKE Phase 1 500 SA. 502 Within IKE, each key refresh requires that a new security association be 503 established. In practice there is a time interval during which an old, 504 about-to-expire SA and newly established SA will both be valid. The 505 IPsec implementation will choose which security association to use based 506 on local policy, and iSCSI concerns play no role in this selection 507 process. 509 3.3. Graceful iSCSI Teardown 511 Mechanisms within iSCSI provide for both graceful and non-graceful 512 teardown of iSCSI Sessions or individual TCP connections within a given 513 session. The iSCSI Logout command is used to effect graceful teardown. 514 This command allows the iSCSI Initiator to request that: 516 [a] the session be closed 518 [b] a specific connection within the session be closed 520 [c] a specific connection be marked for recovery, or 522 [d] a specific connection be closed at the Target's request. 524 When the iSCSI implementation wishes to close a session, it MUST use the 525 appropriate iSCSI commands to accomplish this. After exchanging the 526 appropriate iSCSI control messages for session closure, the iSCSI 527 security implementation SHOULD initiate a half-close of each TCP 528 connection within the iSCSI session. Since a given IKE Phase 1 SA may be 529 bound to multiple iSCSI sessions, the iSCSI implementation will only 530 delete the IKE Phase 1 SAs bound to the iSCSI session if there are no 531 remaining iSCSI sessions bound to those SAs. For those Phase 1 SAs that 532 are deleted, the iSCSI security implementation will also delete the IKE 533 Phase 2 SAs bound to them. 535 When the iSCSI security implementation wishes to close an individual TCP 536 connection while leaving the parent iSCSI session active, it SHOULD 537 half-close the TCP connection. This results in a FIN being sent, putting 538 the TCP connection into the FIN WAIT-1 state, as described in [10]. 539 After the other side responds, the TIME WAIT state is entered. After the 540 expiration of the TIME WAIT timeout, the IKE Phase 2 security 541 association bound to the TCP connection MUST be closed. Closing the TCP 542 connection prior to deleting the IKE Phase 2 SA ensures that all the TCP 543 packets sent on the connection are IPsec-protected. 545 3.4. Non-graceful iSCSI Teardown 547 If the iSCSI security implementation becomes aware that a given TCP 548 connection has unexpectedly failed, it SHOULD delete the associated 549 IKE Phase 2 security association. If the IKE implementation receives a 550 Phase 2 Delete message for a security association bound to a TCP 551 connection, it SHOULD notify the iSCSI security implementation. If the 552 TCP connection whose SA was deleted is one which a Logout Command/Logout 553 Response sequence marked for removal from the iSCSI session, then the 554 IKE Phase 2 Delete message serves as confirmation that the iSCSI peer 555 has executed an iSCSI teardown process for the connection. The iSCSI 556 connection state and any associated filters can now be safely removed. 558 [Issue: If a Logout Command/Logout Response was not received, then what 559 do we do?] 561 If an IKE implementation receives a Phase 1 Delete message for a Phase 1 562 Security Association bound to one or more iSCSI sessions, then it SHOULD 563 notify the iSCSI security implementation. It also SHOULD delete the 564 associated IKE Phase 2 security associations. 566 3.5. Fragmentation Issues 568 Fragmentation can become a concern when prepending IPsec headers to an 569 iSCSI frame. One mechanism which can be used to reduce this problem is 570 to utilize path MTU discovery within the iSCSI transport protocol. For 571 example, if TCP is used as the iSCSI transport, then path MTU discovery 572 [11]-[13], can be used to enable the TCP endpoints to discover the 573 correct MTU, including effects due to IPsec encapsulation. 575 However, Path MTU discovery fails when appropriate ICMP messages are not 576 received by the host. This occurs in IPsec implementations which drop 577 unauthenticated ICMP packets. This can result in blackholing in naive 578 TCP implementations, as described in [14]. Appropriate TCP behavior is 579 described in section 2.1 of [14]: 581 "TCP should notice that the connection is timing out. After several 582 timeouts, TCP should attempt to send smaller packets, perhaps turning 583 off the DF flag for each packet. If this succeeds, it should continue 584 to turn off PMTUD for the connection for some reasonable period of 585 time, after which it should probe again to try to determine if the 586 path has changed." 588 If an ICMP PMTU is received by an IPsec implementation that processes 589 unauthenticated ICMP packets, this value SHOULD be stored in the SA as 590 proposed in [6], and IPsec should also provide notification of this 591 event to TCP so that the new MTU value can be correctly reflected. 593 3.6. Per-packet Security Checks 595 When a packet arrives from a connection which requires security, iSCSI 596 MUST check to ensure that the packet was decrypted and/or authenticated 597 by IPsec. Since IPsec already verifies that the packet arrived in the 598 correct SA, iSCSI can be assured that the packet was indeed sent by a 599 trusted peer. 601 When used with iSCSI, IPsec will negotiate a separate Phase 2 SA for 602 each TCP connection, with IPsec filters specific to the TCP connection. 603 As a result, only traffic for a single TCP connection will flow within 604 each IPsec Phase 2 SA. iSCSI security implementations need not verify 605 that the IP addresses and TCP port values in the packet match the socket 606 information which was used to setup the iSCSI connection. This check 607 will be performed by IPsec, preventing malicious peers from sending 608 iSCSI commands on inappropriate Quick Mode SAs. 610 3.7. Application-layer CRC 612 iSCSI's error detection and recovery assumes that the TCP and IP 613 checksums provide inadequate integrity protection and hence incorporates 614 32 bit CRCs to protect its headers and data. When a receiver CRC check 615 fails (i.e., CRC computed at receiver does not match the received CRC), 616 all data covered by that CRC must be discarded. Since presumably the 617 error was not detected by the TCP checksum, TCP retransmission will not 618 occur and thus cannot assist in recovering from the error. iSCSI 619 contains both data and command retry mechanisms to deal with the 620 resulting situations, including SNACK, the ability to reissue R2T 621 commands, and the retry (X) bit for commands. 623 IPsec per-packet authentication and integrity protection offers strong 624 protection against an attacker attempting to modify packets in transit, 625 as well as unintentional packet modifications caused by router 626 malfunctions. This protection is considerably stronger than both the 627 16-bit TCP checksum [11] and the 32-bit application-layer CRC that has 628 been proposed for use with iSCSI [1]. Since IPsec integrity protection 629 occurs below TCP, if an error is discovered, then the packet will be 630 discarded and TCP retransmission will occur, so that no recovery action 631 need be taken at the iSCSI layer. 633 As a result, if end-to-end IPsec integrity protection is known to be in 634 place, and covers the entire connection between iSCSI endpoints (or the 635 portion thereof that requires this additional integrity connection), 636 portions of iSCSI can be simplified. In this case, the iSCSI CRC and 637 mechanisms to recover from CRC check failures are not necessary. If the 638 iSCSI CRC is negotiated, the recovery logic SHOULD simplified to regard 639 any CRC check failure as fatal (e.g., generate a SCSI CHECK CONDITION on 640 data error, close the corresponding TCP connection on header error) 641 because it will be rare for errors undetected by IPsec integrity 642 protection to be detected by the iSCSI CRC. 644 Note that omitting the iSCSI CRC is not advisable in all situations 645 where IPsec integrity protection is employed. When IPsec, TCP and iSCSI 646 are implemented purely in software, it can be argued that additional 647 failure modes may be detected by the TCP checksum and/or iSCSI CRC, and 648 therefore that these additional checks are worthwhile. For example, 649 verification of the cryptographic message integrity check might be 650 successful, but then after the segment is copied as part of TCP 651 processing, a memory error might cause TCP checksum or iSCSI CRC 652 verification to fail. 654 Given the demand for high speed iSCSI security implementations, 655 implementations utilizing hardware offload are expected to become 656 common. Where IPsec processing as well as TCP checksum and iSCSI CRC 657 verification are offloaded within the NIC, these individual checks no 658 longer provide diversity against single points of failure. Since both 659 the IPsec cryptographic message integrity check, the TCP checksum and 660 the application layer CRC will have been verified prior to transferring 661 data across the bus, subsequent transfer or memory errors will not be 662 detected. 664 As a result, where iSCSI security is supported, and IPsec processing is 665 offloaded to the NIC, the iSCSI CRC is not necessary and the 666 implementation may not request it. There are two exceptions to this: 668 [1] If an implementation is an iSCSI-iSCSI proxy or gateway, it can 669 propagate the iSCSI data CRC from one iSCSI connection to another. 670 In this case, the iSCSI CRC is useful to protect iSCSI data against 671 memory, bus, or software errors within the proxy or gateway, and 672 requesting it is desirable. 674 [2] If IPsec is provided by a device external to the actual iSCSI 675 device, the iSCSI header and data CRCs can be kept across the part 676 of the connection that is not protected by IPsec. For instance, the 677 iSCSI connection could traverse an extra bus, interface card, 678 network, interface card, and bus between the iSCSI device and the 679 device providing IPsec. In this case, the iSCSI CRC is desirable, 680 and the iSCSI implementation behind the IPsec device may request 681 it. 683 Note that if both ends of the connection are on the same segment, then 684 traffic will be effectively protected by the layer 2 CRC, so that 685 negotiation of the iSCSI CRC is not necessary. 687 3.8. NAT traversal 689 iSCSI security utilizes transport mode ESP. As noted in [20], transport 690 mode ESP cannot traverse NAT, even though ESP itself does not include IP 691 header fields within its message integrity check. This is because the 692 16-bit TCP checksum is calculated based on a "pseudo-header" that 693 includes IP header fields, and the checksum is protected by the IPsec 694 message integrity check. As a result, the TCP checksum will be 695 invalidated by a NAT located between the iSCSI Initiator and Target. 697 Since TCP checksum calculation and verification is mandatory in both 698 IPv4 and IPv6, it is not possible to omit checksum verification while 699 remaining standards compliant. In order to enable traversal of NATs 700 existing between iSCSI Initiators and Targets, while remaining in 701 compliance, iSCSI/IPsec implementations MAY implement IPsec/IKE NAT 702 traversal, as described in [20]-[23]. 704 The IPsec/IKE NAT traversal specification [23] enables UDP encapsulation 705 of IPsec to be negotiated if a NAT is detected in the path. By 706 determining the IP address of the NAT, the TCP checksum can be 707 calculated based on a pseudo-header including the NAT-adjusted address 708 and ports. If this is done prior to calculating the IPsec message 709 integrity check, TCP checksum verification will not fail. 711 4. Security considerations 713 IPsec IKE negotiation MUST negotiate an authentication method specified 714 in the IKE RFC 2409 [7]. In addition to IKE authentication, iSCSI 715 implementations utilize their own authentication methods, such as those 716 described in [48]. In this section, we discuss authentication issues. 718 4.1. IKE and iSCSI authentication 720 While iSCSI provides initial authentication, it does not provide per- 721 packet authentication, integrity or replay protection. This implies that 722 the identity verified in the iSCSI logon is not subsequently verified on 723 reception of each packet. 725 With IPsec, when the identity asserted in IKE is authenticated, the 726 resulting derived keys are used to provide per-packet authentication, 727 integrity and replay protection. As a result, the identity verified in 728 the IKE conversation is subsequently verified on reception of each 729 packet. 731 Let us assume that the identity claimed in iSCSI logon is a user 732 identity, while the identity claimed within IKE is a machine identity. 733 Since only the machine identity is verified on a per-packet basis, there 734 is no way for the recipient to verify that only the user authenticated 735 via iSCSI logon is using the IPsec SA. 737 In fact, IPsec implementations that only support machine authentication 738 typically have no way to distinguish between user traffic within the 739 kernel. As a result, where machine authentication is used, once an 740 iSCSI/IPsec SA is opened, another user on a multi-user machine may be 741 able to send traffic down the IPsec SA. 743 To limit the potential vulnerability, iSCSI security implementations 744 MUST negotiate a separate IPsec Phase 2 SA for each iSCSI connection, 745 with descriptors specific to that connection. This will prevent traffic 746 for other iSCSI connections from travel within the IPsec SA negotiated 747 for another iSCSI connection. As a result, if access to the TCP socket 748 used for the iSCSI connection is exclusive to a single user, then access 749 to the corresponding IPsec SA will also be exclusive, even if the IPsec 750 implementation only supports machine authentication. 752 If the IPsec implementation supports user authentication, the user 753 identity asserted within IKE will be verified on a per-packet basis, and 754 stronger assurances can be provided. In this case, the user identity 755 asserted within IKE will be verified on a per-packet basis. In order to 756 provide segregation of traffic between users When user authentication is 757 used, the sender MUST ensure that only traffic from that particular user 758 is sent down the iSCSI SA. Enforcement of this restriction is the 759 responsibility of the operating system. 761 4.2. Certificate authentication 763 When X.509 certificate authentication is chosen within IKE, the iSCSI 764 Target is expected to use an IKE Certificate Request Payload (CRP) to 765 request from the Initiator a certificate issued by a particular 766 certificate authority or may use several CRPs if several certificate 767 authorities are trusted and configured in its IPsec IKE authentication 768 policy. 770 The iSCSI Target SHOULD be able to trust several certificate authorities 771 in order to allow iSCSI Initiators to connect to it using their own 772 certificate credential from their chosen PKI. Client and server side 773 certificate revocation list checking MAY be enabled on a per-CA basis, 774 since differences in revocation list checking exist between different 775 PKI providers. 777 4.3. Machine versus user certificates 779 The certificate credentials provided by the iSCSI Initiator during the 780 IKE negotiation MAY be those of the machine or of the iSCSI user. When 781 machine authentication is used, the machine certificate is typically 782 stored on the iSCSI Initiator and Target during an enrollment process. 783 When user certificates are used, the user certificate can be stored 784 either on the machine or on a smartcard. 786 Since the value of a machine certificate is inversely proportional to 787 the ease with which an attacker can obtain one under false pretenses, it 788 is advisable that the machine certificate enrollment process be strictly 789 controlled. For example, only administrators may have the ability to 790 enroll a machine with a machine certificate. 792 While smartcard certificate storage lessens the probability of 793 compromise of the private key, smartcards are not necessarily desirable 794 in all situations. For example, some organizations deploying machine 795 certificates use them so as to restrict use of non-approved hardware. 796 Since user authentication can be provided within iSCSI logon (keeping in 797 mind the weaknesses described earlier), support for machine 798 authentication in IPsec makes it is possible to authenticate both the 799 machine as well as the user. 801 In circumstances in which this dual assurance is considered valuable, 802 enabling movement of the machine certificate from one machine to 803 another, as would be possible if the machine certificate were stored on 804 a smart card, may be undesirable. 806 Similarly, when user certificate are deployed, it is advisable for the 807 user enrollment process to be strictly controlled. If for example, a 808 user password can be readily used to obtain a certificate (either a 809 temporary or a longer term one), then that certificate has no more 810 security value than the password. To limit the ability of an attacker to 811 obtain a user certificate from a stolen password, the enrollment period 812 can be limited, after which password access will be turned off. Such a 813 policy will prevent an attacker obtaining the password of an unused 814 account from obtaining a user certificate once the enrollment period has 815 expired. 817 4.4. Pre-shared keys 819 Use of pre-shared keys in IKE main mode is vulnerable to man-in-the- 820 middle attacks when used with dynamically addressed Initiators. In main 821 mode it is necessary for SKEYID_e to be used prior to the receipt of the 822 identification payload. Therefore the selection of the pre-shared key 823 may only be based on information contained in the IP header. However, 824 where dynamic IP address assignment is typical, it is often not possible 825 to identify the required pre-shared key based on the IP address. 827 Thus when main mode pre-shared keys are used with iSCSI Targets whose 828 address is dynamically assigned (such as desktop workstations), the same 829 pre-shared key is shared by a group of Initiators and is no longer able 830 to function as an effective shared secret. In this situation, neither 831 the client nor the server identifies itself during IKE phase 1; it is 832 only known that both parties are a member of the group with knowledge of 833 the pre-shared key. This permits anyone with access to the group pre- 834 shared key to act as a man-in-the-middle. 836 This vulnerability does not occur in aggressive mode since the identity 837 payload is sent earlier in the exchange, and therefore the pre-shared 838 key can be selected based on the identity. However, when aggressive mode 839 is used the user identity is exposed and this is often considered 840 undesirable. 842 As a result, where main mode is used with pre-shared keys, unless iSCSI 843 logon performs mutual authentication, the Target is not authenticated. 844 This enables a rogue Target in possession of the group pre-shared key to 845 successfully masquerade as the actual Target and mount a dictionary 846 attack on legacy authentication methods such as CHAP [47]. Such an 847 attack could potentially compromise many passwords at a time. This 848 vulnerability is widely present in existing IPsec implementations. 850 To avoid this problem, iSCSI/IPsec implementations SHOULD NOT use a 851 group pre-shared key for IKE authentication with main mode. If pre- 852 shared keys are required, then aggressive mode SHOULD be used. IKE pre- 853 shared authentication key values SHOULD be protected in a manner similar 854 to the user's account password used in iSCSI logon. 856 5. References 858 [1] Satran, J., et al., "iSCSI", Internet draft (work in progress), 859 draft-ietf-ips-iSCSI-06.txt, April 2001. 861 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 862 Levels", BCP 14, RFC 2119, March 1997. 864 [3] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 865 November 1998. 867 [4] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 868 RFC 2406, November 1998. 870 [5] Piper, D., "The Internet IP Security Domain of Interpretation of 871 ISAKMP", RFC 2407, November 1998. 873 [6] Atkinson, R., Kent, S., "Security Architecture for the Internet 874 Protocol", RFC 2401, November 1998. 876 [7] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 877 2409, November 1998. 879 [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 880 1992. 882 [9] Dobbertin, H., "The Status of MD5 After a Recent Attack", 883 CryptoBytes Vol.2 No.2, Summer 1996. 885 [10] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 886 September 1981. 888 [11] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 889 1990. 891 [12] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", 892 RFC 1435, March 1993. 894 [13] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP 895 version 6", RFC 1981, August 1996. 897 [14] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923, 898 September 2000. 900 [15] Paxon, V., "End-to-end internet packet dynamics", IEEE Transactions 901 on Networking 7,3 (June 1999) pg 277-292. 903 [16] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", 904 ACM Sigcomm, Sept. 2000. 906 [17] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. 908 [18] Krueger, M., et.al., "iSCSI Requirements and Design 909 Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in 910 Progress, July 2001. 912 [19] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for 913 Message Authentication", RFC 2104, February 1997. 915 [20] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-ietf- 916 IPsec-nat-reqts-00.txt, Work in Progress, June 2001. 918 [21] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", draft- 919 ietf-IPsec-udp-encaps-00.txt, June 2001 921 [22] Dixon, W. et. al., "IPsec over NAT Justification for UDP 922 Encapsulation", draft-ietf-IPsec-udp-encaps-justification-00.txt, 923 June 2001 925 [23] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", 926 Internet draft (work in progress), draft-ietf-IPsec-nat-t- 927 ike-00.txt, June 2001. 929 [24] Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP and AH", 930 RFC 2403, November 1998. 932 [25] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and 933 AH", RFC 2404, November 1998. 935 [26] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a 936 parallelizable message authentication code", 937 http://csrc.nist.gov/encryption/modes/proposedmodes/pmac/pmac- 938 spec.pdf 940 [27] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway, P., 941 "UMAC: Fast and provably secure message authentication", Advances 942 in Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 216-233. Full 943 version available from http://www.cs.ucdavis.edu/~rogaway/umac 945 [28] "Descriptions of SHA-256, SHA-384, and SHA-512," 946 http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf. 948 [29] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 949 25, 1999. 951 [30] U.S. DoC/NIST, "Guidelines for implementing and using the nbs data 952 encryption standard", FIPS 74, Apr 1981. 954 [31] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- like 955 cryptosystems", Journal of Cryptology Vol 4, Jan 1991. 957 [32] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With 958 Explicit IV", RFC 2405, November 1998. 960 [33] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms", RFC 961 2451, November 1998. 963 [34] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES 964 Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/ 965 AESAlgs/Rijndael/Rijndael.pdf 967 [35] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", 968 U.S. DoC/NIST, summer 2001. 970 [36] "Symmetric Key Block Cipher Modes of Operation," 971 http://www.nist.gov/modes. 973 [37] "Recommendation for Block Cipher Modes of Operation", National 974 Institute of Standards and Technology (NIST) Special Publication 975 800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington, 976 DC, July 2001. 978 [38] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm and 979 Its Use with IPsec", Internet draft (work in progress), draft-ietf- 980 ipsec-ciph-aes-cbc-01.txt, May 2001. 982 [39] Etienne, J., "The counter-mode and its use with ESP", Internet 983 draft (work in progress), draft-etienne-ipsec-esp-ctr-mode-00.txt, 984 May 2001. 986 [40] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", Comment 987 on mode of operations NIST, Jan 2001. 989 [41] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. 990 Ferguson, "Performance Comparison of the AES Submissions", 991 http://www.counterpane.com/AES-performance.html 993 [42] A. Bosselaers, "Performance of Pentium implementations", 994 http://www.esat.kuleuven.ac.be/~bosselae/ 996 [43] Bellovin, S., "An Issue With DES-CBC When Used Without Strong 997 Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995. 999 [44] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., 1000 Rogaway, P., "UMAC: Message Authentication Code using Universal 1001 Hashing", Internet draft (work in progress), draft-krovetz- 1002 umac-01.txt, October 2000. 1004 [45] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and SHA-512 1005 within ESP, AH and IKE," Work in progress. 1007 [46] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 1008 November 1998. 1010 [47] Simpson, W.,"PPP Challenge Handshake Authentication Protocol 1011 (CHAP)," RFC 1994, August 1996. 1013 [48] Black, D., "iSCSI Security Requirements and SRP-based ESP keys", 1014 Internet draft (work in progress), draft-black-ips-iscsi- 1015 security-00.txt, July 2001. 1017 [49] Steve Kent, IPsec sequence number extension proposal, IETF 50. 1019 [50] American National Standard for Financial Services X9.52-1998, 1020 "Triple Data Encryption Algorithm Modes of Operation", American 1021 Bankers Association, Washington, D.C., July 29, 1998. 1023 [51] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of 1024 Symmetric Encryption: Analysis of the DES Modes of Operation", 1025 1997, http://www-cse.ucsd.edu/users/mihir/ 1027 Appendix A - Software Performance of IPsec Transforms 1029 This Appendix provides data on the performance of IPsec encryption and 1030 authentication transforms in software. Since the performance of IPsec 1031 transforms is heavily implementation dependent, the data presented here 1032 may not be representative of performance in a given situation, and are 1033 presented solely for purposes of comparision. 1035 A.1 Authentication transforms 1037 Table A-1 presents the cycles/byte required by the AES-PMAC, AES-CBC- 1038 MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet 1039 sizes, implemented in software. 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | | | | | | | 1043 | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | 1044 | Size | PMAC | MAC | UMAC | MD5 | SHA1 | 1045 | | | | | | | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | | | | | | | 1069 | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | 1070 | Size | PMAC | MAC | UMAC | MD5 | SHA1 | 1071 | | | | | | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 Table A-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, 1089 AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at 1090 various packet sizes. 1092 Source: Jesse Walker, Intel 1093 (See also http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 1094 for additional data) 1095 Table A-2 presents the cycles/second required by the AES-PMAC, AES-CBC- 1096 MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in 1097 software, assuming a 1500 byte packet. 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 1101 | Transform | octet | @ | @ | @ | 1102 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | | | | | | 1105 | AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B | 1106 | (8 octets) | | | | | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | | | | | | 1109 | HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B | 1110 | (20 octets) | | | | | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | | | | | | 1113 | HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B | 1114 | | | | | | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | | | | | | 1117 | AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B | 1118 | | | | | | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | | | | | | 1121 | AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B | 1122 | (8 octets) | | | | | 1123 | | | | | | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 Table A-2: Software performance of the HMAC-SHA1, HMAC-MD5, AES-CBC-MAC 1127 and AES-PMAC authentication algorithms at 100 Mbps, 1 Gbps, and 10 Gbps 1128 line rates (1500 byte packet). 1130 Source: Jesse Walker, Intel 1132 At speeds of 100 Mbps, AES-UMAC is implementable with only a modest 1133 processor, and the other algorithms are implementable, assuming that a 1134 single high-speed processor can be dedicated to the task. At 1 Gbps, 1135 only AES-UMAC is implementable on a single high-speed processor; 1136 multiple high speed processors (1+ Ghz) will be required for the other 1137 algorithms. At 10 Gbps, only AES-UMAC is implementable even with 1138 multiple high speed processors; the other algorithms will require a 1139 prodigious number of cycles/second. Thus at 10 Gbps, hardware 1140 acceleration will be required for all algorithms with the possible 1141 exception of AES-UMAC. 1143 A.2 Encryption and Authentication transforms 1145 Table A-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 1146 3DES-CBC encryption algorithms (no MAC), implemented in software, for 1147 various packet sizes. 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | | | | | 1151 | Data size | AES-CBC | AES-CTR | 3DES-CBC | 1152 | | | | | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | 64 | 31.22 | 26.02 | 156.09 | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | 128 | 31.22 | 28.62 | 150.89 | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | 192 | 31.22 | 27.75 | 150.89 | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | 256 | 28.62 | 27.32 | 150.89 | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | 320 | 29.14 | 28.1 | 150.89 | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | 384 | 28.62 | 27.75 | 148.29 | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | 448 | 28.99 | 27.5 | 149.4 | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | 512 | 28.62 | 27.32 | 148.29 | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | 576 | 28.33 | 27.75 | 147.72 | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | 640 | 28.62 | 27.06 | 147.77 | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | | | | | 1176 | Data size | AES-CBC | AES-CTR | 3DES-CBC | 1177 | | | | | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | 768 | 28.18 | 27.32 | 147.42 | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | 896 | 28.25 | 27.5 | 147.55 | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | 1024 | 27.97 | 27.32 | 148.29 | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | 1152 | 28.33 | 27.46 | 147.13 | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | 1280 | 28.1 | 27.58 | 146.99 | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | 1408 | 27.91 | 27.43 | 147.34 | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | 1500 | 27.97 | 27.53 | 147.85 | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Table A-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC 1195 encryption algorithms at various packet sizes, implemented in 1196 software. 1198 Source: Jesse Walker, Intel 1199 Table A-4 presents the cycles/second required by the AES-CBC, AES-CTR 1200 and 3DES-CBC encryption algorithms (no MAC), implemented in software, at 1201 100 Mbps, 1 Gbps, and 10 Gbps line rates (assuming a 1500 byte packet). 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 1205 | Transform | octet | @ | @ | @ | 1206 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | | | | | | 1209 | AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B | 1210 | | | | | | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | | | | | | 1213 | AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B | 1214 | | | | | | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | | | | | | 1217 | 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B | 1218 | | | | | | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 Table A-4: Software performance of the AES-CBC, AES-CTR, and 3DES 1222 encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates 1223 (1500 byte packet). 1225 Source: Jesse Walker, Intel 1227 At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a 1228 high-speed processor, while 3DES would require multiple high speed 1229 processors. At speeds of 1 Gbps, multiple high speed processors are 1230 required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, 1231 and 10 Gbps for all algorithms, implementation in software is 1232 infeasible, and hardware acceleration is required. 1234 Table A-5 presents the cycles/byte required for combined 1235 encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + 1236 CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented 1237 in software. 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | | AES | AES | AES | | 1241 | Data size | CBC + | CTR + | CTR + | AES- | 1242 | | CBCMAC | CBCMAC | UMAC | OCB | 1243 | | | | | | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | 64 | 119.67 | 52.03 | 52.03 | 57.23 | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | 128 | 70.24 | 57.23 | 39.02 | 44.23 | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | 192 | 58.97 | 55.5 | 36.42 | 41.63 | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | 256 | 57.23 | 55.93 | 35.12 | 40.32 | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | 320 | 57.23 | 55.15 | 33.3 | 38.5 | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | 384 | 57.23 | 55.5 | 32.95 | 37.29 | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | 448 | 58.72 | 55 | 32.71 | 37.17 | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | 512 | 58.54 | 55.28 | 32.52 | 36.42 | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | | AES | AES | AES | | 1263 | Data size | CBC + | CTR + | CTR + | AES- | 1264 | | CBCMAC | CBCMAC | UMAC | OCB | 1265 | | | | | | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | 576 | 57.81 | 55.5 | 31.8 | 37 | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | 640 | 57.75 | 55.15 | 31.74 | 36.42 | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | 768 | 57.67 | 55.5 | 31.65 | 35.99 | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | 896 | 57.61 | 55.75 | 31.22 | 35.68 | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | 1024 | 57.56 | 55.61 | 31.22 | 35.45 | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | 1152 | 57.52 | 55.21 | 31.22 | 35.55 | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | 1280 | 57.75 | 55.15 | 31.22 | 36.16 | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | 1408 | 57.47 | 55.34 | 30.75 | 35.24 | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | 1500 | 57.72 | 55.5 | 30.86 | 35.3 | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 Table A-5: Cycles/byte of combined encryption/authentication 1287 algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, 1288 and AES-OCB at various packet sizes, implemented in software. 1290 Table A-6 presents the cycles/second required for the AES CBC + CBCMAC, 1291 AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and 1292 authentication algorithms operating at line rates of 100 Mbps, 1 Gbps 1293 and 10 Gbps, assuming 1500 byte packets. 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 1297 | Transform | octet | @ | @ | @ | 1298 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | | | | | | 1301 | AES | | | | | 1302 | CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B | 1303 | | | | | | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | | | | | | 1306 | AES | | | | | 1307 | CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B | 1308 | | | | | | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | | | | | | 1311 | AES | | | | | 1312 | CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B | 1313 | | | | | | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | | | | | | 1316 | | | | | | 1317 | AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B | 1318 | | | | | | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 Table A-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, 1322 AES CTR + UMAC, and AES-OCB encryption and authentication algorithms, 1323 operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, 1324 assuming 1500 octet packets. 1326 Source: Jesse Walker, Intel 1328 At speeds of 100 Mbps, the algorithms are implementable on a high speed 1329 processor. At speeds of 1 Gbps, multiple high speed processors are 1330 required, and none of the algorithms are implementable in software at 10 1331 Gbps line rate. 1333 Acknowledgments 1335 Thanks to Steve Bellovin of AT&T Research for useful discussions of this 1336 problem space. 1338 Authors' Addresses 1340 Bernard Aboba 1341 Microsoft Corporation 1342 One Microsoft Way 1343 Redmond, WA 98052 1345 Phone: +1 425 936 6605 1346 EMail: bernarda@microsoft.com 1348 William Dixon 1349 Microsoft Corporation 1350 One Microsoft Way 1351 Redmond, WA 98052 1353 Phone: +1 425 703 8729 1354 EMail: wdixon@microsoft.com 1356 Joseph J. Tardo 1357 Broadcom 1358 3151 Zanker Road 1359 San Jose, CA 95134 1361 Phone: +1 408 501 8445 1362 Fax: +1 408 501 8460 1363 EMail: jtardo@broadcom.com 1365 Mark Bakke 1366 Cisco Systems, Inc. 1367 6450 Wedgwood Road, Suite 130 1368 Maple Grove, MN 55311 1370 Phone: +1 763 398 1000 1371 Fax: +1 763 398 1001 1372 EMail: mbakke@cisco.com 1374 Steve Senum 1375 Cisco Systems, Inc. 1376 6450 Wedgwood Road, Suite 130 1377 Maple Grove, MN 55311 1379 Phone: 1380 Fax: +1 763 398 1001 1381 EMail: ssenum@cisco.com 1383 Howard Herbert 1384 Intel Corporation 1385 5000 West Chandler Blvd. 1387 M/S CH7-404 1388 Chandler, Arizona 85226 1390 Phone: +1 480 554 3116 1391 EMail: howard.c.herbert@intel.com 1393 Jesse Walker 1394 Intel Corporation 1395 2211 NE 25th Avenue 1396 Hillboro, Oregon 97124 1398 Phone: +1 503 712 1849 1399 Fax: +1 503 264 4843 1400 Email: jesse.walker@intel.com 1402 Julian Satran 1403 IBM, Haifa Research Lab 1404 MATAM - Advanced Technology Center 1405 Haifa 31905, Israel 1407 Phone +972 4 829 6264 1408 EMail: Julian_Satran@vnet.ibm.com 1410 Ofer Biran 1411 IBM, Haifa Research Lab 1412 MATAM - Advanced Technology Center 1413 Haifa 31905, Israel 1415 Phone +972 4 829 6253 1416 Email: biran@il.ibm.com 1418 Charles Kunzinger 1419 IBM Corporation 1420 Research Triangle Park, NC 27709 1422 Phone: +1 919 254 4142 1423 EMail: kunzinge@us.ibm.com 1425 David L. Black 1426 EMC Corporation 1427 42 South Street 1428 Hopkinton, MA 01748 1430 Phone: +1 508 435 1000 x75140 1431 EMail: black_david@emc.com 1432 Intellectual Property Statement 1434 The IETF takes no position regarding the validity or scope of any 1435 intellectual property or other rights that might be claimed to pertain 1436 to the implementation or use of the technology described in this 1437 document or the extent to which any license under such rights might or 1438 might not be available; neither does it represent that it has made any 1439 effort to identify any such rights. Information on the IETF's 1440 procedures with respect to rights in standards-track and standards- 1441 related documentation can be found in BCP-11. Copies of claims of 1442 rights made available for publication and any assurances of licenses to 1443 be made available, or the result of an attempt made to obtain a general 1444 license or permission for the use of such proprietary rights by 1445 implementors or users of this specification can be obtained from the 1446 IETF Secretariat. 1448 The IETF invites any interested party to bring to its attention any 1449 copyrights, patents or patent applications, or other proprietary rights 1450 which may cover technology that may be required to practice this 1451 standard. Please address the information to the IETF Executive 1452 Director. 1454 Full Copyright Statement 1456 Copyright (C) The Internet Society (2001). All Rights Reserved. 1458 This document and translations of it may be copied and furnished to 1459 others, and derivative works that comment on or otherwise explain it or 1460 assist in its implementation may be prepared, copied, published and 1461 distributed, in whole or in part, without restriction of any kind, 1462 provided that the above copyright notice and this paragraph are included 1463 on all such copies and derivative works. However, this document itself 1464 may not be modified in any way, such as by removing the copyright notice 1465 or references to the Internet Society or other Internet organizations, 1466 except as needed for the purpose of developing Internet standards in 1467 which case the procedures for copyrights defined in the Internet 1468 Standards process must be followed, or as required to translate it into 1469 languages other than English. The limited permissions granted above are 1470 perpetual and will not be revoked by the Internet Society or its 1471 successors or assigns. This document and the information contained 1472 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1473 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1474 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1475 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1477 Expiration Date 1479 This memo is filed as , and 1480 expires February 19, 2002.