On 26 July 2017 at 15:38, Robbie Gemmell <[email protected]> wrote:
> On 26 July 2017 at 14:09, Rob Godfrey <[email protected]> wrote: > > On 26 July 2017 at 14:43, Robbie Gemmell <[email protected]> > wrote: > > > >> That essentially summarises some discussion I had with others on this > >> elsewhere late yesterday and was planning to see what you and others > >> thought about it after having a look at the impls. > >> > >> I agree that making a custom mechanism for fragmenting an existing > >> mechanisms content is ugly and probably of little value in the end > >> since you would still need to handle the whole as you say. If the > >> regular mechanism name was offered and it needs >512 byte in a given > >> situation then it obviously wouldnt work if you enforce that limit..so > >> either you couldnt expect it to work anyway, in which case why offer > >> it, or presumably wouldnt enforce the limit. If servers dont offer > >> such mechanism or clients dont select them, which many wont in this > >> case, there isn't an issue for them. > >> > >> To allow proceeding despite the size, we would need to add a toggle to > >> proton-j to control what it will allow to be received for sasl frames, > >> or adjust the default size it will allow, or both. The simplest thing > >> toggle wise would look to be making the existing transport 'remote max > >> frame size' overridable until set by the Open frame arriving and use > >> it to govern this behaviour. > >> > > > > That (configurable initial maximum) sounds sensible to me. Ultimately > > outside of the (in-discussion) CBS mechanism neither side really has much > > influence over the size of the data being exchanged. Out of interest, on > > the sending size does proton already just send large SASL frames if you > > supply it with > 512 bytes of data, or does it error? > > > > -- Rob > > > > It does just send them, yes. > Ah - it's following the the exact opposite of the robustness principle then, nice :) -- Rob > > > > >> > >> Robbie > >> > >> On 26 July 2017 at 09:34, Rob Godfrey <[email protected]> wrote: > >> > *sigh* I always thought 512 was a bit on the low side for this limit > :-( > >> > > >> > For background the original intent of setting MIN-MAX-FRAME-SIZE at > 512 > >> > bytes was to allow AMQP to be used on devices with very limited > >> resources. > >> > Logic(?) then dictated that all frames exchanged prior to a new max > frame > >> > size being agreed need to fit within the known minimum frame size > limit. > >> > In retrospect for SASL this was a mistake, as normally you don't > really > >> > have any choice ab out how big your sasl frames are going to be (the > size > >> > will be determined by the requirements of the mechanism). If (say) we > >> > allowed proton to be more relaxed in the frame sizes it allows (we'd > >> still > >> > want some limit to prevent DoS style attacks) then the worst that > happens > >> > (I think) is that SASL mechanisms that require larger frames will not > >> work > >> > against implementations which enforce the 512 byte limit... but then > such > >> > implementations can't realistically be supporting mechanisms which > >> require > >> > larger exchanges (such as GSSAPI/Kerberos). I don't really see the > value > >> > in inventing a new SASL mechanism for this (allowing fragmentation of > the > >> > responses) as in reality this wouldn't help systems with limited > >> resources > >> > implement the mechanism (they'll still need to assemble the whole > >> response > >> > at some point I imagine). Techniacally this will be spec violating, > but > >> > OTOH without violating the spec you can't implement the mechanism, so > if > >> > you offer the mechanism then you are implicitly saying "I'm not going > to > >> > enforce this rule". > >> > > >> > -- Rob > >> > > >> > On 25 July 2017 at 18:02, Gary Tully <[email protected]> wrote: > >> > > >> >> Hi, > >> >> I have been working through adding SASL GSSAPI (Kerberos) support to > the > >> >> qpid-jms-client[1] and have hit a limit in proton-j > >> >> > >> >> The initial response in the SASL_Init frame can be > 512 which breaks > >> the > >> >> max frame size limitation as frame size negotiation has not completed > >> yet. > >> >> Proton-j will allow the frame to be written but the parse at the > other > >> end > >> >> identifies the size exceeding the limit and errors out. > >> >> > >> >> I see in the AMQP Claims Based Security draft there is some work to > >> >> describe how to SASL within that limitation in the context of a new > >> >> mechanism. > >> >> > >> >> Is it reasonable to relax the check via config to allow the existing > >> gssapi > >> >> mechanism to work. > >> >> > >> >> Of the top of your head, what does proton-c do, maybe it never sends > an > >> >> initial response in the sasl_init? > >> >> > >> >> thanks in advance for any read of this :-) > >> >> > >> >> gary. > >> >> > >> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-303 > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
