Subject: RE: Storage over Ethernet/IP

From: [email-masked]
Date: Fri, 26 May 2000 10:14:03 -0500

>> Encryption will be offloaded to the network interface.  ASICs on the NICs
>> will greatly improve encryption and authentication performance.

>all well and good, provided that this encryption and authentication
>are actually compatible with that specified by higher level protocols
>and the authentication actually meets the needs of users.  
>(if your network interface needs to use and verify users' credentials,
>as opposed to the host's credentials, it might be a stretch.)

A network server will still authenticate user requests.  Only the host
needs to be authenticated with the disk/disks.

>> It won't run over the Internet because of latencies inherent on the 
>> public network.

>at least for some storage applications, latency is not as important
>as bandwidth.  e.g. you can do backups over a high-latency medium
>as long as your bandwidth is adequate (though recovery from write 
>errors gets a bit tricky).

Backups could go through VPNs, I suppose.  Good point.  That would free your

WAN of the backup jobs.  I wasn't thinking of backups when I ruled out
the Internet as a disk I/O medium.  I suppose infrequently used and low
priority files could also be accessed over the 'net.

>> It will run over incredibly fast Packet over SONET Wide Area
>> Networks--behind firewalls.

>...it's 
>inappropriate to assume that it will always be used behind firewalls...

If the larger network that is employing this technology doesn't hire a
decent
consultant, you might be right.  If they do, it will ALWAYS be behind a
firewall :-)

>Firewalls don't help with the majority of security threats...

True, but whether the server accesses the disks via SCSI over TCP or SCSI
over 
Fibre Channel, the SERVER is still the weak link.  The transport protocol
doesn't
create any inherent weaknesses of the type you are refering to--e-mail borne
viruses, 
internal hackers, etc.  The server would still be the attack point.  Why
goodness, 
the server and storage devices could be in a VLAN or something to deny
direct hack 
attempts against the storage device, but the chink in the armor is how
hardened is
your OS?

Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 May 2000 11:33:17 -0400

> Backups could go through VPNs, I suppose.  

except that you can't assume the presence of a VPN either.  you need 
authenticity and privacy specified as part of the storage access protocol.

> I suppose infrequently used and low

yes, but file access protocols are better for this purpose.  
I don't see wanting to mount a raw disk drive 
across the public Internet very often.  
(except perhaps read-only... virtual cdrom, anyone?)

> decent consultant, you might be right.  If they do, it will ALWAYS 
> be behind a firewall :-)

any consultant who pretends that firewalls provide security cannot
be described as 'decent'.

> over Fibre Channel, the SERVER is still the weak link.  

un, no.  SCSI has some inherent length/delay/number-of-stations 
limitations.  but if the disk is accessible using TCP,  there is a 
significant probability that it will be accessible from the global 
Internet and/or from local threats who have physical access to the
transmission medium, and the storage access protocol needs to assume 
that this is the case.

> The transport protocol doesn't create any inherent weaknesses of 
> the type you are refering to--e-mail borne viruses, internal hackers, etc.  

you're assuming a different threat model than I am.  I am indeed
assuming that storage devices will be targed, in addition to servers.

> The server would still be the attack point.  Why goodness, 
> direct hack attempts against the storage device

yes, they *could* be.  but you cannot assume that they *will* be.

> but the chink in the armor is how hardened is your OS?

there's more than one chink in the armor.

IP-based protocols need to be able to work in the global Internet.

Keith

---

From: [email-masked]
Date: Fri, 26 May 2000 11:35:54 -0400

> needs to be authenticated with the disk/disks.

Hmm.  

Isn't this security model the cause of most grumbling regarding NFS security?

> If the larger network that is employing this technology doesn't hire a decent
> consultant, you might be right.  If they do, it will ALWAYS be behind a firewall :-)

Double Hmm.. 

Odd.. I thought we had a clue about security.  The guys at SANS just
gave us a 'Technology Leadership Award'.  I just walked across the hallway,
and I didn't see any firewall in our router swamp.

I guess because we don't have a firewall, we don't have a clue.  Or because
we don't have a firewall, we can't deploy this technology.  Somehow, that
doesn't smell right.

> the server and storage devices could be in a VLAN or something to deny direct hack 
> attempts against the storage device, but the chink in the armor is how hardened is
> your OS?

If your OS is hardened enough, a firewall may not be appropriate.

"New from Kellogs - Firewalls cereal - part of this *COMPLETE* and *BALANCED*
security breakfast".
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 27 May 2000 00:27:01 +0200

At 10:14 26.05.2000 -0500, [email-masked] wrote:
>over Fibre Channel, the SERVER is still the weak link.  The transport 
>protocol doesn't create any inherent weaknesses of the type you are 
>refering to--e-mail borne viruses, internal hackers, etc.  The server 
>would still be the attack point.  Why goodness, the server and storage 
>devices could be in a VLAN or something to deny direct hack attempts 
>against the storage device, but the chink in the armor is how hardened is 
>your OS?
did you hear the story about the MIT students who broke encryption in 
Netscape by replacing the page of the binary containing the crypto 
verification code (sniffing the NFS request and replying faster than the 
real fileserver) while it was being transferred over the network?
Replacing a dedicated medium (such as a SCSI bus) with a shared medium 
(such as an Ethernet cable plant) always opens new chinks.

The point being made, remade and made again here is:
- Any IP technology will be used in contexts where there are security threats
- Any protocol that offers no means of countering such security threats is 
broken, and should not be considered for standardization.

It is perfectly possible that after conducting a threat and modality 
analysis, one ends up with saying that hardware-accelerated IPsec using 
host identities is adequate for the scenarios involving 
otherwise-unprotected Internet links, and that a mode with no protection is 
adequate when the media is physically secured.

But the analysis MUST BE DONE.

                       Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]