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. > >> >> 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]
