On Tue, Nov 16, 2010 at 5:14 AM, Kiran Ayyagari <[email protected]>wrote:
> On Tue, Nov 16, 2010 at 4:48 AM, Emmanuel Lecharny <[email protected]> > 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
