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

[Black_David@emc.com]

> 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. 

The assumption that there's a big on/off switch for
security is not correct (e.g., suppose IPsec is running
with integrity on and confidentiality off) and
"authenticated and certified" is a peculiar concept for
group pre-shared keys, a very likely deployment scenario.
Also, IPsec has no clue about the WWN, and hence the IKE
authentication is not linked to the WWN that has to be
presented (a particular problem with group pre-shared keys,
but also a risk even with certificates).  In other words,
"authenticated and certified" doesn't place any restrictions
on what WWN is presented.  Finally, solving
an inband authentication problem by requiring that IPsec be
used to encrypt the WWN is wildly excessive, and besides,
the WWN has no secret contents- it's a public piece of
configuration information.

There is a solution in this general area, but it involves
linking the WWN to the IKE identity that is authenticated.
That's probably going to break any attempt to use existing
off-the-shelf external IPsec gateways because gateways
don't grok WWNs, and the FCIP implementations won't
know what identity was used in the IKE authentication
to the gateway.  This is all a bit peculiar because FC
currently trust WWNs passed in various FC Login frames
without authenticating them, but that's T11's area of
responsibility putting this sort of thing into an IETF
standard isn't going to be acceptable.

> 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. 

Only on the first TCP connection, unless you plan to require
taking the FCIP link down when the second TCP connection
is added (which strikes me as highly counterproductive).
The second connection just inherits the results of the SLAP
performed on the first one, whether its entitled to or not.

> 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.

I'm not sure what you're referring to, but I suspect they
don't help much here.

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

The fact that the WWN is not authenticated means that anyone
who can set up an FCIP connection to an FCIP entity can tap
into any existing FC traffic flowing on any connection through
that FCIP entity.

--David

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Friday, November 09, 2001 8:06 PM
> To: 'Black_David@emc.com'; ENDL_TX@computer.org; ips@ece.cmu.edu
> Cc: Robert Snively
> Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> Interim meeting)
> 
> 
> 
> 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
>