[OpenAFS] Code to demo NFS/UDP weakness?

[Daniel Clark]

I'm not disagreeing with any of your points, and I've brought most of
them up myself, however they are all somewhat technical (or non-issues
in our particular environment with enough painful planning), and from
a nontechnical perspective "Let's just give more money to Network
Appliance and their completely proprietary Data OnTAP OS" seems like a
reasonable response (esp. now that some of the features you mentioned
are being incorporated into their product line - I think they hired
some ex-Transarc employees).

On the other hand my workplace is *very* security sensitive (not
secure so much, just sensitive ;-), so "look, a random visitor (and/or
unauthorized employee) can jack into our network with a laptop and
copy/modify our intellectual property, which we claim to value so
much" seems like a better argument for my particular situation.

And actually re: scale I think it's a mixed bag. OpenAFS support for
doing things like moving volumes in the face of really big single
volumes (multiple terabytes) seems to be iffy/slow based on reading
random posts/bug reports (and other groups resist any changes to their
processes, such as creating a new AFS volume per (multi-gigabyte)
build or something like that).

Also, although I've managed to nurse out performance of OpenAFS to be
slightly greater than (untuned client) low-end netapp NFSv3
performance by using memory cache (BTW anyone know why memcache isn't
considered default? In my performance testing some of the filesystem
tests were running so slowly using diskcache I had to end them
prematurely), I doubt that it could match higher-end NFS servers/tuned
clients in terms of raw performance on gigabit / trunked gigabit
ethernet (we have a lot of
copy-2GB-of-smallish-files-from-point-a-to-point-b-type use cases).

Re: backups, that would actually be kind of painful/require custom
scripting now that our backup vendor (IBM) no longer supports AFS/XBSA
backups in the latest version of TSM (5.3). I'm thinking we'd need a
large cheap IDE disk array to do dumps to, and then backup the dumps
as normal files. Or a TiBS server (but that will never actually
happen.)

--
Daniel Clark
dclark@pobox.com

On 8/2/06, Anne.Salemme@dartmouth.edu <Anne.Salemme@dartmouth.edu> wrote:
> an even more compelling argument for AFS over NFS or other large
> filesystems is the way you can essentially add unlimited space by
> simply adding servers. the steep learning curve is bringing in afs and
> getting it into production initially. after that, it's easy to add
> space, move volumes around, etc. and the users will Never Notice.
> every NFS site is used to dealing with disks filling up and having
> data outages while stuff gets moved around. same with SAN space,
> re-doings luns, all that stuff. i am pretty sure that AFS is the only
> large filesystems technology that lets the administrators deal with
> adding new space, moving stuff around, replacing servers, etc. doing
> normal admin tasks without any interruption of service to the users.
>
> another compelling argument might be if you can show how it would
> interact with your existing infrastructure, regarding authentication,
> backups, etc.
>
> to me, a real "weakness" of nfs is how poorly it scales up compared
> with afs and how many normal administrative operations involve outages
> for the users.
>
> just my $0.02
>
> anne
>
>
> Quoting Daniel Clark <dclark@pobox.com>:
>
> > I'm putting together a "NFSv3 is disgustingly insecure, we should move
> > to OpenAFS" type presentation for my management [1]. I've found
> > explanations to be less than completely understood, so I've decided to
> > put together a demo.
> >
> > I've already found nfsshell [2], a commonly available user-level
> > program that among other things allows creation of NFS requests as any
> > other user on a system.
> >
> > The most useful article I found on the subject [3] also mentions that
> > "UDP is also trivial to spoof, making it easy to get around the
> > host-based access control, which relies on the IP address of the
> > client." Does anyone know of code that would demo this vulnerability?
> >
> > [1] NFSv4 isn't an option due to platform support requirements.
> >
> > [2] Leendert van Doorn's nfsshell
> > ftp://ftp.cs.vu.nl/pub/leendert/nfsshell.tar.gz
> >
> > [3] ;LOGIN: February 2005 pg. 17 - Rik Farrow's Musings
> > http://www.usenix.org/publications/login/2005-02/pdfs/musings.pdf
> >
> > Thanks,
> > --
> > Daniel Clark
> > dclark@pobox.com
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>