Subject: RE: heads up - NetApp, NFSv4, and UDP

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 Nov 2002 09:45:53 -0800

Trond wrote: 
> >>>>> " " == RJ Atkinson <[email-masked]> writes:
>
>     > 	If someone modifying your TCP/IP stack is really your threat
>     > 	model,
>     > then you probably should not use NFS at all, because there are
>     > N other serious security problems that (timeout + retry) cannot
>     > fix.

> That's why we've added data integrity + data privacy into the security
> model.
> However those apply at the RPC level, *not* at the TCP level. People
> can spoof ACKs back to the client, but they're not supposed to be able
> to spoof RPC requests or replies.

I just can't see any situation in which a denial-of-service attack (which 
I think is what we are talking about here) would be prevented by this 
approach of very slow request retry and on TCP, if we allowed retries, 
they would be very slow, so slow that NFS service would essentially be 
denied.  So after waiting some number of *seconds* you re-issue your request
and for some reason the ACK spoofer misses it and you manage to get
your request over, some of time.  I consider that a situation in which the
denial-of-service attack has succeeded, just as it would have if you didn't
retry.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 26 Nov 2002 19:11:24 +0100

>>>>> " " == Dave Noveck <Noveck> writes:

     > I just can't see any situation in which a denial-of-service
     > attack (which I think is what we are talking about here) would
     > be prevented by this approach of very slow request retry and on
     > TCP, if we allowed retries, they would be very slow, so slow
     > that NFS service would essentially be denied.  So after waiting
     > some number of *seconds* you re-issue your request and for some
     > reason the ACK spoofer misses it and you manage to get your
     > request over, some of time.  I consider that a situation in
     > which the denial-of-service attack has succeeded, just as it
     > would have if you didn't retry.

Unless you try to recover somehow, then the attacker will have
succeeded in more than just disrupting your NFS service.

If all it takes to get an apache server to hang forever is for a
single READ never to make it to the server, of if syslog exits with an
error simply because one WRITE request timed out, then people are
going to stick to using NFSv3 (and perhaps migrate to RPCSEC) where
all this is a non-issue.

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Tue, 26 Nov 2002 15:37:26 -0800

> going to stick to using NFSv3 (and perhaps migrate to RPCSEC) where

It can happen with NFSv3/TCP with or without  RPCSEC_GSS.
See slide 16 of http://www.connectathon.org/talks96/nfstcp.pdf. 

Regardless of NFS version, retrying the request over the same
connection is not a general solution to recovering from this class of attack.
Only breaking the TCP connection and trying again has any hope, but
then the attacker can start all over again. I'm undecided if
this is class of attack is something the NFS client 
implementors should anticipate, but note 
the i-d does leave it as an implementation option. I know Ran hates
it, but the strategy outlined in the NFSv4 specification is a lot
nicer to the network than what NFSv[23] have used.

Gee I can wait to send a message entitled "NetApp, NFSv4, and AUTH_SYS". Just
kidding. :-)

	-mre