RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting)

[Robert Snively <rsnively@Brocade.COM>]

David,

For those cases where a secure environment is required, the
new connection comes up through the normal IPSec authentication
and encryption processes.  As a result, the transmission of
the identifying world wide names is already transmitted in an
encrypted format, creatable only by the authenticated and
certified source and interpretable only by the authenticated
and certified destination.  

If the Fibre Channel fabric is also operating in a secure mode,
subsequent Fibre Channel authentication and certification 
is performed using the standard FC SLAP mechanisms. 

In addition to this, there are a whole bunch of policy 
restrictions that are verified as part of the creation
of subsequent connections.  While these are not necessarily
part of the security steps, they prevent the formation of 
connections which do not meet the security rules.

Assuming security mechanisms are properly implemented, where, 
then, is the security hole?

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

 

> > Those who were at the Irvine Interim meeting will remember that
> > the problem with FCIP and NAPTS is a reliance on IP address in
> > the determination of which incoming TCP connections belong in a
> > given FCIP Link. This proposal solves that problem by requiring
> > that FC Entity World Wide Name be transmitted in the first bytes
> > sent by the FCIP Entity that initiates a TCP Connect request.
> > This allows the FCIP Entity that receives a TCP Connect request
> > to match it with any previously received TCP Connect requests
> > from the same source. Since the transmitted World Wide Name is
> > required to be unique within Fibre Channel, the FCIP Entity
> > that receives this information can correctly assign FCIP Link
> > relationships without relying on IP Addresses.
> 
> From a functional standpoint, this works, but it opens up a security
> issue.  The problem is that on the second TCP connection (and 
> subsequent
> connections) that claim to be from the same FCIP Entity, the WWN that
> is initially sent (and whatever extension is used) is functioning
> as an authentication to allow that connection to join the first
> TCP connection, but that authentication is unsecured -- the sender
> announces the WWN, and the receiver does not (and has no way to)
> check it.
> 
> There's a fairly obvious denial of service attack here involving
> the attacker joining a new connection to an existing one
> and then bit-bucketing all the frames sent over the new connection.
> 
> Limiting FCIP to one TCP connection among any pair of FCIP entity
> identifiers would help, but is not sufficient.  The attack of concern
> in this situation involves the attacker crashing the real entity
> and opening up a connection in its name, thereby locking out the
> real entity when the real entity restarts.
> 
> This may be headed in the direction of needing in-band authentication
> which I know the FCIP community has been doing their best to avoid.
> 
> Sorry to be the bearer of bad news,
> --David