qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Date Wed, 26 Jul 2017 08:34:02 GMT
*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 <gary.tully@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message