You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Andrew Stitcher (JIRA)" <ji...@apache.org> on 2013/05/17 19:09:16 UTC
[jira] [Commented] (QPID-4854) max-negotiate-time feature breaks
AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13660865#comment-13660865 ]
Andrew Stitcher commented on QPID-4854:
---------------------------------------
The original max-negotiate-time code was never a solution (which is why the original bug remains open) it is just a heuristic that works with the qpid implementation of amqp 0-10 (which is all we supported then).
The real issue with the current code is that there is no semantic object that exists from the point that the low level connection is accepted until the point that the connection is authenticated which is when there is no longer any chance of an unauthenticated DoS. This object is what needs to hold the timeout code not the low-level code which has, as Gordon correctly points out, no idea of the underlying semantics and shouldn't have any idea of it.
The only solution that I can see that can be made to work is to refactor the Connection object creation so that it happens much earlier in the accepting a connection process. However this object is currently created as part of the process of making the codec for the specific protocol and so the refactor is larger than I'd wish.
Any other suggestions welcome.
> max-negotiate-time feature breaks AMQP 1.0
> ------------------------------------------
>
> Key: QPID-4854
> URL: https://issues.apache.org/jira/browse/QPID-4854
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.20, 0.22
> Reporter: Gordon Sim
> Assignee: Andrew Stitcher
> Fix For: Future
>
>
> It has assumptions based on 0-10 (and a particular pattern for 0-10 at that) built into the underlying transport code (which should be protocol agnostic).
> As AMQP 1.0 makes it much simpler and more likely for less synchronous handshaking, the '3 reads' magic doesn't work and causes 1.0 connections to be terminated incorrectly. Either the original solution needs to be reimplemented or it needs to be possible to disable it for use with 1.0.
> See QPID-4021 and QPID-2518.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org