Security Gateways

[Black_David@emc.com]

The following issue was hidden in my long set of
comments on the -03 version of FCIP:

> > Delete 12 b).  If an FCIP entity is operating with an external
> > security gateway, only the interface on the public side of the
> > gateway is compliant with this specification.  The interface
> > between the FCIP entity and the gateway is not compliant because
> > it is lacking required security features - the FCIP entity
> > *includes* the security gateway in this structure.
> 
> Please post this as a separate issue because several of the
> FCIP Authors believe it is appropriate for FCIP and I cannot
> represent their opinions.

The issue is not whether it's "appropriate".  The issue
is that if an implementation uses an FCIP Entity plus
an external security gateway, the only interface that
conforms to the forthcoming RFC is the public/external
interface on the security gateway.  The interface between
the FCIP Entity and the security gateway is private
and fails to conform to the security that will be
required of all FCIP implementations.

The above paragraph also applies to iSCSI (substitute iSCSI
for FCIP in all instances).  Let me also note that iSCSI's
ability to use a security gateway is not final at this
juncture.  The spectrum of security possibilities includes
things like SRP keying of ESP and IPsec transport mode that
would make external gateways difficult or impossible to use.

Those who care about being able to use security gateways
(or think that there's no need to support their use)
should speak up on the list, in London, and/or in Orange
County (I would expect the decision not to be made prior
to Orange County) and *EXPLAIN WHY* [technical rationale].

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------