Multithreading the KDC server - a design

[Ken Raeburn]

Something else came up while Sam and I were discussing this, and while 
I was looking over some more stuff:

3.6: Why are TCP requests and UDP requests handled differently?  Sam 
suggested that this design would make a lot of sense if you overlooked 
the fact that we're using non-blocking I/O for the TCP streams.  If 
you're reading the UDP packets always in one thread, I don't see any 
good reason not to read the TCP stream data in the same thread.  
That'll force the serialization needed anyways, if partial messages are 
received.


3.8, step 5: "If 'reply_packet' member of the cache entry is NULL, 
return without any further processing (a concurrent thread is 
processing the request)."

It's possible (though not likely with MIT clients, I think) that the 
same request could've been received from two different source port 
numbers on the client (and maybe, with some NAT setups, two different 
IP addresses), and that the port used to send the first packet is no 
longer listening for replies.  (E.g., send packet, wait for response, 
time out, close socket, repeat with next KDC, get back to first KDC but 
using a new socket and new local port number.)

Also, if two TCP connections come in and send the same data (e.g., 
client tries a second address which happens to also be on the same 
KDC), or a TCP session sends a message that also came in over UDP, I 
don't think it's good to shut down the connection without sending 
anything.  Sending an error doesn't seem right either.

Keep in mind too that even though it may be the same client and same 
KDC talking, stupid sysadmin tricks (broken firewall configuration, 
PMTU discovery problems, etc) could cause the reply to the first port 
or connection not to be seen.  I think only if it's two UDP packets 
with the same source address and port and same destination port and 
address should we really assume that one reply message will suffice.

(There's also the question of making it easy for some attacker to trick 
our KDC into firing UDP packets off at random target destinations, but 
even if we continue to reply to every message that comes in, we'll be 
no worse off in that regard than we are now.  I don't think we need to 
worry about that much.)