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

[Joshua Tseng <jtseng@NishanSystems.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.

Much has been said to deride today's firewall-based security
architecture ("hard on the outside, chewy on the inside...").
But the fact is that we know what the strengths and weaknesses
of this architecture are.  And despite all the touted advantages
of the pure end-to-end security model, do we have any experience
with it? I think not.

One immediate consequence I can think of is that iSCSI devices will
not be able to leverage the services of a security gateway, unless you
have distributed the encryption keys for your iSCSI session to that
firewall.  And contrary to the negative things said about them,
security gateways are, and IMO will continue to be, an important
component to any enterprise's security infrastructure for the forseeable
future.  They are a bottleneck for all traffic entering the network,
making it much easier for the administrator to monitor security threats
to that network, since he only has to monitor his few security gateways,
instead of each of his 1000's of hosts.

And if iSCSI devices cannot leverage the services of a security firewall
because all of their traffic is encrypted, what that means is that they
will each be individually responsible for fending off DOS attacks.  
Anyone can spoof IPSec packets.  From what I understand, the work on
IPSec NAT will not fix this since the NAT boundary is stateless, and
will not authenticate the IPSec.  For some administrators, especially
storage administrators, I believe they would be quite uncomfortable
about this.

I would propose that security gateways will be particularly important
for iSCSI, even if they are equipped with end-to-end security.  iSCSI
should not be compared to WAP, telnet, or even NFS.  Sure, in some cases
iSCSI will be deployed on workstations, and the user will be able to
complain to the administrator if they their system suddenly halts under
the load of a SMURF attack.  But in other environments, I can envision
farms of 100's, perhaps 1000's of iSCSI disk drives and servers, all
managed by a small team of a few administrators. In this situation,
centrally managed security gateways that are fully empowered to filter
and protect will be important.  I would be uncomfortable allowing direct
IP connectivity to the public network for each of these devices, even if
all traffic is IPSec encrypted. 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.

Josh

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