Multithreading the KDC server - a design

[Ken Raeburn]

On Apr 9, 2005, at 01:15, Rahul Srinivas wrote:
> 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.

If reading 1M out of kernel buffers into the KDC's address space is 
going to cause noticeable delays, enough to be a problem, then we 
should look carefully at updating things.  But for now, I think it'll 
be okay.

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

draft-ietf-krb-wg-kerberos-clarifications-07 section 3.1.2: "If a KDC 
receives a request identical to one it has recently successfully 
processed, the KDC MUST respond with a KRB_AS_REP message rather than a 
replay error."  (The description does kind of assume serial processing 
of requests, but I don't think we should use the loophole that the 
first request hasn't yet been successfully processed and therefore a 
replay error for the second one is okay.)

Also, the MIT library code does generate the message once and then 
tries sending via UDP (with retransmissions) and TCP until it gets a 
response, so this is likely to come up in practice.

Ken