FCIP Security

FCIP does not natively support any IP-based security mechanisms. FCIP relies upon IPsec for all IP-based security services. Additional FCIP security can be achieved by masking the existence of FCIP devices during the discovery process. Because FCIP does not support discovery via iSNS, only SLP Scopes can be leveraged for this purpose. However, this form of security is based on a merit system; no enforcement mechanisms are available to prevent direct discovery via probing.

Following FCIP link establishment, the FC virtual inter-switch link (VISL) may be secured by FC-SP procedures. For example, after an FCIP link is established, the peer FC switches may be authenticated via FC-SP procedures during E_Port (VISL) initialization. If authentication fails, no SCSI data can transit the FCIP link even though an active TCP connection exists. One limitation of this approach is the inability to authenticate additional TCP connections that are added to an existing FCIP link. From the perspective of the FC fabric, the additional TCP connections are transparent. Therefore, FC-SP procedures cannot be used to validate additional TCP connections. For this reason, the ANSI T11 FC-BB specification series defines the Authenticate Special Frame (ASF) Switch Internal Link Service (SW_ILS). The ASF is used to authenticate additional TCP connections before they are added to an existing FCIP link. When a new TCP connection is requested for an existing FCIP link, the receiving FCIP Entity passes certain information about the connection request to the FC Entity. The FC Entity uses that information to send an ASF to the claimed requestor. The claimed requestor validates the ASF with a Switch Accept (SW_ACC) SW_ILS if the TCP connection request is valid. Until the ASF transmitter receives an SW_ACC, SCSI data may not traverse the new TCP connection. Readers are encouraged to consult IETF RFC 3723 for background information related to FCIP security.