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

From: Scott Bradner <[email-masked]>
Date: Thu, 2 Aug 2001 19:33:02 -0400 (EDT)

> will talk with Jeff (if I can hunt him down in London)

Jeff will not be in London (his wife is due to have a kid right about now)

Scott

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 3 Aug 2001 09:35:12 -0400

> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 02, 2001 7:11 PM
> To: [email-masked]; [email-masked]
> Subject: saag whyenc draft (was RE: Security Gateways)
> 
> 
> 
> > I also want to be careful about products that are multi
> > gigabit products, but to be "standards compliant" include a software
> > encryption module that runs at 12 Mbit/Sec and is completely useless.  I
> > would rather have that product without security, so that I KNOW that the
> > security isn't there...
> 
> OTOH, this argument may have some merit, as I would definitely expect
> to see things like this sort of brain-damaged software encryption module
> if confidentiality becomes a "MUST implement".  Let me be clear that
> this applies only to confidentiality -- a small amount of thought about
> the consequences of impersonation and a script kiddie's TCP hijack attack
> leads to the conclusion that authentication and cryptographic integrity
> have to be "MUST implement" for iSCSI, FCIP, and iFCP.
> 
> Let us know the results of your discussion.
> 
> Thanks,  --David

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: [email-masked]
Date: Wed, 8 Aug 2001 13:26:25 -0400

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

---

From: Joshua Tseng <[email-masked]>
Date: Thu, 16 Aug 2001 12:02:06 -0700

Ted,

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

Protection against viruses and hackers comes from firewalls and
virus-detection software, not IPSec.  An IPSec-equipped host can
be just as vulnerable to Code Red as one without IPSec.

Maintaining adequate defensive measures to protect against viruses
and hackers is an extremely administratively intensive process.  It
involves buttoning down your host to make sure there are no open
unused TCP ports, and that each new application you install doesn't
open up new weaknesses.  Any security administrator knows this isn't
easy to maintain for even a single host.  That is why the bastion
host/security gateway architecture is practical for a large enterprise.
You only have to do it for your 3-4 security gateways, not your 1000+
hosts.

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

What they need is not necessarily IPSec, but a personal firewall with
virus detection capability for their notebook.  There are many of
these commercially available.

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

The first axiom of security is that NOTHING is 100% secure.  What I
said is that we know the strengths and weaknesses of the security
gateway architecture, and while I agree that it is not invulnerable,
I would rather go with that than trade the known for the unknown.

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

Agreed.  End-to-end IPSec is good to have, but in many cases I
would turn it off, especially if I wanted to leverage the firewall
services of a security gateway.  If end-to-end IPSec is turned
on, then I would need to ensure each host has a personal firewall
and up-to-date virus detection capability.

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

I didn't necessarily mean rely on the corporate firewall.  I believe
an internal isolated subnet within a corporate network, accessed
only through a dedicated iSCSI security gateway, would provide
equivalent if not superior security in many cases.  For sure, it would
be far easier to administer and monitor than end-to-end encryption,
virus-detection software, and host-based firewalls on every individual
iSCSI host.

The point I'm trying to make is that end-to-end IPSec doesn't solve
all the security issues.  There have been statements made about how
end-to-end IPSec provides security so that the end user doesn't have
to worry about it.  I believe this is not only false, but that there
are situations where end-to-end encryption will actually increase your
overall security exposure, because it prevents you from leveraging
firewall available from a generic security gateway.  We need to make
sure expectations are set correctly.  I don't think there is anything
that this working group can do to address every possible security
threat ever known to mankind, and I certainly hope we don't try to.

Josh

> 							- Ted

---

From: Robert Snively <[email-masked]>
Date: Fri, 24 Aug 2001 10:04:16 -0700

Folks,

I am in agreement with Joshua in this discussion.

> > personal machines as if there were no firewall, and use
> > encrypted connections for everything. 

Ted,

This sounds like very helpful news.  How can I set that
up and still maintain access to informative web and ftp sites of
dubious trustworthiness (which are always trying to 
get registrations from me, capture my web-browsing 
habits, and are not responsible for the integrity of their files)?
I would also like to be sure that all my e-mail sources
were also encrypted and authenticated, since e-mail is
the principal source of attacks.  How can I arrange that?

Bob