SUMMARY: (Brief) Secure RPC & NFS

Date: Fri Aug 23 1991 - 07:16:20 CDT

I got some replies and I read an interesting article in Sun's Januari 1991
Software Technical Bulletin.
The replies differs a lot. A lot are interested in the info Summary.
Also the NFS impact differs a lot at several sites.
Here is a short quote from: <> Robert Linton
> You will find a rather measureable decrease in performance, the size of which
> depending on the types of machines involved. With sparc servers and sparc
> clients (diskfull, less than 10 per server), the performance hit is not
> too bad. For larger numbers, or sun 3's it's pretty awful. You have to
> decide if performance or security is the primary concern. Limiting the
> DES secure mounts to those that need it can help, but you have to worry
> about whether this is leaving gaps in your security.
Terrifiing :-(, We have a very big LAN , which is very overloaded already.
All automount cross mounts etc.....
Another opinion , rather different: <> Mark
> We are in the same boat as you, ie no DES chip.
> We have been running secure NFS for ages now and I haven't seen any
> real difference in network performance, or machine performance for
> that matter. The only problem we have had is that when running port
> checking most of our non Sun machines can't access the NFS exported
> partitions on the Suns.
Another ouch !!
Since our LAN is rather Multi Vendor, this is a real pain.
Another thing is that PC-NFS is not running Secure NFS.
That makes it even worse to implement it over all machines.
Our goal was to prohibit NFS from foreign machines hacking on our Disks.
Since normal NFS is not very secure, Secure NFS should be better.
(We have had some login attempts already, so NFS can be the next step)
The Software Technical Bulletin of januari 1991, which I happened to
read for the first time yesterday after sending the SunMGR mail
has some interesting topics about Secure RPC & NFS.
I quote the performance part, it has some interesting views :-) :
> On a Sun-3 the time it takes to encrypt one block is about half a
> milisecond if performed by hardware an 1.2 millisecond by software.
> So the extra time added to the round trip time is about 2 milliseconds for
> hardware and 5 milliseconds for software. The round trip time for the
> average NFS request is about 20 milliseconds, resulting in a performance hit
> of 10 percent if one has encryption, and 25 percent if not.
> Remember that is the impact on _network_ performance. The fact is that
> not all file operations go over the wire, so the impact on total system
> performance will actually be _lower_ than this.
So expect a 50 % decrease of performance ?
I don't think our users would like that, they already are complaining a lot
about performance. A lot of Sun's are used as compute systems for Numerical
> It is also important that
> security is optional, so environments that do not require it may turn it off
> if they want higher performance.
Hah !, so you must blindfold your Sun/Net from the rest of the world or
blindfold yourself from the rest of the world and wait for nasty things to
happen. A real killer conclusion. Sun really admit that standard UNIX
is not secure :-). Well, say no more :-)
Our conlusion in this matter is:
<> Robert Linton is probably right. our NFS automount
environment is very spagetti based, so NFS performance is a big thing.
We have enough NFS troubles here to hold back secure NFS.
( Very soon we have a demo from a small company who sells a NFS
Analyzer which does extensive checking of NFS tracking and logging
( up to files ) . If you are interested, send a mail to )
Multi vendor TCP/IP & NFS network -> No secure NFS possible
Discless clients and Secure NFS -> performance pig
Sun-3's with limited memory -> performance pig
We disabled NFS from the outside world.
This can be done with our router.
We can say that our environment does not really need secure NFS, only if one
wants to mount disks from another site over WAN's on our machines.
Thanx you all Sun-MGR's
This list is really great !
Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN
(and SURFnet IP/ICP), Phone: (+31 /0)2246 4579 Fax: (+31 /0)2246 1864
E-Mail: Bernards@ECN.NL, SnailMail: P.O. Box 1, 1755 ZG Petten
SCREAMNet : AAAAAARGHH!HUH?? : Disclaimer: "The AntiChrist is the Computer !"

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:19 CDT