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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 Nov 2002 07:29:42 -0800

Trond wrote:
>    >> Section 3.1.1 explicitly states that the client is allowed to
>    >> break the transport connection and then resend the request
>    >> (even after it has determined that the server is still
>    >> alive). IIRC that was added specifically in order to allow RPC
>    >> engine reuse with v2 and v3.

R.J. Atkinson wrote:
>     > That would be an unkind thing to deploy, since it likely will
>     > impair user performance and drive NFS server admins nuts.
>     > Please folks avoid doing that sort of thing in real code.

Trond wrote:
> Unlike previous versions of NFS, several operations under v4 are
> subject to hard timeouts (anything that depends on a lease getting
> renewed on time for instance).
> Why shouldn't NFS client administators have the option of setting a
> reasonable timeout period in order to try to recover before those
> leases expire?

There are two kinds of timeouts here: retry timeouts and abort timeouts.
If you want to abort a request in a situation in which that might be
necessary for you to send a renew, then there is nothing in the spec
that prevents you from doing that, although with some requests not
waiting for the response may make it hard to recover (lost stateid's,
etc).

If you have a retry timeout, then yes the spec forbids that, but 
resending a slow request isn't going to help you.  It is not going 
to make the orginal request go faster.  And since the server is not
expecting re-issues like that he need not check the reply cache for
requests in progress, so resending might make things take twice as 
long.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 26 Nov 2002 17:22:52 +0100

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

     > If you have a retry timeout, then yes the spec forbids that,
     > but resending a slow request isn't going to help you.  It is
     > not going to make the orginal request go faster.  And since the
     > server is not expecting re-issues like that he need not check
     > the reply cache for requests in progress, so resending might
     > make things take twice as long.

That depends entirely on the reason. The fact that your TCP stack
thinks it has delivered a message on your behalf is no guarantee that
the NFS server is going to process it. Someone may for instance have
played tricks on your TCP stack, or (as Mike mentioned in another
thread) your request may have been dropped by the auth layer.
If you disallow timeout + retry entirely, how are you going to recover
from such an event?

Cheers,
  Trond

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 11:55:19 -0500

On Tuesday, Nov 26, 2002, at 11:22 America/Montreal, Trond Myklebust 
wrote:
> played tricks on your TCP stack,

	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.

> or (as Mike mentioned in another

	It would only get dropped iff it failed authentication.
It would only fail authentication if one sent an invalid request.
Resending an invalid request won't make it magically valid.

	Bottom line is that (timeout + retry) doesn't really fix
any of the items you raise -- and it does cause operational problems.

Ran

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 26 Nov 2002 18:05:49 +0100

>>>>> " " == RJ Atkinson <[email-masked]> writes:

     > 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.

     > It would only fail authentication if one sent an invalid
     > request.  Resending an invalid request won't make it magically
     > valid.

No. AFAICS it would get dropped iff it violates of the sequence number
window. If so, then breaking the connection, and renegotiating a
context *will* magically make the request valid.

Cheers,
  Trond

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 13:31:41 -0500

On Tuesday, Nov 26, 2002, at 12:05 America/Montreal, Trond Myklebust 

> to spoof RPC requests or replies.

Sorry, but none of that helps.  If the TCP/IP stack can be modified, 
then
there are still N other serious security problems --> so one ought not 
be
trying to use NFS (or several other applications, for that matter) at 
all.

> window.

Hmm.  That is not how TCP works.  Which particular sequence numbers are 
you
thinking of ?

---

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

>> No. AFAICS it would get dropped iff it violates of the sequence
    >> number window.

     > Hmm.  That is not how TCP works.  Which particular sequence
     > numbers are you thinking of ?

RPCSEC_GSS keeps its own sequence numbers and sequence window in order
to prevent message replay attacks.

Cheers,
  Trond

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 14:39:40 -0500

On Tuesday, Nov 26, 2002, at 13:59 America/Montreal, Trond Myklebust 
> to prevent message replay attacks.

I'll defer to Mike Eisler's analysis, which concludes that retries
aren't helpful within RPCSEC_GSS either...

Ran