Multithreading the KDC server - a design

[Rahul Srinivas]

Hi Ken,

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

That is a good suggestion. I will do that for TCP as well. The reason
for
handling TCP packets differently was that the maximum TCP buffer size is
1MB
while the maximum UDP buffer size is 4KB. So, large TCP segments could
delay the main thread from coming back to 'select' the ports.

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

I had not thought of such scenaios. The design does change the way the
KDC deals with replays. I will change the design to correct this. But, I
have a question about the lookaside cache. Though the lookaside cache
makes things easy for KDC clients, doesn't it violate the RFC which says
that authenticators 'will' be rejected if replayed ? Having a duplicate
UDP
packet delivered at the server is one thing, but explicitly re-sending
requests
with same authenticators ... shouldn't this be prevented ?

Regards,

-Rahul S.