idnits 2.17.1 draft-ietf-ips-security-09.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 63 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 64 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.) ** 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 271 has weird spacing: '...ns, and retur...' == Line 528 has weird spacing: '...cess to local...' == Line 529 has weird spacing: '...private key f...' == Line 788 has weird spacing: '... not be maint...' == Line 896 has weird spacing: '... not be maint...' == (4 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 1832 -- Looks like a reference, but probably isn't: '2' on line 1834 -- Looks like a reference, but probably isn't: '3' on line 1836 -- Looks like a reference, but probably isn't: '4' on line 1452 -- Looks like a reference, but probably isn't: '5' on line 1460 -- Looks like a reference, but probably isn't: '6' on line 1482 -- Looks like a reference, but probably isn't: '7' on line 321 -- Looks like a reference, but probably isn't: '8' on line 324 == Missing Reference: 'IPsecNATReq' is mentioned on line 1586, but not defined == Missing Reference: 'RFC2320' is mentioned on line 1509, but not defined == Missing Reference: 'RFC2131' is mentioned on line 1517, but not defined == Missing Reference: 'DHCPv6' is mentioned on line 1517, but not defined == Unused Reference: '3DESANSI' is defined on line 2177, but no explicit reference was found in the text == Unused Reference: 'IPsecNatReq' is defined on line 2237, but no explicit reference was found in the text == Unused Reference: 'AESOCB' is defined on line 2303, but no explicit reference was found in the text == Unused Reference: 'CTR-MODE' is defined on line 2307, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ips-fcovertcpip-06 == Outdated reference: A later version (-09) exists of draft-ietf-ips-fcip-slp-00 ** 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 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'SRPNDSS' ** 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 2923 -- Possible downref: Non-RFC (?) normative reference: ref. 'NISTAES' -- Possible downref: Non-RFC (?) normative reference: ref. '3DESANSI' ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ciph-aes-cbc-01 -- Possible downref: Normative reference to a draft: ref. 'AESCTR' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-dhcp is -12, but you're referring to -13. -- 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) == Outdated reference: A later version (-11) exists of draft-ietf-ips-iscsi-mib-03 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-nat-reqts-00 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-udp-encaps-01 == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-01 == Outdated reference: A later version (-08) exists of draft-ietf-ipsec-nat-t-ike-01 == Outdated reference: A later version (-07) exists of draft-krovetz-umac-01 Summary: 15 errors (**), 0 flaws (~~), 27 warnings (==), 17 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 12 February 2002 Joseph Tardo, Uri Elzur 7 Broadcom 8 Jesse Walker 9 Intel 10 J. Satran, Ofer Biran 11 Charles Kunzinger 12 IBM 13 Venkat Rangan 14 Rhapsody Networks Inc. 15 Franco Travostino 16 Nortel Networks 18 Securing Block Storage Protocols over IP 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with all 23 provisions of Section 10 of RFC 2026. 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other groups 27 may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference material 32 or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2002). All Rights Reserved. 44 Abstract 46 This document discusses how block storage protocols running over IP, 47 including iSCSI, iFCP and FCIP, can utilize IPsec for security. 49 Table of Contents 50 1. Introduction .......................................... 4 51 1.1 iSCSI overview .................................. 4 52 1.2 iFCP overview ................................... 5 53 1.3 FCIP overview ................................... 5 54 1.4 IPsec overview .................................. 5 55 1.5 Terminology ..................................... 6 56 1.6 Requirements language ........................... 7 57 2. Block storage protocol security ....................... 8 58 2.1 Security requirements .......................... 8 59 2.2 Resource constraints ............................ 10 60 2.3 Security protocol ............................... 12 61 2.4 SLPv2 security .................................. 14 62 2.5 iSNS security .................................... 19 63 3. iSCSI security inter-operability guidelines ........... 23 64 3.1 iSCSI security issues ........................... 23 65 3.2 iSCSI and IPsec interaction ..................... 23 66 3.3 Initiating a new iSCSI session .................. 24 67 3.4 Graceful iSCSI teardown ......................... 26 68 3.5 Non-graceful iSCSI teardown ..................... 26 69 3.6 Application layer CRC ........................... 27 70 4. iFCP and FCIP security issues ......................... 29 71 4.1 iFCP and FCIP Authentication Requirements ....... 29 72 4.2 iFCP Interaction with IPsec and IKE ............. 29 73 4.3 FCIP Interaction with IPsec and IKE ............. 31 75 5. Security considerations ............................... 31 76 5.1 Transport mode versus tunnel mode ............... 31 77 5.2 NAT traversal ................................... 34 78 5.3 IKE issues ...................................... 35 79 5.4 Rekeying issues ................................. 35 80 5.5 Transform issues ................................ 37 81 5.6 Fragmentation issues ............................ 39 82 5.7 Security checks ................................. 40 83 5.8 Authentication issues ........................... 41 84 5.9 Use of AES in counter mode ...................... 45 85 5.10 Use of SRP in iSCSI Authentication .............. 45 86 6. Normative references .................................. 45 87 7. Informative references ................................ 48 88 Appendix A - Well Known Groups for Use with SRP ............. 51 89 Appendix B - Software Performance of IPsec Transforms ....... 53 90 B.1 Authentication transforms ....................... 53 91 B.2 Encryption and Authentication transforms ........ 56 92 Acknowledgments .............................................. 61 93 Authors' Addresses ........................................... 62 94 Intellectual Property Statement .............................. 63 95 Full Copyright Statement ..................................... 64 96 1. Introduction 98 This draft proposes use of the IPsec protocol suite for protecting block 99 storage protocols over IP networks, including iSCSI, iFCP and FCIP, and 100 discusses how these protocols should be used with IPsec. 102 1.1. iSCSI overview 104 iSCSI, described in [iSCSI], is a connection-oriented command/response 105 protocol that runs over TCP, and is used to access disk, tape and other 106 devices. iSCSI is a client-server protocol in which clients 107 (Initiators) open connections to servers (Targets) and perform an iSCSI 108 login. 110 This draft uses the SCSI terms Initiator and Target for clarity and to 111 avoid the common assumption that clients have considerably less 112 computational and memory resources than servers; the reverse is often 113 the case for SCSI, as Targets are commonly dedicated devices of some 114 form. 116 The iSCSI protocol has a text based negotiation mechanism as part of its 117 initial (Login) procedure. The mechanism is extensible in what can be 118 negotiated (new text keys and values can be defined) and also in the 119 number of negotiation rounds (e.g., to accommodate functionality such as 120 challenge-response authentication). While the iSCSI login may include 121 mutual authentication of the iSCSI endpoints and negotiation of session 122 parameters, iSCSI does not define its own per-packet authentication, 123 integrity, confidentiality or replay protection mechanisms. 125 After a successful login, the iSCSI Initiator may issue SCSI commands 126 for execution by the iSCSI Target, which returns a status response for 127 each command, over the same connection. A single connection is used for 128 both command/status messages as well as transfer of data and/or optional 129 command parameters. An iSCSI session may have multiple connections, but 130 a separate login is performed on each. The iSCSI session terminates 131 when its last connection is closed. 133 iSCSI Initiators and Targets are layer 5 entities that are independent 134 of TCP ports and IP addresses. Initiators and Targets have names whose 135 syntax is defined in [iSCSIName]. iSCSI sessions between a given 136 Initiator and Target are run over one or more TCP connections between 137 those entities. That is, the Login process establishes an association 138 between an iSCSI Session and the TCP connection(s) over which iSCSI PDUs 139 will be carried. 141 1.2. iFCP overview 143 iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which 144 provides Fibre Channel fabric services to Fibre Channel devices over a 145 TCP/IP network. iFCP's primary objective is to allow interconnection 146 and networking of existing Fibre Channel devices at wire speeds over an 147 IP network. The protocol achieves this transparency through a process 148 that allows normal Fibre Channel frame traffic to pass through the 149 gateway directly, with provisions where necessary for intercepting and 150 emulating the fabric services required by a Fibre Channel device. Each 151 IPsec SA established by IKE protects a single TCP connection, which is 152 used to support storage traffic between a unique pair of Fibre Channel 153 N_PORTs. 155 iFCP does not have a native, in-band security mechanism. Rather, it 156 relies upon the IPsec protocol suite to provide data confidentiality and 157 authentication services, and IKE as the key management protocol. iFCP 158 uses TCP to provide congestion control, error detection and error 159 recovery. 161 1.3. FCIP overview 163 FCIP, defined in [FCIP], is a pure FC encapsulation protocol that 164 transports FC frames. Current specification work intends this for 165 interconnection of Fibre Channel switches over TCP/IP networks, but the 166 protocol is not inherently limited to connecting FC switches. FCIP 167 differs from iFCP in that no interception or emulation of fabric 168 services is involved, and TCP connections are not bound or restricted 169 to specific FC N_Port pairs. 171 FCIP does not have a native, in-band security mechanism. Rather, it 172 relies upon the IPsec protocol suite to provide data confidentiality and 173 authentication services, and IKE as the key management protocol. FCIP 174 uses TCP to provide congestion control, error detection and error 175 recovery. 177 1.4. IPsec overview 179 IPsec is a protocol suite which is used to secure communication at the 180 network layer between two peers. The IPsec protocol suite is specified 181 within the IP Security Architecture [RFC2401], IKE [RFC2409], IPsec 182 Authentication Header (AH) [RFC2402] and IPsec Encapsulating Security 183 Payload (ESP) [RFC2406] documents. IKE is the key management protocol 184 while AH and ESP are used to protect IP traffic. 186 An IPsec SA is a one-way security association, uniquely identified by 187 the 3-tuple: SPI, protocol (ESP) and destination IP. The parameters for 188 an IPsec security association are typically established by a key 189 management protocol. These include the encapsulation mode, encapsulation 190 type, session keys and SPI values. 192 IKE is a two phase negotiation protocol based on the modular exchange of 193 messages defined by ISAKMP [RFC2407],[RFC2408]. IKE has two phases, and 194 accomplishes the following functions: 196 [1] Protected cipher suite and options negotiation - using keyed HMACs 197 and encryption and anti-replay mechanisms 199 [2] Master key generation - via MODP Diffie-Hellman calculations 201 [3] Authentication of end-points 203 [4] IPsec SA management (selector negotiation, options negotiation, 204 create, delete, and rekeying) 206 Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is 207 handled in IKE Phase 2. 209 An IKE phase 2 negotiation is performed to establish both an inbound and 210 an outbound IPsec SAs. The traffic to be protected by an IPsec SA is 211 determined by a selector which has been proposed by the IKE Initiator 212 and accepted by the IKE responder. In IPsec transport mode, the IPsec 213 SA selector can be a "filter" or traffic classifier, defined as the 214 5-tuple: . The successful 216 establishment of a IKE Phase-2 SA results in the creation of two uni- 217 directional IPsec SAs fully qualified by the tuple . 220 The session keys for each IPsec SA are derived from a master key, 221 typically a MODP Diffie-Hellman computation. Rekeying of an existing 222 IPsec SA pair is accomplished by creating two new IPsec SAs, making them 223 active, and then optionally deleting the older IPsec SA pair. Typically 224 the new outbound SA is used immediately, and the old inbound SA is left 225 active to receive packets for some locally defined time, perhaps 30 226 seconds or 1 minute. 228 1.5. Terminology 230 Fibre Channel 231 Fibre Channel (FC) is a gigabit speed networking technology 232 primarily used to implement Storage Area Networks (SANs). FC 233 is standardized under American National Standard for 234 Information Systems of the National Committee for Information 235 Technology Standards (ANSI-NCITS) in its T11 technical 236 committee. 238 FCIP Fibre Channel over IP (FCIP) is a protocol for interconnecting 239 islands of Fibre Channel SANs over IP Networks so as to form a 240 unified SAN in a single Fibre Channel fabric. The principal 241 FCIP interface point to the IP Network is the FCIP Entity. The 242 FCIP Link represents one or more TCP connections that exist 243 between a pair of FCIP Entities. 245 iFCP iFCP is a gateway-to-gateway protocol, which provides Fibre 246 Channel fabric services to Fibre Channel devices over a TCP/IP 247 network. 249 IP block storage protocol 250 Where used within this document, the term "IP block storage 251 protocol" applies to all block storage protocols running over 252 IP, including iSCSI, iFCP and FCIP. 254 iSCSI iSCSI is a client-server protocol in which clients 255 (Initiators) open connections to servers (Targets). 257 iSNS The Internet Storage Name Server (iSNS) protocol provides for 258 discovery and management of iSCSI and Fibre Channel (FCP) 259 storage devices. iSNS applications store iSCSI and FC device 260 attributes and monitor their availability and reachability, 261 providing a consolidated information repository for an 262 integrated IP storage network. iFCP requires iSNS for 263 discovery and management, while iSCSI may use iSNS for 264 discovery, and FCIP does not use iSNS. 266 Initiator The iSCSI Initiator connects to the Target on well-known TCP 267 port 3260. The iSCSI Initiator then issues SCSI commands for 268 execution by the iSCSI Target. 270 Target The iSCSI Target listens on a well-known TCP port for incoming 271 connections, and returns a status response for each command 272 issued by the iSCSI Initiator, over the same connection. 274 1.6. Requirements language 276 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 277 "RECOMMENDED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT", are 278 to be interpreted as described in [RFC2119]. 280 Note that requirements specified in this document apply only to use of 281 IPsec and IKE with IP block storage protocols. Thus, these requirements 282 do not apply to IPsec implementations in general. Implementation 283 requirements language should therefore be assumed to relate to the 284 availability of features for use with IP block storage security only. 286 Although the security requirements in this document are already 287 incorporated into the iSCSI [iSCSI], iFCP [iFCP] and FCIP [FCIP] 288 standards track documents, they are reproduced here for convenience. In 289 the event of a discrepancy, the individual protocol standards track 290 documents take precedence. 292 2. Block storage protocol security 294 2.1. Security requirements 296 IP Block storage protocols such as iSCSI, iFCP and FCIP are used to 297 transmit SCSI commands over IP networks. Therefore, both the control 298 and data packets of these IP block storage protocols are vulnerable to 299 attack. Examples of attacks include: 301 [1] An adversary may attempt to acquire confidential data and 302 identities by snooping data packets. 304 [2] An adversary may attempt to modify packets containing data and 305 control messages. 307 [3] An adversary may attempt to inject packets into an IP block storage 308 connection. 310 [4] An adversary may attempt to hijack TCP connection(s) corresponding 311 to an IP block storage session. 313 [5] An adversary may launch denial of service attacks against IP block 314 storage devices such as by sending a TCP reset. 316 [6] An adversary may attempt to disrupt security negotiation process, 317 in order to weaken the authentication, or gain access to user 318 passwords. This includes disruption of application-layer 319 authentication negotiations such as iSCSI Login. 321 [7] An adversary may attempt to impersonate a legitimate IP block 322 storage entity. 324 [8] An adversary may launch a variety of attacks (packet modification 325 or injection, denial of service) against the discovery (SLPv2, 326 [RFC2608]) or discovery and management (iSNS, [iSNS]) process. 327 iSCSI can use SLPv2 or iSNS. FCIP only uses SLPv2, and iFCP only 328 uses iSNS. 330 Since iFCP and FCIP devices are the last line of defense for a whole 331 Fibre Channel island, the above attacks, if successful, could compromise 332 the security of all the Fibre Channel hosts behind the devices. 334 To address the above threats, IP block storage security protocols MUST 335 provide confidentiality, data origin authentication, integrity, and 336 replay protection on a per-datagram basis. Confidentiality services are 337 important since IP block storage traffic may traverse insecure public 338 networks. The IP block storage security protocols MUST support perfect 339 forward secrecy in the rekeying process. 341 Bi-directional authentication of the communication endpoints MUST be 342 provided. There is no requirement that the identities used in 343 authentication be kept confidential (e.g., from a passive eavesdropper). 345 Given current networking technology, IP block storage security solutions 346 must be implementable at 1 Gbps in terms of CPU overhead and/or 347 availability of suitable hardware implementations and should be 348 implementable at 10 Gbps in the near future. 10 Gbps implementations are 349 desirable but are not an absolute requirement as implementation 350 feasibility at these speeds is not yet demonstrated. 352 These performance levels apply to aggregate throughput, and include all 353 TCP connections used between IP block storage endpoints. IP block 354 storage communications typically involve multiple TCP connections. 355 Since each IPsec security association only protects a single TCP 356 connection, it does not necessarily need to support the entire aggregate 357 throughput. Through use of multiple processing engines that 358 independently support individual security associations, implementations 359 may be able to scale to 10 Gbps throughput in the aggregate. 361 Enterprise data center networks are considered mission-critical 362 facilities that must be isolated and protected from all possible 363 security threats. Such networks are usually protected by security 364 gateways, which at a minimum provide a shield against denial of service 365 attacks. The IP block storage security architecture should be able to 366 leverage the protective services of the existing security 367 infrastructure, including firewall protection, NAT and NAPT services, 368 and VPN services available on existing security gateways. 370 When iFCP or FCIP devices are deployed within enterprise networks, IP 371 addresses will be typically be statically assigned in the same manner as 372 most routers and switches. Consequently, support for dynamic IP 373 address assignment, as described in [DHCPIPsec], will typically not be 374 required, although it cannot be ruled out. Such facilities will also be 375 relevant to iSCSI hosts whose addresses are dynamically assigned. As a 376 result, the IP block storage security protocols MUST NOT introduce 377 additional security vulnerabilities where dynamic address assignment is 378 supported. 380 While IP block storage security is mandatory to implement, it is not 381 mandatory to use. The security services used depend on the 382 configuration and security policies put in place. For example, 383 configuration will influence the authentication algorithm negotiated 384 within iSCSI Login, as well as the security services (encryption, 385 authentication, integrity, replay protection) and transforms negotiated 386 when IPsec is used to protect IP block storage protocols such as iSCSI, 387 iFCP and FCIP. 389 It must be possible for compliant IP block storage security 390 implementations to administratively disable any and all security 391 mechanisms. FCIP implementations may allow enabling and disabling 392 security mechanisms at the granularity of an FCIP Link. For iFCP, the 393 granularity corresponds to a TCP connection (which corresponds to an 394 session). For iSCSI, the granularity of control is 395 typically that of an iSCSI session, although it is possible to exert 396 control down to the granularity of the destination IP address and TCP 397 port. 399 IP block storage protocols can be expected to carry sensitive data and 400 provide access to systems and data that require protection against 401 security threats. SCSI and Fibre Channel currently contain little in 402 the way of security mechanisms, and rely on physical security, 403 administrative security, and correct configuration of the communication 404 medium and systems/devices attached to it for their security properties. 406 For most IP networks, it is inappropriate to assume physical security, 407 administrative security, and correct configuration of the network and 408 all attached nodes (a physically isolated network in a test lab may be 409 an exception). Therefore, authentication SHOULD be used by IP block 410 storage protocols (e.g., iSCSI SHOULD use one of its inband 411 authentication mechanisms or the authentication provided by IKE) in 412 order to provide a minimal assurance that connections have initially 413 been opened with the intended counterpart. 415 iSNS, described in [iSNS], is required in all iFCP deployments. iSCSI 416 may use iSNS for discovery, and FCIP does not use iSNS. iSNS 417 applications store iSCSI and FC device attributes and monitor their 418 availability and reachability, providing a consolidated information 419 repository for an integrated IP storage network. The iSNS specification 420 defines mechanisms to secure communication between an iSNS server and 421 its clients. 423 2.2. Resource constraints 425 iFCP and FCIP devices will typically be embedded systems deployed on 426 racks in air-conditioned data center facilities. Such embedded systems 427 may include hardware chipsets to provide data encryption, 428 authentication, and integrity processing. Therefore, memory and CPU 429 resources are generally not a constraining factor. 431 iSCSI will be implemented on a variety of systems ranging from large 432 servers running general purpose operating systems to embedded host bus 433 adapters (HBAs). Host Bus Adapter is a generic term for a SCSI interface 434 to other device(s); it's roughly analogous to the term Network Interface 435 Card (NIC) for a TCP/IP network interface, except that HBAs generally 436 have on-board SCSI implementations, whereas most NICs do not implement 437 TCP, UDP, or IP. In general, a host bus adapter is the most constrained 438 iSCSI implementation environment, although an HBA may draw upon the 439 resources of the system to which it is attached in some cases (e.g., 440 authentication computations required for connection setup). More 441 resources should be available to iSCSI implementations for embedded and 442 general purpose operating systems. The following guidelines indicate 443 the approximate level of resources that authentication, keying, and 444 rekeying functionality can reasonably expect to draw upon: 446 - Low power processors with small word size are generally not used, 447 as power is usually not a constraining factor, with the possible 448 exception of HBAs, which can draw upon the computational resources 449 of the system into which they are inserted). Computational 450 horsepower should be available to perform a reasonable amount of 451 exponentiation as part of authentication and key derivation for 452 connection setup. The same is true of rekeying, although the 453 ability to avoid exponentiation for rekeying may be desirable (but 454 is not an absolute requirement). 456 - RAM and/or flash resources tend to be constrained in embedded 457 implementations. 8-10 MB of code and data for authentication, 458 keying, and rekeying is clearly excessive, 800-1000 KB is clearly 459 larger than desirable, but tolerable if there is no other 460 alternative and 80-100 KB should be acceptable. These sizes are 461 intended as rough order of magnitude guidance, and should not be 462 taken as hard Targets or limits (e.g., smaller code sizes are 463 always better). Software implementations for general purpose 464 operating systems may have more leeway. 466 The primary resource concern for implementation of authentication and 467 keying mechanisms is code size, as iSCSI assumes that the computational 468 horsepower to do exponentiations will be available. 470 There is no dominant iSCSI usage scenario - the scenarios range from a 471 single connection constrained only by media bandwidth to hundreds of 472 Initiator connections to a single Target or communication endpoint. 473 SCSI sessions and hence the connections they use tend to be relatively 474 long lived; for disk storage, a host typically opens a SCSI connection 475 on boot and closes it on shutdown. Tape session length tends to be 476 measured in hours or fractions thereof (i.e., rapid fire sharing of the 477 same tape device among different Initiators is unusual), although tape 478 robot control sessions can be short when the robot is shared among tape 479 drives. On the other hand, tape will not see a large number of 480 Initiator connections to a single Target or communication endpoint, as 481 each tape drive is dedicated to a single use at a single time, and a 482 dozen tape drives is a large tape device. 484 2.3. Security protocol 486 All IP block storage security compliant implementations MUST support 487 IPsec ESP [RFC2406] to provide security for both control packets and 488 data packets. Conformant IP block storage protocol implementations MUST 489 support ESP in tunnel mode and MUST conform to [RFC2401] requirements 490 for support of ESP in transport mode. It is up to the implementor of an 491 IP block storage protocol to determine whether their IPsec 492 implementation conforms to the [RFC2401] definition of a host or an 493 IPsec security gateway. Section 4.1 of [RFC2401] states: 495 a) A host MUST support both transport and tunnel mode. 496 b) A security gateway is required to support only tunnel 497 mode. If it supports transport mode, that should be used 498 only when the security gateway is acting as a host, e.g., 499 for network management. 501 All IP block storage security compliant implementations MUST support the 502 replay protection mechanisms of IPsec. 504 To provide confidentiality with ESP, ESP with 3DES in CBC mode MUST be 505 supported, and AES in Counter mode, as described in [AESCTR], SHOULD be 506 supported. To provide data origin authentication and integrity with 507 ESP, HMAC-SHA1 MUST be supported, and AES in CBC MAC mode with XCBC 508 extensions [AESCBC] SHOULD be supported. DES in CBC mode SHOULD NOT be 509 used due to its inherent weakness. ESP with NULL encryption MUST be 510 supported for authentication. 512 Conformant IP block storage security implementations MUST support IKE 513 [RFC2409] for peer authentication, negotiation of security associations, 514 and key management, using the IPsec DOI [RFC2407]. Manual keying MUST 515 NOT be used since it does not provide the necessary rekeying support. 516 Conformant IP block storage security implementations MUST support peer 517 authentication using a pre-shared key, and MAY support certificate-based 518 peer authentication using digital signatures. Peer authentication using 519 the public key encryption methods outlined in IKE's sections 5.2 and 5.3 520 [RFC2409] SHOULD NOT be used. 522 Conformant IP block storage security implementations MUST support both 523 IKE Main Mode and Aggressive Mode. When pre-shared keys are used for 524 authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode 525 SHOULD NOT be used. When digital signatures are used for 526 authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. 528 In all cases, access to locally stored secret information (pre-shared 529 key, or private key for digital signing) must be suitably restricted, 530 since compromise of the secret information nullifies the security 531 properties of the IKE/IPsec protocols. 533 When digital signatures are used to achieve authentication, an IKE 534 negotiator SHOULD use IKE Certificate Request Payload(s) to specify the 535 certificate authority (or authorities) that are trusted in accordance 536 with its local policy. IKE negotiators SHOULD check the pertinent 537 Certificate Revocation List (CRL) before accepting a PKI certificate for 538 use in IKE's authentication procedures. 540 The Phase 2 Quick Mode exchanges used to negotiate protection for the 541 TCP connections used by IP block storage protocols MUST explicitly carry 542 the Identity Payload fields (IDci and IDcr). The DOI [RFC2407] provides 543 for several types of identification data. Conformant IP block storage 544 security implementations MUST support the ID_IPV4_ADDR, ID_IPV6_ADDR (if 545 the protocol stack supports IPv6) and ID_FQDN Identity Payloads. This 546 allows the Phase 2 security association to correspond to specific TCP 547 and IP block storage connections. iSCSI security implementations MAY 548 support the ID_USER_FQDN Identity Payload; FCIP, iFCP security 549 implementations SHOULD NOT use the ID_USER_FQDN Identity Payload. The IP 550 Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD 551 NOT be used. The ID_KEY_ID Identity Payload MUST NOT be used. 553 Since IPsec acceleration hardware may only be able to handle a limited 554 number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent 555 for idle SAs, as a means of keeping the number of active Phase 2 SAs to 556 a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be 557 interpreted as a reason for tearing down an IP block storage connection. 558 Rather, it is preferable to leave the connection up, and if additional 559 traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. 560 This avoids the potential for continually bringing connections up and 561 down. 563 To support authentication between the iSCSI Initiator and Target, the 564 Secure Remote Password (SRP) protocol described in [RFC2945] MUST be 565 implemented within the iSCSI text-based multi-round negotiation 566 mechanism. A number of additional authentication protocols have also 567 been specified in the current iSCSI draft. Negotiation between 568 Initiator and Target is used to determine which authentication algorithm 569 to use (or whether to use one at all); the connection closes if either 570 side requires authentication and no mutually acceptable algorithm can be 571 agreed upon. 573 One of the goals of this specification is to reduce the need for 574 security policy configuration to a minimum, so as to enable a high level 575 of interoperability. 577 In terms of security policy configuration, the minimum piece of 578 configuration required is whether an IP block storage endpoint requires 579 IPsec or cleartext. This cannot be determined from the IKE conversation 580 alone without risking a long timeout, which is highly undesirable for a 581 disk access protocol. 583 The information can be configured manually or automatically via an IPsec 584 security policy distribution mechanism. Alternatively, it can be 585 supplied via iSNS or SLPv2. If an IP block storage endpoint can obtain 586 its IPsec security policy by other means (manually, or automatically via 587 an IPsec security policy distribution mechanism) then it need not 588 request this information via iSNS or SLPv2. However, if the required 589 security policy configuration is not available via other mechanisms, 590 iSNS or SLPv2 can be used to obtain it. 592 2.4. SLPv2 Security 594 Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer 595 entities and management servers. SLPv2 may also be used to provide 596 information on peer security configuration. When SLPv2 is deployed, the 597 SA advertisements as well as UA requests and/or responses are subject to 598 the following security threats: 600 [1] An attacker could insert or alter SA advertisements or a response 601 to a UA request in order to masquerade as the real peer or launch a 602 denial of service attack. 604 [2] An attacker could gain knowledge about an SA or a UA through 605 snooping, and launch an attack against the peer. Given the 606 potential value of iSCSI targets and FCIP entities, leaking of such 607 information not only increases the possibility of an attack over 608 the network; there is also the risk of physical theft. 610 [3] An attacker could spoof a DAAdvert. This could cause UAs and SAs to 611 use a rogue DAs. 613 To address these threats, the following capabilities are required: 615 [a] Service information, as included in SrvRply, AttrRply, SrvReg and 616 SrvDereg messages, needs to be kept confidential. 618 [b] The UA has to be able to distinguish between legitimate and 619 illegitimate service information from SrvRply and AttrRply 620 messages. In the SLPv2 security model SAs are trusted to sign 621 data. 623 [c] The DA has to be able to distinguish between legitimate and 624 illegitimate SrvReg and SrvDereg messages. 626 [d] The UA has to be able to distinguish between legitimate and 627 illegitimate DA Advertisements. This allows the UA to avoid rogue 628 DAs which will return incorrect data or no data at all. In the 629 SLPv2 security model, UAs trust DAs to store, answer queries on and 630 forward data on services, but not necessarily to originate it. 632 [e] SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2 is 633 used. In this case, SAs register with only one DA and trust that 634 this DA will forward the registration to others. 636 By itself, SLPv2 security, defined in [RFC2608], does not satisfy these 637 security requirements. SLPv2 only provides end-to-end authentication, 638 but does not support confidentiality. In SLPv2 authentication there is 639 no way to authenticate 'zero result responses'. This enables an 640 attacker to mount a denial of service attack by sending UAs a 'zero 641 results' SrvRply or AttrRply as if from a DA with whose source address 642 corresponds to a legitimate DAAdvert. 644 In all cases, there is a potential for denial of service attack against 645 protocol service providers, but such an attack is possible even in the 646 absence of SLPv2 based discovery mechanisms. 648 2.4.1. SLPv2 security protocol 650 SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, 651 AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, SAAdvert. SLPv2 652 requires that UAs and SAs support SrvRqst, SrvRply, and DAAdvert. SAs 653 must additionally support SrvReg, SrvAck, and SAAdvert. 655 Where no DA exists, the SrvRqst is multicast, but the SrvRply is sent 656 via unicast UDP. DAAdverts are also multicast. However, all other SLPv2 657 messages are sent via UDP unicast. 659 In order to provide the required security functionality, iSCSI and FCIP 660 security implementations SHOULD protect SLPv2 messages sent via unicast 661 using IPsec ESP with a non-null transform. SLPv2 authentication blocks 662 (carrying digital signatures), described in [RFC2608] MAY also be used 663 to authenticate unicast and multicast messages. 665 The usage of SLPv2 by iSCSI is described in [iSCSISLP]. iSCSI Initiators 666 and Targets may enable IKE mechanisms to establish identity. In 667 addition, a subsequent user-level iSCSI session login can protect the 668 Initiator-Target nexus. This will protect them from any compromise of 669 security in the SLPv2 discovery process. 671 The usage of SLPv2 by FCIP is described in [FCIPSLP]. FCIP Entities 672 assume that once the IKE identity of a peer is established, the FCIP 673 Entity Name carried in FCIP Short Frame is also implicitly accepted as 674 the authenticated peer. Any such association between the IKE identity 675 and the FCIP Entity Name is administratively established. 677 For use in securing SLPv2, when digital signatures are used to achieve 678 authentication in IKE, an IKE negotiator SHOULD use IKE Certificate 679 Request Payload(s) to specify the certificate authority (or authorities) 680 that are trusted in accordance with its local policy. IKE negotiators 681 SHOULD check the pertinent Certificate Revocation List (CRL) before 682 accepting a PKI certificate for use in IKE's authentication procedures. 683 If key management of SLPv2 DAs needs to be coordinated with the SAs and 684 the UAs as well as the protocol service implementations, one may use 685 certificate based key management, with a shared root CA. 687 One of the reasons for utilizing IPsec for SLPv2 security is that is 688 more likely that certificates will be deployed for IPsec than for SLPv2. 689 This both simplifies SLPv2 security and makes it more likely that it 690 will be implemented interoperably and more importantly, that it will be 691 employed. As a result, it is desirable that little additional effort be 692 required to enable IPsec protection of SLPv2. 694 However, just because a certificate is trusted for use with IPsec does 695 not necessarily imply that the host is authorized to perform SLPv2 696 operations. When using IPsec to secure SLPv2, it may be desirable to 697 distinguish between certificates appropriate for use by UAs, SAs, and 698 DAs. For example, while a UA might be allowed to use any certificate 699 conforming to IKE certificate policy, the certificate used by an SA 700 might indicate that it is a legitimate source of service advertisements. 701 Similarly, a DA certificate might indicate that it is a valid DA. This 702 can be accomplished by using special CAs to issue certificates valid for 703 use by SAs and DAs; alternatively SA and DA authorizations can be 704 employed. 706 Assume that the policy for issuing and distributing SLPv2 authorized 707 certificates to SAs and DAs limits them only to legitimate SAs and DAs. 708 In this case, IPsec is used to provide SLPv2 security as follows: 710 [f] SLPv2 messages sent via unicast are IPsec protected, using ESP with 711 a non-null transform. 713 [g] SrvRply and AttrRply messages from either a DA or SA are unicast to 714 UAs. Assuming that the SA used a certificate authorized for SLPv2 715 service advertisement in establishing the the IKE Phase 1 SA, or 716 that the DA used a certificate authorized for DA usage, the UA can 717 accept the information sent, even if it has no SLPv2 authentication 718 block. 720 [h] SrvReg and SrvDereg messages from a SA are unicast to DAs. 721 Assuming that the SA used a certificate authorized for SLPv2 722 service advertisement in establishing the the IKE Phase 1 SA, the 723 DA can accept the de/registration even if it has no SLPv2 724 authentication block. Typically, the SA will check the DA 725 authorization prior to sending the service advertisement. 727 [i] Multicast DAAdverts can be considered advisory. The UA will 728 attempt to contact DAs via unicast. Assuming that the DA used a 729 certificate authorized for SLPv2 DAAdverts in establishing the the 730 IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no 731 SLPv2 authentication block. 733 [j] SAs can accept DAAdverts as described in i. 735 2.4.2. Confidentiality of service information 737 Since SLPv2 messages can contain information that can potentially reveal 738 the vendor of the device or its other associated characteristics, 739 revealing service information constitutes a security risk. As an 740 example, the FCIP Entity Name may reveal a WWN from which an attacker 741 can learn potentially useful information about the Entity's 742 characteristics. 744 The SLPv2 security model assumes that service information is public, and 745 therefore does not provide for confidentiality. However, storage devices 746 represent mission critical infrastructure of substantial value, and so 747 iSCSI and FCIP security implementations MUST support confidentiality as 748 well as authentication of unicast SLPv2 messages. 750 Assuming that all unicast SLPv2 messages are protected by IPsec, and 751 that confidentiality is provided, then the risk of disclosure can be 752 limited to SLPv2 messages sent via multicast, namely the SrvRqst and 753 DAAdvert. 755 The information leaked in a multicast SrvRqst depends on the level of 756 detail in the query. If leakage is a concern, then a DA can be provided. 757 If this is not feasible, then a general query can be sent via multicast, 758 and then further detail can be obtained from the replying entities via 759 additional unicast queries, protected by IPsec. 761 Information leakage via a multicast DAAdvert is less of a concern than 762 the authenticity of the message, since knowing that a DA is present on 763 the network only enables an attacker to know that SLPv2 is in use, and 764 possibly that a directory service is also present. This information is 765 not considered very valuable. 767 2.4.3. SLPv2 security implications 769 Through the definition of security attributes, it is possible to use 770 SLPv2 to distribute information about security settings for IP block 771 storage entities. SLPv2 distribution of security policy is not 772 necessary if the security settings can be determined by other means, 773 such as manual configuration or IPsec security policy distribution. If 774 an entity has already obtained its security configuration via other 775 mechanisms, then it MUST NOT request security policy via SLPv2. 777 Where SLPv2 is used to provide security policy information for use with 778 IP block storage protocols, SLPv2 MUST be protected by IPsec as 779 described in this document. Where SLPv2 is not used to distribute 780 security policy information, implementations MAY implement SLPv2 781 security as described in this document. 783 Where SLPv2 is used, but security is not implemented, IP block storage 784 protocol implementations MUST support a negative cache for 785 authentication failures. This allows implementations to avoid 786 continually contacting discovered endpoints which fail authentication 787 within IPsec or at the application layer (in the case of iSCSI Login). 788 The negative cache need not be maintained within the IPsec 789 implementation, but rather within the IP block storage protocol 790 implementation. 792 Since this document proposes that hop-by-hop security be used as the 793 primary mechanism to protect SLPv2, UAs have to trust DAs to accurately 794 relay data from SAs. This is a change to the SLPv2 security model 795 described in [RFC2608]. 797 When IPsec is used to protect SLPv2, it is not necessarily appropriate 798 for all hosts with whom an IPsec security association can be established 799 to be trusted to originate SLPv2 service advertisements. This is 800 particularly the case in environments where it is easy to obtain 801 certificates valid for use with IPsec (for example, where anyone with 802 access to the network can obtain a machine certificate valid for use 803 with IPsec). If not all hosts are authorized to originate service 804 advertisements, then it is necessary to distinguish between authorized 805 and unauthorized hosts. 807 This can be accomplished by restricting the issuance of certificates 808 valid for use in SLPv2 service advertisement. For example, while all 809 certificates allowed for use with IPsec will chain to a trusted root, 810 certificates for hosts authorized to originate service advertisements 811 could be signed by an SLPv2-authorized CA, or could contain explicit 812 SLPv2 authorizations within the certificate. After the IPsec security 813 association is set up between the SLPv2 entities, the SLPv2 814 implementations can then retrieve the certificates used in the 815 negotiation in order to determine whether the entities are authorized 816 for the operations that are being performed. 818 Use of IPsec for SLPv2 security has advantages over SLPv2 authentication 819 as defined in [RFC2608], which does not provide a way to authenticate 820 "zero result responses", leaving SLPv2 vulnerable to a denial of service 821 attack. Such an attack can be carried out on a UA by sending it a "zero 822 results" SrvRply or AttrRply, sent from a source address corresponding 823 to a DA issuing a legitimate DAAdvert. 825 When IPsec with ESP and a non-null transform is used to protect SLPv2, 826 not only can unicast requests and replies be authenticated, but 827 confidentiality can also be provided. This includes unicast requests to 828 DAs and SAs as well as replies. It is also possible to actively discover 829 SAs using multicast SA discovery, and then to send unicast requests to 830 the discovered SAs. 832 Using IPsec to secure SLPv2 has performance implications. Security 833 associations established between: 835 - UAs and SAs may be reused (the client on the UA host will use the 836 service on the SA host). 838 - SAs and DAs may be reused (the SAs will reregister services) 840 - UAs and DAs will probably not be reused (many idle security 841 associations are likely to result, and build up on the DA). 843 2.5. iSNS security 845 The iSCSI protocol may use iSNS for discovery and management services, 846 while the iFCP protocol is required to use iSNS for such services. In 847 addition, iSNS can be used to store and distribute security policy to 848 iSCSI and iFCP devices. When the iSNS protocol is deployed, the 849 interaction between iSNS server and iSNS clients are subject to the 850 following additional security threats: 852 [1] An attacker can alter iSNS protocol messages, directing iSCSI and 853 iFCP devices to establish connections with rogue devices, or 854 weakening IPsec protection for iSCSI or iFCP traffic. 856 [2] An attacker can masquerade as the real iSNS server by sending false 857 iSNS heartbeat messages. This could could deceive iSCSI and iFCP 858 devices into using rogue iSNS servers. 860 [3] An attacker can gain knowledge about iSCSI and iFCP devices by 861 snooping iSNS protocol messages. Such information could aid an 862 attacker in mounting a direct attack on iSCSI and iFCP devices, 863 such as a denial-of-service attack or outright physical theft. 865 To address these threats, the following capabilities are needed: 867 [a] Unicast iSNS protocol messages need to be authenticated and 868 confidential. 870 [b] Multicast iSNS protocol messages such as the iSNS heartbeat message 871 need to be authenticated. These messages need not be confidential 872 since they do not leak critical information. 874 There is no requirement that the identities of iSNS entities be kept 875 confidential. Specifically, the identity and location of the iSNS server 876 need not be kept confidential. 878 In order to protect against an attacker masquerading as an iSNS server, 879 client devices MUST be able to authenticate broadcast or multicast 880 messages such as the iSNS heartbeat. The iSNS authentication block 881 (which is identical in format to the SLP authentication block) MAY be 882 used for this purpose. Note that the authentication block is used only 883 for iSNS broadcast or multicast messages, and SHOULD NOT be used in 884 unicast iSNS messages. 886 Since iSNS is used to distribute authorizations and can be used to 887 distribute security policy for iFCP and iSCSI, IPsec ESP with null 888 transform MUST be implemented. Where confidentiality is desired, IPsec 889 ESP with non-null transform MAY be used. 891 Where iSNS is used, but security is not implemented, IP block storage 892 protocol implementations MUST support a negative cache for 893 authentication failures. This allows implementations to avoid 894 continually contacting discovered endpoints which fail authentication 895 within IPsec or at the application layer (in the case of iSCSI Login). 896 The negative cache need not be maintained within the IPsec 897 implementation, but rather within the IP block storage protocol 898 implementation. 900 For protecting unicast iSNS protocol messages, iSNS servers supporting 901 security MUST implement ESP in tunnel mode and MUST conform to [RFC2401] 902 requirements for support of ESP in transport mode. Section 4.1 of 903 [RFC2401] states: 905 a) A host MUST support both transport and tunnel mode. 906 b) A security gateway is required to support only tunnel 907 mode. If it supports transport mode, that should be used 908 only when the security gateway is acting as a host, e.g., 909 for network management. 911 All iSNS implementations supporting security MUST support the replay 912 protection mechanisms of IPsec. 914 2.5.1. Use of iSNS for security policy configuration 916 In practice, within a single installation, iSCSI and/or iFCP devices may 917 have different security settings. For example, some devices may be 918 configured to initiate secure communication, while other devices may be 919 configured to respond to a request for secure communication, but not to 920 require security. Still other devices, while security capable, may 921 neither initiate nor respond securely. 923 In practice, these variations in configuration can result in devices 924 being unable to communicate with each other. For example, a device that 925 is configured to always initiate secure communication will experience 926 difficulties in communicating with a device that neither initiates nor 927 responds securely. 929 The iSNS protocol is used to transfer naming, discovery, and management 930 information between iSCSI devices, iFCP gateways, management stations, 931 and the iSNS server. This includes the ability to enable discovery of 932 security settings used for communication via the iSCSI and/or iFCP 933 protocols. 935 Once communication between iSNS clients and the iSNS server are secured 936 through use of IPsec, iSNS clients have the capability to discover the 937 security settings required for communication via the iSCSI and/or iFCP 938 protocols. Use of iSNS for distribution of security policies offers the 939 potential to reduce the burden of manual device configuration, and 940 decrease the probability of communications failures due to incompatible 941 security policies. 943 The iSNS server stores security settings for each iSCSI and iFCP device 944 interface. These security settings, which can be retrieved by 945 authorized hosts, include use or non-use of IPSec, IKE, Main Mode, 946 Aggressive Mode, PFS, Pre-shared Key, and certificates. 948 For example, IKE may not be enabled for a particular device interface. 949 If a peer device can learn of this in advance by consulting the iSNS 950 server, it will not need to waste time and resources attempting to 951 initiate an IKE Phase 1 SA with that device interface. 953 Note that iSNS distribution of security policy is not necessary if the 954 security settings can be determined by other means, such as manual 955 configuration or IPsec security policy distribution. If an entity has 956 already obtained its security configuration via other mechanisms, then 957 it MUST NOT request security policy via iSNS. 959 If iSNS is used to distribute security policy, then the minimum 960 information that should be learned from the iSNS server is the use or 961 non-use of IKE and IPSec by each iFCP or iSCSI peer device interface. 962 This information is encoded in the Security Bitmap field of each Portal 963 of the peer device, and is applicable on a per-interface basis for the 964 peer device. iSNS queries to acquire security configuration data about 965 peer devices MUST be protected by IPsec/ESP authentication. 967 Additionally, the iSNS server can store policies that are used for IKE 968 phase 1 and phase 2 negotiations between client devices. The IKE 969 payload format includes a series of one or more proposals that the iSCSI 970 or iFCP device will use when negotiating the appropriate IPsec policy to 971 use to protect iSCSI or iFCP traffic. For further details on how to 972 store and retrieve IKE policy proposals in the iSNS server, see [iSNS]. 974 2.5.2. iSNS Interaction with IKE and IPsec 976 When IPsec security is enabled, each iSNS client that is registered in 977 the iSNS database maintains at least one phase 1 and one phase 2 978 security association with the iSNS server. All iSNS protocol messages 979 between iSNS clients and the iSNS server are to be protected by a phase- 980 2 security association. 982 When an iSNS client is removed from the iSNS database, the iSNS server 983 sends an IKE phase 1 delete message to the associated IKE peer, and 984 tears down all IKE phase 1 and phase 2 SAs associated with that iSNS 985 client. 987 2.5.3. iSNS Server Implementation Requirements 989 To provide confidentiality with ESP, 3DES in CBC mode MUST be supported, 990 and AES in Counter mode, as described in [AESCTR], SHOULD be supported. 991 To provide data origin authentication and integrity with ESP, HMAC-SHA1 992 MUST be supported, and AES in CBC MAC mode with XCBC extensions [AESCBC] 993 SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its 994 inherent weakness. If confidentiality is not required but data origin 995 authentication and integrity is enabled, ESP with NULL Encryption MUST 996 be used. 998 Conformant iSNS implementations MUST support IKE for authentication, 999 negotiation of security associations, and key management, using the 1000 IPsec DOI, described in [RFC2407]. Manual keying SHOULD NOT be used 1001 since it does not provide the necessary rekeying support. Conformant 1002 iSNS security implementations MUST support authentication using a pre- 1003 shared key, and MAY support certificate-based peer authentication using 1004 digital signatures. Peer authentication using the public key encryption 1005 methods outlined in [RFC2409] sections 5.2 and 5.3 SHOULD NOT be 1006 supported. 1008 When pre-shared keys are used for authentication, IKE Aggressive Mode 1009 SHOULD be used, and the IKE Main Mode SHOULD NOT be used. When digital 1010 signatures are used for authentication, either IKE Main Mode or IKE 1011 Aggressive Mode MAY be used. In all cases, access to locally stored 1012 secret information (pre-shared key or private key for digital signing) 1013 MUST be suitably restricted, since compromise of the secret information 1014 nullifies the security properties of the IKE/IPsec protocols. 1016 When digital signatures are used to achieve authentication, an IKE 1017 negotiator SHOULD use IKE Certificate Request Payload(s) to specify the 1018 certificate authority (or authorities) that are trusted in accordance 1019 with its local policy. IKE negotiators SHOULD check the pertinent 1020 Certificate Revocation List (CRL) before accepting a PKI certificate for 1021 use in IKE's authentication procedures. 1023 3. iSCSI security inter-operability guidelines 1025 The following guidelines are established to meet iSCSI security 1026 requirements using IPsec in practical situations. 1028 3.1. iSCSI security issues 1030 iSCSI provides for iSCSI Login, which includes support for application- 1031 layer authentication. This authentication is logically between the 1032 iSCSI Initiator and the iSCSI Target (as opposed to between the TCP/IP 1033 communication endpoints). The intent of the iSCSI design is that the 1034 Initiator and Target represent the systems (e.g., host and disk array or 1035 tape system) participating in the communication, as opposed to network 1036 communication interfaces or endpoints. 1038 The iSCSI protocol, and iSCSI Login authentication do not meet the 1039 security requirements for iSCSI. iSCSI Login authentication provides 1040 mutual authentication between the iSCSI Initiator and Target at 1041 connection origination, but does not protect control and data traffic on 1042 a per packet basis, leaving the iSCSI connection vulnerable to attack. 1043 iSCSI Login authentication can mutually authenticates the Initiator to 1044 the Target, but does not by itself provide per-packet authentication, 1045 integrity, confidentiality or replay protection. In addition, iSCSI 1046 Login authentication, outlined in [iSCSI], does not provide for a 1047 protected ciphersuite negotiation. Therefore, iSCSI Login provides a 1048 weak security solution. 1050 3.2. iSCSI and IPsec interaction 1052 An iSCSI session [iSCSI], comprised of one or more TCP connections, is 1053 identified by the 2-tuple of the Initiator-defined identifier and the 1054 Target-defined identifier, . Each connection within a given 1055 session is assigned a unique Connection Identification, CID. The TCP 1056 connection is identified by the 5-tuple . An IPsec 1058 Phase 2 SA is identified by the 3-tuple . 1061 The iSCSI session and connection information is carried within the iSCSI 1062 Login Commands, transported over TCP. Since an iSCSI Initiator may have 1063 multiple interfaces, iSCSI connections within an iSCSI session may be 1064 initiated from different IP addresses. Similarly, multiple iSCSI Targets 1065 may exist behind a single IP address, so that there may be multiple 1066 iSCSI sessions between a given pair. 1069 When multiple iSCSI sessions are active between a given pair, the set of TCP connections used by a given iSCSI session 1071 must be disjoint from those used by all other iSCSI sessions between the 1072 same pair. Therefore a TCP connection can be 1073 associated with one and only one iSCSI session. 1075 The relationship between iSCSI sessions, TCP connections and IKE Phase 1 1076 and Phase 2 SAs is as follows: 1078 [1] An iSCSI Initiator or Target may have more than one interface, and 1079 therefore may have multiple IP addresses. Also, multiple iSCSI 1080 Initiators and Targets may exist behind a single IP address. As a 1081 result, an iSCSI Session may correspond to multiple IKE Phase 1 1082 Security Associations, though typically a single IKE Phase 1 1083 security association will exist for an tuple. 1086 [2] Each TCP connection within an iSCSI Session is protected by a 1087 separate IKE Phase 2 SA, with selectors specific to that TCP 1088 connection. Each IKE Phase 2 SA protects only a single TCP 1089 connection, and each TCP connection is transported under only one 1090 IKE Phase 2 SA. 1092 Given this, all the information needed for the iSCSI/IPsec binding is 1093 contained within the iSCSI Login messages from the iSCSI Initiator and 1094 Target. This includes the binding between an IKE Phase 1 SA and the 1095 corresponding iSCSI sessions, as well as the binding between an IPsec 1096 Phase 2 SA and the TCP connection and iSCSI connection ID. 1098 3.3. Initiating a New iSCSI Session 1100 In order to create a new iSCSI Session, an Initiator implementing iSCSI 1101 security first establishes IKE Phase 1 and Phase 2 SAs, then exchanges 1102 iSCSI control messages over an IPsec-secured TCP connection. 1104 The iSCSI Initiator contacts the Target on well-known TCP port 3260. 1105 Typically, the Initiator and Target implementations successfully 1106 complete the IKE phase 1 and Phase 2 negotiations before the initial TCP 1107 connection setup messages are exchanged so that these messages can be 1108 IPsec protected. IPsec implementations configured with the correct 1109 policies (e.g. use ESP with non-null transform for all traffic destined 1110 to or originating from the iSCSI well-known TCP port) will handle this 1111 automatically. 1113 Once an IKE Phase 1 SA is established, subsequent iSCSI connections 1114 established within the iSCSI session will typically be protected by IKE 1115 Phase 2 SAs derived from that IKE Phase 1 SA, although additional IKE 1116 Phase 1 SAs can also be brought up. 1118 Once the IKE Phase 2 negotiations are complete and the TCP connection is 1119 established over IPsec, the iSCSI Initiator sends the iSCSI Login 1120 command over the TCP connection secured by the recently negotiated Quick 1121 Mode SA. 1123 The Initiator fills in the ISID field, and leaves the TSID field set to 1124 zero, to indicate that it is the first message of a new session 1125 establishment exchange. The Initiator also fills in a CID value, that 1126 identifies the TCP connection over which the Login command is being 1127 exchanged. When the iSCSI Target replies with its Login Command, both 1128 iSCSI devices will know the TSID, and therefore the iSCSI session 1129 identifier . 1131 A single iSCSI session identifier may have multiple associated IKE Phase 1132 1 SAs, and each IKE Phase 1 SA may correspond to multiple iSCSI session 1133 identifiers. Each iSCSI connection (identified by the connection 1134 identifier) corresponds to a single TCP connection (identified by the 1135 5-tuple) and IPsec Phase 2 SA. Each IKE Phase 2 SA corresponds to a 1136 single IKE Phase 1 SA, and is identified by the combination. 1139 Before adding a new TCP connection to an existing iSCSI Session, a new 1140 IKE Quick Mode exchange MUST occur, under the protection of an IKE Phase 1141 1 SA. This can be existing IKE Phase 1 SA, or a new IKE Phase 1 SA can 1142 be brought up for this purpose. 1144 Within IKE, each key refresh requires that a new security association be 1145 established. In practice there is a time interval during which an old, 1146 about-to-expire SA and newly established SA will both be valid. The 1147 IPsec implementation will choose which security association to use based 1148 on local policy, and iSCSI concerns play no role in this selection 1149 process. 1151 3.4. Graceful iSCSI Teardown 1153 Mechanisms within iSCSI provide for both graceful and non-graceful 1154 teardown of iSCSI Sessions or individual TCP connections within a given 1155 session. The iSCSI Logout command is used to effect graceful teardown. 1156 This command allows the iSCSI Initiator to request that: 1158 [a] the session be closed 1160 [b] a specific connection within the session be closed 1162 [c] a specific connection be marked for recovery 1164 When the iSCSI implementation wishes to close a session, it uses the 1165 appropriate iSCSI commands to accomplish this. After exchanging the 1166 appropriate iSCSI control messages for session closure, the iSCSI 1167 security implementation will typically initiate a half-close of each TCP 1168 connection within the iSCSI session. Since a given IKE Phase 1 SA may 1169 correspond to multiple iSCSI sessions, the iSCSI implementation will 1170 only delete the IKE Phase 1 SAs corresponding to the iSCSI session if 1171 there are no remaining iSCSI sessions corresponding to those SAs. For 1172 those Phase 1 SAs that are deleted, the iSCSI security implementation 1173 will also delete the IKE Phase 2 SAs bound to them first, before 1174 deleting the Phase 1 SA. 1176 When the iSCSI security implementation wishes to close an individual TCP 1177 connection while leaving the parent iSCSI session active, it should 1178 half-close the TCP connection. This results in a FIN being sent, putting 1179 the TCP connection into the FIN WAIT-1 state, as described in [RFC793]. 1180 After the other side responds, the TIME WAIT state is entered. After the 1181 expiration of the TIME WAIT timeout, the IKE Phase 2 security 1182 association bound to the TCP connection can be closed. Closing the TCP 1183 connection prior to deleting the IKE Phase 2 SA ensures that all the TCP 1184 packets sent on the connection are IPsec-protected. 1186 3.5. Non-graceful iSCSI Teardown 1188 If a given TCP connection unexpectedly fails, the associated iSCSI 1189 connection is torn down. Some time after this, the IKE Phase 2 security 1190 association will typically be deleted; however, there is no requirement 1191 that an IKE Phase 2 delete immediately follow iSCSI connection tear down 1192 of Phase 1 deletion. Similarly, if the IKE implementation receives a 1193 Phase 2 Delete message for a security association corresponding to a TCP 1194 connection, this does not necessarily imply that the TCP or iSCSI 1195 connection is to be torn down. 1197 If a Logout Command/Logout Response sequence marks a connection for 1198 removal from the iSCSI session, then after the iSCSI peer has executed 1199 an iSCSI teardown process for the connection, the TCP connection will be 1200 closed. The iSCSI connection state can then be safely removed. 1202 Since the IKE Phase 2 SA corresponding to the TCP connection may not be 1203 immediately deleted and can remain up for some time, iSCSI 1204 implementations should not depend on receiving the IPsec Phase 2 delete 1205 as confirmation that the iSCSI peer has executed an iSCSI teardown 1206 process for the connection. 1208 Since IPsec acceleration hardware may only be able to handle a limited 1209 number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent 1210 for idle SAs, as a means of keeping the number of active Phase 2 SAs to 1211 a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be 1212 interpreted as a reason for tearing down the corresponding iSCSI 1213 connection if no Logout Command/Logout Receive has been executed on the 1214 connection. Rather, it is preferable to leave the iSCSI connection up, 1215 and if additional traffic is sent on it, to bring up another IKE Phase 2 1216 SA to protect it. This avoids the potential for continually bringing 1217 iSCSI connections up and down. 1219 3.6. Application-layer CRC 1221 iSCSI's error detection and recovery assumes that the TCP and IP 1222 checksums provide inadequate integrity protection for high speed 1223 communications. As described in [CRCTCP], when operating at high speeds, 1224 the 16-bit TCP checksum [RFC793] will not necessarily detect all errors, 1225 resulting in possible data corruption. iSCSI [iSCSI] therefore 1226 incorporates a 32-bit CRC to protect its headers and data. 1228 When a CRC check fails (i.e. CRC computed at receiver does not match 1229 the received CRC), the iSCSI PDU covered by that CRC is discarded. 1230 Since presumably the error was not detected by the TCP checksum, TCP 1231 retransmission will not occur and thus cannot assist in recovering from 1232 the error. iSCSI contains both data and command retry mechanisms to 1233 deal with the resulting situations, including SNACK, the ability to 1234 reissue R2T commands, and the retry (X) bit for commands. 1236 IPsec offers protection against an attacker attempting to modify packets 1237 in transit, as well as unintentional packet modifications caused by 1238 router malfunctions. In general, IPsec authentication transforms afford 1239 stronger integrity protection than both the 16-bit TCP checksum and the 1240 32-bit application-layer CRC that has been proposed for use with iSCSI. 1241 Since IPsec integrity protection occurs below TCP, if an error is 1242 discovered, then the packet will be discarded and TCP retransmission 1243 will occur, so that no recovery action need be taken at the iSCSI layer. 1245 3.6.1. Simplification of recovery logic 1247 Where IPsec integrity protection is known to be in place, and covers the 1248 entire connection between iSCSI endpoints (or the portion that requires 1249 additional integrity connection), portions of iSCSI can be simplified. 1250 For example, mechanisms to recover from CRC check failures are not 1251 necessary. 1253 If the iSCSI CRC is negotiated, the recovery logic can be simplified to 1254 regard any CRC check failure as fatal (e.g., generate a SCSI CHECK 1255 CONDITION on data error, close the corresponding TCP connection on 1256 header error) because it will be very rare for errors undetected by 1257 IPsec integrity protection to be detected by the iSCSI CRC. 1259 3.6.2. Omission of iSCSI CRC 1261 In some situations where IPsec is employed, the iSCSI CRC will not 1262 provide additional protection, and can be omitted. 1264 For example, where IPsec processing as well as TCP checksum and iSCSI 1265 CRC verification are offloaded within the NIC, each of these checks will 1266 be verified prior to transferring data across the bus, so that 1267 subsequent errors will not be detected. As a result, where IPsec 1268 processing is offloaded to the NIC, the iSCSI CRC is not necessary and 1269 the implementations may wish not to negotiate it. 1271 However, in other circumstances, the TCP checksum and iSCSI CRC will 1272 provide additional protection, and it is desirable to negotiate use of 1273 the iSCSI CRC even though IPsec is available. These situations occur 1274 where: 1276 [1] IPsec, TCP and iSCSI are implemented purely in software. Here, 1277 additional failure modes may be detected by the TCP checksum and/or 1278 iSCSI CRC. For example, after the IPsec message integrity check is 1279 successfully verified, the segment is copied as part of TCP 1280 processing, and a memory error during this process might cause the 1281 TCP checksum or iSCSI CRC verification to fail. 1283 [2] The implementation is an iSCSI-iSCSI proxy or gateway. Here the 1284 iSCSI CRC can be propagated from one iSCSI connection to another. 1285 In this case, the iSCSI CRC is useful to protect iSCSI data against 1286 memory, bus, or software errors within the proxy or gateway, and 1287 requesting it is desirable. 1289 [3] IPsec is provided by a device external to the actual iSCSI device. 1290 Here the iSCSI header and data CRCs can be kept across the part of 1291 the connection that is not protected by IPsec. For instance, the 1292 iSCSI connection could traverse an extra bus, interface card, 1293 network, interface card, and bus between the iSCSI device and the 1294 device providing IPsec. In this case, the iSCSI CRC is desirable, 1295 and the iSCSI implementation behind the IPsec device may request 1296 it. 1298 Note that if both ends of the connection are on the same segment, 1299 then traffic will be effectively protected by the layer 2 CRC, so 1300 that negotiation of the iSCSI CRC is not necessary. 1302 4. iFCP and FCIP security issues 1304 4.1. iFCP and FCIP Authentication Requirements 1306 iFCP and FCIP are peer-to-peer protocols. iFCP and FCIP sessions may be 1307 initiated by either or both peer gateways. Consequently, bi-directional 1308 authentication of peer gateways MUST be provided. 1310 iFCP and FCIP are transport protocols that encapsulate SCSI and Fibre 1311 Channel frames over IP. Therefore, Fibre Channel, operating system, and 1312 user identities are transparent to the iFCP and FCIP protocols. In iFCP 1313 and FCIP, IP addresses MUST be used as the identities for IKE 1314 authentication. 1316 iFCP gateways use Discovery Domain information obtained from the iSNS 1317 server to determine whether the initiating Fibre Channel N_PORT should 1318 be allowed access to the Target N_PORT. N_PORT identities used in the 1319 Port Login (PLOGI) process will be considered authenticated provided 1320 that they are received over a connection whose security complies with 1321 the local security policy. 1323 There is no requirement that the identities used in authentication be 1324 kept confidential. 1326 4.2. iFCP Interaction with IPsec and IKE 1328 iFCP devices may have more than one interface and IP address. For iFCP, 1329 multiple TCP connections to other iFCP devices may exist at each 1330 interface and IP address. 1332 An active iFCP session is supported by one and only one TCP connection. 1333 This iFCP session is identified by the 2-tuple of the two communicating 1334 N_PORT ID's (3 byte Fibre Channel Port Identifier). A TCP connection is 1335 bound to an iFCP session using the CBIND message. 1337 Each IP address supporting iFCP communication can establish one or more 1338 Phase-1 IKE Security Associations (SA) to other IP addresses configured 1339 at peering iFCP gateways, using the IP address as identity. IKE Phase 1 1340 SAs may be established at gateway initialization, or may be brought up 1341 when TCP connections matching the IPsec security policy are established. 1343 Unlike Phase 1 SAs, a Phase 2 SA maps to an individual TCP connection. 1344 Once the phase 2 security association is established, it protects the 1345 TCP setup process and all subsequent TCP traffic. Before a new TCP 1346 connection to a remote iFCP or device is established, IKE will typically 1347 negotiate a phase 2 security association using Quick Mode to protect 1348 that new connection. Where the correct IPsec policy is in place, 1349 mandating IPsec protection of packets destined to and from the iFCP 1350 well-known port, this will occur automatically. 1352 iFCP connections protected by the phase 2 SA are either in the unbound 1353 state, or are bound to a specific session. The 1354 creation of an IKE Phase 2 SA to protect an iFCP connection may be 1355 triggered by a policy rule supplied through a management interface, or 1356 by N_PORT properties registered with the iSNS. For iFCP, the use of Key 1357 Exchange payload in Quick Mode for perfect forward secrecy may be 1358 dictated through a management interface, or by N_PORT properties 1359 registered with the iSNS. Multiple implementation strategies, are 1360 permitted so as to enable establishment of IKE Phase 2 SAs at different 1361 times. Examples of implementation strategies include: 1363 [1] There exists a unique iFCP security policy for all TCP connections 1364 regardless of their bound or unbound state. Thus, an unbound TCP 1365 connection can be bound to a session without the 1366 need to bring up a new IKE Phase-2 SA. 1368 [2] There exist multiple choices of iFCP security policy for unbound 1369 TCP connections and active sessions. An unbound 1370 TCP connection becomes bound to a session after 1371 establishing a new IKE Phase-2 SA matching the new security policy 1372 for that N_PORT session. 1374 [3] The iFCP implementation does not support TCP connections lingering 1375 in an unbound state. Both a IKE Phase-2 SA and a TCP connection 1376 need to be started anew anytime a new session is 1377 identified. 1379 If an iFCP implementation strategy uses unbound TCP connections, then an 1380 IKE Phase-2 SA MUST protect each of such unbound connections. 1382 iSNS [iSNS] is an invariant in all iFCP deployments. iFCP gateways use 1383 iSNS for discovery services, and MAY use security policies configured in 1384 the iSNS as the basis for algorithm negotiation in IKE. iFCP 1385 implementations MAY administratively disable any and all security 1386 mechanisms, on a per basis. This implies that IKE and 1387 IPsec security associations may not be established for one or more 1388 sessions. A configuration of this type may be 1389 accomplished through a management interface, or through attributes set 1390 in the iSNS server. 1392 4.3. FCIP Interaction with IPsec and IKE 1394 FCIP Entities establish tunnels with other FCIP Entities in order to 1395 transfer IP encapsulated FC frames. Each tunnel is a separate FCIP Link, 1396 and can encapsulate multiple TCP connections. The binding of TCP 1397 connections to an FCIP Link is performed using the Fibre Channel World 1398 Wide Names (WWNs) of the two FCIP Entities. 1400 FCIP Entities may have more than one interface and IP address, and it is 1401 possible for an FCIP Link to contain multiple TCP connections whose FCIP 1402 endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is 1403 typically established for each FCIP endpoint IP Address pair. For the 1404 purposes of establishing an IKE Phase 1 SA, static IP addresses are 1405 typically used for identification. 1407 Each TCP connection within an FCIP Link uses an independently negotiated 1408 IKE Phase 2 (Quick Mode) SA. This is established prior to sending the 1409 initial TCP SYN packet and applies to the life of the connection. Phase 1410 2 negotiation is also required for rekeying, in order to protect against 1411 replay attacks. 1413 FCIP implementations MAY provide administrative management of 1414 Confidentiality usage. These management interfaces SHOULD be provided in 1415 a secure manner, so as to prevent an attacker from subverting the 1416 security process by attacking the management interface. 1418 FCIP Entities do not require any user-level authentication, since all 1419 FCIP Entities participate in a machine-level tunnel function. 1421 FCIP uses SLP for discovery. However, SLP is not used to distribute 1422 security policies. 1424 5. Security considerations 1426 5.1. Transport mode versus tunnel mode 1428 With respect to storage protocols, the major differences between the 1429 IPsec tunnel mode and transport mode are as follows: 1431 [1] MTU considerations. Tunnel mode introduces an additional IP header 1432 into the datagram that reflects itself in a corresponding decrease 1433 in the path MTU seen by packets traversing the tunnel. This may 1434 result in a decrease in the maximum segment size of TCP connections 1435 running over the tunnel. 1437 [2] Address assignment and configuration. Within IPsec tunnel mode, it 1438 is necessary for inner and outer source addresses to be configured, 1439 and for inner and outer destination addresses to be discovered. 1440 Within transport mode it is only necessary to discover a single 1441 destination address and configure a single source address. IPsec 1442 tunnel mode address usage considerations are discussed in more 1443 detail below. 1445 [3] NAT traversal. As noted in [IPsecNATReq], IPsec tunnel mode ESP can 1446 traverse NAT in limited circumstances, whereas transport mode ESP 1447 cannot traverse NAT. To enable NAT traversal in the general case, 1448 the IPsec NAT traversal functionality described in [UDPIPsec], 1449 [IPsecNATJust], [NATIKE] can be implemented. More details are 1450 provided in the next section. 1452 [4] Connection-specific selectors. For both transport and tunnel mode, 1453 it is possible to negotiate connection-specific selectors, so that 1454 only a single iSCSI, iFCP or FCIP connection will be protected by 1455 an IKE Phase 2 SA. However, while negotiation of connection- 1456 specific selectors is common within IPsec transport mode 1457 implementations, IPsec security gateway implementations typically 1458 negotiate "ANY to ANY" selectors by default. 1460 [5] Firewall traversal. Where a storage protocol is to traverse 1461 administrative domains, the firewall administrator may desire to 1462 verify the integrity and authenticity of each transiting packet, 1463 rather than opening a hole in the firewall for the storage 1464 protocol. IPsec tunnel mode lends itself to such verification, 1465 since the firewall can terminate the tunnel mode connection while 1466 still allowing the endpoints to communicate end-to-end. If desired, 1467 the endpoints can in addition utilize IPsec transport mode for end- 1468 to-end security, so that they can also verify authenticity and 1469 integrity of each packet for themselves. 1471 In contrast, carrying out this verification with IPsec transport 1472 mode is more complex, since the firewall will need to terminate the 1473 IPsec transport mode connection and will need to act as an iSCSI, 1474 iFCP or FCIP gateway or TCP proxy, originating a new IPsec 1475 transport mode connection from the firewall to the internal 1476 endpoint. Such an implementation cannot provide end-to-end 1477 authenticity or integrity protection, and an application-layer CRC 1478 (iSCSI) or forwarding of the Fibre Channel frame CRC (iFCP and 1479 FCIP) is necessary to protect against errors introduced by the 1480 firewall. 1482 [6] IPsec-application integration. Where IPsec and the application 1483 layer protocol are implemented on the same device or host, it is 1484 possible to enable tight integration between them. For example, the 1485 application layer can request and verify that connections are 1486 protected by IPsec, and can obtain attributes of the IPsec security 1487 association. While in transport mode implementations the IPsec and 1488 application protocol implementations typically reside on the same 1489 host, with IPsec tunnel mode, they may reside on different hosts. 1490 Where IPsec is implemented on an external gateway, integration 1491 between the application and IPsec is typically not possible. This 1492 limits the ability of the application to control and verify IPsec 1493 behavior. 1495 5.1.1. IPsec tunnel mode addressing considerations 1497 IPsec tunnels include both inner and outer source as well as destination 1498 addresses. 1500 When used with IP block storage protocols, the inner destination address 1501 represents the address of the IP block storage protocol peer (e.g. the 1502 ultimate destination for the packet). The inner destination address can 1503 be discovered using SLPv2 or iSNS, or can be resolved from an FQDN via 1504 DNS, so that obtaining this address is typically not an issue. 1506 The outer destination address represents the address of the IPsec 1507 security gateway used to reach the peer. Several mechanisms have been 1508 proposed for discovering the IPsec security gateway used to reach a 1509 particular peer. [RFC2320] discusses the use of KX Resource Records 1510 (RRs) for IPsec gateway discovery. However, while KX RRs are supported 1511 by many DNS server implementations, they have not yet been widely 1512 deployed. Alternatively, DNS SRV [RFC2782] can also be used for this 1513 purpose, as can protocols such as Tunnel Endpoint Discovery [TED]. 1515 When used with IP block storage protocols, the outer source address is 1516 configured either statically or dynamically, using mechanisms such as 1517 DHCPv4 [RFC2131], DHCPV6 [DHCPv6], or Stateless address 1518 autoconfiguration [RFC2373]. 1520 The inner source address SHOULD be included in the quick mode ID when 1521 the peer establishes a tunnel mode SA with the IPsec security gateway. 1522 This enables the IPsec security gateway to properly route packets back 1523 to the remote peer. The inner source address can be configured via a 1524 variety of mechanisms, depending on the scenario. Where the IP block 1525 storage peers are located within the same administrative domain, it is 1526 typically possible for the inner and outer source addresses to be the 1527 same. This will work because the outer source address is presumably 1528 assigned from within a prefix assigned to the administrative domain, and 1529 which is therefore routable within the domain. Assuming that the IPsec 1530 security gateway is aware of the inner source address used by the 1531 connecting peer and plumbs a host route for it, then packets arriving at 1532 the IPsec security gateway destined for the address can be correctly 1533 encapsulated and sent down the correct tunnel. 1535 Where IP block storage peers are located within different administrative 1536 domains, it may be necessary for the inner source address to be assigned 1537 by the IPsec security gateway, effectively "joining" the remote host to 1538 the LAN attached to the IPsec security gateway. For example, if the 1539 remote peer were to use its assigned (outer) source address as the inner 1540 source address, then a number of problems might result: 1542 [1] Intrusion detection systems sniffing the LAN behind the IPsec 1543 security gateway would notice source addresses originating outside 1544 the administative domain. 1546 [2] Reply packets might not reach their destination, since the IPsec 1547 security gateway typically does not advertise default, but rather 1548 only the prefix that it allocates addresses from. Since the remote 1549 peer's address does not originate from with a prefix native to the 1550 administrative domain, it is likely that routers within the domain 1551 would not have a route for it, and would send the packet off to the 1552 router advertising default (perhaps a border router), instead of to 1553 the IPsec security gateway. 1555 For these reasons, for inter-domain use, assignment of inner source 1556 addresses may be needed. The use of DHCP within IPsec tunnel mode has 1557 been proposed for this, as described in [DHCPIPsec]. However, this 1558 mechanism is not yet widely deployed within IPsec security gateways. 1559 Existing IPsec tunnel mode servers typically implement the desired 1560 functionality via proprietary extensions to IKE. 1562 5.2. NAT traversal 1564 As noted in [IPsecNATJust], tunnel mode ESP can traverse NAT in a 1565 limited set of circumstances. For example, if there is only one protocol 1566 endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the 1567 receiver does not perform source address validation, then tunnel mode 1568 ESP may successfully traverse NATs. Since ignoring source address 1569 validation introduces new security vulnerabilities, and negotiation of 1570 specific selectors is desirable so as to limit the traffic that can be 1571 sent down the tunnel, these conditions may not necessarily apply, and 1572 tunnel mode NAT traversal will not always be possible. 1574 Transport mode ESP cannot traverse NAT, even though ESP itself does not 1575 include IP header fields within its message integrity check. This is 1576 because the 16-bit TCP checksum is calculated based on a "pseudo-header" 1577 that includes IP header fields, and the checksum is protected by the 1578 IPsec message integrity check. As a result, the TCP checksum will be 1579 invalidated by a NAT located between the two endpoints. 1581 Since TCP checksum calculation and verification is mandatory in both 1582 IPv4 and IPv6, it is not possible to omit checksum verification while 1583 remaining standards compliant. In order to enable traversal of NATs 1584 existing while remaining in compliance, iSCSI, iFCP or FCIP security 1585 implementations can implement IPsec/IKE NAT traversal, as described in 1586 [IPsecNATReq], [UDPIPsec], [IPsecNATJust], [NATIKE]. 1588 The IKE [NATIKE] and IPsec [UDPIPsec] NAT traversal specifications 1589 enable UDP encapsulation of IPsec to be negotiated if a NAT is detected 1590 in the path. By determining the IP address of the NAT, the TCP checksum 1591 can be calculated based on a pseudo-header including the NAT-adjusted 1592 address and ports. If this is done prior to calculating the IPsec 1593 message integrity check, TCP checksum verification will not fail. 1595 5.3. IKE issues 1597 There are situations where it is necessary for IKE to be implemented in 1598 firmware. In such situations, it is important to keep the size of the 1599 IKE implementation within strict limits. An upper bound on the size of 1600 an IKE implementation might be considered to be 800 KB, with 80 KB 1601 enabling implementation in a wide range of situations. 1603 As noted in Table 5.3-1 on the next page, IKE implementations currently 1604 exist which meet the requirements. Therefore, while removal of seldomly 1605 used IKE functionality (such as the nonce authentication methods) would 1606 reduce complexity, implementations typically will not require this in 1607 order to fit within the code size budget. 1609 5.4. Rekeying issues 1611 It is expected that IP block storage implementations will need to 1612 operate at high speed. For example, implementations operating at 1 Gbps 1613 are currently in design, with 10 Gbps implementations to follow shortly 1614 thereafter. At these speeds, a single IPsec SA could rapidly cycle 1615 through the 32-bit IPsec sequence number space. 1617 For example, a single SA operating at 1 Gbps line rate and sending 64 1618 octet packets would exhaust the 32-bit sequence number space in 2200 1619 seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur 1620 in 14.5 hours. At 10 Gbs, exhaustion would occur in 220 seconds or 3.67 1621 minutes. With 1518 octet packets, this would occur within 1.45 hours. 1622 In the future, it may be desirable forimplementations operating at 1623 speeds of 1 Gbps or greater to implement IPsec sequence number 1624 extension, described in [Seq]. 1626 Note that depending on the transform in use, it is possible that 1627 rekeying will be required prior to exhaustion of the sequence number 1628 space. 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | | Code size | | 1632 |Implementation | (octets) | Release | 1633 | | | | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | | | Linux | 1636 | Pluto | 258KB | FreeSWAN | 1637 |(FreeSWAN) | | x86 | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | | | | 1640 | Racoon | 400KB | NetBSD 1.5 | 1641 | (KAME) | | x86 | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | | | | 1644 | Isakmpd | 283KB | NetBSD 1.5 | 1645 | (Erickson) | | x86 | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | | | | 1648 | WindRiver | 142KB | PowerPC | 1649 | | | | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | | | | 1652 | Cisco | 222KB | PowerPC | 1653 | VPN1700 | | | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | | | | 1656 | Cisco | 350K | PowerPC | 1657 | VPN3000 | | | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 | | | | 1660 | Cisco | 228KB | MIPS | 1661 | VPN7200 | | | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 Table 5.3-1 - Code Size for IKE implementations 1666 In CBC-mode ciphers the ciphertext of one block depends on the plaintext 1667 of that block as well as the ciphertext of the previous block. This 1668 implies that if the ciphertext of two blocks are identical, and the 1669 plaintext of the next block is also identical, then the ciphertext of 1670 the next block will be identical. Thuss, if identical ciphertext blocks 1671 can be found with matching subsequent blocks, an attacker can determine 1672 the existence of matching plaintext. 1674 Such "Birthday attacks" were examined by Bellare et. al. in [DESANALY]. 1675 On average, a ciphertext block of size n bits will be expected to repeat 1676 every 2^[n/2] blocks. Although a single "birthday attack" does not 1677 provide much information to an attacker, multiple such attacks might 1678 provide useful information. To make this unlikely, it is recommended 1679 that a rekey occur before 2^[n/2] blocks have been sent on a given SA. 1680 These conclusions do not apply to counter mode. Bellare et. al. have 1681 formalized this in [DESANALY], showing that the insecurity of CBC mode 1682 increases as O(s^2/2^n), where n is the block size in bits, and s is the 1683 total number of blocks encrypted. These conclusions do not apply to 1684 counter mode. 1686 The formula below sets a limit on the bytes that can be sent on a CBC SA 1687 before a rekey is required: 1689 B = (n/8) * 2^[n/2] 1690 Where: 1691 B = maximum bytes sent on the SA 1692 n = block size in bits 1694 This means that cipher block size as well as key length need to be 1695 considered in the rekey decision. 3DES uses a block size n = 64 bits 1696 (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) 1697 * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that a rekey 1698 will be required every 274.9 seconds (4.6 minutes); at 10 Gbps, a rekey 1699 is required every 27.5 seconds. 1701 In terms of the sequence number space, for a 3DES encrypted message of 1702 512 = 2^9 bytes (2^6 blocks) this implies that the key has become 1703 insecure after about 2^26 messages. 1705 5.5. Transform issues 1707 Since IP block storage implementations may operate at speeds of 1 Gbps 1708 or greater, the ability to offer IPsec security services at high speeds 1709 is of intense concern. Since support for multiple algorithms multiplies 1710 the complexity and expense of hardware design, one of the goals of the 1711 transform selection effort is to find a minimal set of confidentiality 1712 and authentication algorithms implementable in hardware at speeds of up 1713 to 10 Gbps, as well as being efficient for implementation in software at 1714 speeds of 100 Mbps or slower. 1716 In this specification, we primarily concern ourselves with IPsec 1717 transforms that have already been specified, and for which parts are 1718 available that can run at 1 Gbps line rate. Where existing algorithms do 1719 not gracefully scale to 10 Gbps, we further consider algorithms for 1720 which transform specifications are not yet complete, but for which parts 1721 are expected to be available for inclusion in products shipping within 1722 the next 12 months. As the state of the art advances, the range of 1723 feasible algorithms will broaden and additional mandatory-to-implement 1724 algorithms may be considered. 1726 Section 5 of [RFC2406] states: 1728 "A compliant ESP implementation MUST support the following 1729 mandatory-to-implement algorithms: 1731 - DES in CBC mode 1732 - HMAC with MD5 1733 - HMAC with SHA-1 1734 - NULL Authentication algorithm 1735 - NULL Encryption algorithm 1736 " 1738 The DES algorithm is specified in [FIPS46-3]; implementation guidelines 1739 are found in [FIPS74], and security issues are discussed in 1740 [DESDIFF],[DESINT], [DESCRACK]. The DES IPsec transform is defined in 1741 [RFC2405] and the 3DES in CBC mode IPsec transform is specified in 1742 [RFC2451]. 1744 The MD5 algorithm is specified in [MD5]; HMAC is defined in [RFC2104] 1745 and security issues with MD5 are discussed in [MD5Attack]. The HMAC-MD5 1746 IPsec transform is specified in [HMACMD5IPsec]. The HMAC-SHA1 IPsec 1747 transform is specified in [RFC2404]. 1749 In addition to these existing algorithms, NIST is currently evaluating 1750 the following modes [NSPUE2] of AES, defined in [RIJNDAEL],[NISTAES]: 1752 AES in Electronic Codebook (ECB) confidentiality mode 1753 AES in Cipher Block Chaining (CBC) confidentiality mode 1754 AES in Cipher Feedback (CFB) confidentiality mode 1755 AES in Output Feedback (OFB) confidentiality mode 1756 AES in Counter (CTR) confidentiality mode 1757 AES CBC-MAC authentication mode 1759 The Modes [MODES] effort is also considering a number of additional 1760 algorithms, including the following: 1762 PMAC 1764 To provide authentication, integrity and replay protection, IP block 1765 storage security implementations MUST support HMAC-SHA1 [RFC2404] for 1766 authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be 1767 supported [AESCBC]. 1769 HMAC-SHA1 [RFC2404] is to be preferred to HMAC-MD5, due to concerns that 1770 have been raised about the security of MD5 [MD5Attack]. HMAC-SHA1 parts 1771 are currently available that run at 1 Gbps, the algorithm is 1772 implementable in hardware at speeds up to 10 Gbps, and an IPsec 1773 transform specification [RFC2404] exists. As a result, it is most 1774 practical to utilize HMAC-SHA1 as the authentication algorithm for 1775 products shipping in the near future. The HMAC-SHA2 algorithm [NISTSHA] 1776 is also under development, including an IPsec transform [SHAEXT], so 1777 that this may merit consideration in the future. AES in CBC-MAC 1778 authentication mode with XCBC extensions was selected since it avoids 1779 adding substantial additional code if AES is already being implemented 1780 for encryption; an IPsec transform document is available [AESCBC]. 1782 Authentication transforms also exist that are considerably more 1783 efficient to implement than HMAC-SHA1, HMAC-SHA2 or AES in CBC-MAC 1784 authentication mode. UMAC [UMAC],[UMACKR] is more efficient to 1785 implement in software and PMAC [PMAC] is more efficient to implement in 1786 hardware. PMAC is currently being evaluated as part of the NIST modes 1787 effort [MODES] but an IPsec transform does not yet exist; neither does a 1788 UMAC transform. 1790 For confidentiality, the ESP mandatory-to-implement algorithm (DES) is 1791 unacceptable. As noted in [DESCRACK], DES is crackable with modest 1792 computation resources, and so is inappropriate for use in situations 1793 requiring high levels of security. 1795 To provide confidentiality for iSCSI, iFCP, and FCIP, 3DES in CBC mode 1796 [RFC2451] MUST be supported and AES in Counter Mode [AESCTR] SHOULD be 1797 supported. For use in high speed implementations, 3DES has significant 1798 disadvantages. However, a 3DES IPsec transform has been specified and 1799 parts are available that can run at 1 Gbps, implementing 3DES in 1800 products is practical for the short term. 1802 As described in Appendix B, 3DES software implementations make excessive 1803 computational demands at speeds of 100 Mbps or greater, effectively 1804 ruling out software-only implementations. In addition, 3DES 1805 implementations require rekeying prior to exhaustion of the current 1806 32-bit IPsec sequence number space, and thus would not be able to make 1807 use of sequence space extensions, if they were available. This means 1808 that 3DES will require very frequent rekeying at speeds of 10 Gbps or 1809 faster. Thus, 3DES is inconvenient for use at very high speeds, as well 1810 as being impractical for implementation in software at slower speeds 1811 (100+ Mbps). 1813 5.6. Fragmentation Issues 1815 When certificate authentication is used, IKE fragmentation can be 1816 encountered. This can occur when certificate chains are used, or even 1817 when exchanging a single certificate if the key size, or size of other 1818 certificate fields (such as the distinguished name and other OIDs) is 1819 large enough. Many Network Address Translators (NATs) and firewalls do 1820 not handle fragments properly, dropping them on inbound and/or outbound. 1822 Routers in the path will also frequently discard fragments after the 1823 intial one, since they typically will not contain full IP headers that 1824 can be compared against an Access List. 1826 As a result, where IKE fragmentation occurs, the endpoints will often be 1827 unable to establish an IPsec security association. The solution to this 1828 problem is to install NAT, firewall or router code load that can 1829 properly support fragments. If this cannot be done, then the following 1830 alternatives can be considered: 1832 [1] Obtaining certificates by other means. 1834 [2] Reducing the size of the certificate chain. 1836 [3] Reducing the size of fields within the certificates. This includes 1837 reduction in the key size, the distinguished name or other fields. 1838 This should be considered only as a last resort. 1840 Fragmentation can become a concern when prepending IPsec headers to a 1841 frame. One mechanism which can be used to reduce this problem is to 1842 utilize path MTU discovery. For example, when TCP is used as the 1843 transport for iSCSI, iFCP or FCIP then path MTU discovery, described in 1844 [RFC1191], [RFC1435], [RFC1981], can be used to enable the TCP endpoints 1845 to discover the correct MTU, including effects due to IPsec 1846 encapsulation. 1848 However, Path MTU discovery fails when appropriate ICMP messages are not 1849 received by the host. This occurs in IPsec implementations which drop 1850 unauthenticated ICMP packets. This can result in blackholing in naive 1851 TCP implementations, as described in [RFC2923]. Appropriate TCP 1852 behavior is described in section 2.1 of [RFC2923]: 1854 "TCP should notice that the connection is timing out. After several 1855 timeouts, TCP should attempt to send smaller packets, perhaps turning 1856 off the DF flag for each packet. If this succeeds, it should continue 1857 to turn off PMTUD for the connection for some reasonable period of 1858 time, after which it should probe again to try to determine if the 1859 path has changed." 1861 If an ICMP PMTU is received by an IPsec implementation that processes 1862 unauthenticated ICMP packets, this value should be stored in the SA as 1863 proposed in [RFC2401], and IPsec should also provide notification of 1864 this event to TCP so that the new MTU value can be correctly reflected. 1866 5.7. Security Checks 1868 When a connection is opened which requires security, IP block storage 1869 security implementations may wish to check that the connection is 1870 protected by IPsec. If security is desired and IPsec protection is 1871 removed on a connection, it is reinstated before non-protected IP block 1872 storage packets are sent. Since IPsec verifies that each packet arrives 1873 on the correct SA, as long as it can be ensured that IPsec protection is 1874 in place, then IP block storage implementations can be assured that each 1875 received packet was sent by a trusted peer. 1877 When used with IP block storage protocols, IPsec MUST negotiate a 1878 separate Phase 2 SA for each TCP connection, with selectors specific to 1879 the TCP connection. As a result, only traffic for a single TCP 1880 connection will flow within each IPsec Phase 2 SA. IP block storage 1881 security implementations need not verify that the IP addresses and TCP 1882 port values in the packet match the socket information which was used to 1883 setup the connection. This check will be performed by IPsec, preventing 1884 malicious peers from sending commands on inappropriate Quick Mode SAs. 1886 5.8. Authentication issues 1888 5.8.1. Machine versus user certificates 1890 The certificate credentials provided by the iSCSI Initiator during the 1891 IKE negotiation may be those of the machine or of the iSCSI entity. When 1892 machine authentication is used, the machine certificate is typically 1893 stored on the iSCSI Initiator and Target during an enrollment process. 1894 When user certificates are used, the user certificate can be stored 1895 either on the machine or on a smartcard. For iFCP and FCIP, the 1896 certificate credentials provided will almost always be those of the 1897 device and will be stored on the device. 1899 Since the value of a machine certificate is inversely proportional to 1900 the ease with which an attacker can obtain one under false pretenses, it 1901 is advisable that the machine certificate enrollment process be strictly 1902 controlled. For example, only administrators may have the ability to 1903 enroll a machine with a machine certificate. 1905 While smartcard certificate storage lessens the probability of 1906 compromise of the private key, smartcards are not necessarily desirable 1907 in all situations. For example, some organizations deploying machine 1908 certificates use them so as to restrict use of non-approved hardware. 1909 Since user authentication can be provided within iSCSI Login (keeping in 1910 mind the weaknesses described earlier), support for machine 1911 authentication in IPsec makes it is possible to authenticate both the 1912 machine as well as the user. Since iFCP and FCIP have no equivalent of 1913 iSCSI Login, for these protocols only the machine is authenticated. 1915 In circumstances in which this dual assurance is considered valuable, 1916 enabling movement of the machine certificate from one machine to 1917 another, as would be possible if the machine certificate were stored on 1918 a smart card, may be undesirable. 1920 Similarly, when user certificate are deployed, it is advisable for the 1921 user enrollment process to be strictly controlled. If for example, a 1922 user password can be readily used to obtain a certificate (either a 1923 temporary or a longer term one), then that certificate has no more 1924 security value than the password. To limit the ability of an attacker to 1925 obtain a user certificate from a stolen password, the enrollment period 1926 can be limited, after which password access will be turned off. Such a 1927 policy will prevent an attacker obtaining the password of an unused 1928 account from obtaining a user certificate once the enrollment period has 1929 expired. 1931 5.8.2. Pre-shared keys 1933 Use of pre-shared keys in IKE main mode is vulnerable to man-in-the- 1934 middle attacks when used with dynamically addressed hosts (such as with 1935 iSCSI Initiators). In main mode it is necessary for SKEYID_e to be used 1936 prior to the receipt of the identification payload. Therefore the 1937 selection of the pre-shared key may only be based on information 1938 contained in the IP header. However, where dynamic IP address assignment 1939 is typical, it is often not possible to identify the required pre-shared 1940 key based on the IP address. 1942 Thus when main mode pre-shared keys are used with iSCSI, iFCP or FCIP 1943 entities whose address is dynamically assigned, the same pre-shared key 1944 is shared by a group of Initiators and is no longer able to function as 1945 an effective shared secret. In this situation, neither the Initiator 1946 nor responder identifies itself during IKE phase 1; it is only known 1947 that both parties are a member of the group with knowledge of the pre- 1948 shared key. This permits anyone with access to the group pre-shared key 1949 to act as a man-in-the-middle. This vulnerability is typically not of 1950 concern with iFCP and FCIP, since iFCP and FCIP devices typically use 1951 statically defined addresses, so that individual pre-shared keys are 1952 possible within IKE main mode. 1954 As a result, where main mode is used with pre-shared keys and 1955 dynamically addressed hosts, unless application-layer mutual 1956 authentication is performed (e.g. iSCSI Login), the Responder is not 1957 authenticated. This enables a rogue Responder in possession of the group 1958 pre-shared key to successfully masquerade as the actual Responder and 1959 mount a dictionary attack on legacy authentication methods such as CHAP 1960 [RFC1994]. Such an attack could potentially compromise many passwords at 1961 a time. This vulnerability is widely present in existing IPsec 1962 implementations. 1964 As a result, where iSCSI, iFCP, or FCIP Entities utilize dynamic address 1965 assignment along with pre-shared key authentication, IKE Agressive Mode 1966 MUST be used. 1968 Group pre-shared keys are not required in aggressive mode since the 1969 identity payload is sent earlier in the exchange, and therefore the pre- 1970 shared key can be selected based on the identity. However, when 1971 aggressive mode is used the user identity is exposed and this is often 1972 considered undesirable. 1974 Note that care needs to be taken with Identity Payload selection in 1975 order to enable mapping of identities to pre-shared keys even with 1976 aggressive mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 1977 Payloads are used and address are dynamically assigned, mapping of 1978 identities to keys is not possible, so that group pre-shared keys are 1979 still a practical necessity. As a result, IP block storage protocols 1980 MUST support ID_FQDN as well as ID_IPV4_ADDR and ID_IPV6_ADDR (if IPv6 1981 is supported within the protocol stack) and MAY support ID_USER_FQDN. 1982 ID_FQDN SHOULD be used in situations where IP addresses are dynamically 1983 assigned. 1985 5.8.3. IKE and application-layer authentication 1987 In addition to IKE authentication, iSCSI implementations utilize their 1988 own authentication methods, such as SRP described in [RFC2945]. 1989 Currently, work is underway on Fibre Channel security, so that a similar 1990 authentication process may eventually also apply to iFCP and FCIP as 1991 well. 1993 While iSCSI provides initial authentication, it does not provide per- 1994 packet authentication, integrity or replay protection. This implies that 1995 the identity verified in the iSCSI Login is not subsequently verified on 1996 reception of each packet. 1998 With IPsec, when the identity asserted in IKE is authenticated, the 1999 resulting derived keys are used to provide per-packet authentication, 2000 integrity and replay protection. As a result, the identity verified in 2001 the IKE conversation is subsequently verified on reception of each 2002 packet. 2004 Let us assume that the identity claimed in iSCSI Login is a user 2005 identity, while the identity claimed within IKE is a machine identity. 2006 Since only the machine identity is verified on a per-packet basis, there 2007 is no way for the recipient to verify that only the user authenticated 2008 via iSCSI Login is using the IPsec SA. 2010 In fact, IPsec implementations that only support machine authentication 2011 typically have no way to distinguish between user traffic within the 2012 kernel. As a result, where machine authentication is used, once an IPsec 2013 SA is opened, another user on a multi-user machine may be able to send 2014 traffic down the IPsec SA. 2016 To limit the potential vulnerability, iSCSI, iFCP or FCIP security 2017 implementations MUST negotiate a separate IPsec Phase 2 SA for each 2018 connection, with descriptors specific to that connection. This will 2019 prevent traffic for other connections from traveling within the IPsec SA 2020 negotiated for another connection. As a result, if access to the TCP 2021 socket used for the connection is exclusive, then access to the 2022 corresponding IPsec SA will also be exclusive, even if the IPsec 2023 implementation only supports machine authentication. 2025 While the identity asserted within IKE is verified on a per-packet 2026 basis, to avoid interference between users on a given machine, operating 2027 system support is required. In order to segregate traffic between users 2028 when user authentication is supported, the IPsec endpoints must ensure 2029 that only traffic from that particular user is sent or received within 2030 the IPsec SA. Enforcement of this restriction is the responsibility of 2031 the operating system. 2033 In kernel mode iSCSI drivers there typically is no user context to 2034 perform user authentication. In this case the authentication is closer 2035 to machine authentication. In most operating systems device permissions 2036 would control the ability to read/write to the device prior to mounting. 2037 Once the device is mounted, ACLs set by the filesystem control access to 2038 the device. An administrator can access the blocks on the device 2039 directly (for instance, by sending pass through requests to the port 2040 driver directly such as in Windows NT). In the same way, an 2041 administrator can open raw socket and send IPsec protected packets to an 2042 iSCSI Target. The situation is analogous, and in this respect no new 2043 vulnerability is created that didn't previously exist. The Operating 2044 system's ACLs need to be effective to protect a device (whether it is a 2045 SCSI device or an iSCSI device). 2047 5.8.4. IP block storage authorization 2049 IP block storage protocols can use a variety of mechanisms for 2050 authorization. Where ID_FQDN is used as the Identity Payload, IP block 2051 storage endpoints can be configured with a list of authorized FQDNs. The 2052 configuration can occur manually, or automatically via iSNS or the iSCSI 2053 MIB, defined in [AuthMIB]. 2055 Assuming that IPsec authentication is successful, this list of FQDNs can 2056 be examined to determine authorization levels. Where certificate 2057 authentication is used, it is possible to configure IP block storage 2058 protocol endpoints with trusted roots. The trusted roots used with IP 2059 block storage protocols might be different from the trusted roots used 2060 for other purposes. If this is the case, then the burden of negotiating 2061 use of the proper certificates lies with the IPsec initiator. 2063 Note that because IKE does not deal well with certificate chains, and is 2064 typically configured with a limited set of trusted roots, it is most 2065 appropriate for intra-domain usage. 2067 Since iSCSI supports Login authentication, it is also possible to use 2068 the identities presented within the iSCSI Login for authorization 2069 purposes. 2071 5.9. Use of AES in counter mode 2073 When AES in counter mode is used, it is important to avoid reuse of the 2074 counter with the same key, even across all time. Counter mode creates 2075 ciphertext by XORing generated key stream with plaintext. It is fairly 2076 easy to recover the plaintext from two messages counter mode encrypted 2077 under the same counter value, simply by XORing together the two packets. 2078 The implication of this is that it is almost always an error to use 2079 IPsec manual keying with counter mode, except when the implementation 2080 takes heroic measures to maintain state across sessions. 2082 Another counter mode issue is it makes forgery of correct packets 2083 trivial. Counter mode should therefore never be used without also using 2084 data authentication. 2086 5.10. Use of SRP in iSCSI Authentication 2088 The strength of SRP security is dependent on the characteristics of the 2089 group being used (i.e., the prime modulus N and generator g). As 2090 described in [RFC2945], N is required to be a Sophie-German prime (of 2091 the form N = 2q + 1, where q is also prime) the generator g is a 2092 primitive root of GF(n) [SRPNDSS]. For use in iSCSI authentication, the 2093 prime modulus N MUST be at least 768 bits. 2095 Upon receiving N and g from the Target, the Initiator MUST verify that 2096 they satisfy the above requirements (and abort the connection 2097 otherwise). This verification MAY start by trying to match them with a 2098 well-known group that satisfies the above requirements. SRP well-known 2099 groups are included in Appendix A. 2101 6. Normative references 2103 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 2104 progress), draft-ietf-ips-iSCSI-08.txt, September 2001 2106 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 2107 Channel Storage Networking", Internet drafts (work in 2108 progress), draft-ietf-ips-ifcp-06.txt, October 2001 2110 [FCIP] Rajagopal, M., et al., "Fibre Channel over TCP/IP (FCIP)", 2111 Internet draft (work in progress), draft-ietf-ips- 2112 fcovertcpip-06.txt, September 2001 2114 [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M, "Service 2115 Location Protocol, Version 2", RFC 2608, June 1999 2117 [iSCSIName] Bakke, M., et.al., "iSCSI Naming and Discovery", draft-ietf- 2118 ips-iscsi-name-disc-02.txt, Work in Progress, August 2001 2120 [FCIPSLP] Petersen, D., "Finding FCIP Entities Using SLP", Internet 2121 draft (work in progress), draft-ietf-ips-fcip-slp-00.txt, 2122 August 2001 2124 [iSCSISLP] Bakke, M., "Finding iSCSI Targets and Name Servers Using 2125 SLP", Internet draft (work in progress), draft-ietf-ips- 2126 iscsi-slp-01.txt, July 2001 2128 [iSNS] Gibbons, K., et al., "iSNS Internet Storage Name Service", 2129 Internet draft (work in progress), draft-ietf-ips- 2130 isns-05.txt, November 2001 2132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2133 Requirement Levels", BCP 14, RFC 2119, March 1997 2135 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 2136 Internet Protocol", RFC 2401, November 1998 2138 [RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload 2139 (ESP)", RFC 2406, November 1998 2141 [RFC2407] Piper, D., "The Internet IP Security Domain of 2142 Interpretation of ISAKMP", RFC 2407, November 1998 2144 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 2145 "Internet Security Association and Key Management Protocol 2146 (ISAKMP), RFC 2408, November 1998 2148 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", 2149 RFC 2409, November 1998 2151 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2152 2412, November 1998 2154 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 2155 September 1981 2157 [SRPNDSS] Wu, T., "The Secure Remote Password Protocol", in 2158 Proceedings of the 1998 Internet Society Symposium on 2159 Network and Distributed Systems Security, San Diego, CA, pp. 2160 97-111 2162 [RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, 2163 November 1990 2165 [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU 2166 Discovery", RFC 1435, March 1993 2168 [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery 2169 for IP version 6", RFC 1981, August 1996 2171 [RFC2923] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923, 2172 September 2000 2174 [NISTAES] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard 2175 (AES)", U.S. DoC/NIST, summer 2001 2177 [3DESANSI] American National Standard for Financial Services 2178 X9.52-1998, "Triple Data Encryption Algorithm Modes of 2179 Operation", American Bankers Association, Washington, D.C., 2180 July 29, 1998 2182 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 2183 Hashing for Message Authentication", RFC 2104, February 1997 2185 [RFC2451] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 2186 Algorithms", RFC 2451, November 1998 2188 [AESCBC] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm 2189 and Its Use with IPsec", Internet draft (work in progress), 2190 draft-ietf-ipsec-ciph-aes-cbc-01.txt, May 2001 2192 [AESCTR] Walker, J., Moskowitz, R., "The AES128 CTR Mode of Operation 2193 and Its Use with IPsec", Internet draft (work in progress), 2194 draft-moskowitz-aes128-ctr-00.txt, September 2001 2196 [RFC2404] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 2197 and AH", RFC 2404, November 1998 2199 [DHCPIPsec] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 2200 Configuration of IPsec Tunnel Mode", Internet draft (work in 2201 progress), draft-ietf-ipsec-dhcp-13.txt, June 2001 2203 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System," 2204 RFC 2945, September 2000 2206 7. Informative references 2208 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 2209 Architecture", RFC 2373, July 1998. 2211 [RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 2212 November 1998 2214 [RFC2782] Gulbrandsen , A., . Vixie, P., Esibov, L. "A DNS RR for 2215 specifying the location of services (DNS SRV)", RFC 2782, 2216 February 2000. 2218 [AuthMIB] Bakke, M., et al., "Definitions of Managed Objects for 2219 iSCSI", Internet draft (work in progress), draft-ietf-ips- 2220 iscsi-mib-03.txt, October 2001. 2222 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2223 April 1992 2225 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", 2226 CryptoBytes Vol.2 No.2, Summer 1996 2228 [CRCTCP] Stone J., Partridge, C., "When the CRC and TCP checksum 2229 disagree", ACM Sigcomm, Sept. 2000 2231 [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000 2233 [iSCSIREQ] Krueger, M., et.al., "iSCSI Requirements and Design 2234 Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in 2235 Progress, July 2001 2237 [IPsecNatReq] 2238 Aboba, B., "IPsec-NAT Compatibility Requirements", draft- 2239 ietf-ipsec-nat-reqts-00.txt, Work in Progress, June 2001 2241 [UDPIPsec] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 2242 draft-ietf-ipsec-udp-encaps-01.txt, October 2001 2244 [Seq] Kent, S., "IP Encapsulating Security Payload (ESP)", 2245 Internet draft (work in progress), draft-ietf-ipsec-esp- 2246 v3-01.txt, November 2002 2248 [IPsecNATJust] 2249 Dixon, W. et. al., "IPsec over NAT Justification for UDP 2250 Encapsulation", draft-ietf-ipsec-udp-encaps- 2251 justification-00.txt, June 2001 2253 [NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the 2254 IKE", Internet draft (work in progress), draft-ietf-ipsec- 2255 nat-t-ike-01.txt, October 2001 2257 [HMACMD5IPsec] 2258 Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP 2259 and AH", RFC 2403, November 1998 2261 [PMAC] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a 2262 parallelizable message authentication code", 2263 http://csrc.nist.gov/encryption/modes/proposedmodes/ 2264 pmac/pmac-spec.pdf 2266 [TED] Fluhrer, S., "Tunnel Endpoint Discovery", Internet draft 2267 (work in progress), draft-fluhrer-ted-00.txt, November 2001. 2269 [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway, 2270 P., "UMAC: Fast and provably secure message authentication", 2271 Advances in Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 2272 216-233. Full version available from 2273 http://www.cs.ucdavis.edu/~rogaway/umac 2275 [NISTSHA] "Descriptions of SHA-256, SHA-384, and SHA-512," 2276 http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf 2278 [FIPS46-3] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, 2279 October 25, 1999 2281 [FIPS74] U.S. DoC/NIST, "Guidelines for implementing and using the 2282 nbs data encryption standard", FIPS 74, Apr 1981 2284 [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- 2285 like cryptosystems", Journal of Cryptology Vol 4, Jan 1991 2287 [RFC2405] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm 2288 With Explicit IV", RFC 2405, November 1998 2290 [RIJNDAEL] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES 2291 Proposal, June 1998 2292 http://csrc.nist.gov/encryption/aes/round2/ 2293 AESAlgs/Rijndael/Rijndael.pdf 2295 [MODES] "Symmetric Key Block Cipher Modes of Operation," 2296 http://www.nist.gov/modes 2298 [NSPUE2] "Recommendation for Block Cipher Modes of Operation", 2299 National Institute of Standards and Technology (NIST) 2300 Special Publication 800-XX, CODEN: NSPUE2, U.S. Government 2301 Printing Office, Washington, DC, July 2001 2303 [AESOCB] Moskowitz, R., Walker, J., "The AES128 OCB Mode of Operation 2304 and Its Use with IPsec", Internet draft (work in progress), 2305 draft-moskowitz-aes128-ocb-00.txt, September 2001 2307 [CTR-MODE] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", 2308 Comment on mode of operations NIST, Jan 2001 2310 [AESPERF] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, 2311 and N. Ferguson, "Performance Comparison of the AES 2312 Submissions", http://www.counterpane.com/AES- 2313 performance.html 2315 [PENTPERF] A. Bosselaers, "Performance of Pentium implementations", 2316 http://www.esat.kuleuven.ac.be/~bosselae/ 2318 [UMACPERF] Rogaway, P., "UMAC Performance", 2319 http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 2321 [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without 2322 Strong Integrity", Proceedings of the 32nd IETF, Danvers, 2323 MA, April 1995 2325 [UMACKR] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., 2326 Rogaway, P., "UMAC: Message Authentication Code using 2327 Universal Hashing", Internet draft (work in progress), 2328 draft-krovetz-umac-01.txt, October 2000. Also available at: 2329 http://www.cs.ucdavis.edu/~rogaway/umac/draft-krovetz- 2330 umac-01.txt 2332 [RFC1994] Simpson, W.,"PPP Challenge Handshake Authentication Protocol 2333 (CHAP)," RFC 1994, August 1996. 2335 [DESANALY] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of 2336 Symmetric Encryption: Analysis of the DES Modes of 2337 Operation", 1997, http://www-cse.ucsd.edu/users/mihir/ 2339 [SRPDIST] Wu, T., "SRP Distribution", http://www-cs- 2340 students.stanford.edu/~tjw/srp/download.html 2342 [SHAEXT] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and 2343 SHA-512 within ESP, AH and IKE," Work in progress 2345 Appendix A - Well Known Groups for Use with SRP 2347 Modulus (N) and generator (g) values for various modulus lengths are 2348 given below. The values below are taken from software developed by Tom 2349 Wu and Eugene Jhong for the Stanford SRP distribution [SRPDIST]: 2351 [768 bits] 2352 Modulus (base 16) = 2353 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9F40 2354 2653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE694AFF 2355 737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867C60C3262B 2356 Generator = 2 2358 [1024 bits] 2359 Modulus (base 16) = 2360 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576 2361 D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD1 2362 5DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC 2363 68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 2364 Generator = 2 2366 [1280 bits] 2367 Modulus (base 16) = 2368 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690DC4 2369 3872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E004B78 2370 6C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744B1CDE1891 2371 690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB14BB2049B163 2372 EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5003686161F0605B 2373 Generator = 2 2375 [1536 bits] 2376 Modulus (base 16) = 2377 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19CC4D 2378 5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A22E8DC 2379 DF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D47548381DBC5B1FC 2380 764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2FD53D24B7C486 2381 65772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87F8A2FE9B8B5292E 2382 5A021FFF5E91479E8CE7A28C2442C6F315180F93499A234DCF76E3FED135F9BB 2383 Generator = 2 2384 [2048 bits] 2385 Modulus (base 16) = 2386 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050 2387 A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50 2388 E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A9962F0B93B8 2389 55F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D281E446B14773B 2390 CA97B43A23FB801676BD207A436C6481F1D2B9078717461A5B9D32E688F87748 2391 544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3786160279004E57AE6 2392 AF874E7303CE53299CCC041C7BC308D82A5698F3A8D0C38271AE35F8E9DBFBB6 2393 94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73 2394 Generator = 2 2396 In addition the Oakley Group 1 (768 bit prime) and Group 2 (1024 bit 2397 prime) defined in [RFC2412] Section E MAY be used. 2399 Appendix B - Software Performance of IPsec Transforms 2401 This Appendix provides data on the performance of IPsec encryption and 2402 authentication transforms in software. Since the performance of IPsec 2403 transforms is heavily implementation dependent, the data presented here 2404 may not be representative of performance in a given situation, and are 2405 presented solely for purposes of comparison. Other performance data is 2406 available in [AESPERF],[PENTPERF] and [UMACPERF]. 2408 B.1 Authentication transforms 2410 Table B-1 presents the cycles/byte required by the AES-PMAC, AES-CBC- 2411 MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet 2412 sizes, implemented in software. 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | | | | | | | 2416 | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | 2417 | Size | PMAC | MAC | UMAC | MD5 | SHA1 | 2418 | | | | | | | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | | | | | | | 2442 | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | 2443 | Size | PMAC | MAC | UMAC | MD5 | SHA1 | 2444 | | | | | | | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 | 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 | 2453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 | 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 | 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 Table B-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, 2462 AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at 2463 various packet sizes. 2465 Source: Jesse Walker, Intel 2466 Table B-2 presents the cycles/second required by the AES-PMAC, AES-CBC- 2467 MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in 2468 software, assuming a 1500 byte packet. 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 2472 | Transform | octet | @ | @ | @ | 2473 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | | | | | | 2476 | AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B | 2477 | (8 octets) | | | | | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 | | | | | | 2480 | HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B | 2481 | (20 octets) | | | | | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | | | | | | 2484 | HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B | 2485 | | | | | | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | | | | | | 2488 | AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B | 2489 | | | | | | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | | | | | | 2492 | AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B | 2493 | (8 octets) | | | | | 2494 | | | | | | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 Table B-2: Software performance of the HMAC-SHA1, HMAC-MD5, AES-CBC-MAC 2498 and AES-PMAC authentication algorithms at 100 Mbps, 1 Gbps, and 10 Gbps 2499 line rates (1500 byte packet). 2501 Source: Jesse Walker, Intel 2503 At speeds of 100 Mbps, AES-UMAC is implementable with only a modest 2504 processor, and the other algorithms are implementable, assuming that a 2505 single high-speed processor can be dedicated to the task. At 1 Gbps, 2506 only AES-UMAC is implementable on a single high-speed processor; 2507 multiple high speed processors (1+ Ghz) will be required for the other 2508 algorithms. At 10 Gbps, only AES-UMAC is implementable even with 2509 multiple high speed processors; the other algorithms will require a 2510 prodigious number of cycles/second. Thus at 10 Gbps, hardware 2511 acceleration will be required for all algorithms with the possible 2512 exception of AES-UMAC. 2514 B.2 Encryption and Authentication transforms 2516 Table B-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 2517 3DES-CBC encryption algorithms (no MAC), implemented in software, for 2518 various packet sizes. 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | | | | | 2522 | Data size | AES-CBC | AES-CTR | 3DES-CBC | 2523 | | | | | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | 64 | 31.22 | 26.02 | 156.09 | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | 128 | 31.22 | 28.62 | 150.89 | 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 | 192 | 31.22 | 27.75 | 150.89 | 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 | 256 | 28.62 | 27.32 | 150.89 | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 | 320 | 29.14 | 28.1 | 150.89 | 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 | 384 | 28.62 | 27.75 | 148.29 | 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 | 448 | 28.99 | 27.5 | 149.4 | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | 512 | 28.62 | 27.32 | 148.29 | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | 576 | 28.33 | 27.75 | 147.72 | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | 640 | 28.62 | 27.06 | 147.77 | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | | | | | 2547 | Data size | AES-CBC | AES-CTR | 3DES-CBC | 2548 | | | | | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 | 768 | 28.18 | 27.32 | 147.42 | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | 896 | 28.25 | 27.5 | 147.55 | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | 1024 | 27.97 | 27.32 | 148.29 | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | 1152 | 28.33 | 27.46 | 147.13 | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | 1280 | 28.1 | 27.58 | 146.99 | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | 1408 | 27.91 | 27.43 | 147.34 | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | 1500 | 27.97 | 27.53 | 147.85 | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 Table B-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC 2566 encryption algorithms at various packet sizes, implemented in 2567 software. 2569 Source: Jesse Walker, Intel 2570 Table B-4 presents the cycles/second required by the AES-CBC, AES-CTR 2571 and 3DES-CBC encryption algorithms (no MAC), implemented in software, at 2572 100 Mbps, 1 Gbps, and 10 Gbps line rates (assuming a 1500 byte packet). 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 2576 | Transform | octet | @ | @ | @ | 2577 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | | | | | | 2580 | AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B | 2581 | | | | | | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | | | | | | 2584 | AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B | 2585 | | | | | | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | | | | | | 2588 | 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B | 2589 | | | | | | 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 Table B-4: Software performance of the AES-CBC, AES-CTR, and 3DES 2593 encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates 2594 (1500 byte packet). 2596 Source: Jesse Walker, Intel 2598 At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a 2599 high-speed processor, while 3DES would require multiple high speed 2600 processors. At speeds of 1 Gbps, multiple high speed processors are 2601 required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, 2602 and 10 Gbps for all algorithms, implementation in software is 2603 infeasible, and hardware acceleration is required. 2605 Table B-5 presents the cycles/byte required for combined 2606 encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + 2607 CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented 2608 in software. 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | | AES | AES | AES | | 2612 | Data size | CBC + | CTR + | CTR + | AES- | 2613 | | CBCMAC | CBCMAC | UMAC | OCB | 2614 | | | | | | 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | 64 | 119.67 | 52.03 | 52.03 | 57.23 | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | 128 | 70.24 | 57.23 | 39.02 | 44.23 | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | 192 | 58.97 | 55.5 | 36.42 | 41.63 | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 | 256 | 57.23 | 55.93 | 35.12 | 40.32 | 2623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2624 | 320 | 57.23 | 55.15 | 33.3 | 38.5 | 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 | 384 | 57.23 | 55.5 | 32.95 | 37.29 | 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | 448 | 58.72 | 55 | 32.71 | 37.17 | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 | 512 | 58.54 | 55.28 | 32.52 | 36.42 | 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 | | AES | AES | AES | | 2634 | Data size | CBC + | CTR + | CTR + | AES- | 2635 | | CBCMAC | CBCMAC | UMAC | OCB | 2636 | | | | | | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | 576 | 57.81 | 55.5 | 31.8 | 37 | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 | 640 | 57.75 | 55.15 | 31.74 | 36.42 | 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | 768 | 57.67 | 55.5 | 31.65 | 35.99 | 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | 896 | 57.61 | 55.75 | 31.22 | 35.68 | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | 1024 | 57.56 | 55.61 | 31.22 | 35.45 | 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | 1152 | 57.52 | 55.21 | 31.22 | 35.55 | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | 1280 | 57.75 | 55.15 | 31.22 | 36.16 | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2652 | 1408 | 57.47 | 55.34 | 30.75 | 35.24 | 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 | 1500 | 57.72 | 55.5 | 30.86 | 35.3 | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 Table B-5: Cycles/byte of combined encryption/authentication 2658 algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, 2659 and AES-OCB at various packet sizes, implemented in software. 2661 Table B-6 presents the cycles/second required for the AES CBC + CBCMAC, 2662 AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and 2663 authentication algorithms operating at line rates of 100 Mbps, 1 Gbps 2664 and 10 Gbps, assuming 1500 byte packets. 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | 2668 | Transform | octet | @ | @ | @ | 2669 | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | | | | | | 2672 | AES | | | | | 2673 | CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B | 2674 | | | | | | 2675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2676 | | | | | | 2677 | AES | | | | | 2678 | CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B | 2679 | | | | | | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | | | | | | 2682 | AES | | | | | 2683 | CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B | 2684 | | | | | | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2686 | | | | | | 2687 | | | | | | 2688 | AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B | 2689 | | | | | | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 Table B-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, 2693 AES CTR + UMAC, and AES-OCB encryption and authentication algorithms, 2694 operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, 2695 assuming 1500 octet packets. 2697 Source: Jesse Walker, Intel 2699 At speeds of 100 Mbps, the algorithms are implementable on a high speed 2700 processor. At speeds of 1 Gbps, multiple high speed processors are 2701 required, and none of the algorithms are implementable in software at 10 2702 Gbps line rate. 2704 Acknowledgments 2706 Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft, 2707 David Black of EMC, Mark Bakke and Steve Senum of Cisco, Erik Guttman of 2708 Sun Microsystems and Howard Herbert of Intel for useful discussions of 2709 this problem space. 2711 Authors' Addresses 2713 Bernard Aboba 2714 Microsoft Corporation 2715 One Microsoft Way 2716 Redmond, WA 98052 2718 Phone: +1 425 706 6605 2719 Fax: +1 425 706 7329 2720 EMail: bernarda@microsoft.com 2722 Joshua Tseng 2723 Nishan Systems 2724 3850 North First Street 2725 San Jose, CA 95134-1702 2727 Phone: +1 408 519 3749 2728 EMail: jtseng@nishansystems.com 2730 Joseph J. Tardo 2731 Broadcom 2732 3151 Zanker Road 2733 San Jose, CA 95134 2735 Phone: +1 408 501 8445 2736 Fax: +1 408 501 8460 2737 EMail: jtardo@broadcom.com 2739 Jesse Walker 2740 Intel Corporation 2741 2211 NE 25th Avenue 2742 Hillboro, OR 97124 2744 Phone: +1 503 712 1849 2745 Fax: +1 503 264 4843 2746 Email: jesse.walker@intel.com 2748 Julian Satran 2749 IBM, Haifa Research Lab 2750 MATAM - Advanced Technology Center 2751 Haifa 31905, Israel 2753 Phone +972 4 829 6264 2754 EMail: Julian_Satran@vnet.ibm.com 2755 Ofer Biran 2756 IBM, Haifa Research Lab 2757 MATAM - Advanced Technology Center 2758 Haifa 31905, Israel 2760 Phone +972 4 829 6253 2761 Email: biran@il.ibm.com 2763 Charles Kunzinger 2764 IBM Corporation 2765 Research Triangle Park, NC 27709 2767 Phone: +1 919 254 4142 2768 EMail: kunzinge@us.ibm.com 2770 Venkat Rangan 2771 Rhapsody Networks Inc. 2772 3450 W. Warren Ave. 2773 Fremont, CA 94538 2775 Phone: +1 510 743 3018 2776 Fax: +1 510 687 0136 2777 EMail: venkat@rhapsodynetworks.com 2779 Franco Travostino 2780 Director, Content Internetworking Lab 2781 Nortel Networks 2782 3 Federal Street 2783 Billerica, MA 01821 2785 Phone: +1 978 288 7708 2786 EMail: travos@nortelnetworks.com 2788 Intellectual Property Statement 2790 The IETF takes no position regarding the validity or scope of any 2791 intellectual property or other rights that might be claimed to pertain 2792 to the implementation or use of the technology described in this 2793 document or the extent to which any license under such rights might or 2794 might not be available; neither does it represent that it has made any 2795 effort to identify any such rights. Information on the IETF's 2796 procedures with respect to rights in standards-track and standards- 2797 related documentation can be found in BCP-11. Copies of claims of 2798 rights made available for publication and any assurances of licenses to 2799 be made available, or the result of an attempt made to obtain a general 2800 license or permission for the use of such proprietary rights by 2801 implementors or users of this specification can be obtained from the 2802 IETF Secretariat. 2804 The IETF invites any interested party to bring to its attention any 2805 copyrights, patents or patent applications, or other proprietary rights 2806 which may cover technology that may be required to practice this 2807 standard. Please address the information to the IETF Executive 2808 Director. 2810 Full Copyright Statement 2812 Copyright (C) The Internet Society (2002). All Rights Reserved. 2814 This document and translations of it may be copied and furnished to 2815 others, and derivative works that comment on or otherwise explain it or 2816 assist in its implementation may be prepared, copied, published and 2817 distributed, in whole or in part, without restriction of any kind, 2818 provided that the above copyright notice and this paragraph are included 2819 on all such copies and derivative works. However, this document itself 2820 may not be modified in any way, such as by removing the copyright notice 2821 or references to the Internet Society or other Internet organizations, 2822 except as needed for the purpose of developing Internet standards in 2823 which case the procedures for copyrights defined in the Internet 2824 Standards process must be followed, or as required to translate it into 2825 languages other than English. The limited permissions granted above are 2826 perpetual and will not be revoked by the Internet Society or its 2827 successors or assigns. This document and the information contained 2828 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2829 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2830 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2831 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2834 Expiration Date 2836 This memo is filed as , and expires 2837 August 22, 2002.