Kerberos PDU decoder performances

[Emmanuel Lecharny <el...@gmail.com>]

Ok, now that I understand the PDU structure for AS-REQ, I have done a
little perf test on it :
1 000 000 PDU decoded in 38 seconds on my laptop.

Not too bad.

Some possible improvement :
- switch to the LDAP decoder should be possible without a lot of
effort. DER and BER are very closed, and we can modify easily the LDAP
decoder to support DER
- switching to shared-ldap decoder would improve a lot the
performance. For a similar PDU size (less than 255 bytes), and
complexity, we can decode around 200 000 PDUs in shared-ldap (it
depends on which kind of treatment we do with the data, of course).
- there is also one major gain : the current decoder stores the bytes
for each decoded TLV, so for this 240 bytes length PDU,  we are
creating 53 byte array to decoder recursively the TLVs. The total
allocated storage is 1661 bytes long. That means more GC...
- Doing so also allow the PDU to be hand crafted to make the decoder
explode. If, for instance, the first TLV length is 100, we can provide
a TLV which length could be 200000000 bytes length later in the code,
without any problem, but an OOM... As this OOM won't be catched, the
returned error will be a little bit cryptic, I guess.

Emmanuel.

Re: Kerberos PDU decoder performances

[Enrique Rodriguez <en...@gmail.com>]

On 6/15/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> Some possible improvement :
> - switch to the LDAP decoder should be possible without a lot of
> effort. DER and BER are very closed, and we can modify easily the LDAP
> decoder to support DER

I'm 100% behind this.  If you can at least jumpstart the conversion, I
can commit to finishing it.  By jumpstart I'm picturing you might add
DER support and write some examples of codecs so I can see how it
would work.  I could then convert the rest of the codecs and make sure
everything works and do final troubleshooting.  I will be adding
better unit tests, hopefully this weekend, so the timing is good to
make a big change like this.

There are 2 things we'll need for Kerberos that may not have come up in LDAP:

1)  In addition to decoding PDUs there are a couple message objects
that we need the raw undecoded bytes for.  Examples would be the
KdcRequest and the Ticket.  The KdcRequest bytes need to be saved in
the session for later validation of a (keyed) checksum.  The Ticket
bytes are needed to pass undecoded as credentials for cases where
decoding might strip proprietary or unsupported extensions.

2)  As you saw, the EncryptedData structure carries data that requires
decryption/encryption outside of the codecs.  So in addition to codecs
in the filter chain, we'll need "one-shot" codecs for these message
parts, to be used in the handler.  There are ~10 of these in use so
far.

> - switching to shared-ldap decoder would improve a lot the
> performance. For a similar PDU size (less than 255 bytes), and
> complexity, we can decode around 200 000 PDUs in shared-ldap (it
> depends on which kind of treatment we do with the data, of course).

W.r.t. 200 000 do you mean "per second"?  That would be a lot better.

Enrique