directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Kerberos codec and other codec, and a bit of 'state of the nation'
Date Sat, 27 Nov 2010 14:15:55 GMT
On 11/27/10 2:32 PM, Kiran Ayyagari wrote:
> Atm I'm reviewing what we have done, and try to clean up the thing, as the
>> code we wrote at the end is different from what we started with, as we
>> improved the process a lot. There are a few points I think worth discussing.
>> - The loggers. Currently, we use a per class logger. I think it's
>> inaccurate, as we won't be able to group all the logs for a specific
>> protocol in one single logger. Of course, if we want to disable the codec
>> logs, we can always do that by filtering on the package, but I think we
>> could also decide to generate all the logs into one single logger, called
>> "CODEC". wdyt ?
> IMO this should be the way to go, how about KRB-CODEC

That won't work, as the classes are shared with the LDAP codec and all 
the controls codec...

>> - The tests. Right now, testing that the decoder is correct is a burden. We
>> discussed a lot about it, and we didn't found a convenient case to test all
>> the possible wrong PDU we should reject. We need a tool for that, but I
>> doubt a tool can be written in less than a few weeks. Thoughts ?
> rather than that am thinking that let us invest that time on writing a
> krb client and we can test it against ours and MIT krb server and
> compare the results and apply fixes if needed
That's something we have to do anyway, but it won't help us against hand 
crafted PDU. One thing I'm thinking about is the PDU where teh Length 
part is huge, but with no data coming. In fact, the main problem will be 
to protect the server against a DDOS, so we must limit the PDU size (and 
Kerberos PDU are smaller than LDAP PDU, so we must have a different 
setting), and also limit the time we keep an undecoded PDU (someone 
might draft a big PDU, but send it byte by byte, with a delay between 
each byte). A solution would be to keep a timestamp when we receive the 
first TLV, and if the end of the PDU is not received in a reasonable 
delay, then we discard the full PDU.

Emmanuel L├ęcharny

View raw message