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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 Nov 2002 08:37:17 -0800

> >>>>> " " == 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, 

It is no guarantee but the NFS server has promised to process it, that's
the contract.  The motherboard may be fried in which case it has an
excuse.  The point is, that that is the nature of valid excuses.  It
is not the case that server may validly just not process requests, or
allow someone to play tricks on their TCP stack, such that re-issuing the
same request will work.  That's what the spec says is broken behavior.

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

I don't understand GSSRPC well enough to respond to this (and retrying
the question won't help :-)  I'm sure Mike will chime in.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 26 Nov 2002 10:56:22 -0800

> the question won't help :-)  I'm sure Mike will chime in.

There's an assumption that client will properly construct the RPC request,
and, if the transport is reliable that it will either rrive on the server in logical
form equal to that which is was sent, or the connection will
break. Things that would violate this assumption:

	- the transport is actually not reliable
	- the client or server implementation of TCP or RPC or RPCSEC_GSS is buggy
	- there is an active attack on the network which inteferes with
		the state machines maintainted by TCP or RPCSEC_GSS

RFC2203 says silent drops occur due to duplicate sequence numbers in the RPCSEC_GSS
credential. The aforementioned assumption violaters would cause this.
The rationale is the server can't discern which of the above cases apply. RFC2203 is 
simple enough that I didn't see any point in adding protocol complexity to deal with server
and client bugs that would result in duplicates. The most likely cause is an attack.
Responding to the attack simply consumes more resources.

So the question is, how is the client going to recover from it sending a
duplicate sequence number or the server re-processing a duplicate sequence number?
My answer is: don't do that. 

If people want to go down the path of revising RFC2203 to deal with this issue,
let me point out, at least based on my interpretation of the specification, an
improperly constructed RPC header will often result in no response going back
to the client. A duplicate sequence number in the credential is just another
case of a bad header. And then there's the issue of a 16 bit checksum in
the IP header and TCP segment being insufficient for high speed networks (when
the number of bits fly quickly enough, if there are physical network faults that
corrupt data, then the chances of hitting the lottery on 16 bit checksum verifying
corrupt data are very high. I.e. the transport is not reliable). 
I've probably only scratched the surface. 

Invest in good implementations of each layer of the protocol
stack. I don't believe the Internet is (or could be) designed to overcome all possible
bugs in implementations of each layer of the stack. If the worst thing as result of
those bugs is a process hang on the client, then I can live with it.

	-mre