>Its pretty trivial to forge addresses.

Not always, not if you're on a different subnet and the routers drop
misaddressed packets.  That's been a standard facility from router
vendors for over a decade.

>Not every site filters incoming traffic. Sad but true. Security
>systems should be robust in depth.

So that's a reason to exclude another defense method???

>fsirand is necessary.

Not *always*, not against *all* threats, no, it isn't.   End of story.


>I'm really sick of arguing about this. So far as I can tell, the
>decision on this has already been made. fsirand is part of what NetBSD
>does. Lets drop this.

If *you* are going to stop insisting that we shouldn't have both, I'm
happy to drop it.

Perry, please show me where I've ever said or suggested that fsirand
be dropped, or indeed be anything other than strengthened?  I don't
want fsirand dropped.  Have I ever said or implied I did?

As far as I can tell, you've been pushing the viewpoint that fsirand
is *necessary* and, implicitly, sufficient NFS security in *all*
environments.    That's just not the case.  In some environments,
an (optional) enforcement of /etc/exports ACLs on NFS RPC requests
would be more effective.

Yet you've insisted, forcefully, that such an option should *not* be
considered.  I've never claimed that it's a panacea, but in *some*
environments it *is* more useful than fsirand, and so we should
provide it as an option.   I think it's a more useful option
than checking that clients use privileged  ports, but that may just
be local.

Since we already have fsirand, adding such an option would give us
both. I really dont understand your problem with that.