idnits 2.17.1 draft-maino-fcsp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 629. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (September 14, 2005) is 6800 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 565, but not defined == Missing Reference: 'I-D.ietf-ipsec-ikev2-17' is mentioned on line 549, but not defined == Missing Reference: 'RFC2406' is mentioned on line 568, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2625' is mentioned on line 571, but not defined ** Obsolete undefined reference: RFC 2625 (Obsoleted by RFC 4338) == Missing Reference: 'RFC3643' is mentioned on line 578, but not defined == Missing Reference: 'RFC3821' is mentioned on line 582, but not defined == Missing Reference: 'RFC3602' is mentioned on line 574, but not defined == Missing Reference: 'RFC2104' is mentioned on line 561, but not defined == Missing Reference: 'RFC1321' is mentioned on line 558, but not defined Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Maino 3 Internet-Draft Cisco Systems 4 Expires: March 18, 2006 D. Black 5 EMC Corporation 6 September 14, 2005 8 Use of IKEv2 in The Fibre Channel Security Association Management 9 Protocol 10 draft-maino-fcsp-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 18, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes the use of IKEv2 to negotiate security 44 protocols and transforms for Fibre Channel as part of the Fibre 45 Channel Security Association Management Protocol. This usage 46 requires that IKEv2 be extended with Fibre-Channel-specific security 47 protocols, transforms and name types. This document specifies these 48 IKEv2 extensions and allocates identifiers for them. Using new IKEv2 49 identifiers for Fibre Channel security protocols avoids any possible 50 confusion between IKEv2 negotiation for IP networks and IKEv2 51 negotiation for Fibre Channel. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Fibre Channel Security Protocols . . . . . . . . . . . . . . . 6 59 4.1. ESP_Header Protocol . . . . . . . . . . . . . . . . . . . 7 60 4.2. CT_Authentication Protocol . . . . . . . . . . . . . . . . 8 61 5. The FC SA Management Protocol . . . . . . . . . . . . . . . . 10 62 5.1. Fibre Channel Name Identifier . . . . . . . . . . . . . . 10 63 5.2. ESP_Header and CT_AUthentication Protocol ID . . . . . . . 10 64 5.3. CT_Authentication Protocol Transform Identifiers . . . . . 11 65 5.4. Fibre Channel Traffic Selectors . . . . . . . . . . . . . 11 66 5.5. Negotiating Security Associations for FC and IP . . . . . 13 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 8.1. Informative References . . . . . . . . . . . . . . . . . . 16 71 8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . . . . 19 75 1. Requirements notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 Fibre Channel (FC) is a gigabit speed network technology primarily 84 used for Storage Networking. Fibre Channel is standardized in the 85 T11 [T11] Technical Committee of the InterNational Committee for 86 Information Technology Standards (INCITS), an American National 87 Standard Institute (ANSI) accredited standards committee. 89 FC-SP (Fibre Channel Security Protocols) is a working group of the 90 T11 Technical Committee that is developing the "Fibre Channel 91 Security Protocols" standard [FC-SP], a security architecture for 92 Fibre Channel networks. 94 The FC-SP standard defines a set of protocols for fibre channel 95 networks that provides: 97 1. device to device (hosts, disks, switches) authentication; 99 2. management and establishment of secrets and security 100 associations; 102 3. data origin authentication, integrity, anti-replay protection, 103 confidentiality; 105 4. security policies distribution. 107 Within this framework a fibre channel device can verify the identity 108 of another fibre channel device, establish a shared secret that will 109 be used to negotiate security associations for security protocols 110 applied to fibre channel frames and information unit. The same 111 framework allows for distributions within a fibre channel fabric of 112 policies that will be enforced by the fabric. 114 FC-SP is adapting the IKEv2 protocol [I-D.ietf-ipsec-ikev2-17] to 115 provide authentication of Fibre Channel entities and setup of 116 security associations. 118 3. Overview 120 Fibre Channel defines two security protocols that provide security 121 services for different portions of Fibre Channel traffic: ESP_Header 122 is defined in [FC-FS], while CT_Authentication is defined in [FC-GS]. 124 The ESP_Header protocol is a transform applied to FC-2 fibre channel 125 frames, and is based on the IP Encapsulation Security Payload 126 [RFC2406], to provide origin authentication, integrity, anti-replay 127 protection and optionally confidentiality to generic fibre channel 128 frames. The CT_Authentication protocol is a transform that provides 129 the same set of security services, but is applied to Common Transport 130 Information Units, a protocol used for control information. The 131 separation of Fibre Channel data traffic from control traffic results 132 in only one protocol (either ESP_Header or CT_Authentication) being 133 applicable to any FC Security Associaton. 135 Security associations for the ESP_Header and CT_Authentication 136 protocols between two fibre channel entities (hosts, disks, or 137 switches) are negotiated by the Fibre Channel Security Association 138 Management Protocol, a generic protocol based on IKEv2 [I-D.ietf- 139 ipsec-ikev2-17]. 141 Since IP is transported over Fibre Channel [RFC2625] and Fibre 142 Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is 143 the potential for confusion when IKEv2 is used for both IP and FC 144 traffic. This document specifies identifiers for IKEv2 over FC in a 145 fashion that ensures that any mistaken usage of IKEv2/FC over IP will 146 result in a negotiation failure due to absence of an acceptable 147 proposal (and likewise for IKEv2/IP over FC). This document gives an 148 overview of the security architecture defined by the FC-SP standard, 149 including the security protocols used to protect frames and to 150 negotiate SAs, and specifies the entities for which new identifiers 151 are to be assigned. 153 4. Fibre Channel Security Protocols 155 The Fibre Channel protocol is described in [FC-FS] as a network 156 architecture organized in 5 levels. The FC-2 level defines the FC 157 frame format (shown in Figure 1), the transport services, and control 158 functions required for information transfer. 160 +-----+-----------+-----------+--------//-------+-----+-----+ 161 | | | Data Field | | | 162 | SOF | FC Header |<--------------------------->| CRC | EOF | 163 | | | Optional | Frame | | | 164 | | | Header(s) | Payload | | | 165 +-----+-----------+-----------+--------//-------+-----+-----+ 167 Figure 1: Fibre Channel Frame Format 169 Fibre Channel Generic Services share a Common Transport (CT) at the 170 FC-4 level defined in [FC-GS]. The CT provides access to a Service 171 (e.g. Directory Service) with a set of service parameters that 172 facilitates the usage of Fibre Channel constructs. 174 A Common Transport IU (CT_IU) is the common Fibre Channel Sequence 175 used to transfer all information between a Client and a Server. The 176 first part of the CT_IU, shown in Figure 2, contains a preamble with 177 information common to all CT_IUs. An optional Extended CT_IU 178 Preamble carries the CT_Authentication protocol that provides 179 authentication and optionally confidentiality to CT_IUs. The CT_IU 180 is completed by an optional Vendor Specific Preambol, and by 181 additional information as defined by the preamble. 183 0 1 2 3 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 ~ Basic CT_IU Preamble ~ 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 ~ Extended CT_IU Preamble (optional) ~ 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 ~ Vendor Specific Preamble (optional) ~ 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | 199 ~ Additional Information ~ 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 2: CT_IU 205 Two security protocols are defined for Fibre Channel: the ESP_Header 206 protocol that protects the FC-2 level, and the CT_Authentication 207 protocol that protects the Common Transport at the FC-4 level. 209 Security Association for the ESP_Header and CT_Authentication 210 protocols are negotiated by the Fibre Channel Security Association 211 Management Protocol. 213 4.1. ESP_Header Protocol 215 ESP_header is a security protocol for FC-2 Fibre Channel frames that 216 provides origin authentication, integrity, anti-replay protection, 217 and confidentiality. ESP_Header is carried as the first optional 218 header in the FC-2 frame, and its presence is signaled by a flag in 219 the DF_CTL field of the FC-2 header. 221 Figure 3 shows the format of an FC-2 frame encapsulated with an 222 ESP_Header. The encapsulation format is equivalent to the IP 223 Encapsulating Security Payload [RFC2406], but the scope of the 224 authentication covers the entire FC-2 header. The Destination and 225 Source fibre channel addresses (D_ID and S_ID) and the CS_CTL/ 226 Priority field are normalized before computation of the Integrity 227 Check value to allow for address translation. 229 0 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 232 | R_CTL |////////////////D_ID///////////////////////////| ^ 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 234 |//CS_CTL/Pri.//|////////////////S_ID///////////////////////////| | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 236 | Type | F_CTL |Auth 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cov- 238 | SEQ_ID | DF_CTL | SEQ_CNT |era- 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ge 240 | OX_ID | RX_ID | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 242 | Parameter | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 244 | Security Parameters Index (SPI) | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 246 | Sequence Number | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- 248 | Payload Data (variable) | |^ 249 ~ ~ || 250 ~ ~Conf 251 | |Cov- 252 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+era- 253 | | Padding (0-255 bytes) |ge 254 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || 255 | | Pad Length | Reserved | vv 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---- 257 | Integrity Check Value (variable) | 258 ~ ~ 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 3: ESP_Header Encapsulation 264 All the security transforms that are defined for the IP Encapsulating 265 Security Payload, such as AES-CBC [RFC3602], can be applied to the 266 ESP_Header protocol. 268 4.2. CT_Authentication Protocol 270 CT_Authentication is a security protocol for Common Transport FC-4 271 Information Units that provides origin authentication, integrity, 272 anti-replay protection. The CT_Authentication protocol is carried in 273 the optional extended CT_IU preamble 275 The extended CT_IU preamble, shown in Figure 4, includes an 276 Authentication Security Association Identifier (SAID), a transaction 277 ID, the N_port name of the requesting node, a Time Stamp used to 278 prevent replay attacks, and an Authentication Hash Block. 280 The scope of the Authentication Hash Block Covers all data words of 281 the CT_IU, with the exception of the frame_header, the IN_ID field in 282 the basic CT_IU preamble, the Authentication Hash Block itself, and 283 the frame CRC field. 285 0 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Authentication SAID | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Transaction_id | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 + Requesting_CT N_Port Name + 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 + Time Stamp + 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 ~ Authentication Hash Block ~ 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 4: Extended CT_IU Preamble 307 The Authentication Hash Block is computed as an HMAC keyed hashing, 308 as defined in [RFC2104], of the CT_IU. The entire output of the HMAC 309 computation is included in the Authentication Hash Block, without any 310 truncation. Two transforms are defined: HMAC-SHA1-160 based on the 311 cryptographic hash function SHA1[NIST.180-1.1995], and HMAC-MD5-128 312 based on the cryptographic hash function MD5 [RFC1321]. 314 5. The FC SA Management Protocol 316 Fibre Channel entities negotiate security associations for the 317 protocols described above using the Fibre Channel Security 318 Association Management protocol, as defined in [FC-SP]. The protocol 319 is a modified subset of the IKEv2 protocol [I-D.ietf-ipsec-ikev2-17] 320 that performs the same core operations, and uses the Fibre Channel 321 AUTH protocol to transport IKEv2 messages. 323 The protocol supports only the basic features of IKEv2: initial 324 exchange to create an IKE SA and the first child SA, the 325 CREATE_CHILD_SA exchange to negotiate additional SAs, and the 326 INFORMATIONAL exchange including notification, delete and vendor ID 327 payloads. IKEv2 features that are not supported for Fibre Channels 328 include: negotiation of multiple protocols within the same proposal, 329 capability to handle multiple outstanding requests, cookies, 330 configuration payload, and the Extended Authentication Protocol (EAP) 331 payload. 333 The following subsections describe the additional IANA assigned 334 values required by the Fibre Channel Security Association Management 335 protocol, as defined in [FC-SP]. All the values are to be allocated 336 from the new registries created for the IKEv2 protocol [I-D.ietf- 337 ipsec-ikev2-17]. 339 5.1. Fibre Channel Name Identifier 341 Fibre Channels entities that negotiate security associations are 342 identified by an 8-byte Name. Support for this name format has been 343 added to the IKEv2 Identification Payload, introducing a new ID type 344 beyond the ones already defined in section 3.5 of [I-D.ietf-ipsec- 345 ikev2-17]. This ID Type MUST be supported by any implementation of 346 the Fibre Channel Security Association Management Protocol. 348 The FC_Name_Identifier is then defined as a single eight (8) octets 349 Fibre Channel Name: 351 ID Type value 352 ------- ----- 353 ID_FC_NAME To be assigned by IANA 355 5.2. ESP_Header and CT_AUthentication Protocol ID 357 Security protocols negotiated by IKEv2 are identified by the Protocol 358 ID field contained in the proposal substructure of a Security 359 Association Payload, as defined in section 3.3.1 of [I-D.ietf-ipsec- 360 ikev2-17]. 362 The following protocol ID have been defined to identify the Fibre 363 Channel ESP_Header and the CT_Authentication security protocols: 365 Protocol ID value 366 ----------- ----- 367 FC_ESP_HEADER To be assigned by IANA 369 FC_CT_AUTHENTICATION To be assigned by IANA 371 The existing IKEv2 value for ESP (3) is deliberately not reused to 372 avoid any possibility of confusion between IKEv2 proposals for IP 373 security associations and IKEv2 proposals for FC security 374 associations. 376 The number and type of transforms that accompany an SA payload are 377 dependent on the protocol in the SA itself. An SA payload proposing 378 the establishment of a Fibre Channel SA has the following mandatory 379 and optional transform types. 381 Protocol Mandatory Types Optional Types 382 -------- --------------- -------------- 383 FC_ESP_HEADER Encryption Integrity, DH Groups 385 FC_CT_AUTHENTICATION Integrity Encryption, DH Groups 387 5.3. CT_Authentication Protocol Transform Identifiers 389 The CT_Authentication transform ID defined for Transform Type 3 390 (Integrity Algorithm), are: 392 Name Number Defined in 393 ---- ------ ---------- 394 AUTH_HMAC_MD5_128 To be assigned by IANA FC-SP 396 AUTH_HMAC_SHA1_160 To be assigned by IANA FC-SP 398 These transforms differ from the corresponding _96 transforms used in 399 IPsec solely in the omission of the truncation of the HMAC output to 400 96 bits; instead the entire output (128 bits for MD5, 160 bits for 401 SHA-1) is transmitted. MD5 support is required due to existing usage 402 of MD5 in CT_Authentication; SHA-1 is RECOMMENDED in all new 403 implementations. 405 5.4. Fibre Channel Traffic Selectors 407 Fibre Channel Traffic Selectors allow peers to identify packet flows 408 for processing by Fibre Channel security services. A new Traffic 409 Selector Type has been added to the IKEv2 Traffic Selector Types 410 Registry defined in section 3.13.1 of [I-D.ietf-ipsec-ikev2-17]. 411 This Traffic Selector Type MUST be supported by any implementation of 412 the Fibre Channel Security Association Management Protocol. 414 Fibre Channel traffic selectors are defined in [FC-SP] as a list of 415 FC address and protocol ranges, as shown in Figure 9. 417 0 1 2 3 418 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | TS TYPE | Reserved | Selector Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Reserved | Starting Address | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Reserved | Ending Address | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Starting R_CTL| Ending R_CTL | Starting Type | Ending Type | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 9: Fibre Channel Traffic Selector 431 The following table lists the assigned value for the Fibre Channel 432 Traffic Selector Type field: 434 TS Type value 435 ------- ----- 436 TS_FC_ADDR_RANGE To be assigned by IANA 438 The Starting and Ending Address fields are 24 bit addresses assigned 439 to Fibre Channel names as part of initializing Fibre Channel 440 communications (e.g., for a switched Fibre Channel Fabric, end nodes 441 aquire these identifiers from Fabric Login, FLOGI). 443 The Starting and Ending R_CTL fields are the 8-bit Routing Control 444 identifiers that define the category and in some cases he function of 445 the FC frame; see [FC-FS] for details. 447 The separation of Fibre Channel data traffic from control traffic 448 results in only one protocol (either ESP_Header or CT_Authentication) 449 being applicable to any FC Security Associaton. When the Fibre 450 Channel Traffic Selector is defined for the ESP_Header protocol, the 451 Starting Type and Ending Type fields identify the range of FC-2 452 protocols to be selected. When the Fibre Channel Traffic Selector is 453 defined for the CT_Authentication protocol, the FC-2 Type is 454 implicitly set to the value '20h' that idenitifies CT_Authentication 455 information units, and the Starting Type and Ending Type fields 456 identify the range of Generic Service subtypes (GS_Subtype) to be 457 selected. See [FC-FS] and [FC-GS] for details. 459 5.5. Negotiating Security Associations for FC and IP 461 The ESP_header and CT_Authentication protocols are Fibre-Channel- 462 specific security protocols that applies to Fibre Channel frames 463 only. The values identifying security protocols, transforms, 464 selectors and name types defined in this document MUST NOT be used 465 during IKEv2 negotiation for IPsec protocols. 467 6. Security Considerations 469 The security considerations in IKEv2 [I-D.ietf-ipsec-ikev2-17] apply 470 with the exception of those related to NAT traversal, EAP, and IP 471 fragmentation. NAT traversal and EAP, in fact, are not supported by 472 the Fibre Channel Security Association Management Protocol (based on 473 IKEv2), and IP fragmentation cannot occur because IP is not used to 474 carry the Fibre Channel Security Association Management Protocol 475 messages. 477 Fibre Channel Security Association Management Protocol messages are 478 mapped over Fibre Channel Sequences. A Sequence is able to carry up 479 to 4 GB of data, then there are no theoretical limitations to the 480 size of IKEv2 messages. However, some Fibre Channel end point 481 implementations have limited sequencing capabilities for the 482 particular frames used to map IKEv2 messages over Fibre Channel. To 483 address these limitations the Fibre Channel Security Association 484 Management Protocol supports fragmentation of IKEv2 messages (see 485 section 5.9 of [FC-SP]). In those cases where the IKEv2 messages are 486 long enough to trigger fragmentation it is possible that attackers 487 could prevent the IKEv2 exchange from completing by exhausting the 488 reassembly buffers. The chances of this can be minimized by using 489 the Hash and URL encodings instead of sending certificates (see 490 section 3.6 of [I-D.ietf-ipsec-ikev2-17]). 492 7. IANA Considerations 494 The standards action of this document establishes the following 495 values to be allocated by IANAin the registries created for the 496 [I-D.ietf-ipsec-ikev2-17]. 498 Allocate the following value for the IKEv2 Identification Payload ID 499 Types Registry (section 3.5 of [I-D.ietf-ipsec-ikev2-17]): 501 ID Type value 502 ------- ----- 503 ID_FC_NAME To be assigned by IANA 505 Allocate the following values for the IKEv2 Security Protocol 506 Identifiers Registry (section 3.3.1 of [I-D.ietf-ipsec-ikev2-17]): 508 Protocol ID value 509 ----------- ----- 510 FC_ESP_HEADER To be assigned by IANA 512 FC_CT_AUTHENTICATION To be assigned by IANA 514 Allocate the following values for Transform Type 3 (Integrity 515 Algorithm) for the IKEv2 Integrity Algorithm Transform IDs Registry 516 (section 3.3.2 of [I-D.ietf-ipsec-ikev2-17]): 518 Name Number 519 ---- ------ 520 AUTH_HMAC_MD5_128 To be assigned by IANA 522 AUTH_HMAC_SHA1_160 To be assigned by IANA 524 Allocate the following value for the IKEv2 Traffic Selector Types 525 Registry (section 3.13.1 of [I-D.ietf-ipsec-ikev2-17]): 527 TS Type value 528 ------- ----- 529 TS_FC_ADDR_RANGE To be assigned by IANA 531 8. References 533 8.1. Informative References 535 [FC-FS] INCITS Technical Commitee T11, "ANSI INCITS 373-2003, "Fibre 536 Channel - Framing and Signaling (FC-FS)". 538 [FC-GS] INCITS Technical Commitee T11, "ANSI INCITS xxx-200x, "Fibre 539 Channel - Generic Services (FC-GS)". 541 [FC-SP] INCITS Technical Commitee T11, "ANSI INCITS xxx-200x, "Fibre 542 Channel - Security Protocols (FC-SP)". 544 [T11] INCITS Technical Commitee T11, "Home Page of the INCITS 545 Technical Commitee T11". 547 8.2. References 549 [I-D.ietf-ipsec-ikev2-17] 550 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 551 draft-ietf-ipsec-ikev2-17 (work in progress), 552 September 2004. 554 [NIST.180-1.1995] 555 National Institute of Standards and Technology, "Secure 556 Hash Standard", NIST 180-1, April 1995. 558 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 559 April 1992. 561 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 562 Hashing for Message Authentication", RFC 2104, 563 February 1997. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 569 Payload (ESP)", RFC 2406, November 1998. 571 [RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP 572 over Fibre Channel", RFC 2625, June 1999. 574 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 575 Algorithm and Its Use with IPsec", RFC 3602, 576 September 2003. 578 [RFC3643] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., 579 Monia, C., and M. Merhar, "Fibre Channel (FC) Frame 580 Encapsulation", RFC 3643, December 2003. 582 [RFC3821] Rajagopal, M., E. Rodriguez, E., and R. Weber, "Fibre 583 Channel Over TCP/IP (FCIP)", RFC 3602, July 2004. 585 Authors' Addresses 587 Fabio Maino 588 Cisco Systems 589 375 East Tasman Drive 590 San Jose, CA 95134 591 US 593 Phone: +1 408 853 7530 594 Email: fmaino@cisco.com 595 URI: http://www.cisco.com/ 597 David Black 598 EMC Corporation 599 176 South Street 600 Hopkinton, MA 01748 601 US 603 Phone: +1 508 293-7953 604 Email: black_david@emc.com 605 URI: http://www.emc.com/ 607 Intellectual Property Statement 609 The IETF takes no position regarding the validity or scope of any 610 Intellectual Property Rights or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; nor does it represent that it has 614 made any independent effort to identify any such rights. Information 615 on the procedures with respect to rights in RFC documents can be 616 found in BCP 78 and BCP 79. 618 Copies of IPR disclosures made to the IETF Secretariat and any 619 assurances of licenses to be made available, or the result of an 620 attempt made to obtain a general license or permission for the use of 621 such proprietary rights by implementers or users of this 622 specification can be obtained from the IETF on-line IPR repository at 623 http://www.ietf.org/ipr. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights that may cover technology that may be required to implement 628 this standard. Please address the information to the IETF at 629 ietf-ipr@ietf.org. 631 Disclaimer of Validity 633 This document and the information contained herein are provided on an 634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 636 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 637 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 638 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 641 Copyright Statement 643 Copyright (C) The Internet Society (2005). This document is subject 644 to the rights, licenses and restrictions contained in BCP 78, and 645 except as set forth therein, the authors retain all their rights. 647 Acknowledgment 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.