FCIP: Short Frame Security Solution Proposal

[Ralph Weber <ralphoweber@compuserve.com>]

This message proposes a solution to the security
issues surrounding the FCIP Short Frame proposed as
a solution to the NAPTs problem.  The security
issues and directions toward a solution were
discussed in Salt Lake and this message is an
attempt to follow the path charted in those
discussions.

Solution Assumptions

A) This matters a lot less if IPsec authentication 
is in use and rigorously managed because IPsec solves
this authenticates TCP connections, substantially
reducing the opportunity for rogue end-points to
make TCP connections to FC/FCIP devices.

B) Securing the first TCP connection in an FCIP Link
is handled outside the scope of this solution. In Fibre
Channel, securing the first TCP connection may be 
accomplished using FCAP. At this time, it is not clear 
whether FCAP authentication of the TCP connection 
needs to be mandatory or recommended for configurations
exposed to security risks.

C) Once authenticated, the first TCP connection is
allowed to carry F Class frames.

D) The objective of this solution is to authenticate
the second to n-th TCP connections using a protocol
that has lower overhead than FCAP or IPsec.

Solution Changes in FCIP

The principle change in FCIP is to REQUIRE the FCIP
Entity to interact with the FC Entity to authenticate
the second through n-th TCP connections for a given
Link End Point (LEP).

Upon receipt of an n-th TCP connect request and Short
Frame (SF), the FCIP Entity MUST request (from the FC
Entity) confirmation that the TCP connect request is 
from the same FC/FCIP Entity as the first TCP connection.
The FCIP Entity MUST delay return of the SF until the FC 
Entity provides the confirmation.

In addition, a new 64-bit nonce field is needed in
the SF. Theoretically, the nonce field could overlay
the Destination FC Fabric Entity WWN field. However,
the current leaning is to add a new field, lengthening 
the FCIP Short Frame to the point where it will have 
to be called the FCIP Special Frame.

The FCIP Entity shall communicate the newly defined
SF nonce plus other SF information to the FC Entity
in the interaction required to confirm the second
through n-th TCP connect requests.

Solution Changes in FC-BB-2

The principle changes in FC-BB-2 are:

  a) Discussion of how the FC Entity may respond
     to an FCIP Entity request for authentication
     of a second through n-th TCP connect request;
  b) Definition of a new SW_ILS to be used in
     confirming the second through n-th TCP
     connect requests; and
  c) Description of how the new SW_ILS is exchanged
     between the FC Entity where the TCP connect 
     request is received an authenticated FC Entity 
     over an existing F Class enabled TCP Connection.

N.B. It is important that this negotiation be placed
in the FC Entity because the Fibre Channel elements
at each end of a link have in place protocol mechanisms
for negotiations and exchanges of this type.

Solution Mechanics

When an FC/FCIP Entity makes a TCP connect request
for what it knows to be the second to n-th TCP
connection in an FCIP Link, it places a randomly
generated 64-bit nonce in the SF. (Note: There needs
to be requirements on the nonce generation method to
ensure that predicting nonce values is sufficiently
difficult. The ULP Framing draft has been recommended
as a source for these requirements.)

When an FCIP Entity receives a second to n-th
TCP connect request, it will delay returning the
SF until the SF nonce and other SF information is
authenticated by the FC Entity. If the FC Entity
reports that authentication failed, the FCIP
Entity SHALL close the TCP connection.

Details of the mechanism by which the FC Entity
authenticates a second to n-th TCP Connect request
are to be specified by T11 in FC-BB-2 (along with
numerous other Fibre Channel protocol issues
related to FCIP).

A proposal containing at least the following
will be made.

The FC Entity may authenticate the TCP Connect request 
based on configuration information that is outside the 
scope of the standards. In situations where security
risks are possible, the FC Entity shall transmit
the information provided by the FCIP Entity via a new 
SW_ILS on a previously authenticated TCP connection
(FCIP Data Engine) enabled for Class F frames.

It can be assumed that an authenticated TCP connection
enabled for F Class frames exists because the absence
on such a connection prohibits basic Fibre Channel
link operation (i.e., the problem must be dealt with
as a general concern for FC-BB-2 operation over FCIP.)

The response to the new SW_ILS will be one of:

   SW_ACC - indicating that the new TCP Connect
            request is authenticated
   SW_RJT - indicating that the new TCP Connect
            request is not authenticated

The response shall be communicated to the FCIP Entity
who shall act accordingly, as described above.

An FC Entity that receives one of the new SW_ILSs shall 
perform the requested authentication by verifying that it 
initiated a TCP connect request and sent the SF nonce. 
The results of the authentication shall be communicated
in the response to the SW_ILS as described above.

To further increase the difficulty of snooping
TCP connections, an FCIP Entity that receives
a duplicate nonce shall close the connection
on which that nonce was received immediately
without causing the SW_ILS to be sent.

Solution Pragmatics

This solution binds the authentication of the
second through n-th TCP connections to the
authentication of the first TCP connection,
thus fitting the solution within the bounds
of the assumptions (but no more).

Once the first TCP connection is properly
authenticated, it is reasonable to ask the
FC/FCIP Entity at the other end, "Did you
make this additional TCP connect request?"
The nonce (properly guaranteed for randomness)
represents the "this" aspect of the question
and renders nearly impossible nonce replay
attacks wherein the FC/FCIP Entity asked the
SW_ILS question is fooled into believing
that SW_ACC should be sent because a correct
nonce is presented.

This solution slows down the process of
establishing TCP connections, but that seems
unavoidable.

It may be desirable to require that there
be no attempts to establish the second through
n-th TCP connections until the first is
authenticated. This is another slow down in
the process, but one that will be imposed
anyway at a later step.

It may be desirable to further slow down
the process by requiring FC/FCIP Entities
to process only one TCP connect request
at a time, rejecting all TCP connect
requests that arrive while another is
in process. This will further add to the
difficulty of mounting a replay attack.