[OpenAFS-devel] Stop me before I NAT again...

[Todd M. Lewis]

Mitch Collinsworth wrote:
> Question: what will this do if the client has an intermittent network
> connection.  For example if I'm using a laptop on a wireless network
> and step into the elevator (where I lose my connection when the doors
> close), ride up 6 floors and then step out of the elevator (whereupon
> I regain my connection).  Will the probes that are sent during my brief
> "disconnect" cause fileservers to be marked down?

Yes, but that's happening now every 10 minutes.  We don't want to call 
afs_CheckServers() more frequently than that.  I just did it to test the 
concept.

> Will they be
> immediately marked up when the next probe is sent?

Yes, that's what afs_CheckServers() does.  That's where those 
"fileserver blah.de.blah lost/found it's cookie" messages come from.

> Will this sequence
> of events cause more grief that this or will it be mostly painless due
> to the increased probing frequency?

If done right, only NATed boxes would send out increased traffic, and 
those packets need never make it all the way to the server.  I suggest 
making a separate natkeep-like thread so as not to screw up the 
afs_checkserver thread. (Or perhaps it could be part of afs_checkserver; 
'd'have to look at it again.)

>>It's been on my list (which never shrinks). Ideally you don't need a
>>configure option, just run-time configuration.

I was thinking some people might not care to have the code in their 
client daemons at all if they know they don't intend to run it. 
Run-time config would be necessary either way.  In particular, the user 
need to be able to specify:
* 'on' or 'off'
* the interval between refreshes (shorter than the UDP timeout),
* the initial Time To Live (ttl) for the packets
* ???

Q: Should these be controllable the same way 'fs checks -interval NN' 
works? (Just what 'fs' needs -- more subcommands.)

>> I'm happy to argue merits
>> with people about it if there are people who think I'm nuts.

Didn't mean to imply that.  I meant that I've found myself initially 
enthusiastic about what turned out to be bad ideas before, and I 
wouldn't be surprised if those who understand better than I do how AFS 
and networking in general work have reservations about this suggestion.

>> I'd have to look at code before I can make any code suggestions.

Guess I'll have to write some. :-)

No, seriously, studying afs_CheckServers() to see how it results in 
packets being generated has been a daunting experience.  I thought 
figuring out which servers to toss UDP packets toward would be the hard 
part.  Turns out that's easy.  Getting from there to packets going out 
the back of the box is not at all obvious.  I'll have to study the code 
a few more times before I'm ready to attempt a real natkeep-like 
implementation within OpenAFS.

(And we'll need a name for this, too.  Is "natkeep" okay?)

> In general this sounds like a great idea.  I'm not certain about the
> run-time configuration idea though.  Again, what about mobile clients
> that may pop up behind a NAT one time and on their own IP the next?

They are broken now.  (Well, okay, NAT is broken by design, but the user 
doesn't appreciate the distinction.)  Let's get the client NAT-proof, or 
at least NAT-resistant, then tackle the mobile problem.

> I think we need to decide that either a) it's ok to make this change
> global for all clients, or b) it's not ok, only NAT-bound clients should
> do this, and therefore the client should somehow auto-discover if it's
> NAT-bound dynamically and adjust its behavior accordingly.

A straight-forward way to discover whether you're NATted is to send the 
in and out addresses and ports as the data in a packet to a service 
which returns the same info from the service's perspective.  If the 
ports don't match up, you're NATted.  I don't know of such a service, 
but it should be a breeze to put up.  Would that be an AFS specific 
thing, or is it generally useful to IP clients?

> Then it will
> be safe to let users install the client w/o a sysadmin having to watch
> over their shoulder to make sure they don't screw up.  Or worse, if the
> wrong installation options being chosen means the clients can DOS the cell
> then it's only a matter of time before someone does this malitiously
> rather than accidentally...

At least initially, I'd say 'off' is the better default; turn it on as 
experience indicates it's appropriate.  Whether the client, sysadmin, or 
user makes the call probably depends on how much work you want to put 
into making each of those three smarter.
-- 
    +--------------------------------------------------------------+
   / Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl /
  /            Is a book on voyeurism a peeping tome?            /
+--------------------------------------------------------------+