RE: BOUNCE ips@ece.cmu.edu: Non-member submission from [Brian Pawlowski <beepy@netapp.com>]

[Sudhir Srinivasan <SudhirS@trebia.com>]

Beepy,

I have been thinking about NFSv4 also, in the context
of this discussion and I believe the analogy is not
particularly relevant for a few reasons:

1. The security holes in NFSv2/3 were much more fundamental
   than on-the-wire security - so the real fix in NFSv4 is the
   introduction of better access control through ACLs
   (a la CIFS). On-the-wire security, IMO doesn't add much
   value to NFSv4 in the most typical deployments (I'm very
   curious to see how many people actually use s/w based
   per-packet security in NFSv4 within the data center or
   office environment). To put some perspective, it is much
   more likely that a security breach will happen via hacks
   into servers rather than people spoofing wires inside a
   data center. So robust access control goes a long way here.

2. The main justification for on-the-wire security in NFSv4
   is, IMO, due to the stated goal of NFSv4 to be the file-access
   mechanism for the (big bad) Internet. The equivalent in
   the IPS world would be FCIP. Bob Snively has made some
   excellent points about the pragmatics of deploying security
   in these situations.

3. The per-packet security mechanism in NFSv4 (RPCSEC_GSS)
   implies NFSv4 vendors have to modify their RPC stacks --
   security cannot be "added on" by users if it's not
   implemented in the RPC stack. So it makes sense to
   mandate implementation.
   In the case of IPS, the security mechanism is quite
   amenable to a deployment using an adjunct device
   or a boundary gateway device (subject to acceptable
   resolution of the keying exchange issues).

It's important to understand that the IPSec discussion is 
different from the access-control aspect of NAS security.


Regards,
Sudhir

> -----Original Message-----
> From: Jim McKinney [mailto:jmck+@ece.cmu.edu]
> Sent: Thursday, August 02, 2001 7:27 AM
> To: ips@ece.cmu.edu
> Subject: Fwd: BOUNCE ips@ece.cmu.edu: Non-member submission 
> from [Brian
> Pawlowski <beepy@netapp.com>] 
> 
> 
> From: Brian Pawlowski <beepy@netapp.com>
> Message-Id: <200108020447.VAA02871@tooting-fe.eng.netapp.com>
> Subject: Re: Security Gateways
> In-Reply-To: <200108020206.f7226He27045@ece.cmu.edu> from Jim 
> McKinney at "Aug 1, 1 10:06:17 pm"
> To: jmck+@ece.cmu.edu (Jim McKinney)
> Date: Wed, 1 Aug 2001 21:47:20 -0700 (PDT)
> Cc: ips@ece.cmu.edu
> X-Mailer: ELM [version 2.4ME++ PL40 (25)]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  
> 
> I've often mused that storage environments today based on FC are
> physically secure as an artifact of the severe deployment restrictions
> that the technology itself supports.
> 
> Replacing FC deployments with TCP/IP-based networks blows these
> assumptions.
> 
> After years in the insecure wilderness within NFS, and the inability
> to count on strong security from all vendors removing a motivation
> to even invest in it (it was optional), the movement in NFS Version 4
> to strong security was a key component of the evolution wrought since
> it was handed to the IETF.
> 
> I look back on our lack of commitment to providing interoperable,
> manadatory to implement (optional to enable) strong security as being
> one of the greatest failures in NFS - that is finally being corrected.
> 
> It is certainly sobering when your PC on your desktop 
> provides stronger
> security guarantees in a simple network when it accesses data on some
> server (CIFS) than you are guaranteed (through mandatory to implement)
> in your enterprise class storage network. 
> 
> beepy
> 
>