On Tue, Nov 16, 2010 at 5:14 AM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Tue, Nov 16, 2010 at 4:48 AM, Emmanuel Lecharny <elecharny@apache.org> wrote:
> Hi,
> the way we decode the Kerberos is not good, as I said in a previous mail. We
> can't process a fragmented PDU.
> I suggested that we manipulate the State in order to pick the right
> container, but this is really too complex, and brittle.
> I have one other solution :
> pre-read the PDU size. As we are using TLV, the Length once read will let us
> read the Value as an opaque element, then once completely read, we will be
> able to process the PDU
> This seems a minimal cost to get the codec working with the grammars we have
> defined.
> thoughts ?
sounds good to me, OTOH what are the disadvantages of reading whole
PDU and processing it?

Increases potentials for large PDU attacks to overflow memory but we can mitigate that with limits on the PDU size we're willing to process.

Otherwise it sounds like a good idea if the grammar in the current situation is getting too cumbersome to deal with. Really KRB PDU sizes are not that large AFAIK so this is not that bad. It does not follow with zero copy principles of building good performing network servers but for now we need to go this route until we find a better way later.

Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu