RE: saag whyenc draft (was RE: Security Gateways)

[Black_David@emc.com]

> I would like to second Jim's remarks below, and would like to see some
> or all of his text included in the iSCSI document.  I think
> this is a reasonable approach which would address most concerns on
> all sides.

Not exactly.  The "asterisk" type of implementation (complies with
the security portion of the RFC only when a separately purchased
external gateway is present) have the potential to provide other
than end-to-end security because there's no way to control how
much network is between the iSCSI device and the gateway (e.g.,
suppose the gateway goofs and instead of talking to its peer
in the other city winds up talking to a gateway located a few
hops away in a metro POP).  At the moment, both automatic keying
proposals for iSCSI (SRP/ESP and some variant of IKE) are headed
in this direction by requiring modifications to current IPsec
firewalls in order to correctly implement the keying and/or
ESP processing.

The rest of Josh's message confuses "mandatory to implement" (which
iSCSI is being required to do) with "mandatory to use" (which is
not required, not even by the saag whyenc draft. After a long
exposition on the utility of corporate security gateways (mostly
correct, as they are in fact useful) Josh sums up by saying:

>  My solution would be to hide these devices
> behind a security gateway network proxy, turn off the end-to-end security,
> and use the security gateway's IPSec.

This is completely permissible, even under the saag whyenc draft (see its
discussion of "mandatory to implement" vs. "mandatory to use" in Section 7),
and is the obvious thing to do in the situation Josh is concerned about.

One other note is that to get denial of service prevention benefits for
iSCSI from a firewall, one probably needs iSCSI-specific inspection code
in the firewall.  Needless to say, this won't happen right away.

--David

p.s.  Jim's original text on types of implementations is below.


> > 
> > I think with regards to both confidentiality and 
> authentication (IPSec
> > authentication, not login authentication) one can expect three types
> > of implementations.
> > 
> > 1.  Products that claim full RFC compliance in big letters with a 
> >     small foot note stating that an external gateway is required
> >     for compliance with the security section of the RFC.
> > 
> > 2.  Products that claim full RFC compliance but drop to 1% normal
> >     throughput whenever security is enabled, and whose customers
> >     will buy an external gateway anyway when they want security.
> > 
> > 3.  Products that can run security at full speed but which are
> >     not competative in terms of cost/performance with 1 and 2.
> > 
> > I don't have a problem with any of these, but I think it's 
> critically
> > important that the security protocol for iSCSI doesn't preclude
> > options 1 and 2.  In terms of actual deployment, I suspect these
> > will be the most common.  A requirement for keying IPSec in
> > a way that is not compatable with existing security gateways
> > would be a serious setback to general acceptance of iSCSI, and
> > could potentially result in the emergence of a de facto standard
> > (no security) which diverges from the RFC standard (manditory 
> > security).  I don't think diverging standards are in anyone's
> > best interest, especially if there are practical ways to 
> > aviod it.
> > 
> > 
>