RFC 4595
Use of IKEv2 in the Fibre Channel Security Association Management Protocol
RFC 4595: Use of IKEv2 in the Fibre Channel Security Association Management Protocol 🎀
Okay bestie, this one is RFC 4595 💖 It came out in July 2006 and it's written by F. Maino (Cisco Systems) and D. Black (EMC Corporation). It's Informational, which means it shares info with the Internet community and doesn't set an Internet standard 🫶 The title block doesn't list any RFC it obsoletes or updates, so it's just doing its own thing ✨
Network Working Group, Request for Comments: 4595
Status of This Memo 📜
Quick legal-ish bit: this memo is here to give the Internet community information. It is not a standard of any kind 🙈 And distribution is unlimited, so share it with whoever you want 💅
Copyright Notice 🌸
Copyright (C) The Internet Society (2006).
Abstract 🦋
Okay so this doc explains how to use IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. The catch is that IKEv2 needs to be extended with Fibre-Channel-specific security protocols, transforms, and name types, and this document is the one that specifies those extensions and hands out the identifiers for them 🎀 Using new IKEv2 identifiers for Fibre Channel security protocols means IP networks and Fibre Channel can't get mixed up when they both use IKEv2. It's giving clean separation 🔥
Table of Contents 📑
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
2. Overview ........................................................4
3. Fibre Channel Security Protocols ................................5
3.1. ESP_Header Protocol ........................................6
3.2. CT_Authentication Protocol .................................7
4. The FC SA Management Protocol ...................................9
4.1. Fibre Channel Name Identifier ..............................9
4.2. ESP_Header and CT_Authentication Protocol ID ...............9
4.3. CT_Authentication Protocol Transform Identifiers ..........10
4.4. Fibre Channel Traffic Selectors ...........................10
4.5. Negotiating Security Associations for FC and IP ...........12
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................141. Introduction ✨
So Fibre Channel (FC) is a gigabit-speed network technology that's mostly used for Storage Networking 💾 It's standardized by the T11 [T11] Technical Committee of the InterNational Committee for Information Technology Standards (INCITS), which is an American National Standard Institute (ANSI) accredited standards committee. Very official, very serious 🧚
Then there's FC-SP (Fibre Channel Security Protocols), a T11 Technical Committee working group. They wrote the "Fibre Channel Security Protocols" standard [FC-SP], which is a security architecture for Fibre Channel networks 🔐
The FC-SP standard defines a set of protocols for Fibre Channel networks, and they give you:
- device-to-device (hosts, disks, switches) authentication;
- management and establishment of secrets and security associations;
- data origin authentication, integrity, anti-replay protection, confidentiality; and
- security policies distribution.
Within this framework, a Fibre Channel device can verify who another Fibre Channel device is, and then set up a shared secret. That shared secret gets used to negotiate security associations for the security protocols that apply to Fibre Channel frames and information units. The same framework also lets a fabric distribute policies within itself, and the fabric enforces them 👑
FC-SP adapted the IKEv2 protocol [RFC4306] to handle authentication of Fibre Channel entities and the setup of security associations. IKEv2 is the main character here 💅
1.1. Requirements Notation 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Overview 🌈
Fibre Channel has two security protocols that cover different parts of Fibre Channel traffic: the ESP_Header, defined in [FC-FS], and CT_Authentication, defined in [FC-GS-4] 🦋
The ESP_Header protocol is a transform applied to FC-2 Fibre Channel frames. It's based on the IP Encapsulation Security Payload [RFC4303], and it gives generic Fibre Channel frames origin authentication, integrity, anti-replay protection, and optional confidentiality. CT_Authentication is a transform that gives the same set of security services, but for Common Transport Information Units, which carry control information. Fibre Channel splits data traffic from control traffic, so only one of these protocols (either ESP_Header or CT_Authentication) applies to any FC Security Association (SA). Bestie, that split is what keeps things tidy 🎀
Security associations for the ESP_Header and CT_Authentication protocols between two Fibre Channel entities (hosts, disks, or switches) are negotiated by the Fibre Channel Security Association Management Protocol. It's a generic protocol based on IKEv2 [RFC4306] 🫶
Here's the tea ☕ IP gets carried over Fibre Channel [RFC4338], and Fibre Channel/SCSI gets carried over IP [RFC3643], [RFC3821]. So when IKEv2 is used for both IP and FC traffic, things can get confusing. This document specifies identifiers for IKEv2 over FC in a way that makes sure any mix-up of IKEv2/FC over IP ends in a negotiation failure, because there's no acceptable proposal. The same goes for IKEv2/IP over FC. This document also gives an overview of the security architecture defined by the FC-SP standard, including the security protocols used to protect frames and negotiate SAs, and it names the entities that got new identifiers 🔥
3. Fibre Channel Security Protocols 🔐
The Fibre Channel protocol is described in [FC-FS] as a network architecture organized in 5 levels. The FC-2 level defines the FC frame format (shown in Figure 1), plus the transport services and control functions needed for information transfer 💖
+-----+-----------+-----------+--------//-------+-----+-----+
| | | Data Field | | |
| SOF | FC Header |<--------------------------->| CRC | EOF |
| | | Optional | Frame | | |
| | | Header(s) | Payload | | |
+-----+-----------+-----------+--------//-------+-----+-----+
Figure 1: Fibre Channel Frame FormatFibre Channel Generic Services share a Common Transport (CT) at the FC-4 level, which is defined in [FC-GS-4]. The CT gives you access to a Service (for example, Directory Service) with a set of service parameters that makes Fibre Channel constructs easier to use 🧚
A Common Transport Information Unit (CT_IU) is the common Fibre Channel Sequence used to move all information between a Client and a Server. The first part of the CT_IU, shown in Figure 2, has a preamble with info that every CT_IU shares. An optional Extended CT_IU Preamble carries the CT_Authentication protocol, which gives CT_IUs authentication and, optionally, confidentiality 🦋 The CT_IU is finished off by an optional Vendor-Specific Preamble and by any extra information the preamble defines.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Basic CT_IU Preamble ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extended CT_IU Preamble (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Vendor Specific Preamble (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional Information ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CT_IUTwo security protocols are defined for Fibre Channel: the ESP_Header protocol, which protects the FC-2 level, and the CT_Authentication protocol, which protects the Common Transport at the FC-4 level 🎀
Security Associations for the ESP_Header and CT_Authentication protocols are negotiated by the Fibre Channel Security Association Management Protocol. That's the whole vibe of this section, bestie 💜
part 1 of 3 💖 part 2 is coming next, don't leave me on read 🙈
3.1. ESP_Header Protocol ✨
Okay so ESP_Header is a security protocol for FC-2 Fibre Channel frames, and it's giving origin authentication, integrity, anti-replay protection, AND confidentiality 🔐💖. It sits as the first optional header in the FC-2 frame, and you can tell it's there because of a flag in the DF_CTL field of the FC-2 header 🦋.
Figure 3 shows what an FC-2 frame looks like once it's wrapped with an ESP_Header 🎀. The encapsulation is basically the same as the IP Encapsulating Security Payload [RFC4303], but the authentication covers the entire FC-2 header, which is so thorough 😭. The Destination and Source Fibre Channel addresses (D_ID and S_ID) and the CS_CTL/Priority field get normalized before the Integrity Check value is computed, so address translation still works 🌸.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| R_CTL |////////////////D_ID///////////////////////////| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|//CS_CTL/Pri.//|////////////////S_ID///////////////////////////| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type | F_CTL |Auth
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cov-
| SEQ_ID | DF_CTL | SEQ_CNT |era-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ge
| OX_ID | RX_ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Parameter | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Security Parameters Index (SPI) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |--
| Payload Data (variable) | |^
~ ~ ||
~ ~Conf
| |Cov-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+era-
| | Padding (0-255 bytes) |ge
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| | Pad Length | Reserved | vv
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----
| Integrity Check Value (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ESP_Header EncapsulationEvery security transform defined for the IP Encapsulating Security Payload, like AES-CBC [RFC3602], can be used with the ESP_Header protocol 🔥.
3.2. CT_Authentication Protocol 💜
CT_Authentication is a security protocol for Common Transport FC-4 Information Units that gives you origin authentication, integrity, and anti-replay protection 🫶. It rides along in the optional extended CT_IU preamble. The extended CT_IU preamble, shown in Figure 4, has an Authentication Security Association Identifier (SAID), a transaction ID, the N_port name of the requesting node, a Time Stamp used to prevent replay attacks, and an Authentication Hash Block 🧚.
The Authentication Hash Block covers all data words of the CT_IU, except for the frame_header, the IN_ID field in the basic CT_IU preamble, the Authentication Hash Block itself, and the frame CRC field 👑.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Requesting_CT N_Port Name +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Stamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Hash Block ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Extended CT_IU PreambleThe Authentication Hash Block is computed as an HMAC keyed hash of the CT_IU, as defined in [RFC2104] 🌈. The whole HMAC output goes into the Authentication Hash Block, with no truncation at all 💅. There are two transforms: HMAC-SHA1-160, which is based on the SHA1 hash function [NIST.180-1.1995], and HMAC-MD5-128, which is based on the MD5 hash function [RFC1321] ✨.
4. The FC SA Management Protocol 🦋
Fibre Channel entities negotiate security associations for the protocols above using the Fibre Channel Security Association Management protocol, as defined in [FC-SP] 💖. It's a modified subset of the IKEv2 protocol [RFC4306] that does the same core operations, and it uses the Fibre Channel AUTH protocol to carry IKEv2 messages 🎀.
The protocol only supports the basic IKEv2 features: the initial exchange that creates an IKE SA and the first child SA, the CREATE_CHILD_SA exchange for negotiating extra SAs, and the INFORMATIONAL exchange, which includes notification, delete, and vendor ID payloads 🔥. The IKEv2 features NOT supported for Fibre Channels are: negotiating multiple protocols within the same proposal, handling multiple outstanding requests at once, cookies, configuration payload, and the Extended Authentication Protocol (EAP) payload 💀.
The following subsections describe the additional IANA assigned values that the Fibre Channel Security Association Management protocol needs, as defined in [FC-SP] 🌸. All of these values were allocated from the new registries created for the IKEv2 protocol [RFC4306] 🧚.
4.1. Fibre Channel Name Identifier 🍓
Fibre Channel entities that negotiate security associations are identified by an 8-byte Name. Support for this name format was added to the IKEv2 Identification Payload, introducing a new ID type on top of the ones already defined in Section 3.5 of [RFC4306] 🙈. This ID Type MUST be supported by any implementation of the Fibre Channel Security Association Management Protocol 😭.
The FC_Name_Identifier is then defined as a single 8-octet Fibre Channel Name:
ID Type Value
------- -----
ID_FC_NAME 124.2. ESP_Header and CT_Authentication Protocol ID 🔮
Security protocols negotiated by IKEv2 are identified by the Protocol ID field in the proposal substructure of a Security Association Payload, as defined in Section 3.3.1 of [RFC4306] 🫶.
The following protocol IDs were defined to identify the Fibre Channel ESP_Header and CT_Authentication security protocols 🌈:
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
FC_CT_AUTHENTICATION 5The existing IKEv2 value for ESP (3) is deliberately NOT reused, so there's zero chance of mixing up IKEv2 proposals for IP security associations with IKEv2 proposals for FC security associations 👑.
The number and type of transforms that come with an SA payload depend on the protocol in the SA itself. An SA payload proposing a Fibre Channel SA has the following mandatory and optional transform types 💅:
Protocol Mandatory Types Optional Types
-------- --------------- --------------
FC_ESP_HEADER Integrity Encryption, DH Groups
FC_CT_AUTHENTICATION Integrity Encryption, DH Groups4.3. CT_Authentication Protocol Transform Identifiers ✨
The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are 🦋:
Name Number Defined in
---- ------ ----------
AUTH_HMAC_MD5_128 6 FC-SP
AUTH_HMAC_SHA1_160 7 FC-SPThese transforms differ from the matching _96 transforms used in IPsec only in that the HMAC output is NOT truncated to 96 bits. Instead, the whole output gets sent (128 bits for MD5, 160 bits for SHA-1) 💖. MD5 support is required because MD5 is already in use with CT_Authentication, and SHA-1 is RECOMMENDED in all new implementations 🔥.
4.4. Fibre Channel Traffic Selectors 🦋
okay so traffic selectors are how peers figure out which packet flows get handled by the Fibre Channel security services 👀 bestie, this section adds a brand new Traffic Selector Type to the IKEv2 Traffic Selector Types Registry, which lives in Section 3.13.1 of [RFC4306]. Any implementation of the Fibre Channel Security Association Management Protocol MUST support this Traffic Selector Type 🫶
The FC traffic selectors themselves are defined in [FC-SP] as a list of FC address and protocol ranges. Here's the layout, as shown in Figure 5 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS TYPE | Reserved | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Starting Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Ending Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting R_CTL| Ending R_CTL | Starting Type | Ending Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Fibre Channel Traffic SelectorThe table below lists the value assigned to the Fibre Channel Traffic Selector Type field ✨
TS Type Value
------- -----
TS_FC_ADDR_RANGE 9The Starting and Ending Address fields are 24-bit addresses that get assigned to Fibre Channel names when Fibre Channel communications are being set up 🌸 For example, in a switched Fibre Channel Fabric, end nodes grab these identifiers from Fabric Login (FLOGI).
The Starting and Ending R_CTL fields are 8-bit Routing Control identifiers. They tell you the category of the FC frame and, in some cases, its function. Check out [FC-FS] for the full scoop 📚
Here's the big idea: Fibre Channel data traffic is kept separate from control traffic, so only one protocol (either ESP_Header or CT_Authentication) can apply to any FC Security Association. 🧚 When the Fibre Channel Traffic Selector is for ESP_Header, the Starting Type and Ending Type fields pick out a range of FC-2 protocols. When it's for CT_Authentication, the FC-2 Type is implicitly set to '20h' (which marks CT_Authentication information units), and the Starting Type and Ending Type fields pick out a range of Generic Service subtypes (GS_Subtype). For more details, see [FC-FS] and [FC-GS-4] 💖
4.5. Negotiating Security Associations for FC and IP 🌈
Real talk: ESP_header and CT_Authentication are Fibre-Channel-specific security protocols, and they only apply to Fibre Channel frames 🙅♀️ So the protocol, transform, selector, and name type values defined in this document MUST NOT be used during IKEv2 negotiation for IPsec protocols. Keep the FC stuff in its lane, periodt 💅
5. Security Considerations 💀
This one is serious, bestie, so pay attention 🔥 The security considerations in IKEv2 [RFC4306] apply here, except for the ones about NAT traversal, EAP, and IP fragmentation. NAT traversal and EAP aren't supported by the Fibre Channel Security Association Management Protocol (which is built on IKEv2). And IP fragmentation can't happen, because IP isn't used to carry the Fibre Channel Security Association Management Protocol messages.
Fibre Channel Security Association Management Protocol messages get mapped over Fibre Channel Sequences. A Sequence can carry up to 4 GB of data, and there are no theoretical limits on how big IKEv2 messages can be. BUT some Fibre Channel endpoint implementations have limited sequencing capabilities for the particular frames used to map IKEv2 messages over Fibre Channel 😭 To deal with that, the protocol supports fragmentation of IKEv2 messages (see Section 5.9 of [FC-SP]).
Now the scary part: if the IKEv2 messages are long enough to trigger fragmentation, an attacker could stop the IKEv2 exchange from ever finishing by exhausting the reassembly buffers 💀 You can lower the chances of this by using the Hash and URL encodings instead of sending certificates (see Section 3.6 of [RFC4306]). Protect your buffers, queen 👑
6. IANA Considerations 🍓
The standards action in this document sets up the following values, which IANA allocates in the registries created for IKEv2 [RFC4306].
Here's what gets allocated for the IKEv2 Identification Payload ID Types Registry (Section 3.5 of [RFC4306]) ✨
ID Type Value
------- -----
ID_FC_NAME 12Next, the IKEv2 Security Protocol Identifiers Registry (Section 3.3.1 of [RFC4306]) gets these two values 🧚
Protocol ID Value
----------- -----
FC_ESP_HEADER 4
FC_CT_AUTHENTICATION 5For Transform Type 3 (Integrity Algorithm), in the IKEv2 Integrity Algorithm Transform IDs Registry (Section 3.3.2 of [RFC4306]), these values are allocated 💜
Name Number
---- ------
AUTH_HMAC_MD5_128 6
AUTH_HMAC_SHA1_160 7And last but not least, the IKEv2 Traffic Selector Types Registry (Section 3.13.1 of [RFC4306]) gets this value 🦋
TS Type Value
------- -----
TS_FC_ADDR_RANGE 97. References 📚
7.1. Normative References
These are the must-reads, the references this document depends on to work 🤓
[NIST.180-1.1995]
National Institute of Standards and Technology, "Secure
Hash Standard", NIST 180-1, April 1995.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC3643] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M.,
Monia, C., and M. Merhar, "Fibre Channel (FC) Frame
Encapsulation", RFC 3643, December 2003.
[RFC3821] Rajagopal, M., E. Rodriguez, E., and R. Weber, "Fibre
Channel Over TCP/IP (FCIP)", RFC 3602, July 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of
IPv6, IPv4, and Address Resolution Protocol (ARP) Packets
over Fibre Channel", RFC 4338, January 2006.7.2. Informative References
These ones are good to know, but you don't need them to get the core idea 💫
[FC-FS] INCITS Technical Committee T11, ANSI INCITS 373-2003,
"Fibre Channel - Framing and Signaling (FC-FS)".
[FC-GS-4] INCITS Technical Committee T11, ANSI INCITS 387-2004,
"Fibre Channel - Generic Services 4 (FC-GS-4)".
[FC-SP] INCITS Technical Committee T11, ANSI INCITS xxx-200x,
"Fibre Channel - Security Protocols (FC-SP)".
[T11] INCITS Technical Commitee T11, "Home Page of the INCITS
Technical Committee T11", <http://www.t11.org>.Authors' Addresses 🎀
These are the two people who wrote it, with their contact details 💌
Fabio Maino
Cisco Systems
375 East Tasman Drive
San Jose, CA 95134
US
Phone: +1 408 853 7530
EMail: fmaino@cisco.com
URI: http://www.cisco.com/
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
US
Phone: +1 508 293-7953
EMail: black_david@emc.com
URI: http://www.emc.com/Full Copyright Statement ©
The copyright belongs to The Internet Society (2006) 📜 This document is subject to the rights, licenses and restrictions in BCP 78. Except where BCP 78 says otherwise, the authors keep all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that someone might claim for the technology in this document are valid or in scope. It also doesn't say whether licenses for those rights are available, and it hasn't independently checked for any such rights. For the rules on rights in RFC documents, look at BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, are available from the IETF online IPR repository at http://www.ietf.org/ipr. That's also where you can find the result of any attempt to get a general license or permission for implementers or users of this specification to use the proprietary rights.
The IETF invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them. Send that info to ietf-ipr@ietf.org 💖
Acknowledgement 🌸
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶
📦 where this page comes from
- ietf: rfc4595 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms