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

From: Joshua Tseng <[email-masked]>
Date: Tue, 7 Aug 2001 00:18:04 -0700

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

---

From: Theodore Tso <[email-masked]>
Date: Wed, 8 Aug 2001 06:29:58 -0400

On Tue, Aug 07, 2001 at 12:18:04AM -0700, Joshua Tseng wrote:
> And despite all the touted advantages

Actually, quite a few organizations have had a lot of experince with a
pure end-to-end security model.  Try just about any university, which
simply can't run with firewalls because every single professor has
collaborative research projects with so many folks at other
organizations that a firewall would be pointless (there'd be so many
holes in the firewalls that you might as well not bother).

> instead of each of his 1000's of hosts.

... and when someone takes their infected Windows 2000 laptop back
behind the corporate firewall, viruses such as Code Red generally
rampage completely out of control, since people behind the firewall
get careless and assume that they don't need to worry about security
or applying the latest security patches or service packs behind the
firewall.

This has happened to at least three companies, according to reports
from IETF'ers.  One of them at last count hadn't been able to read
e-mail for the last 48+ hours because Code Red was disrupting the
internal network so badly that he wasn't able to get to his corporate
mail servers.

If you think that administrators only need to monitor the few security
gateways, in order to assure the security of the enterprise, you're
beeing hopelessly optimistic.

That being said, no one is saying that security firewalls should be
thrown out; first of all, by saying that security should be mandatory
to implement, it gives the choice of whether or not the encryption
should be turned on to the user.  Mantory to implement != manadatory
to use.  Secondly, defense in depth is important.  

Even behind my corporate firewall of my company, I maintain my
personal machines as if there were no firewall, and use encrypted
connections for everything.  This meant that after we got badly
attacked by hackers who were able to pierce the corporate firewalls, I
wasn't affected.  However the naive folks who assumed they didn't need
to worry about security because the firewall would protect them were
very badly affected indeed.

							- Ted